Re: PaceFeedIdOrSelf
On 10 May 2005, at 04:23, Antone Roundy wrote: On Monday, May 9, 2005, at 07:52 PM, Eric Scheid wrote: rel=self is in no way a substitute for an identifier Why not? the uri can change. Yes, I acknowledged that a little after why not?. So we have a tradeoff--greater permanence vs. greater resistance to spoofing. In my opinion, protection against spoofing is more valuable, in part because I expect most feed URIs to be stable enough that their changing won't be a significant issue. Also because things like the volume of SPAM that gets sent to me convince me that people WILL exploit atom:id's spoofability to DOS others' entries. I'm open to experience and reasoning to the contrary, but at this point, that's my position. I am starting agree a little hesitantly with that position. For either a feed or an entry there has to be a url that is used to DELETE, PUT, or GET it. These actions being available automatically give clients a handle on the identity of the resource. If the id is just a string to be shoved around with no means of verifying it in this way, making it possible to be spoofed, then all trust in it will vanish and inevitably the role of identity will go to whatever enables actions such as DELETE, PUT and GET. Now perhaps in a p2p world it makes sense to GET a url such as tag:example.org,2003:3.2397 and so that our language is just being open to new protocols. (Can a P2P network allows PUTs and DELETE on such a url?) I say I am agreeing hesitantly, because the idea of having an id that would allow one to move one's feed or entry from one server to another seems very appealing. But perhaps there will be other methods of noting such a move that will be more effective. One such way would be for the old moved url to send http redirects to the new one. One could also choose one's blog service provider by asking for a contract where they agree to provide such a redirect on all one's entries in case one wishes to move. Henry
Re: PaceFeedIdOrSelf
On 10 May 2005, at 2:12 am, Antone Roundy wrote: Why not? Because: a) It's not possible to compare an atom:id with a rel=self link. It's perfectly possible for the URI in atom:id to be the same as the rel=self in a different feed (unlikely, but possible). It's also possible for the same feed to switch from having an atom:id with one value, to having a rel=self with the a different value. b) rel=self can change c) rel=self offers no guarantee of uniqueness Unless you can explain how multiple different feeds can be obtained via one URI As I explained on a thread last week, rel=self doesn't necessarily correspond with the address the feed is being served from. Stop making this mistake. Graham
Re: PaceFeedIdOrSelf
On 10 May 2005, at 2:42 pm, Antone Roundy wrote: Both the proposed text and the text that made it in say that the URI (or IRI) identifies or SHOULD identify the feed. The proposal says that the feed SHOULD be available from that xRI. OK, fair enough. But the other reasons I gave are far more important. Was not self added largely/primarily to enable feed readers that didn't get the information about the IRI from which a feed was retrieved to subscribe to it? Did we not discuss standard behavior when obtaining a feed from a different IRI being automatically switching to the self value when accessing it in the future? See http://www.imc.org/atom-syntax/mail-archive/msg12176.html for example. The model was that the browser downloaded the file, and the OS sent a system event to the feed reader asking it to open the file. If I received such a system event, I'd look for the rel=self in the file and subscribe to that address. This all works without looking at self in feeds that are already subscribed to, which would be entirely separate functionality and (apart from that message) hasn't been discussed on the list, as far as I remember. Graham
Re: PaceFeedIdOrSelf
On 10/5/05 12:50 AM, Antone Roundy [EMAIL PROTECTED] wrote: I didn't change the Pace, since such a change could conceivably change the opinions of people who've expressed an opinion on it already. But I would be interested to know whether people think this would be an improvement, make it worse, or if either is just as well. +1, an improvement e.
Re: PaceFeedIdOrSelf
On Monday, May 9, 2005, at 05:05 PM, Graham wrote: On 4 Apr 2005, at 6:59 pm, Antone Roundy wrote: And add this bullet point: * atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of self. rel=self is in no way a substitute for an identifier Why not? Unless you can explain how multiple different feeds can be obtained via one URI (other than content negotiation to determine the format of the feed or some ridiculous abuse of standards), I disagree completely. @rel=self does precisely identify a feed--the feed pointed to by @href--and while it may be less permanent than atom:id in some cases, it should be sufficiently stable in most cases, and is less spoofable than atom:id, which in my book makes it a better identifier.
Re: PaceFeedIdOrSelf
On Tue, May 10, 2005 at 12:05:22AM +0100, Graham wrote: rel=self is in no way a substitute for an identifier and shouldn't Has anyone considered merging these into one (required) element? The ID can be a URI. The URI need not be resolvable. If the URI is a URL, it SHOULD (MUST?) point to the feed's location. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: PaceFeedIdOrSelf
On 10/5/05 11:12 AM, Antone Roundy [EMAIL PROTECTED] wrote: rel=self is in no way a substitute for an identifier Why not? the uri can change. e.
Re: PaceFeedIdOrSelf
On Tue, May 10, 2005 at 11:52:55AM +1000, Eric Scheid wrote: Why not? the uri can change. URIs don't change; People change them.[1] But yah, things are never that simple. Consequently, ignore my other e-mail in this thread. (And sorry if this is all a re-hash.) David [1] http://www.w3.org/Provider/Style/URI.html -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: PaceFeedIdOrSelf
On 10/5/05 11:36 AM, David Nesting [EMAIL PROTECTED] wrote: rel=self is in no way a substitute for an identifier and shouldn't Has anyone considered merging these into one (required) element? The ID can be a URI. The URI need not be resolvable. If the URI is a URL, it SHOULD (MUST?) point to the feed's location. in the spec the atom:id *is* a URI. introducing SHOULD/MUST point to the feed's location would put pressure on the value of atom:id being changed if the feed is re-located (eg. to FeedBurner). Not a good thing. e.
Re: PaceFeedIdOrSelf
+1 From prior discussion, people have indicated that they want *something* that they can use to track feeds identity, and the consensus seemed to be that id and/or self was more appropriate than link. - Sam Ruby
Re: PaceFeedIdOrSelf
+1 At 02:59 05/04/05, Antone Roundy wrote: http://www.intertwingly.net/wiki/pie/PaceFeedIdOrSelf
Re: PaceFeedIdOrSelf
Antone Roundy wrote: ... Proposal In section 4.1.1 of atompub-format-06, change this: * atom:feed elements MUST contain at least one atom:link element with a relation of alternate. To this: * atom:feed elements SHOULD contain at least one atom:link element with a relation of alternate. +1 (I just checked my two test feeds; one of which doesn't have an alternate version so currently I have to lie). And add this bullet point: * atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of self. Fine with me as well. ... Best regards, Julian
