Subject: Re: PaceFeedIdOrSelf

From: Graham <[email-masked]>
Date: Tue, 10 May 2005 00:05:22 +0100

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 and shouldn't  
be presented as such, the way this text does. If the intent is to  
require an identifier, we should just require atom:id.

-1

Graham

---

From: Antone Roundy <[email-masked]>
Date: Mon, 9 May 2005 19:12:59 -0600

On Monday, May 9, 2005, at 05:05  PM, Graham wrote:
> 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.

---

From: David Nesting <[email-masked]>
Date: Mon, 9 May 2005 20:36:15 -0500

> 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-masked] http://fastolfe.net/ ==
 fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882  C41F 3065 57D9 832F AB01

---

From: Eric Scheid <[email-masked]>
Date: Tue, 10 May 2005 11:52:55 +1000

On 10/5/05 11:12 AM, "Antone Roundy" <[email-masked]> wrote:

> Why not?  

the uri can change.

e.

---

From: David Nesting <[email-masked]>
Date: Mon, 9 May 2005 21:00:08 -0500

> 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

---

From: Eric Scheid <[email-masked]>
Date: Tue, 10 May 2005 11:58:46 +1000

> 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.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 9 May 2005 20:23:12 -0600

>>> rel="self" is in no way a substitute for an identifier
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.

---

From: Henry Story <[email-masked]>
Date: Tue, 10 May 2005 09:17:10 +0200

On 10 May 2005, at 04:23, Antone Roundy wrote:
> 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

---

From: Graham <[email-masked]>
Date: Tue, 10 May 2005 10:41:37 +0100

> 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

---

From: Antone Roundy <[email-masked]>
Date: Tue, 10 May 2005 07:42:27 -0600

On Tuesday, May 10, 2005, at 03:41  AM, Graham wrote:
> correspond with the address the feed is being served from. Stop making 
> this mistake.

Let's look at the proposed text from PaceFeedLink, the proposal that 
added "self":

     atom:head elements SHOULD contain one atom:link element with a rel
     attribute value of "self" and SHOULD contain a href attribute with 
an
     absolute URI as its value. This URI SHOULD identify the feed and a
     representation exactly equivalent to the feed SHOULD be available
     through a HTTP GET on the URI. If the link has a "type" attribute, 
its
     value MUST conform to the Atom MIME type as described in Section 10.
     The atom:link element MUST otherwise conform to the definition of a
     Link Construct in Section 3.5.

"This URI SHOULD identify the feed and a representation exactly 
equivalent to the feed SHOULD be available through a HTTP GET on the 
URI."  I don't think the full meaning behind that sentence made it into 
the actual spec.  Here's what's in the spec--in one place:

    3.  The value "self" signifies that the IRI in the value of the href
        attribute identifies a resource equivalent to the containing
        element.

and elsewhere:

    o  atom:feed elements SHOULD contain one atom:link element with a rel
       attribute value of "self".  This URI identifies the feed and a
       representation equivalent to the feed.

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.

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.

---

From: Graham <[email-masked]>
Date: Tue, 10 May 2005 15:08:39 +0100

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.

> 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