Really Simple Subscription

Dave Winer proposes a solution to the problems caused by the lack of a standardized method for feed subscription. While I would love to see these problems resolved, with all due respect to Dave, I can't say I'm wild about the idea of a centralized subscription server. This seems too complicated for something called Really Simple Syndication, and I imagine many users wouldn't want their subscriptions stored on someone else's server (or wouldn't be permitted to by their employers).

In my mind, the real problem is that the browser does the wrong thing when you click that ugly orange RSS or XML button. Just as your browser knows how to handle "mailto:" links, it should understand what to do with a link to a feed.

So I have to point out that the feed:// protocol (aka: feed URI scheme) was created to resolve this problem. Is it a perfect solution? No, it's not (there's no such thing). Past discussions about this idea have devolved into arguments about MIME types, but I maintain that it's the best one we've got because it works right now. It's already supported by FeedDemon, NetNewsWire, RSS Bandit, NewsGator, NewzCrawler, SharpReader, Shrook, FeedReader, Awasu and other desktop RSS readers. It would be simple for Yahoo!, Google or MSN to support it through their toolbars, and for Bloglines to support it through their notifier tool. And it would be dead simple for browser developers to support it as well.

The other part of the problem is that those orange RSS or XML buttons look far too techie. Why not drop the geek acronym and just use FEED instead?

Comments

[David Sims]

I agree completely with Nick...if I knew that my entire feed subscription life(!) were available publicly on a single server for anyone to use (for whatever purpose, benign or otherwise), that would be the end of RSS for me! - In a word, too "Microsoftian".

Also, in these days of "post-911 patriotism", who's to stop any relevant branch of our federal government from simply burning a copy of your server and using the info for whatever purpose suits it (again, either benign or otherwise). The airlines had to hand over the goods, why not the techies who run the world's RSS server. Maybe they don't really like it that some people are subscribed to opposing-viewpoint blogs, etc. (and no, I'm not).

With all due respect to Mr. Winer: "BAD IDEA".

(You can almost always tell this kind of bad idea, because a techie behind it says something like "it would be cool" - yes, that's a direct quote. "Cool" doesn't even begin to take into account the entire context of people's entire lives, both offline as well as on. Part of that context includes privacy, and that often means that users will have to lift a little finger to do more to subscribe, but at least a user will have a measure of control over his or her own life. I can see why this sort of proposal "works" from the technical side, but it serves the technical world, not your grandmother.)

[Rijk]

Agreed. There is a philosophical problem that these feeds are *not* actually using a different protocol nor is there a 'feed' format, they use 'http' and 'xml'. But the fact that it works (on multiple platforms) and doesn't break things means it is the best practical solution.

And it means people might get a message 'format not supported' or the like in their browser when simply clicking and they have no feedreader installed, instead of seeing a bunch of tags. Which is good, IMHO :)

[Serge Baltic]

Why do MIME types not work? If the server provides the same XML content marked as something like text/rss MIME type, you can catch it at the client side and do whatever needed for subscription.

This could be done by a browser plugin, or, under WinNT (Win9x too?), by installing a MIME type handler that will be invoked each time such a content is downloaded. Note that in this case it will not get a file to consume, but the very HTTP stream!

[Rijk]

Mime types do indeed not work for transmitting the address of the feed from the browser to the feedreader, because only the content will be passed on. You don't just want to read the current items, you'll likely want to subscribe as well. For this, the feed url needs to be passed to the feedreader application.

[Nick Bradbury]

I'm not about to enter into another debate about MIME types. If you're curious as to the problems, please Google for previous discussions on the matter.

I'm proposing that we go ahead with something that already works and has already been implemented by many RSS readers.

[Mike Rowehl]

Hey Nick, this is Mike from VendorCon (Bloggercon afterparty). I'm working over at Feedster now, and I just posted a simple solution to this same problem last weekend:

http://www.bitsplitter.net/blog/index.php?p=388

It's more of a redirection service than a centralized subscription server. Of course, it is still somewhat centralized in that the cookies telling what reader a user prefers are owned by a central server/domain. I've been trying to figure out how to get rid of that issue, but I think as is it's still pretty compelling. Everyone sees just one button, the button they want to see, and they can use either a feed: URI or a web request to add the feed. It works with the currently deployed browsers is what I guess I'm trying to say, and doesn't prevent browsers that know about it from using the feed: URI scheme.

[Derek Scruggs]

