# BitTorrent as a positive role model

Guess what this is?

http://bitflood.org:8080/file?info_hash=D%12%85z%88%AF%22%A7%C4VA1DP%97%A2%89%E9O8

Well, it's a URI, and as a matter of fact it's a plain old HTTP URI. Now that might not be suprising to you, but it sure was suprising to me. You see, this turns out to be a link to a bittorrent of Jon Stewart's appearance on CNN's Crossfire.

Why is this suprising? Well, I have it on good authority that if you want to do anything new on the internet then, despite the admonition of the W3C's TAG, and a fairly detailed tutorial to the contrary, you have to come up with a new URI scheme. Yet, after installing BitTorrent, with a single click on that URI the BitTorrent application loads and the download begins. Is it voodoo? I was told this just can't work. I mean, I have it on good authority that using mime-types doesn't work:

MIME types alone do not solve the problem [Greg Reinacker

So let's look under that URI and see what's really going on:

C:\>curl --include http://bitflood.org:8080/file?info_hash=D%12%85z%88%AF%22%A7%C4VA1DP%97%A2%89%E9O8
HTTP/1.0 200 OK
Content-Length: 3054
Content-Type: application/x-bittorrent
Content-Disposition: attachment; filename=Crossfire-20041015-John_Stewart--compressed.wmv.torrent


Well it appears that BitTorrent does use mime-types to launch the application. Who knew? So now explain to me again why this works for BitTorrent but you have to create a new URI scheme to subscribe to feeds?

While this (above) is an accurate quote from Greg, it misses his broader argument.  If one follows the entire discussion, including that which precedes the quote you reference, it's clear that Greg does not dispute that MIME types can work, technically.  However, for many (most?) RSS publishers, there is no control over MIME types due to limitations of their hosting environment.  So Greg thought that an alternate solution might gain more traction.  The problem is wider than just what is technically possible.  Certainly the MIME type approach is an acceptable solution from a purely technical standpoint: it works, no doubt.  But in terms of what can actually be deployed and widely adopted, it has its limitations owing to the requirement that the publisher have or gain some control over MIME types and/or HTTP response headers.  Such control may not be available to the vast majority of RSS publishers.

Posted by Allie Rogers on 2004-10-26

Because feeds are so much more complicated... Duh! No, seriously, that's a very good question. It would be interesting if some of the 'feed:' URI scheme's proponents could speak up and explain. I have no idea.

PS: Kind of irritating that your comment script doesn't allow for non-ASCII characters. My name isn't really "Asbjorn" with an 'o'. :-)

Posted by Asbjorn Ulsberg on 2004-10-26

Greg addressed this... the browser passes the contents of the file to the destination app, not the URI. And what the aggregator needs is the URI.

If all RSS feeds contained references to themselves, MIME types would work. But they don't, so they don't.

Posted by Roger Benningfield on 2004-10-26

So if the Atom feed format features a mandatory spot for the URI of the feed then it looks like this is a solved problem for Atom.

<a href="http://cvs.apache.org/viewcvs.cgi/apache-1.3/conf/mime.types?rev=1.43&view=auto">http://cvs.apache.org/viewcvs.cgi/apache-1.3/conf/mime.types?rev=1.43&view=auto</a>

On the other hand, with native support of auto-discovery being built into browsers, this problem may go away on it's own for any feed format.

Posted by joe on 2004-10-26

Joe,
I like the way you feign ignorance of the fact that most of the XML feeds on the Web (RSS 1.0, RSS 2.0, Atom 0.3, etc) all use incorrect MIME types so depending on them is error prone at best.

This ignores the obvious limitation to using just MIME types with RSS feeds given that they don't contain a reference to the feed URI which Greg mentioned and Roger reiterated above.

Posted by Dare Obasanjo on 2004-10-27

RSS feeds don't need to include a self reference for this to work in IE. IE will pass the URI to the application in addition to the content.

If the a mime type handler implements IPersistMoniker, then IE will pass a moniker to the handler instead of the stream.  The handler can examine the moniker to get the URL and bind to the moniker to get the data stream.

IE will ignore the content type from the server if IE data sniffer has an opinion about the content type.  The data sniffer can be configured with registry entries.  Perhaps it can be configured to recognize RSS.  Search for FindMimeFromData to find info about the sniffer.

Posted by Arnold Smith on 2004-10-28