Only if we want to contradict what we say here:
http://httpd.apache.org/docs-2.0/mod/mod_mime.html#typesconfig

I don't have a problem with making exceptions to rules (especially considering
the filename extension is very unique); we just need to be careful we don't
trigger a flood of x- types.

Bram writes:
> I used an x- mimetype becaues IANA says that you should do that when your
> protocol isn't approved by them. Of course, they want everyone to get a
> mimetype without the x- approved by them eventually, which involves a
> compatibility breakage. I see no need for that pain, especially since
> collisions in the mimetype namespace never happen; One of the nice effects
> of it being a string rather than a number.

I don't know - it's not up to me, but Bram's not alone in his opinion of the
brokenness with regards to the x- concept with IANA. 

My quick reading of the material under
http://www.iana.org/cgi-bin/mediatypes.pl
seems to contradict this.

Those RFCs explicitly discourage the use of x- types, except for
experimental or private communication.  They also say a non x- type
can't be used until it is registered, but registration is a simple
two-week process.  It doesn't require any complicated approval
process.

I'm not sure what the RFC means by x- mimetypes 'can't' be used. the x- mimetype
for BitTorrent was used on tens of thousands of machines during the period when
the protocol was in such flux that a protocol specification would have been
pointless because it would have become obsolete almost immediately. My decision
to use an unregistered mimetype during that period was based on the engineering
reality of it being impossible to design a massively scalable protocol without
trying it out under massive scaling. That mimetype has continued being used
since because there was no time in which it was necessary to break all existing
machine configurations which used BitTorrent, so there was no opportunity to
change the mimetype without inflicting unnecessary pain.

For what it's worth, the hoop-jumping involved in registering a mimetype would
have actually been quite a lot for me to do back when I was spending all my time
just trying to get BitTorrent to work.

Also, and this is just anecdotal, for another project I attempted to get an
assigned port number and got nowhere. I filled out the appropriate form and got
mail back months later with a simple request to fill out questions I hadn't
answered at length. I responded with an explanation of how those questions
appeared to be nonsensical in the context of the particular protocol, and a
request for clarification. I never heard back again. In practice everyone just
claims port numbers and the 'official' IANA list has a lot of holes.

Notably there's a plethora of x- pdf mimetypes and jigdo uses an x- mimetype, so
others have skipped out on formal registration as well.

In any case, There are now over a million deployed BitTorrent clients which
expect the x- mimetype, and switching it would incur the pain of breaking all of
them in exchange for dubious benefits, so the mimetype is going to remain the same.

-Bram

What concerns me the most is that I don't want to see us acting as an
arbiter of what is a proper mime type.  The IANA already has a whole
infrastructure for that, and I don't see any point in us duplicating it.
A discussion on the docs@httpd.apache.org list hasn't revealed any
inclination to change our general policy of deffering to the IANA.

As far as making an exception in this case, I have no particular problem
with that, but I won't do it myself without some additional support.
To be specific: I'll add this type if I see at least two more
+1s (positive votes) from apache project members.

Well, you could certainly have the client support the unregistered and a new
registered mime type.

The other alternative is to forgo registration and use the vendor space.
Something like: application/vnd.bittorrent-foo. ViewCVS uses this approach for
its custom mime type.

I'm not trying to defend the IANA, but I do agree with wanting to avoid becoming
an arbiter and getting deluged with "choose mine! choose mine!" posts. And yes,
I'm a happy BitTorrent user, too :-)  I just happen to fall in the camp of
trying to use standards whenever possible, and it appears there *are* ways to
move towards a standard (dual mime type support in client, and/or vendor space)

It seems that this (important) discussion has somehow been left in the dustheap.
I may not be an Apache developer, but Bram certainly gets my vote; the number of
BitTorrent installations is probably in the tens of millions by now.

Well. Once it's registered at IANA, it'll go into the distribution. The policiy
is clear at this point and was not changed in the meantime. Please reopen the
report when it's time to wake up.

First off, my appologies for digging up an old bug if it is not welcome.

And second, my comment: While still not registered with IANA, I think the
explosive growth in BitTorrent (Now accounting for over a third of overall
internet traffic) merits special treatment.

Considering that BitTorrent is probably only second in internet traffic to a
small handful of protocols (I'd imagine HTTP would be top on the list), it would
be interesting to calculate what percentage of IANA-approved protocols would,
when combined, still account for less total internet bandwidth than BitTorrent.
I would imagine BitTorrent would account for more internet bandwidth than nearly
all IANA-approved protocols combined. I propose that under those circumstances,
 IANA is much less relevant (to this discussion) than this bug's comments hold
it to.

<insert joke here about BitTorrent adding support for the HTTP mimetype rather
than the other way around>