More on feed:

After some lively discussion yesterday (more references below), here are my thoughts.

  • We need to come up with something that’s easy for the publisher. If it’s not, this has approximately 0.142% chance of widespread adoptance.
     
  • MIME types alone do not solve the problem – lots of discussion about this on yesterday’s post.
     
  • Escaping the URL after feed: is going to be way too error prone. Look how many feeds don’t correctly escape their content – this is going to be much worse. Which means tools will have to deal with correct and incorrect forms both…so let’s just do it the easy way.
     
  • Having a “standard” port for aggregators to listen on is a bad idea; and in fact, many folks (including me) would argue that having the aggregator listen on any port is a bad idea.
     
  • We’re not developing a new protocol – this is merely a hook into the browser and the shell to make it easy to subscribe. The characters “feed:” will never go across the wire in a request. 

With all that said, I’m thinking we just go with

feed:http://www.rassoc.com/gregr/weblog/rss.aspx

More reference on this: 1 2 3 4 5 6

Keep the comments coming! Let’s try to hammer this out soon – we’re all in this to increase adoption of RSS…and arguing over MIME types, parameters, and escaping doesn’t get us too much closer to that end.

17 Comments

17 thoughts on “More on feed:”

  4. Pete Hopkins

    Steven —

    Fair enough… I’d like to hear more opinions before the shorthand is thrown out, but it’s a minor quibble. I just like seeing the URLs as simple as possible… these days I expect very few people need the general version, so it makes some sense to optimize for HTTP.

    Reply ↓
  6. Today's links

    Verisign is Pure Evil…”Elements of Style” for Weblogs…”Feed:” proposal…Office 2003 available and works great with Newsgator…Laszlo…Blogpulse…Gelsinger on desktop power consumption (bummer)…P2PForums…[more]

    Reply ↓
  7. Manuel Gonzalez

    ABOUT HTTP DEFAULT

    I think that feed:www.host.com/file.xml would be great links, short and easy to support.

    ABOUT HOST NAMES

    Also, what do you think about feed.host.com (defaulting to feed protocol instead of http) using the root file as feed file by default. This is the next step, for webmasters.

    ABOUT THE DOUBLE SLASHES

    Don’t worry about the // double slashes, you should be able to put or remove them from feed URL, as currently happens with http URL like:

    http:www.google.com

    http://www.google.com

    Feed URL will never be sent over the network, as they are processed locally like outlook: and mailto: URL, you can ignore the // because they always are global resources.

    Why prohibit feed:// URL to be valid?

    I’ve put some examples at http://www.brindys.com/winrss/feedformat.html

    Reply ↓
  10. Greg Reinacker

    Pete, Steven – I don’t like feed://example.org because then it looks like a protocol – and we’re defining a browser shortcut, not a protocol. In reality, tools will probably have to parse this format, because it will come up in the wild no matter what we do, but I’d rather NOT recommend it. We’ll probably also need to support feed://http://example.org (note the // after feed), but I’d rather not recommend that either.

    Manuel –

    Re feed:www.host.com/file.xml, I think this is NOT a good idea. http:www.host.com is not technically valid either – browsers might parse it, but that doesn’t make it valid or good! Double slashes should not be optional, in at least the http part of the URL spec. That said, we’ll probably all build pretty tolerant parsers, but that doesn’t mean we should allow non-well-formed URLs.

    Re feed.host.com, I wouldn’t expect anyone to allocate an entire host name out of their domain just to support a feed. I see absolutely no value in this, actually…maybe I’m missing your point.

    Reply ↓
  12. Richard

    It’s starting to look like a vote now ;), but I prefer feed:http://, as mentioned by others this way it’s a browser shortcut.

    Also I think we should go for one solution and not feed:// and feed:http://, if we go for that then we are creating yet more confusion. Anyways thats just my 2cts on that topic ;)

    Reply ↓
  13. Using feed:// for Subscriptions

    Via Greg Reinacker (author of NewsGator): “This seems like a reasonable idea to me…with the obvious benefit that a user could just click on the link, and the aggregator could add a subscription to the feed. As opposed to the situation today, where if the user clicks on a feed link, they’ll see (at best) a page full of XML.” Further comments can be found in a later post. Genius idea that, once again, will rely on the support of news aggregator programmers….[more]

    Reply ↓
  14. Jaykul

    I don’t think you get a choice, Richard. (Read my ‘feed:http:// is better’ article…)

    If you’ve registered “feed:” … any link that looks like that at all is going to get sent to your application, so you have to handle it. I mean, you can say: We prefer that people use feed:http://www … but if someone puts a link up: feed://www, or even feed:www … your application is going to get invoked.

    Reply ↓
  15. Danny

    re. “We’re not developing a new protocol…”, I agree with the comments that it sure looks like one, and add that however browser-specific, it’s still behaving pretty much like one. This suggests that the functionality required is something like a protocol, and given the problems relating to unregistered schemes (also check the W3C Web Architecture doc) I’d still favour the MIME-type approach, because in addition to providing the hook it is also more generally useful.

    Reply ↓

Leave a Reply