I have seen several suggestions:
Content-T-E: base64; compressor=compress
Content-T-E: compressed-base64
Content-T-E: base64-compressed
Content-T-E: base64/compressed; compressor=compress
There were/are probably others.
IMHO adding compression is an issue that should be dealt with separately
or independently from the Content-Type or Content-Transfer-Encoding,
since it doesn't really have anything to do with MIME data-types or
MIME transfer-encodings. It is something that we want to do to the
data before encoding it for the wire (for bandwidth/filespace savings)
and needs to be recorded so that the process can be reversed. So maybe
I missed it; but, what is the problem with adding a Content-Compression:
header with what-ever semantics are necessary to do/undo compression?
If the message has a Content-Compression: header, the message is
DEcompressed after it is transfer-DEcoded.
For example:
MUA message_body -> compression -> transfer_encoding -> wire
1. The user wants us to compress some content-type using xyz compression
algorithm (xyz is a registered for Content-Compression use algorithm)
or using x-xyz because the receiver knows x-xyz compression and can
deal with it.
2. The content-type data is compressed by xyz algorithm compressor.
3. We label the Content-Transfer-Encoding as binary if using 8-bit capable
mail or we base64 the compressed data and label it as base64.
4. We send it.
5. The reciever gets the message with the
{binary|base64}-compressed-content-type.
6. If the cte is base64, the body is un-base64'ed.
7. We examine the Content-Compression header and undo the compression.
If we don't know how, at least we can allow the user to save it to a
file.
8. We display the content-type data as best we can. If decompression was
successful.
Since adding compression is going to break existing applications anyway, why
don't we do it correctly?
My suggestion is to either add a new message header "Content-Compression:"
or at worst(?) add a "compression=" parameter to the Content-Type header.
Lets leave the Content-Transfer-Encoding meaning what we did to the data
so we could send it, intact.
We also need to consider what happens at gateways when a compressed message
arrives. Having n! Content-Transfer-Encodings as going to make it less
likely and much more difficult for a gateway to "get it right".
makr
-------------------------------------------------------------------------------
Mark A Keasling Twin Sun Inc AIR Co. LTD
360 N. Sepulveda Suite #2055 Software Development 7F
El Segundo, CA 90245 1-3-14 Kitahama Chuo-ku
Email: (310) 524-1800 Osaka 541 Japan
makr(_at_)twinsun(_dot_)com : in the United States
(06) 201-4307
makr(_at_)airco(_dot_)co(_dot_)jp : in Japan
-------------------------------------------------------------------------------