1. is only a problem in a limited number of circumstances (see above). Alternative mechanisms are still available at the client side. In fact, any behaviour you trigger from a feed: URI could be triggered from receipt of mime-typed data (you also have more information on which to act).

1a. There are plenty of people who wouldn’t know a URI scheme from a hole in the head. There plenty of room for misinterpretation of “feed:” (especially when what you’re using it for is “subscribe”). Making sure that your work follows good practice guidelines is one way of avoiding confusion.

2. That the user agent doesn’t pass the URI is really an oversight of the agent. Creating a new (monumental) architectural feature to workaround this is a ridiculous hack. A more sensible hack is simply to pass the URI in the feed. This has collateral advantages - e.g. the data is more portable.

You’re also advocating a MIME type without addressing the very real problems.

One of my biggest complaints with feed: is that (as mentioned before), it’s /harder/ to configure at the client side than MIME type support anyway. Windows has a centralised MIME registry (it hooks into file types, but we can’t have everything) where I can choose the handling app. Not so for scheme handling; it’s centralised (presumably), but without a convenient editing interface. If I run one main aggregator, but evaluate others that grab the feed: scheme, I’m going to go crazy. Little modal boxes asking me if I want to switch handling back to MachoAggregator (and do I want it to check in the future?) aren’t much help either. Please, let’s not end up with a solution that requires a helper app to switch between candidate feed: handlers …

(Incidentally, why doesn’t someone write a plugin for MSIE, and another for Mozilla, that gives a “subscribe to this” context menu item with config that allows you to select your aggregator … that’d be cool. Safari would be a nice third browser to support … :-)

Danny: I don’t personally have a horse in this race for precisely the reason you mention… all of my RSS is generated dynamically, so I can set the MIME type at will. If that’s the way things go, it’s no big deal for me. All I need to do is add support for to JournURL’s template language and I’m done.

But there’s a simplicity to the feed: approach that strikes me as just about perfect for this space. It’s a purely client-side thing, so I don’t see any real-world harm coming from it, and it can be implemented and understood by virtually anyone.

I *would* recommend something a little less generic, though. An unregistered scheme like javascript: is safe because it’s so specific… but someone might get the wild idea to do a “real” feed: scheme someday. Might be better to go with feedsub: or something similar.

mailto: is a registered scheme. See http://www.iana.org/assignments/uri-schemes for a list of registered schemes.

javascript: is not registered, but it doesn’t really have to be because it isn’t used for URIs anyway. The whole “link” is handled by the client, without contacting any server, so there’s no need for a “real” URI.

A feed: scheme I think is a bad idea. This isn’t the first time that a new file type has been invented and people start using it on the web more commonly, and it certainly won’t be the last time. You can’t be serious about wanting to introduce a new URI scheme for every new file type. When RSS becomes more commonly used, web hosting service providers will start configuring their servers to respond with an appropriate Content-Type header for files with a .rss extension, so problem 1 and 1a will become a non-issue. The same thing has happened with other new file formats (.png, .xml, .swf, .svg, …).

Also note that if an application can (on Windows) register itself for handling a certain scheme, it can do the same with MIME types. Adobe’s Acrobat Reader for example by default installs itself to handle application/pdf content, so it’s certainly possible.

Using feed: has other problems as well, for example how does the aggregator know what protocol to use for downloading the file? Yes, probably HTTP, but are you sure you want to make it impossible to use other protocols like HTTPS or FTP?

Regarding problem 2, wouldn’t the most simple idea be to include the subscription url as an attribute somewhere in the RSS file? (Yes, that would mean having to extend the RSS standard, but I think that solution is far better than abusing established internet standards just because it looks like the simpler “solution” in the short term.)