Nic, I'm with you on this. I like the MIME type idea too, but feed:// works now and a lot of aggregators already support it. Is it safe to assume we can use your FEED gifs? :)

[Dare Obasanjo]

I agree 100% with Nick. In fact, this post has motivated me to start evangelizing to folks at work about using the feed URI scheme for linking to RSS feeds.

[Rob L.]

Why not drop the geek acronym and just use FEED instead?

Yes, yes, yes. An idea now long overdue.

[eduardo]

Please remember that english is not the only languaje in the world.

FEED dont meant nothing to spanish speakers like me.

[Robert Sayre]

Ok, but what happens when people start putting all manner of "feed formats" in the feed:// scheme. Back to square one.

[Nick Bradbury]

Mike, congrats on the move to Feedster - you've joined some smart folks there (although you might want to change your name to "Scott" if you hope to climb the ranks).

Your suggestion does have the benefit of being simpler for web-based apps to deal with, and it's nice to see that you've focused on making it simple. However, it still requires a central server, which I'm srongly opposed to. Even if everyone trusted a central server to do the job, we still need something that works right now. Feed subscription should work like a mailto:// link, where the browser simply passes control to the user's default email application - with nothing in between.

[Nick Bradbury]

Eduardo, that's a good point, but given that RSS and XML are English acronyms, I still think FEED is an improvement.

[Nick Bradbury]

Robert, if by "feed format" you mean RSS vs. Atom, it's simple for an aggregator to tell which format a feed uses, and new formats would also be easily detectable.

If you mean using a protocol other than HTTP, I believe that's also covered. I think it's safe for aggregators to assume that the default protocol for feed:// links is HTTP, but you could always specify a different protocol.

[Koz]

Eduardo, does RSS or Atom mean anything to spanish speakers?

[Nick Bradbury]

Dare, thanks for joining in here - and a *big* thanks for taking the time to write the feed URI scheme pre-draft.

[Alex Ezell]

Since I don't know enough to comment on the feed: URI vs. some central server stuff, I will stick to this XML/RSS/FEED icon issue.

Since when has a good icon been one with words on it? Isn't the idea behind an icon to iconify a concept or a word? That is, it should be an image that represents what we all accept as an XML feed of any kind.

So, the question is, what is that iconic image that inately describes an RSS feed. Newspapers seem to be a common idea that surround many RSS reader clients (especially FD!), so perhaps the best image lies in that realm.

[Robert Sayre]

Nick, neither.

At some point, someone will decide their funky format is a "feed". Perhaps a competitor will make up a format. Perhaps it won't even be XML. Then they will say "FeedDemon doesn't handle format/mime-type x? Make my program the default feed:// handler."

So, yeah, feed:// works now. But if it becomes wildly popular, you'll end up with an HTTP doppelganger that has the same MIME problem. That means *both* approaches need to be addressed. feed:// is a decent short term solution. Long term, MIME is the way to go, IMHO.

[Rijk]

Robert: nothing stops you from using a proper mime type for your feeds, even when people use the feed: scheme to link to it.

*Especially* when you invent your own funky cool new format, it is smart to use a unique mime-type. If you have a new format, it would not be wise though to tell producers to use the 'feed:' scheme to link to it, until you know most common feedreaders can handle it.

Mime-type will work fine for new formats as long as the cool new format *always* contains the base subscription URL. The mime-type solution for new formats will work today in existing browsers and cross-platform if the receivers have an application that can handle those mime types.

[Xofis]

"Subscribe" is way less techie/confusing than "feed."

[Antonio]

[Re: Spanish]
- RSS and XML are known acronyms, specially XML (but used in too many contexts).
- "FEED" is not.
- "Atom" is quite unknown, even for people who knows what "RSS" is.
- My preference is then "RSS"
- And, practical considerations aside, I don't like the "feed://" addresses for the same reason.

[Nick Bradbury]

Xofis, I agree that "Subscribe" is even better - except when you consider languages other than English. "FEED" may still sound a little techie, but I believe it would be more recognizable across different languages.

Antonio, the acronyms RSS and XML are known among us techies, but we're looking for widespread adoption here.

[Nick Bradbury]

Robert, you've got to admit that's a bit of a stretch. Someone who decides that their funky format is a feed will face numerous problems regardless of whether they use feed://.

[Morgan Pugh]

Why does it have to be feed:// why can't it be rss:// ? I can understand where Antonio is coming from as I work in translation at Xerox. I think a button labeled RSS and using rss:// would be a much better option as you know what it is for like mailto:, etc.

