I'm also worried about phase-in and acceptance of this new RFC, which is
why support for things like UNIX compress and uuencode seem vital. Not
to mention BINHEX, etc. for Macs -- we've got a lot of Macs on our net.
A compressed, uuencoded message can already be handled (with user
intervention) in most existing UNIX mailers. I suggest that MUAs will
be divided into two camps, those that are basically lightly re-worked
older UAs, able perhaps to run some of the decoding processes, then fork
off the appropriate tool for displaying the body of the message, and
newer UAs, that will understand the RFC-XXXX scheme in more detail, and
be able to do more sophisticated processing. I expect that most of the
older mailers will not deal well with recursively-typed or multipart
message-bodies. But that is no reason to handicap users of these older
mailers in trying to mail around audio, say, or any other single-part
8-bit message-body, which could frequently be conveniently encoded as
uuencoded-compressed.
I feel that Content-Encoding should describe "the [reversible?] things
that have been done to the body of this message". With this in mind,
I'd argue for standardized definition of the following Content-Encodings:
BASE64
BASE64-COMPRESSED - 7-bit safe "mail" compressed
COMPRESSED - 8-bit "mail" compressed
QUOTED-PRINTABLE
UNIX-UUENCODED-COMPRESSED - for those who have to
communicate with UNIX
UNIX-COMPRESSED - 8-bit UNIX compressed
BINHEX - for those who have to
communicate with Macs
(possibly 5 or 6 others)
As phase-in progresses, I'd assume that the first 4 encodings would
become more common, the rest less common, which should be encouraged,
but not mandated. I'd like to avoid mixing "styles", which is why
BASE64-UNIX-COMPRESSED is not up there. Note the absence of 7BIT, 8BIT,
or BINARY. Most of the above could be handled with 7BIT; the use of
8BIT or BINARY is not really about the encoding of the message-body, but
about the assumptions made about mail transport. Perhaps they could go
in the apocryphal "Codeset" or "Charset" headers, which would be
orthogonal to the Content-Encoding header.
Bill