On Mon, Jun 7, 2010 at 9:08 AM, Martin Atkins <[email protected]> wrote: > > I think we need an unambiguous way to determine whether a particular hub for > a particular resource is for whole-document update notifications or whether > it's capable of format-specific delta notifications. That way subscribers > will know what to expect before the subscribe and find that they aren't > getting the kind of notification they wanted. > > Here's a strawman: > > If the hub is published in a Link: header, then the hub handles > whole-document updates agnostic to the type of the body. > > Otherwise, the hub is declared inside the entity body in a format-specific > way. In this case, the resource format and the notification format are > defined by whatever specification defined how to find the hub URL. > > This is consistent with the capabilities we'd expect consumers of this > information to have anyway; you can't parse the atom:link in Atom/RSS or the > "hubs" property in my JSON proposal without having support for those > specific payload formats, but that's okay because you wouldn't have been > able to parse the update notifications anyway.
Generally I agree with this approach. The needs of a self-describing document/payload are different than those of a document/payload that requires the headers for correct interpretation. The same applies to HTML and hAtom, where the hub link would be in the html <head> and the headers are mostly irrelevant. This also has an effect on security, where the generic HTTP version must preserve the fidelity of the payload's headers, whereas the self-describing document can drop them.
