Re: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues)

[Henry Story <henry.story@xxxxxxxxxxx>]

On 18 May 2005, at 16:41, Antone Roundy wrote:
> On Tuesday, May 17, 2005, at 11:07  PM, Sam Ruby wrote:
>
> > > "If multiple atom:entry elements with the same atom:id value  
> > > appear in an Atom Feed document, they describe the same entry and  
> > > software MUST treat them as such."
> >
> > IIRC, much of this started due to an objection by Bob Wyman that  
> > treating atom:entries from different sources with the same atom:id  
> > as the same entry would cause problems for PubSub.  What ever  
> > happened to that objection?
>
> This is the one remaining issue I'm aware of that I think we really  
> need to resolve.  Until mankind evolves to the point that DOS  
> attacks are no longer attempted, we need to try to protect against  
> them.  A MUST here goes beyond just allowing DOS attacks, it's  
> practically an invitation: copy the target entry, increment  
> atom:updated, change a few critical details, publish. How can an  
> aggregator protect against this without violating the spec?

I supposed the surest way to make it impossible to fake the id, is to  
specify that
by dereferencing the id and doing a GET (whatever the correct method  
of doing that for the
protocol happens to be) one should be able to retrieve the entry.

This I know goes against some of the hopes built into id, but I think  
that it may be that
this is the cost of working in on the web. You just can't escape REST.

> An oddity this language introduces is that if the entries don't  
> appear in the same Atom Feed Document, they apparently don't have  
> to be treated as the same entry, but if they're aggregated  
> together, they do. Going a little further, if I'm subscribed to  
> both original feeds and an aggregation that includes both, then I  
> have potentially four <entry>s with the same id.  Which are the  
> same entry and which aren't?  Only the two in the aggregation,  
> which really aren't, are required to be treated as the same.

I always thought that two entries with the same id should be treated  
as the same entry.
What makes you thing otherwise?

Henry Story
http://bblfish.net/blog/