Subject: Feed, know thyself?

From: Danny Ayers <[email-masked]>
Date: Fri, 14 Jan 2005 21:37:46 +0100

I was just in the middle of putting the world to rights regarding feed
discovery/subscription from browsers [1] when something occurred to
me. Correct me if I'm wrong, but isn't one of the solutions for this
to serve the feed with the Atom mime type, which will trigger an
appropriate handler in the browser?

If I remember correctly from previous discussions, there is a little
snag with most browsers only passing the data, not the source URI.
Thing is, with the spec as it currently stands, we don't have a link
from the feed that can be guarenteed to point to the feed URI itself.
Having the handler go back to a HTML page to do autodiscovery seems a
little roundabout. Relevant spec bit pasted below.

Thoughts?

Cheers,
Danny.

4.2.2  "atom:link" Element

   The "atom:link" element is a Link construct that conveys a URI
   associated with the feed.  The nature of the relationship is
   determined by the construct's rel attribute.

   atom:head elements MUST contain at least one atom:link element with a
   rel attribute value of "alternate".

   atom:head elements MUST NOT contain more than one atom:link element
   with a rel attribute value of "alternate" that has the same type
   attribute value.

[1] http://danja.typepad.com/uncooked/2005/01/life_the_univer.html

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Fri, 14 Jan 2005 15:52:58 -0500

> from the feed that can be guarenteed to point to the feed URI itself.

That's not a very robust way to accomplish the goal. People tend to use 
"cp" without thinking about these things. The browser vendors will deal 
with it eventually (Safari 2.0 does...) and/or we'll get a playlist type 
thing. That's the only way it will work reliably.

Robert Sayre

---

From: "John Panzer" <[email-masked]>
Date: Fri, 14 Jan 2005 12:58:59 -0800

Hmmm.  Not looking at the spec, but at the feeds we're currently 
producting for AOL Journals, our feeds have <link rel="service.feed" 
...> essentially pointing to themselves, which I yesterday thought was 
redundant but perhaps is actually useful.  Useful enough to be 
mandatory, perhaps?

-John

-- 
John Panzer | Sr Technical Manager, AOL
Blog: http://journals.aol.com/panzerjohn/abstractioneer

---

From: Eric Scheid <[email-masked]>
Date: Sat, 15 Jan 2005 13:17:53 +1100

On 15/1/05 7:37 AM, "Danny Ayers" <[email-masked]> wrote:

> little roundabout.

+1 to having a self-referential link to the preferred URL for subscription.
Not only does it help with the "browser passes content only to handler
specified by mime-type" situation, but it also helps to avoid
accidental/nutty aliases from propogating (eg. http://example.com/feed.atom
vs http://203.xxx.xxx.xxx/feed.atom, where both actually point to the same
feed)

We need an appropriate @rel value (to put into the spec and the registry).

Prior art suggests "bookmark".

e.

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 14 Jan 2005 22:35:10 -0500

> redundant but perhaps is actually useful.  Useful enough to be

Yes, being mandatory would be helpful:

    http://bitworking.org/news/Atom_Auto_Sub_How_To

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Danny Ayers <[email-masked]>
Date: Sat, 15 Jan 2005 10:05:19 +0100

On Fri, 14 Jan 2005 15:52:58 -0500, Robert Sayre <[email-masked]> wrote:
> "cp" without thinking about these things. 

Do they? I've done HTTP redirects often enough (had to yesterday,
coincidentally) but don't recall ever having to do anything that would
break a source reference.

The browser vendors will deal
> thing. That's the only way it will work reliably.

Maybe, but right now the leading browser doesn't deal with it, it's
not clear they even have any motivation to.

Seems to me like making a source-URI reference a SHOULD would help
solve an immediate problem, irrespective of the hypothetical problem
of copying.

Is a Pace needed? (Where is the time???)

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Sat, 15 Jan 2005 08:37:47 -0800

> solve an immediate problem, irrespective of the hypothetical problem

I see no downside.  There are going to be scenarios where it's not 
reliable, but there are going to be lots where it's useful.

> Is a Pace needed?

Yes. -Tim

---

From: Danny Ayers <[email-masked]>
Date: Sat, 15 Jan 2005 19:53:02 +0100

> reliable, but there are going to be lots where it's useful.

[expletive deleted]! 
Ok, I'll try and sort it tomorrow. I'm sure extensibility is in good hands...

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Sat, 15 Jan 2005 20:06:40 +0100

On Sat, 15 Jan 2005 13:59:12 -0500, Robert Sayre <[email-masked]> wrote:
> Tim Bray wrote:
> Well, it does make it easy for me to put entries in your feed.

...and to confirm they weren't there to start with.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Sat, 15 Jan 2005 13:59:12 -0500

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 15 Jan 2005 14:16:37 -0500

> ...and to confirm they weren't there to start with.

How so? Do I go back and confirm with the server? Why did I downoad a 
whole feed to do that? Maybe it's changed. What does it mean if I 
retrieve at a feed a URI and it's not the same one?

This creates a unique situation for users, where they can download a 
feed, but possibly not subscribe to it.

It's also a whole new class of bugs, and I'm having trouble thinking of 
all of them.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Sat, 15 Jan 2005 21:03:21 +0100

On Sat, 15 Jan 2005 14:16:37 -0500, Robert Sayre <[email-masked]> wrote:

