Package: mime-support Version: 3.48-1 The mime.types file is missing MIME types for x-gzip and x-compress. The debian mime.types file states:
# Note: Compression schemes like "gzip", "bzip", and "compress" are # not actually "mime-types". They are "encodings" and hence must # _not_ have entries in this file to map their extensions. I will systematically prove that (depending on semantics) either this is outright false, or that the term "encoding" has been misappropriated and, in the context of MIME, excluding these on the basis that they are "encodings" is completely inappropriate. A file that has been gzipped contains data, and is a particular type of file: a compressed archive. An archive of what, MIME has no way to know, and no reason to care. It matters only that it is a gzip archive. In order for MUAs to handle such files suitably when attached to a MIME e-mail, it must be possible for those mailers to identify the type of file that has been attached. Without a MIME type, MUAs are expected to assume that an attached file is plain text (see RFC 2045, section 5.2). A gzip archive file is not plain text, and may or may not consist of compressed plain text, though the latter fact is actually completely irrelevant. The MIME standard does contain the concept of a transfer encoding, of which a compressed archive file is not. MIME encodings exist to facilitate transfer of non-ASCII data over e-mail, however this is the only context in which an encoding is relevant to MIME (see RFC 2045, sections 5 and 6, for example). The primary purpose of file compression is to archive data in a smaller amount of space than it otherwise would consume. It's true that compressing the file constitutes an "encoding" -- but then the same is true of encoding music as MP3, images as PNG, HTML-formatted text, etc. In fact all data represented on a computer, regardless of the type of data intended to be represented, constitute an encoding of data. These do not constitute transfer encodings, as their main purpose is not to facilitate the transfer of data. They are, as is a gzip archive, merely data types which MIME was intended to accomodate. It's also true that compressing data in some way facilitates transfer, but this is not its main goal. Further, as with all of the above examples, compressing a file with gzip *does not* fulfill the purpose of the transfer encoding with respect to MIME. Once the file is encoded with gzip, it is *still unsuitable for transfer* and must subsequently be re-encoded using one of the transfer encoding schemes specifically defined in the MIME standards. Additionally, a gzip archive provides no means to identify the type of content that is encoded. All that one can be sure of is that the data so provided can be reprocessed by gzip to uncompress it. The MIME standards likewise currently provide nothing suitable for e-mail clients to convey this information. For these reasons, it is only suitable for MIME handlers to treat such files as application data, which can be processed by the gzip program, as MIME was always intended to be used. Finally, the MIME standards dictate that files not marked with an associated Content-Type (MIME type) be asssumed to be plain text (RFC 2045 sect. 5.2). This clearly is unacceptable for gzipped data, as it is quite certainly invalid plain text. As such, it *must* have a suitable MIME type associated with it. Please add MIME types for gzip and compress archive files. Thanks -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
pgpskwH9XxKeE.pgp
Description: PGP signature
