I agree. 8BITMIME has largely failed (strictly speaking, announcing
8BITMIME requires body rewrite features in mail relay software). We
should not introduce similar functionality, as an RFC for that will
be ignored, implemented incorrectly, or not implemented due to the
involved complexity.
It's a different world now. At the time 8BITMIME was defined few MUAs
supported MIME, but many could display 8bit text in message bodies
as long as it wasn't MIME encoded, and sender and receiver happened
to use the same character set. And given the demographics of the
Internet at that time, there was at least a fair chance that both
sender and receiver used iso-8859-1 (though many others were in use).
At the present time most MUAs support MIME encoding. Essentially all
MUAs that support utf-8 also support MIME; thus they are able to decode
2047 headers and use the proper character encoding for display. OTOH
unlabeled 8bit text in message headers is not treated consistently
across MUAs, and there are many more character sets in wide use than when
8BITMIME was defined. Though it is generally possible to distinguish
between several of the popular encodings even without tagging, it's
probably the case that header text encoded in 2047 is more likely to
work with existing MUAs than unencoded utf-8.
The real problem with 8BITMIME was that it essentially forced the
MTA to make a guess about whether the recipient's MUA supported MIME.
I agree that we don't want to do that again. MTAs should be encouraged
to handle relayed messages as transparently as possible.
However, the benefit in doing so is mostly for the long term. It still
won't permit us to use unencoded utf-8 in message headers in the near term.
Keith