Joshua Allen has a post entitled RSS Last Mile where he complains about the lack of a clear story with regards to one click subscription to RSS/ATOM feeds. I wrote about the various approaches to achieving one click subscription to ATOM and RSS feeds a few months ago which led to drafting feed URI scheme. Three months later, one click subscription to syndication feeds is still as confused as it's always been. A lot of the major aggregators support the feed URI scheme but none of the major blogging tools has decided to support it yet. Instead a lot of folks still use the hack popularized by Radio Userland but which is now utilized by a wide number of aggregators. However most websites just do nothing with regards to one click subscription and just have a hyperlinked image, such as , which points to the RSS feed. 

The only new thing I've seen is that yet another person has cooked up their own one click subscription scheme that is incompatible with all the others. Thanks to Joshua's post I found an RFC for one click subscription to syndication feeds which seems to me to be the least advantegeous of the approaches that have shown themselves thus far.

The author of the RFC wrote the following about existing approaches, I've annotated his comments with mine in red text

Current solutions:

  • have the aggregator clients register with some mime-type (for either RSS or OPML), I don't believe anyone's actually implemented this since most aggregator authors know this doesn't work for a variety of reasons listed in my post on one click subscription to ATOM and RSS feeds
  • have a new protocol (feed:), actually this is a URI scheme not a protocol, and the process is the same as the above, have the aggregator clients register with as the handler for some URI scheme
  • support as many clients as possible via javascript (see QuickSub),
  • transform the RSS with XSL in the browser to help newbies (no really a one-click subscription solution though).This could be a one click subscription option if the prettied up RSS feed shown to the user also displays a link that uses one of the other 3 techniques mentioned above. So this approach is really orthogonal to the others and in fact can be considered complimentary

The author of the RFC post then goes on to suggesting an Internet Explorer specific solution namely that

Replace the orange Feed button:
The orange feed button needs to be wrapped with an object tag:

<object classid="clsid:0123456789ABCDEF [1]">
  <param name="feedurl" value="http://feedurl [2]">
  <param name="description" value="blah blah [3]">
  <param name="imageurl" value="http://buttonimageurl [4]">

  <a href="http://feedurl [2]"><img src="http://buttonimageurl [4]" /></a>

If the ActiveX control with class ID [1] is installed, it displays a custom "subscribe" button. When you click on it, it uses the feedurl parameter [3] to subscribe.

Besides the fact that this approach is Internet Explorer specific since it requires an ActiveX object it doesn't offer anything that the other approaches don't.  I don't see why Joshua thinks it's a good idea, considering that all 3 of the other approaches work in a variety of browsers on a variety of platforms.



Monday, April 5, 2004 10:30:02 PM (GMT Daylight Time, UTC+01:00)
In a sort of odd way, I like the ActiveX solution, though. One thing I always hope any sort of subscription scheme will avoid is making it impossible for me to see the feed itself, since when I'm left-clicking on a feed link, it's because something's broken or someone asked for my help, and I just want text/plain there in my browser.

So, if you're one of the 95%, you get an ActiveX object holding your hand, and if you're one of the 5%, you fall through to the old standard link? Sweet!
Monday, April 5, 2004 10:43:00 PM (GMT Daylight Time, UTC+01:00)
The solutions that involve providing a prettified version of the feed via an XSLT or CSS stylesheet still enable you to look at the raw XML since you can do a "View Source".
Tuesday, April 6, 2004 9:56:08 AM (GMT Daylight Time, UTC+01:00)
feed: defines how the data (URI of the feed) should be transferred from one agent (the browser) to another (the aggregator). i.e. it's a protocol. But it's masquerading as a scheme, and in that you have the essence of why it's a bad idea.

It's remarkably bad design to stick raw XML in someone's face when you have the opportunity to provide an informative message.

The object approach could well be a great step forward towards a web-friendly solution.
Tuesday, April 6, 2004 6:55:24 PM (GMT Daylight Time, UTC+01:00)
Everything you complain about the feed URI scheme is implemented just the same way for the mailto, news and nntp URI schemes in most browsers. Your complaints seem like just making arbitrary distinctions on what you feel is "architecturally pure" and what isn't. I'm quite surprised that using an proprietary Microsoft-only solution is a more desirable alternative to you than using a general, cross platform solution. I guess architectural purity and politcs make for strange bedfellows.
Tuesday, April 6, 2004 7:10:08 PM (GMT Daylight Time, UTC+01:00)
Thanks for the feedback and corrections. I do agree that the current "solutions" are not satisfying thus a tentative new approach ;-)

I'm going to write a post today to go in the details of my arguments, but here are three main points:

- NOT IE SPECIFIC! :-) It should be possible to have this work for all platforms, just the same way Macromedia Flash runs on all platforms. This may require having the "object" tag contain an "embed" tag,

- the main advantage of this approach is that it can be user-friendly when you don't have an aggregator installed. it falls back to displaying a link to an XSL transformed RSS page, which can point you to using an aggregator and installing the component.

- the main problem with the feed: scheme is that it doesn't help unless you have an aggregator already installed. Other than that I think this would probably be the best solution.

I believe the second point is the most important, because user-friendlyness is the biggest limit for adoption today.

Tuesday, April 6, 2004 9:18:24 PM (GMT Daylight Time, UTC+01:00)
I still think "feed:" is less than ideal, even if aggregators were ubiquitous. Nobody ever sticks the darned hyperlink in the same place, so you have to hunt for it. Think of functionality like "print". Would you like it is the way that you print a word document was to go hunt for the place in the document where the author decided to stick the "print" button? I believe that "subscribe" is a functionality that should be just as generic as "print", and there is no excuse for it being invoked from random locations inside the document.
Tuesday, April 6, 2004 9:28:30 PM (GMT Daylight Time, UTC+01:00)
Just posted a detailled response at:

The problem with the "print" solution is that I think it is important to support linking to multiple feeds from a single page.
Using link rel="feed" tags would work great. The browser would have to include a "Subscribe to feeds" button and display a selector UI to confirm and resolve ambiguities (when multiple feeds are available).
Thursday, April 8, 2004 3:06:17 PM (GMT Daylight Time, UTC+01:00)
I missed the XP Baloon tips is this application.
But the app is very good. (Alexandre)
Comments are closed.