Subject: Which is the preferred feed?

From: "Bob Wyman" <[email-masked]>
Date: Mon, 9 May 2005 12:22:23 -0400

Some sites are beginning to serve their feeds via intermediaries like
FeedBurner. They are doing this, in part, to make it easier for them to get
better statistics on their use of the feeds, to off-load bandwidth
requirements, or to take advantage of the advertising insertion and
management programs of the intermediaries.

However, many of today's intermediaries require that program participants
manage a "base" feed on their own sites that is later copied to the
intermediary. This is the approach taken by FeedBurner among others. Whether
or not the intermediaries require that a feed be maintained on the site,
this is usually required if only because there will be people who are
reading the feed and there is no means to notify them, within the feed, that
a new "preferred" source of the feeds is available.

For instance, the Typepad site blog.deeje.tv has two feeds generated by
Typepad:

http://blog.deeje.tv/musings/atom.xml

http://blog.deeje.tv/musings/index.rdf

and it has a feed generated by FeedBurner:

http://feeds.feedburner.com/deeje/musings

Now, my assumption is that the owner of blog.deeje.tv probably would prefer
that people read his FeedBurner feed rather than the TypePad feeds. Evidence
of this can be seen in that the autodiscovery links on the page point to the
FeedBurner feeds. However, while the links currently point to FeedBurner,
they have not always pointed there. At some point in the past, the owner of
this blog decided to prefer the FeedBurner service over Typepad for feed
services. At some point in the future, the same owner might wish to drop the
FeedBurner service in favor of some other service - or perhaps just go back
to Typepad normal feeds.

The problem, of course, is that there is no existing mechanism by which
these changes in preferred feeds can be indicated in either an Atom or RSS
file. The result is that any software system that started reading the Atom
or RDF feeds provided by Typepad before this blog started using FeedBurner
will continue to read the Typepad feeds in the future. Similarly, any system
currently reading the FeedBurner feeds is likely to continue reading those
feeds in the future.

One could argue that feed reading software should, on some regular schedule,
re-scan the "alternate" site for a feed to see if the autodiscovery links
have changed. However, this is a pretty crude solution. It would be much,
much better to allow a feed to contain data that explicitly identifies a
"preferred" alternative source.

Supporting a means to identify a "preferred" alternative source would
greatly improve the mobility of feeds across the network and would avoid the
current problem of potentially pinning someone down to a feed delivery
service simply because of historical accident. If I want to move my feeds
from Typepad to FeedBurner, I should be able to without having to worry
about leaving behind everyone who had ever started reading my Typepad feeds.
Similarly, if I later decide that I want to move off FeedBurner, there
should be a way to point people to the location of my preferred feeds.

bob wyman

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 09 May 2005 18:27:53 +0200

> management programs of the intermediaries.

Sites could also use a HTTP 302 link on their own site that points to 
FeedBurner in the end. When FeedBurner dies or when they no longer have 
desire to use the service, they switch the location of the temporary 
redirect and all is fine.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Antone Roundy <[email-masked]>
Date: Mon, 9 May 2005 10:53:14 -0600

On Monday, May 9, 2005, at 10:27  AM, Anne van Kesteren wrote:
> FeedBurner in the end. When FeedBurner dies or when they no longer 
> have desire to use the service, they switch the location of the 
> temporary redirect and all is fine.

This method would have a few weaknesses:

1) From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10:

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since 
the redirection might be altered on occasion, the client SHOULD 
continue to use the Request-URI for future requests.

302 would result in feed readers (that follow the HTTP spec) continuing 
to hit the publisher's site every time they checked the feed, and then 
going to FeedBurner.

2) Not everyone is going to be able to send a 302.

A 301 would solve the first problem, but replace it with a worse 
one--there would be no way to indicate a new location to people once 
they were subscribed to the FeedBurner feed if it were to move again.

