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.
Greg, you are really making two proposals (relative to the email
on the list).
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.
Basically, I view the content type field as picking the
"viewer" of the data, and would like to be able to add
compression of this data between consenting UA's without
having to come up with new viewers.
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...).
Neil