Lenny Domnitser wrote:
> * If the IDs of two entries from different feeds are the same and the
> data is different, this can be one of two things: a DoS attack or an
> update to the entry. In either case, show the updated version without
> wiping out the old one.
What if the two entries are both found in the same feed but have
different source feeds identified in their atom:source elements? These two
entries are clearly *from* different feeds, yet they might be found in a
single feed.
The problem here is, of course, that 4.1.1 of the specification
says: "atom:feed elements MUST NOT contain atom:entry elements with
identical atom:id values." Thus, one of the two entries should not have been
written to the feed. Which of the two entries should NOT have been written?
Note: There is no good answer here. You might have an attack or you might
just have a "secondary" copied entry that is being inserted. In any case,
there isn't enough info to know which to accept and which to reject. So...
I believe that the prohibition against multiple entries with
identical IDs should be relaxed to say:
"atom:feed elements MUST NOT contain atom:entry elements with
identical atom:id values unless each such entry contains an atom:source
element which is different from that of any of the other entries with which
the entry shares identical atom:id values. Two or more atom:source elements
MUST only be considered different if they each contain an atom:link element
with a rel value of "self" which identifies different feed URIs."
Yes, I know that language is very tortured... In any case, you can't
build a synthetic feed generator which is robust against attack unless the
proposed relaxation is supported. ID's must be feed specific where feed is
defined as the source feed -- not the feed in which the entry is found.
bob wyman
