Well, basically it is the same, but with some improvements and
enhancements. MIME should be enhanced in the same way, to remedy
the inconveniciences found in 2 years of MIME practice.
Sure. Just make the default charset not US-ASCII but ISO-2022-INT-*
(described in draft-ohta-text-encoding-01.txt) and add more elegant
header encoding and everything will be fine. Just a minor update
and we don't need 8 bit supoort.
Uhhh...maybe not. The requirements for encoding text in headers are
more stringent than for the message body. In particular, you have
to make sure that any characters that are "special" to RFC 822, do
not appear in the ISO-2022-INT-* encoded form of text.
That's why I wrote "more elegant header encoding".
If they do,
you still need "Q" encoding at least.
That's a possibility though we don't need charset labelling nor control
character escaping.
The other painless approach is not to use non-ASCII in structured headers.
But this is really beside the point.
Everyone agrees (including the author!) that 1522 is ugly. But at this point,
UNLESS THERE ARE UNFIXABLE TECHNICAL FLAWS in 1522,
IMHO, charset labelling is the one. But it's possible to not to use it
without pain.
any attempt at solving this
problem in a way which is incompatible with 1522, is a non-starter.
What is "this problem"? Ugliness problem can be solved simply by not
using the ugliest part of MIME.
Masataka Ohta