/etc/mime.types lists multiple file subtypes beginning with "x-". Apparently prefixing nonstandard and yet-to-be-standardized media types with an "x-" is now considered deprecated: https://tools.ietf.org/html/rfc6648 "x-" prefixed media types also seem to have been (almost) entirely removed from the IANA media types list online: https://www.iana.org/assignments/media-types/media-types.xhtml I understand this sort of change has the potential to break backwards compatibility for other packages. However, so many people play fast and loose with these media type definitions, that there can be multiple widely used variations on a given type. Most applications, as far as I know, therefore already allow for some variation when matching media types. --- I'll also be reposting this for the xdg-utils package, so I apologize if you see this message twice. These packages are not dependent on each other, as far as I can tell, so I thought I should report this issue separately to both.
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.