Then again I don't think I have the knowledge to give any helpful input to this subject :-/

[Nick Bradbury]

Morgan, I just think "RSS" seems too geeky for widespread adoption. That's all. I probably should've talked about changing the orange buttons in another post :)

[Robert Sayre]

Nick, my opinion is that the scheme is certain to be polluted, but I don't have to ship product today and you do.

So, in the interest of making this cause as little damage as possible, I'll note that the feed: scheme has a screwed up definition. "feed://" is fine, but "feed:https://" is not. Furthermore, you can't compose a URI by tacking information on to the absoluteURI production, so in the context of RFC2396[bis], the spec is nonsense. I recommend using "feed+https://", "feed+soap://", etc.

I think the way forward is for browser vendors to an equivalent to that little orange button in Firefox, and allow the user to send it to their app or site of choice. The same functionality could be used with MIME types, whether they're declared or sniffed.

[Nick Bradbury]

Robert, I agree that the feed URI scheme is flaky regarding protocols other than HTTP, and your solution certainly sounds reasonable.

[Rijk]

BTW, slightly off-topic:

It is annoying to see that even a company like SixApart doesn't bother to fix typepad.com. It still sends rss feeds as 'text/plain'.

[Randy Charles Morin]

Rijk, I always thought that typepad was returning other than text/plain? In fact, by check a couple feeds in my blogroll, typepad is the only one doing it right. What am I missing?

[Logan]

Maybe I'm confused.

HTML's link tag includes a rel attribute, a type attribute, and an href. Why shouldn't browsers just pass the hrefs of any link that has type=application/rss+xml (or atom, or whatever) to your feedreading 'helper' app? After all, that's who autodiscovery of feeds works now, right?

Why is it necessary to break the URL by conflating content with protocol?

[Nick Bradbury]

Logan, browsers *should* pass auto-discovered feeds to the default aggregator - but they don't. Since the current crop of browsers don't support this, we're proposing a solution that doesn't require making changes to the browser, and is already supported by most aggregators.

[Erik J. Barzeski]

It's supported by PulpFiction as well (http://freshlysqueezedsoftware.com/products/pulpfiction/).

The good news is that Safari RSS, in publicly displayed versions, has an option to hand off "feed://" links to third-party syndicated content aggregators. So, there's a shot across the bow.

[Lachlan Hunt]

I completely disagree with the idea for the feed:// URI scheme. The URI scheme should not say what the resource is, but how to access it. In this case, the feed is being accessed via HTTP, so the http:// URI scheme should be used. Your comparison with mailto: links is bogus, because the mailto: URI scheme uses e-mail protocols, so in that case, the different URI scheme is correctly used.

The best way to improve the ease of subscription is to increase the semantics of the link. eg. rel="feed" (or similar) and the use of the appropriate MIME type, such as application/atom+xml, application/rss+xml or application/rdf+xml. That way, the user agent will know what it is from the semantics, not from the URI scheme, and it should be able to launch the appropriate application for the user.

[Jens Alfke]

Safari RSS (coming soon in Safari 2.0) uses the feed: protocol pretty heavily. The display portion is implemented as a built-in URL protocol handler for "feed:", which fetches the RSS or Atom data (from its cache or directly from the site) and postprocesses it into DHTML for Safari to display.

As part of this, Safari detects when it loads an http: resource that consists of RSS or Atom data, and immediately redirects to the corresponding feed: URL. Which makes those dumb orange "XML" buttons actually work! (And yes, if you've changed your default feed: handler from Safari to a different news reader, clicking the orange button will send the URL off to that app instead.)

Safari RSS also detects LINK tags in the header that point to feeds, and will display a blue "RSS" button (yes, even if it's an Atom feed...) in the address bar that when clicked takes you to the feed.

http://www.apple.com/macosx/tiger/safari.html

[Nick Bradbury]

Jens, thanks for letting us know about this - I wasn't aware that feed:// support would be in Safari RSS, and this will really help its adoption.

[Arve]

Opera 8 beta 1 also displays an "RSS" icon in the address bar when a web page uses feed autodiscovery through link /, and if multiple feeds are specified, it offers a dropdown list of available feeds.

[Danny]

feed:// runs counter to good practice, and (as Robert pointed out) will just be another ugly hack everyone has to work around further down the line.

Did you see:

http://www.kbcafe.com/rss/usm.html