I've written the first draft of the specification for the "feed" URI scheme. From the abstract

This document specifies the "feed" URI (Uniform Resource Identifier) scheme for identifying data feeds used for syndicating news or other content from an information source such as a weblog or news website. In practice, such data feeds will most likely be XML documents containing a series of news items representing updated information from a particular news source.

The purpose of this scheme is to enable one click subscription to syndication feeds in a straightforward, easy to implement and cross platform manner. Support for one click subscription using the "feed" URI scheme is currently supported by NetNewsWire, Shrook, SharpReader and RSS Bandit. The author of NewsGator has indicated that support for one click subscription using the "feed" URI scheme will exist in next version.

Any feedback on the draft specification would be appreciated.

Update: Graham Parks has pointed out in the comments to this post that URIs of the form "feed://http://www.example.com/rss.xml" are not compliant with RFC 2396. This will be folded into the next draft of the spec.


Monday, December 29, 2003 7:30:07 PM (GMT Standard Time, UTC+00:00)
Just a clarification -- the current version of NetNewsWire (1.0.7) already does support the feed URI scheme.
Monday, December 29, 2003 8:28:48 PM (GMT Standard Time, UTC+00:00)
(The last few versions of Shrook have supported it)

One thing:
feed://http://example.com/rss.xml is not a valid URL and should not be in the spec. See http://www.fondantfancies.com/shrook/feed.php .
Tuesday, December 30, 2003 2:45:18 AM (GMT Standard Time, UTC+00:00)
+ for using Marshall's XML RFC tools
- for not having a public mailing list to discuss
? for me not being sure this is worth the cost"

Simplest fix for standards compliance would seem to be to define the feed URI to be this:
Sunday, January 4, 2004 7:24:42 PM (GMT Standard Time, UTC+00:00)
The URI spec does not disallow colon. After the first colon in scheme, you can have whatever you want; the rest is opaque anyway -- this is one of the fundamental principles of Web architecture outlined by TimBL. Now, I have no beef with encoding the embedded URL, and there is a benefit to doing this since you could stipulate that it be normalized/canonicalized before encoding so that it would be possible to perform reliable comparisons between feed URIs using only string comparison. But this kindof raises the bar for mere mortals to store their feed. There is something nice about feed:http://foo.org/rss.xml. Also, I won't get into the arguments about why it is a bad idea to invent a new scheme for something that a scheme already exists (HTTP), and something that seems like simply a hack to get around the fact that mime support is piss-poor and it's easier to just grep for "feed:" -- I *could* make those arguments, but I admit that running code and pragmatism looks better to me that purity right now.
Comments are closed.