Re: PaceOriginalAttribute
-1 An entry only needs one identifier. The way to solve this problem (if it needs solving) is allowing duplicate ids under some or all circumstances. Graham
Re: PaceOriginalAttribute
On 5/10/05, Graham [EMAIL PROTECTED] wrote: On 11 May 2005, at 1:22 am, Robert Sayre wrote: Hmm. I'd be curious to hear what you think the problem is. Every system I can think of that does forwarding or versioning assigns multiple identifiers. Perhaps you have an example system in mind? atompub-format-08: When an Atom document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change. No, I mean a deployed system. Robert Sayre
Re: PaceOriginalAttribute
Tim Bray wrote: +1 I'm not 100% convinced it solves the problems Rob says it does, but it seems cheap, lightweight, and unlikely to cause any harm. -Tim I'm growing increasingly comfortable with the concept of allowing redistributors to assign new ids as long as they track the original (i.e.: not immediate predecessor!) entry. That being said, I have two things I want to think more about w.r.t. how this Pace is currently worded. (Note: the first is actually only a nit concerning the current draft, not the Pace itself): 1) MAY be preserved I would prefer if this were recast not so much as an RFC 2119 interoperability statement, but rather as a definitional one. original attributes in atom:source elements are used to indicate... Something along those lines. 2) Atom feeds MUST NOT contain duplicate atom:id values How did that get in there? Depending on how you read it, this Pace is incompatible with PaceAllowDuplicateIDs, implying that Tim's +1 above can be construed as voting against a Pace he authored! Whether or not the work group comes to consensus about allowing multiple entries to share the same ID in a feed, it still is true that entries may change over time. Perhaps atom:source elements could also define an @updated attribute. As atom:updated is a required element for atom:entry, it would not be an unreasonable burden to require @updated attributes on atom:source elements. - Sam Ruby
Re: PaceOriginalAttribute
On Thursday, May 5, 2005, at 05:21 PM, Robert Sayre wrote: On 5/5/05, Antone Roundy [EMAIL PROTECTED] wrote: Yeah, they think they are, or at least claim to think so. But isn't that the same thing that is stated if you see the following in two feeds? feed idbar:bar/id entry idfoo:bar/id source idfoo:foo/id /source titleI may be an imposter/title /title /feed This says that this feed is (or at least claims it is) forwarding the entry with the id foo:bar from the feed foo:foo. OK, now let's say you're subscribed to imposter in PubSub. feed idbar:bar/id entry idquux:quux1/id source orginal=foo:bar idfoo:foo/id /source titleI may be an imposter/title /entry entry idquux:quux2/id source orginal=foo:bar idbaz:baz/id /source titleI may be an imposter/title /entry /feed Sorry, I don't understand the point of this example. I read it as saying that these two entries from different feeds claimed the same id. I don't know whether they really are the same entry, or whether one or both of their original ids were minted erroneously (accidentally duplicating another entry's id) or maliciously (attempting to DOS someone else's entry). I can't see any way of resolving that question that I wouldn't have if PubSub had given me this instead: feed idbar:bar/id entry idfoo:bar/id source idfoo:foo/id /source titleI may be an imposter/title /entry entry idfoo:bar/id source idbaz:baz/id /source titleI may be an imposter/title /entry /feed
PaceOriginalAttribute
-1. I don't see that this solves any problem. It may help people avoid accidentally generating invalid feeds (if we stick to not to allowing duplication of atom:id within a feed), but it does it by simply shunting the issue off into a different element which doesn't have duplication constraints. It doesn't address the DOS problem--neither accidental nor intentional. And it doesn't make it any easier to determine whether or not entries in different feeds with the same atom:id are really the same entry or not. In fact, it just complicates the task by requiring the inspection of two elements instead of one.
Re: PaceOriginalAttribute
On 5/5/05, Antone Roundy [EMAIL PROTECTED] wrote: -1. I don't see that this solves any problem. I suggest you reread it. Your analysis is deeply flawed. It may help people avoid accidentally generating invalid feeds (if we stick to not to allowing duplication of atom:id within a feed), but it does it by simply shunting the issue off into a different element which doesn't have duplication constraints. Incorrect. Think harder about what PubSub services do. They take an entry, and munge it (people like that). They move the feed data to atom:source, and probably add their own extension elements to it. I think they are forwarding a message. My proposal preserves the identity of the original message, while requiring the service to mint an identifier for its forwarded message. It doesn't address the DOS problem--neither accidental nor intentional. Oh yes it does. Each entry's provenance is documented. The data format accurately states that the intermediary has munged the original entry. And it doesn't make it any easier to determine whether or not entries in different feeds with the same atom:id are really the same entry or not. In fact, it just complicates the task by requiring the inspection of two elements instead of one. Incorrect. What it does is explicitly state that two different feeds think they are fowarding the same entry. Robert Sayre
Re: PaceOriginalAttribute
On Thursday, May 5, 2005, at 10:14 AM, Robert Sayre wrote: On 5/5/05, Antone Roundy [EMAIL PROTECTED] wrote: It may help people avoid accidentally generating invalid feeds (if we stick to not to allowing duplication of atom:id within a feed), but it does it by simply shunting the issue off into a different element which doesn't have duplication constraints. Incorrect. Think harder about what PubSub services do. They take an entry, and munge it (people like that). They move the feed data to atom:source, and probably add their own extension elements to it. I think they are forwarding a message. My proposal preserves the identity of the original message, while requiring the service to mint an identifier for its forwarded message. Okay, the forwarded message has it's own all-in-one-element identifier. This sounds useful...except that someone may accidentally or intentionally duplicate that identifier too. It doesn't address the DOS problem--neither accidental nor intentional. Oh yes it does. Each entry's provenance is documented. The data format accurately states that the intermediary has munged the original entry. Maybe I am missing something, but if so...well, by definition, I'm not seeing it. Let's look at an example. Say your aggregator sees these in different feeds: feed idfoo:foo/id entry idfoo:bar/id titleI'm the real thing/title /entry /feed feed idbar:bar/id entry idbar:foo/id source idfoo:foo/id originalfoo:bar/original /source titleI may be an imposter/title /title /feed Do you display one or both? How would your decision making process differ from if you were to see the following in the second case? feed idbar:bar/id entry idfoo:bar/id source idfoo:foo/id /source titleI may be an imposter/title /title /feed And what if we added a third case? feed idqwerty:bar/id entry idbar:foo/id source idfoo:foo/id originalfoo:bar/original /source titleI'm definitely an imposter/title /title /feed And it doesn't make it any easier to determine whether or not entries in different feeds with the same atom:id are really the same entry or not. In fact, it just complicates the task by requiring the inspection of two elements instead of one. Incorrect. What it does is explicitly state that two different feeds think they are fowarding the same entry. Yeah, they think they are, or at least claim to think so. But isn't that the same thing that is stated if you see the following in two feeds? feed idbar:bar/id entry idfoo:bar/id source idfoo:foo/id /source titleI may be an imposter/title /title /feed This says that this feed is (or at least claims it is) forwarding the entry with the id foo:bar from the feed foo:foo. I am honestly trying to see more in this, but as yet, I don't.
PaceOriginalAttribute
+1 I'm not 100% convinced it solves the problems Rob says it does, but it seems cheap, lightweight, and unlikely to cause any harm. -Tim
PaceOriginalAttribute (was: PaceDuplicateIDWithSource2)
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.
