There has been a lot of debate following my initial post about Really Simple Subscription. Shortly after I suggested using the feed URI scheme, NetNewsWire developer Brent Simmons came out in favor it, and in the comments to my post we heard that Safari RSS (part of Apple’s upcoming Safari 2.0) will use feed:// quite heavily.
But other solutions have been proposed, such as the Universal Subscription Mechanism (USM) authored by Randy Morin. I’ve spoken with Randy about USM, and he knows that I have a number of issues with the “reflexive auto-discovery” mechanism. However, part of his proposal includes convincing feed producers to provide the correct Content-Type header for their feeds, and I’m 100% in favor of this. Although having the correct Content-Type doesn’t entirely solve the problem, it would take us a big step in the right direction.
If you’re interested in this topic, be sure to read all the comments beneath Brent Simmons’ post, including Danny Ayres’ comment that he “can’t actually see [much] conflict between these approaches, implementing one doesn’t rule out implementing the other.” I agree. We’d all be better served if we realized this isn’t either/or situation and stopped endlessly debating which solution is better. I’m in favor of feed:// because it’s simple for everyone to implement, but I’m also in favor of evangelizing feed producers to use the correct Content-Type. And once it’s fleshed out some more and answers my concerns about privacy, I may like Dave Winer’s solution as well.
9 thoughts on “Really Simple Subscription, PII”
Hurrah for compromise and collaboration.
I have one really dumb question about the feed:// protocol that I haven’t been able to find an answer to — are the double slashes really necessary at all?
From what I read feed:http://some.site.with/feed.xml is permissable and makes a lot of sense to me. This form is just like mailto: is to email so it doesn’t take much to see how a link of this type will behave the same way — it launches a local program and fires off an action. What does feed:// do differently then?
I guess the idea of an HTTP protocol alias is what sticks in my craw ever so slightly because of the precedence it sets. Not to be argumentative because I think getting MIME types right and giving users a consistent a simple way to subscribe to feed is avery good one. I’m just curious as to the thinking behind them and to find out what I’m missing.
Timothy, I believe feed:// is just a shorter way of saying feed:http://. If no protocol is defined, then HTTP is assumed.
Timothy, the “//” characters are necessary for URIs that include “authority” components (such as web hosts). It’s written this way so that a URI parser can understand the structure of a URI without knowing a specific scheme (such as feed).
I’d be interested to hear why you don’t like “reflexive auto-discovery” (I don’t either).
Nick, the RSS feed link in the right sidebar is returning
Could I ask a question or two? I this a typepad thing? If so, how would someone fix this? I’m compiling instructions for users.
Thanks for the reference. Much appreciated.
Robert, I just don’t see reflexive auto-discovery as being reliable – there are too many situations where it would fail. If you were using FeedDemon and cared nothing about the guts of RSS, how would you react if FeedDemon told you that you can’t subscribe to a feed because FeedDemon couldn’t figure out the URL?
Randy, I actually sent a support question to TypePad about this earlier today, asking how to change the content-type to application/rss+xml. At this point I don’t know how it’s done, but I’m assuming it’s possible.
Adding feed:// is unnecessary and it will only add another level of confusion. The best and simplest solution, IMHO, is to add the MIME attribute to the hypertext link. This works fine with the Auto Discovery, why don’t we follow suit and use the same method for the Auto Subscribe rather than inventing some thing new? Please see the following proposal:
RSS Auto Discovery & Auto Subscribe
Nick, any progress with Typepad’s Content-Type issue?
Comments are closed.