I'm not really happy with this. Conceptually, it seems to replace an ID for an entry with a pair (ID,feed). As IDs are URIs/IRIs (remember what they expand to), that doesn't make sense. What guarantee do we have that two feeds will be different? (yes, these days, we get feeds over http, but there are other ways to get feeds, where things may not be that easy).
If we don't have a solution for the malicious case, and we think we need one, we should work on some security stuff.
If we think that accidential ID duplication is a problem, then let's look at how we can improve the explanation. After that, there may still be an occasional accident, but the spec should be worded to catch that, not to provide a loophole.
If we have to allow duplicate IDs, I'd rather prefer we do it without all this feed/source/... stuff: I.e. if you are an aggregator and can't manage to do duplicate elimination, you can just delegate the problem to the next place in the feeding chain.
Regards, Martin.
At 06:03 05/05/03, Antone Roundy wrote:
>
>http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource2
>
>This is what I thought had been suggested. Hopefully I didn't err in putting two changes into one proposal, but the first seemed a little odd without the acknowledgment provided by the second.
>
>Coming up with wording for the first change that makes the point without getting horrendously verbose and convoluted isn't as easy as I thought!
>
>Antone
>
>== Abstract ==
>
>Allow multiple entries with the same ID in a feed document if their source feeds are demonstrably different. Adjust the wording regarding the uniquess of atom:id values to reflect the recognition that publishers might duplicate each others' atom:ids, even if accidentally.
>
>== Status ==
>
>Proposed.
>
>== Rationale ==
>
>The current spec does not allow multiple entries in a feed document with the same ID. This can cause problems if, whether accidentally or maliciously, different feeds use the same IDs for their entries. This proposal alleviates this problem by allowing a feed document to contain multiple entries with the same ID as long as their source feed's ID is different, enabling consumers to determine that they are not duplicates of the same entry.
>
>The current spec requires atom:id values to be minted in a way that "assures uniqueness". This is impossible, since no one can prevent others from, whether accidentally or maliciously, duplicating one's ids. This proposal rewords that requirement to reflect recognition of this fact.
>
>== Proposal ==
>
>In relation to atompub-format-08:
>
>In section 4.1.1, replace:
>
> atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values
>
>With:
>
> atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values unless the values of the atom:id elements for each of their source feeds is different. If the value of atom:id for the source feed cannot be determined by one of the two following rules, then the value of atom:id for the atom:entry MUST be unique within its enclosing atom:feed element.
>
> * If an atom:entry element contains an atom:source element, and that element contains an atom:id element, use its value.
> * If an atom:entry does not contain an atom:source element, and the atom:entry element's parent atom:feed element contains an atom:id element, use its value.
>
>In 4.2.7, replace:
>
> The content of an atom:id element MUST be created in a way that assures uniqueness.
>
>With:
>
> The content of an atom:id element MUST be created in a way that, as nearly as possible, assures uniqueness. An atom:id value that has been used with one entry in a particular feed MUST NOT ever be used with a different entry in the same feed, and SHOULD NOT ever be used with an entry in another feed.
>
>== Impacts ==
>
>Allows duplication ids within feeds, so atom:source/atom:id or atom:feed/atom:id must be examined when looking for duplicates.
>
