On Mon, 2010-11-29 at 22:52 +0100, Brian White wrote: > If an application stores information about the original file (like > it's filename) rather than just act without thought on a data stream, > then it's more than just an encoding. Yes that's what I've meant... > > > Especially > application/x-gtar-compressed tgz taz > > however not (don't know about the others). > tgz and taz should be added to application/x-tar (in addition > to .tar), as > they're both tar archives just with an gzip/compress > Content-Encoding. >
> Correct, but not so simple. Expecting a program/person to > recognize .gz and meaning gzipped is more reasonable than expecting > it/them to reliably recognize that some (but not all) extensions > ending with a "z" are also such. > > > After that, we're left with the fact that tar will not process a tgz > or taz file without an added option on the command line. Thus, it > must map to a different type to get opened in a different way. I > gather newer version of tar can recognize some file extensions but I > don't know to what degree and apparently not by analyzing the data > stream itself (which is important should the data be coming from > stdin). There's also something to be said for backwards > compatibility. Well this might be true in practise... (or better said with all programs that don't use MIME types as they should But it makes problem e.g. with Apache and in general the way how MIME types are defined to be used. The standard says that the type is really just for the content. So e.g. with apache, if I would like to have the correct: type=application/tar + encoding=gzip I need to first manually remove the mapping from /etc/mime.types. I mean I totally see your point, but IMHO these are bugs in the applications using that mime types because they lack the concept of an encoding. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
