Re: [idn] Re: 7 bits forever!

[Keith Moore <moore@cs.utk.edu>]

> 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