My point was that the argument that it's bad and evil to make an
incompatible change that would mean that 8 bit data would circulate
somewhere where it's not allowed in the current standards is weak
because the actual situation is that a lot of 8 bit data is being sent.
no, it doesn't follow. yes, a lot of 8-bit data is being sent,
but there's also a very good chance that that data is not being
displayed correctly at the recipient's end. most mail handling
tools have learned not to crash when presented with 8-bit header
text, but there is no good convention for how to interpret such
text. (and simply saying "use utf-8" doesn't work
And that the current endorsed solution for sending non US-ASCII data
(RFC2047) has so many problems that in many situations, messages are
more likely be handled correctly by sending them in raw 8 bits that by
using RFC2047.
strongly disagree. yes, text that is repeatedly unencoded and
re-encoded by lots of different user agents is likely to get corrupted
at some point. but that situation seems to be improving. and 2047
is more likely to be presented correctly.
Keith