> > > Because if .gz was present, it would send the file as the associated > type. > > If it wasn't, then it would look beyond and send the correct type with a > > content-encoding of "gzip". > > Then Apache (or possibly the HTTP standard itself) is broken, and > should be fixed. You can not justify breaking a pre-existing standard > to make a subsequent unrelated one happy. >
MIME is far more broken than HTTP. > > > > It has the same features as something that is "uuencoded". > > > > > > False. Something uuencoded has been re-encoded in a different format > > > expressly for the purpose of *transfering* it via mechanisms which > > > require 7-bit ASCII (SMTP). > > > > The purpose does not matter. It's an encoding. Whether it's an encoding > > for a 7-bit, non-clean channel or any other kind of encoding, it's still > an > > encoding. > > Everything is an encoding. HTML is an encoding. MP3 is an encoding. > ASCII is an encoding. All digital data on a computer is an encoding > of some sort. Purpose *absolutely* matters. > All of those are more than an encoding. They apply some meaning to the data. As you say, purpose matters. There is no purpose to data just because it's gzipped. The purpose of the data is the same both before and after the compression. > > > tar xvf - . | gzip -c > my_archive.gz > > > > That's still one file, a tar file. The fact that tar contains other > files > > within it is not relevant. As far as gzip is concerned, it is a single > > entity. > > But how does mime-support identify what the file type is? It can't... > because the file type of *this file* is gzip data, and you've not > provided a type for that. > It's smart. It recognizes the indication that the data has been compressed and then uncompresses it before using the type of the data to determine the proper destination. > > The content type is "x-tar" (or whatever) and the encoding is "gzip". > > for i in * do; echo __divider__ ; cat $i; done |gzip -c > my_archive.gz > > Now what is it? It's still one data stream and one file as far as gzip is concerned. > Again, the point is that gzip data is arbitrary; all > that the e-mail system knows, and needs to know, about this file is > that it is gzip data. No! Knowing that it's compressed is absolutely useless to an e-mail system because it cannot _do_ anything with it. > Just as MP3 files are meaningless until they > are decoded with an mp3 player, this archive file is meaningless until > it is decoded with a decompression program. It's meaningless after, too, which is the difference. > MIME, i.e. the e-mail > system need not know what type of data is compressed; MIME exists to > convey to the user what to do with the attached file. This file needs > to be processed with a decompression program. You're failing to > provide that by not providing MIME types for gzip. > > > > > Thus, both the type and the encoding are available in the filename. > > > > > > Clearly false from the above. > > > > Clearly true if you start with a file and don't specifically choose to > > obfuscate the data. > > Only true if you actually *have* a file. The gzip application makes > no such assumption, and MIME must not either. Arbitrary data on stdin > is not a file and has no data type, as far as gzip is concerned. The > resulting file does: gzip data. > No, it's "gzipped arbitrary data" since "arbitrary data" was the input. > > In the end, the amount of information about the type of data is the same > > both before and after gzip touches it. If it came from a file, the type > > (extension) is preserved. If it came as an arbitrary octet stream, the > > output is an arbitrary octet stream. > > But with respect to your e-mail via which you're transporting the > archive, it's a gzip archive. > No, it's "gzipped something". > > > > There is a way to know; use content-type and content-encoding, just > as > > > HTTP > > > > does. > > > > > > Please show me where in the MIME standards this is allowed. > > > Content-encoding is not a valid MIME header, as far as I'm aware. > > > Content-transfer-encoding is, but gzip is not a valid content transfer > > > encoding defined by the MIME standards, and in fact it can not be one, > > > because attachments "encoded" in gzip can not be sent as-is over SMTP. > > > > > > > MIME allows for extensions. I didn't say it was part of the RFC. > > Sure it does, but no such standardized extensions exist, and no such > extensions are implemented in a standard fashion. And the fact is > none is needed or desired; all that is required is to specify that the > attached file is gzip data. Users who transmit gzipped files > typically don't want you to uncompress the files upon delivery (which > is also true for files downloaded via HTTP, in my experience)... they > want to save the compressed archive for later processing. > > Regardless, your insistance that gzip is an encoding is not supported > by the MIME spec or any standard extension. It's invalid for MIME, > though it's perfectly correct for HTTP. > > > > This is essentially true, but providing a proper MIME type prevents > > > e-mail clients from mishandling gzip files, for example by attaching > > > them with an incorrect MIME type (or none at all) or attempting to > > > display them as plain text when their mime-type lookup fails. > > > > That is unfortunate, I agree. > > This is the very problem which MIME was invented to solve!!! By not > providing an entry for gzip, you've broken it. In the case of gzipped > files attached to e-mails sent or received on Debian systems, > mime-support is broken. > Gzipped data is not a type. MIME may have intended to solve such things but it did not. It does not matter what type you assign to such a data stream, it will be incorrect and thus is not more correct than not having a type at all. Yes, with a type, some mail programs may better handle the file because it won't treat it as text but dumping the uncompressed output isn't any better. Clicking on a .tiff.gz file won't display the image. It will still be broken. > > > > Despite the problems, mapping ".gz" to a gzip type gains nothing. > > > Clicking > > > It gains something very important: it prevents e-mail clients from > > > mishandling gzipped files. > > > > But adds nothing regarding proper handling of the data. > > file. By adding a mime type for the data, you prevent e-mail clients > from automatically mishandling the file, allowing the user to save the > file as was almost certainly intended. > Any mail program that alters the contents of the data while saving, regardless of its type (explicit or implicit), is asking for trouble. > > MIME may not, but Apache uses (or used) the /etc/mime.types file. Adding > > these definitions could break a great many webservers around the world. > > Then fix Apache. Or explain why other Linux distros which do have > these types (e.g. most any Red-Hat based distro) don't have this > problem... > Apache used to come with its own mime.types file independent of the system. The Debian package used the system one. *You* fix apache! And fix all previous releases. And push that change to every Debian-based webserver on Earth. Then we can talk. Brian bcwh...@pobox.com ----------------------------------------------------------------------------------------- Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
