Content-Type and Schema distinction

[azaroth42]

It is unclear whether the media type (application/ld+json) or the complete value of the Content-Type header must be the same, including the parameters such as charset, and any other media type specific params such as JSON-LD's profile.

If the Topic resource is JSON, it is currently compliant to send completely different JSON from the resource's representation ... but not XML. It would, however, not be compliant to send completely different JSON when the content-type of the resource has a profile parameter that specifies the schema/structure. Or to send unicode if the resource is a different charset.

If the intent is to distribute the actual representation of the resource (fat ping) then section 6 should just require that. Otherwise you have the incompatibility as people try to work around it within the recommended but not mandatory nature of the content being the same, rather than knowing to avoid the specification from the outset.

[azaroth42]

For example, if my topic's content type is application/json, with a representation:

{"id": "/anno1.json", "type": "Annotation", "body": {"value": "This is an annotation!"}, "target": "/index.html"}

I could compliantly send a Notification:

{"id": "/notif1.json", "type": "as:Updated", "actor": {"label": "Rob"}, "object": "/anno1.json"}

Making a thin ping, and wrecking any receiving system that overwrites the Annotation representation with the AS2 Updated activity representation. So unless you require the representation be the same, you haven't achieved the interoperability that Sandro refers to in #84.

[dissolve]

Thats not actually a thin ping as you are providing content. The spec currently doesn't seem to allow thin pings (section 6 says that you MUST provide a body). It says you SHOULD give the full content of the topic url but MAY reduce to a diff. Perhaps this could be better specified to make the intended requirement that you only have these two options, providing anything other than the original or a diff is not allowed.

[sandhawke]

Yeah, it would be nice to clarify that what's being sent is the latest/current representation of the topic resource. I wonder if it's legit/helpful to send Last-Modified and ETag headers, even. It seems logically appropriate. (Although it would make more sense on PUT than POST, but that would be a breaking change, alas.)

[azaroth42]

Yes, per #84, I think adding it in the Intro and the requirement in Section 6 would be valuable. That would close the "same content-type, totally different representation" loophole.

[aaronpk]

The goal of that sentence about content-type was to ensure that hubs deliver the exact payload at the topic URL (fat pings) with the only exceptions made for existing RSS and Atom implementations that have a well-defined "diffing" mechanism. In the future, other diffing mechanisms could be made for new content types, but that would be done as an extension. In #81 I added some language describing the diffing mechanism for Atom and RSS more explicitly.

[julien51]

Thanks @azaroth42 for your contribution. I am in line with the comments above and I think it is a good approach to have the Content-Type header be maintained as identical from the publisher to the subscriber.

Please let us know if you disagree or close that issue if you think it's resolved. Thanks!

[azaroth42]

"corresponding" is a bit weak for "identical" but it's certainly an improvement. I'm okay to close.