Re: New URI scheme talk in RSS-land

> So what if the feed must be be accessed over HTTPS?  Do we then also 
> need a "feeds" scheme?  

Actually, the feed protocol has been unofficially defined as feed:url, where
http is the default protocol for the url if none is specified. 
So feed:www.tbray.org/ongoing/ongoing.rss is really just the abbreviated
version of feed:http://www.tbray.org/ongoing/ongoing.rss .
https feeds would need to be fully specified as
feed:https://example.org/feed.rss

> How about this instead:  create a new scheme 
> called "handler" (or maybe "mime-handler") that has a format like:
>
> handler:application/rss+xml;http://example.org/feed.rss
>
> or generically "handler:mime-type;uri".  Now the mime-type can be used 
> to determine the appropriate application and the uri can be passed to 
> that application directly.  This is generic, flexible, and simple.  This 
> way, if you have one application for processing RSS 1.0 (because it's 
> RDF and you like to do more than just read the entries), another for RSS 
> 2.0 (because your RDF tool won't like it), and another for processing 
> Atom (because your RSS reader won't like it), your various applications 
> won't trip over each other as much as they would if they all recognized 
> the "feed" or "subscribe" schemes.

I doubt anyone would use separate aggregators for rss 1, rss 2 and atom -
typically you'll have one aggregator to handle all formats.
I see your point though where handler: is more easily extendable - one
protocol to rule them all.

Initially this would be slightly more work as aggregator-writers would have
to register the handler: protocol with a dispatch-mechanism based on the
mime-type, and then also register the mime type to point to their
aggregator. If the handler protocol would be an official w3c approved
standard though, I can see future operating systems would come with the
dispatching mechanism built in

--Luke