http://www.intertwingly.net/wiki/pie/PaceOriginalAttribute
On 5/3/05, Martin Duerst <[EMAIL PROTECTED]> wrote:
>
> I'm not really happy with this.
I found Martin's comments (copied in full below) to be accurate. So, I
thought I would try another approach. Comments, suggestions, and
alterations are welcome.
Robert Sayre
== Abstract ==
Preserve the original ID elsewhere, and require republishers to mint
new IDs for *their entries*.
== Status ==
Open
== Rationale ==
Duplicate entry ids in feeds are too easy to create unintentionally,
and the legitimate uses can't be verified as updates unless they come
from the originating feed.
== Proposal ==
Add an 'original' attribute to atom:source and reword as follows:
{{{
If an atom:entry is copied from one feed into another feed, then the
source atom:feed's metadata (all child elements of atom:feed other
than the atom:entry elements) MAY be preserved within the copied
entry by adding an atom:source child element, if it is not already
present in the entry, and including some or all of the source feed's
metadata elements as the atom:source element's children. Such
metadata SHOULD be preserved if the source atom:feed contains any of
the child elements atom:author, atom:contributor, atom:copyright, or
atom:category and those child elements are not present in the source
atom:entry.
4.2.11.1 The 'original' Attribute
Atom entries can be republished and altered by intermediaries, but
Atom feeds MUST NOT contain duplicate atom:id values. The 'original'
attribute contains the entry's initial atom:id value. atom:source
elements MUST have an 'original' attribute.
}}}
== Impacts ==
== Notes ==
----
CategoryProposals
On 5/3/05, Martin Duerst <[EMAIL PROTECTED]> wrote:
>
> 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.
