[Top] [All Lists]

RE: compressed content-transfer-encoding?

1999-07-27 11:55:34
Is there an RFC (or movement toward one) for a compressed encoding
within MIME?

There seems to be a lot of interest lately in compressing attachments.
End users are encouraged to zip Office files before mailing them,
and at least one product (MaxCompression) does this automatically
(in a proprietary way.)  Even with modem compression, there seems to
be some gain from this, and the disk storage implications on the mail
server are also interesting.

It seems that a new MIME standard for content-transfer-encoding that
would indicate a compressed base64 type ala gzip could be nice.
Creative minds might even improve the efficiency of base64 at the
same time, if we don't have to worry about translation into EBCDIC

HTTP (RFC 2616) added a different transformational layer
(Content-Encoding) to avoid combinatorial explosion with different
transfer-encodings (transfer-encodings were also kept distinct
from content-transfer-encodings). Valid content-coding tokens
include "gzip", "compress" and "deflate".

It might be possible to extend Content-Encoding to work with mail.

And if you want to avoid Base64 in mail, well, there's BINARYMIME
(RFC 1830).