One solution that might work would be to set the "self" link to the 
preferred address.  That wouldn't provide a way to indicate a preferred 
format though, if that's part of what's desired.  If all formats are 
being served from the same address using content negotiation, then that 
doesn't matter.  And if they're being served from different addresses, 
then each feed can point it's "self" link to the preferred address for 
that format.

Are there any issues that couldn't be solved by that method?

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 09 May 2005 19:07:28 +0200

> to hit the publisher's site every time they checked the feed, and then 

As it would not be a very large hit of say, 25 to 50 KiB; I guess people 
can live with that.

> 2) Not everyone is going to be able to send a 302.

Not everyone is going to be able to send 410 either. Not everyone is 
going to be able to say that the MIME type is application/atom+xml (yes, 
I'm aware about the deal with Apache and Microsoft). Et cetera.

---

From: Graham <[email-masked]>
Date: Mon, 9 May 2005 18:00:32 +0100

On 9 May 2005, at 5:22 pm, Bob Wyman wrote:
> However, many of today’s intermediaries require that program  
> participants manage a “base” feed on their own sites that is later  
> copied to the intermediary. This is the approach taken by  
> FeedBurner among others. Whether or not the intermediaries require  
> that a feed be maintained on the site, this is usually required if  
> only because there will be people who are reading the feed and  
> there is no means to notify them, within the feed, that a new  
> “preferred” source of the feeds is available.
Why can't they use an HTTP redirect like everyone else? They can then  
publish the base feed from a private address.

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 9 May 2005 13:29:38 -0400

Anne van Kesteren wrote:
> Sites could also use a HTTP 302 link on their own site that points
> to FeedBurner in the end. When FeedBurner dies or when they no longer
	While 302 is an obvious technical solution, it just doesn't do the
job. HTTP's 302 is just a bit too absolute...
	For instance, if I'm trying to push people from my Atom 0.3 feed to
my Atom V1.0 feed, it is likely that there will be many readers who don't
know how to process Atom V1.0 correctly -- at least initially. They should
be free to fallback to the Atom 0.3 feed until they learn the new format.
Similarly, if I have readers who use one of the MAC based readers that only
read RSS, it becomes problematic to force them to read my Atom V1.0 feeds...
	It should also be noted that the ability to change HTTP response
codes is not something which is typically provided to many bloggers today.
I'm aware of no blog hosting services that allow for "customer-requested
302" status values. Even on the one-user systems, I think its pretty hard
for normal folk to figure out how to make the modifications needed to return
a 302 for some files.
	We should also realize that business issues are likely to make it
difficult for people to use 302-based solutions. For instance, a site that
provided intermediary feed serving might not wish to make it easy for people
to migrate their feeds away from their service. They might *like* the idea
that switching costs are very high... Thus, they might simply refuse (on
some technical grounds) to allow users who are moving to a new service to
get 302-forwarding on their feeds. On the other hand, if the Atom format
itself contained a means of redirecting to preferred feeds, and if the spec
said that such data "MUST NOT" be removed when a feed is copied, etc., then
one could essentially force vendors to support feed mobility. (Yes, there
would be loop-holes)
	Normally, I wouldn't argue for replicating an HTTP feature inside
the feeds, however, I think that what I'm talking about here is not really
what 302 was intended to provide. In any case, this may be looked at as a
layering issue. 302 provides hard redirection at the HTTP level, a
"preferred" feed indicator provides soft-redirection at the application
level. Implementation of similar services in multiple layers of the stack is
a reasonable thing to do as long as the semantics vary at least slightly
between the layers and the reasons for the variances are related to the
nature of the layers.

		bob wyman

---

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

> to hit the publisher's site every time they checked the feed, and then 

I'm not sure how user agents would handle it, but one could always
attach some caching headers to that 302 response to indicate that the
302 is semi-permanent.  In theory, user agents could hold on to that
302 response for a little while and follow the "cached" redirection.

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