Bug 1424914

Also, the "x-" prefix was apparently deprecated nearly 5 years ago.

I'm not at all conviced that this should be done for mime.types, for three reasons:

1) The cited RFC is about use of the x- prefix in "application protocols" and "parameters" in them. I don't see any evidence that would lead me to believe that a MIME type would fall into that category.

2) The cited RFC explicitly deprecates the x- prefix for "for newly defined parameters" only, and "makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-""

3) Interoperability, as mentioned.

> The cited RFC is about use of the x- prefix in "application protocols" [...]

I don't think they were talking about protocols in the sense meant for, like, TCP/IP. The RFC introduction, section 1, talks about "application protocols [using] parameters with textual (as opposed to numerical) names to identify data ([such as] **media types** [...])."

(Asterisk-emphasis added.)


> The cited RFC explicitly deprecates the x- prefix for "for newly defined parameters" only, and "makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-""

Many media types are reregistering, or have already reregistered, without the prefix, though.

I guess the real issue is that I had noticed a general lack of "x-" prefixed types on IANA, and a number of prefixed types in /etc/mime.types, but did not check if the mime.types prefixed types had yet registered unprefixed equivalents. I had only recently learned about the "x-" prefix being deprecated and was excited to find things to update, including my own out-of-date server configs. You already do a better job keeping up with IANA media types than I initially thought.

When I actually went through the mime.types list, I only found two examples that might be replaceable:

1. "application/x-shockwave-flash" I believe should now be
   "application/vnd.adobe.flash-movie"
2. "application/x-troff-man" and some of its variations, I believe might
   merge as "text/troff".

Interoperability is of course still an issue. When gzip officially registered as simply "application/gzip", the "x-" prefixed version had already become such a defacto standard that receiving applications simply had to support both versions of the media type.

I'm not certain of the semantics of the mime.types file. If possible, what might be best is to *prefer* the types without "x-" prefixes, wherever available, but allow the prefixed versions to remain as a fallback for older software.

(In reply to terrycloth from comment #3)
> 
> 1. "application/x-shockwave-flash" I believe should now be
>    "application/vnd.adobe.flash-movie"

Yeah, maybe enough time has passed from the 2013 IANA registration. So done, https://pagure.io/mailcap/c/fa718bb5ec47de6bfed2e8bc10809674f01508d5?branch=master

> 2. "application/x-troff-man" and some of its variations, I believe might
>    merge as "text/troff".

I'm not qualified to judge this, but shared-mime-info has similar separation for these as mime.types. So unless there's clear evidence that it should be changed, I prefer to keep them as they are in both.

> If possible, what
> might be best is to *prefer* the types without "x-" prefixes, wherever
> available, but allow the prefixed versions to remain as a fallback for older
> software.

There's no support for that in mime.types at all, and I would be very surprised if there would ever going to be something like that; it's a legacy format. More modern registries exist e.g. in shared-mime-info, and things like the above are already implemented and in use with it.