On 2012-09-28 08:48:00 +0900, Charles Plessy wrote: > I would like to follow the IANA and add the new meda types. However, it is > hard to predict the consequences given that Debian packages have evolved for > years in an environment where application/x-gzip was absent on purpose, and > given on the other hand that some programs are probably going to ignore > application/gzip because they hardcode the x- prefix. > > What is your experience with this ? I can update mime-support in > experimental and ask people to test, but this is more on topic for > the Jessie development cycle.
I don't know which applications use /etc/mime.types, but let us consider the following ones: * Apache: it does with mod_mime thanks to the TypesConfig /etc/mime.types config line, and web servers are probably the only applications where there is a notion of encoding. Now, such applications should have their own way to deal with it, and the default /etc/apache2/mods-available/mime.conf configuration file even contains: AddType application/x-compress .Z AddType application/x-gzip .gz .tgz AddType application/x-bzip2 .bz2 with the encoding part commented out: #AddEncoding x-compress .Z #AddEncoding x-gzip .gz .tgz #AddEncoding x-bzip2 .bz2 So, even in the case of Apache, adding the gzip (etc.) media type to /etc/mime.types should be recommended, to avoid the above AddType lines. It is still possible to remove the types in Apache, if the user wants too, with RemoveType (this works at least with types added by AddType), but this should be tested with the particular case of /etc/mime.types. * Mutt: upstream provides its own etc/mime.types, e.g. installed in the user's home directory when the user installs Mutt there. In particular, it has: application/x-gunzip gz With Debian's Mutt, /etc/mime.types is used, and one gets the useless application/octet-stream (actually Mutt tries to guess whether this is text or binary, when the extension is unknown). I think that application/gzip would be more useful. But I usually use my own version of Mutt installed in my home directory, so that I don't have the problem with the missing entry in /etc/mime.types. * Subversion: it doesn't use /etc/mime.types, but has its own mapping file. Since it doesn't have the notion of encoding, I think that application/gzip is the best choice. > Please let me know if an upload to Experimental would help, otherwise I > propose to wait for Wheezy is released. I think that you can wait. > Also, if we add application/gzip and application/zlib, then I will be > reluctant to add the unregistered application/x-gzip type. Can you tell > me what you think about this ? I think that you should forget the non-standard application/x-gzip, in particular because not all applications agree on what it should be (see the difference with Mutt, for instance). In the long term, I wonder whether the "x-" should be removed for other types, as they now seem to be deprecated: http://tools.ietf.org/html/rfc6648 But you know that. :) -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
