From: Neil(_dot_)Katin(_at_)eng(_dot_)sun(_dot_)com (Neil Katin )
Summary and Strawman Proposal
Define a single new content-transfer-encoding, compressed-base64.
This will provide compression for existing 7 bit transport. Should
binary transport be widely available in the future, and the need for
compression be demonstrated in this environment, a compressed-binary
may be defined later.
1. we should use the CTE field for compression. I'm on record
as not favoring this technique because it assumes a single
(or very small number) of compression values. Architecturally
I think this is the wrong answer -- I think one would want
to use compression (or the generalization of compression --
a general "filter" field) for any content type, especially
video, image, or audio.
I've been following this conversation and I'm convinced that going for
a minimum number of options and using CTE('s) is best from the point
of view of interoperability as well as consistency with the MIME way
of doing thngs.
But I have to admit that Keith has made a good argument
as to why this is "too late", and we would run into
compatibility problems with existing UAs
2. However, I really object to only having a compressed-base64
CTE. While SMTP is only 7 bit, and will probably be that way
for the forseeable future, MIME is larger than that. In particular,
we've seen other internet protocols like Gopher and Netnews, both
of which have binary transports, want to adopt MIME. Why should
we set up extra, arbitrary barriers for them. In addition, a
compressed binary CTE is very useful in the purely local case
(which is outside our design charter, but still a valid
target for some of us...).
However, I agree that compressed-binary should be defined from the
beginning. If it's need is anticipated in mail, that would be enough
reason, but the potential for use of MIME or MIME-like messages within
other protocols seems like the clincher to me. Who knows, even the
next verion of IRC might use MIME so you could send sounds, etc., as
well as text.