On Mon, Oct 19, 2009 at 6:45 AM, Brett Slatkin <[email protected]> wrote:
>> I think there needs to be quite a bit more clarity here. It's clear >> that the hub is required to preserve the atom:id. How about the other >> elements? I would be *very* nervous about a hub that screwed around >> with my atom:updated or other header fields. The current text sounds ... > My response to this would be, if you don't like how a Hub screws with > your content, then don't use that hub to distribute your data. ... > Does that make sense? Is there anything that would clarify this in the > spec? Yeah, it's clear that no spec can enforce ethical behaviour on the part of of hubs. I am left troubled though by the hint-between-the-lines flavour of the 0.2 daft, and I do think it's important to set expectations. Let me propose some text that might help move this discussion along: "The intent of this specification is that hub implementations SHOULD distribute faithful copies of the feeds as provided by the publishers. In some cases hubs may offer to enhance feeds, for example with statistics or translation. However, this specification cannot guarantee the faithfulness or integrity of hub implementations. In particular, the <atom:id> elements of feeds and their entries, preservation of the exact value provided by the publisher is crucial to the integrity of the whole feed ecosystem. Thus, implementations conforming to this specification MUST reproduce the atom:id value exactly as provided. Also, the other elements required by the Atom specification, when provided by the publisher, MUST be present in the version served by the hub." I.e., in English, "We can't guarantee that hubs won't be evil or that they'll provide bit-for-bit copies. But they really shouldn't mess with atom:id and they shouldn't leave out required elements if you provide them." Based on bitter experience with implementors who have fairy-story beliefs that specs can enforce integrity, I think that some explicit warning is called for here. -Tim
