After further thought, I've concluded that Greg's "Content-conversion"
idea may be the key to a solution here, though with one twist: I'd
prefer to leave it out of this RFC. Here's an explanation.
After many years of experimentation, the Internet has evolved several
mechanisms for sending multipart, possibly non-text objects through the
mail. The original Content-Type RFC (1049) grew out of the Andrew work,
which addressed both the encoding and multipart issues in a
"proprietary" way -- i.e. it had its own encoding and multipart
structures. This was widely (and correctly, in my view) perceived as
inferior to a general "open" solution to both of these problems. RFC
1154 offered a step in the right direction: an "open" solution for the
multipart problem, but nothing general for the 7-bit/long line encoding
problem, and with additional problems (at least in some peoples' eyes --
its not worth reopening the argument here). Thus, this whole RFC is an
effort that is well-grounded in history. I believe that we know what
we're trying to do and why: We're trying to design an open architecture
for encoding multipart messages that might include 8 bit or binary data.
To put it less grandly, we're trying to do things that have already
been done for years by Andrew and other systems, but we're trying to do
it in a standardized way. We're trying to build on LOTS of peoples'
experience to produce an open architecture that everyone can migrate to.
Now, having said that, it is fairly easy to see how most of the proposed
RFC fits this description. I believe the limited definition of
Content-Encoding also fits this description -- it's just a
publicly-defined version of what lots of people have done
idiosyncratically. But then when you look at the broader idea of
Content-Encoding, it seems very vague and nebulous. It's breaking new
ground. Unlike the rest of this RFC, it doesn't strike me as being
potentially "standards track". (Actually, the other part of the RFC
that has that flavor is the header-encoding stuff, but a lot of people
have what I regard as convincing arguments that addressing this issue is
vital.)
If we take Greg's suggestion, but simply punt on defining
Content-conversion for now, that will leave us with something widely
workable, and will the freedom to experiment to people inclined to do
so. After playing with the content-conversion idea for a while, they
will probably be better able to explain why (or even if) they still
think multiple encodings or transformations are a good idea.
In other words, we stick with the "small" idea of Content-Encoding, with
the understanding that if it proves to be inadequate, people can
experiment with a Content-Conversion or something like it in order to
solve the problems encountered. Since no one has yet, as far as I can
tell, clearly enunciated a single inadequacy with the simple
Content-Encoding scheme, this strikes me as a reasoanble approach. How
does it strike the people who have been arguing for nested/multiple
encodings?