> whole feed to do that? 

You may want to check a mirror/proxy. 

Maybe it's changed. What does it mean if I
> retrieve at a feed a URI and it's not the same one?

You know the original data is either out-of-date or untrustworthy.

> feed, but possibly not subscribe to it.

Right now there's no way to subscribe from say IE. 

> It's also a whole new class of bugs, and I'm having trouble thinking of

No, this is already possible with RSS 1.0. If you build new
applications, then you may start to introduce new bugs.

There may be reasons why this isn't a good idea, but these issues all
still seem very hypothetical, whereas the potential benefit is fairly
tangible.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Sat, 15 Jan 2005 15:15:46 -0500

> Right now there's no way to subscribe from say IE. 

That's not the point. That does not result in a support call to the 
aggregator vendor, because it's IE's problem.

Right now, once the user gets the URI to the aggregator somehow, things 
tend to work. This proposal introduces a situation where the feed can 
show up in the aggregator and appear broken. As such, it would be 
foolish to implement this in an aggregator.

> No, this is already possible with RSS 1.0.

Really? How is it done?

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 15 Jan 2005 15:21:23 -0500

Danny Ayers wrote:
> we don't have a link from the feed that can be guarenteed to point
> to the feed URI itself.
	If these links were in the feed's <head/> element it would make life
easier for us at PubSub.com. We currently insert a link pointing to the
source feed into every entry that we insert into one of our synthetic feeds.
We do this for both RSS and Atom. 
	It should be noted, however, that there are potentially two "source"
feed links that are interesting. When an aggregator is in use, you could
have the "source" link that is reported by the feed itself and you could
have a different source URI which would be the URI at which the feed was
actually discovered. At PubSub.com, we'll probably want to report both of
these -- particularly if they differ.
	The difference between these two URI's can, of course, have a number
of different causes. These include: 1) Typographical error by the feed owner
when inserting the source URI. 2) The feed might have been copied to a
location other then the location it was intended to have when first created
and when the source URI was written. 3) Feeds might be stored in locations
that have multiple equivalent names. For instance, the feed might have a URI
whose "host" field is a domain name, yet, the feed was retrieved using an IP
address as the "host" (i.e. pubsub.com vs "209.11.36.154" -- both
equivelant.) The same sort of multiple naming can result from symlinks,
multi-hosting servers, etc. 

		bob wyman

---

From: David Powell <[email-masked]>
Date: Sat, 15 Jan 2005 20:28:48 +0000

> Robert Sayre

Would something like this fix it?

It might require the feed to be fetched twice, but it is only at
subscription time.

BTW - Is it really impossible to obtain the location that a feed was
fetched from on IE/Win?  IE manages it for CDF files, and I believe
that Acrobat files are streamed by Acrobat when you click on link.

11.1  Verifying the Authenticity of Self Links

  If an atom:head element contains a Link construct where the "rel"
  attribute is "self", software processing the document SHOULD NOT
  assume that the URI specified by the "href" attribute is genuine
  unless the software can confirm that the URI matches the URI that
  the document was obtained from.

  Software that cannot verify the authenticity of the self link,
  SHOULD refetch the Atom document using the self link.

-- 
Dave

---

From: Danny Ayers <[email-masked]>
Date: Sat, 15 Jan 2005 21:30:14 +0100

> > No, this is already possible with RSS 1.0.

My apologies, the RSS 1.0 spec actually says the rss:channel resource is
"...either the URL of the homepage being described or a URL where the
RSS file can be found."

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Sat, 15 Jan 2005 20:52:39 +0000

> 11.1  Verifying the Authenticity of Self Links

Can someone explain the attack model here? The worst that I can see 
happening is that when you try to subscribe to my feed, you end up 
subscribed to someone else's. How does this harm anyone but me?

Graham

---

From: David Powell <[email-masked]>
Date: Sun, 16 Jan 2005 09:38:09 +0000

> subscribed to someone else's. How does this harm anyone but me?

Feed id's are optional, so software is likely to use the feed location
to identify feeds. So if a user subscribes to a feed with a faked
"self" link, then they will see the initial entries of the faked
document, merged with future entries from the real feed, which could
be used to misrepresent the author of the real feed.

It probably isn't a significant attack. If a user is vulnerable to
subscribing to a fake feed, then redirecting the user to a genuine
feed is the nicest thing the attacker could do.

-- 
Dave

---

From: Graham <[email-masked]>
Date: Sun, 16 Jan 2005 16:25:40 +0000

> be used to misrepresent the author of the real feed.

The user would be trying to subscribe to my feed though, so it's 
equally likely they'll think I wrote the other person's entries. It's 
nothing you can't do with a HTTP redirect or a spoofed link. In any 
case I'd expect the aggregator to discard the content of the downloaded 
file and only use content downloaded from the "self" link. I don't know 
how other aggregators work, but in Shrook at least I'd have to make a 
deliberate effort to incorporate the contents of the file before 
switching to the linked feed.

Graham

---

From: "Roger B." <[email-masked]>
Date: Mon, 17 Jan 2005 00:08:44 -0600

Danny: Works for me, at least in the sense that I have no problem with
it while wearing either of my blogging or aggregating hats. I would
like to see some of the objections fleshed out a bit, though, just in
case we're overlooking something significant.

--
Roger Benningfield