David Herron's message exemplifies exactly what I don't want to see
happening with the Content-Encoding header. We have a fundamental
difference of philosophy here: some of us see Content-Encoding as a
very simple mechanism to solve the 7-bit-limited-line restrictions of
SMTP. Others see it as an open-ended mechanism that might eventually
solve, for example, the problem of splitting large mail into multiple
pieces.
The problem of sending 8-bit and binary data through the mail is a VERY
important one. That's why this whole can of worms was opened up. To
solve it properly, and to see that solution widely implemented, we need
a simple solution. The simpler the solution, I believe, the more likely
it is to see widespread implementation. David's notion of
Content-Encoding might or might not be viewed as far more elegant, and
its certainly more powerful, but I'd hate to see it become the sticking
point that prevents binary mail from becoming a "standard" part of the
internet infrastructure.
Incidentally, all of David's examples can, I believe, be handled with
Content-types, at the cost of the proliferation of lots more
content-types. But this is much better, in my opinion, because
content-types don't need to be universal. Content-types are useful as
long as they are understood by a cooperating set of User Agents. I
don't believe that this is as true of content-encodings, primarily
because I think of content-encodings as something that users will often
be totally unaware of. That is, I'll be aware that I'm sending you,
say, an image, but I won't be aware of its base64 encoding. Therefore
I, as a user, might reasonably be expected only to send you an image if
I know you can receive it, but I can't reasonably be expected to worry
about what encodings you can handle. That mechanism should be standard.