I'm injecting myself into this discussion with considerable reluctance,
since I find I have a lot of sympathy for both sides. In the hope of
restoring a little calm, let me try to call out and reinterpret a few
things that have been said before in other forms:
(i) We are really going to get only one chance to get non-ASCII in
headers right. We had better do it right, and that means that we should
not try to stuff half-considered solutions into RFC-XXXX in order to meet
some artificial deadline. I think it also means that we should avoid
"let's do some headers now and a few more later" solutions, since they
tend to lead to either incompatible changes or horrible kludges.
(ii) Not liking the implications of (i) doesn't change it. I don't like
them. But I see the inevitability. Similarly, not liking the fact that
the work on complex message bodies got far ahead of the work on completely
"internationalized" simple messages (I take that to include the
user-specifiable, non-<mailbox>, header fields) doesn't change the fact
that it happened or roll back the clock.
(iii) 8bit transport may solve some problems, but simplistic approaches
to it don't. Especially where the message headers are concerned, one can
start altering the rules and assumptions that 822 specifies only if
something can be easily and accurately recognized as a *different* message
format, not merely an "extended" one. And those assumptions include, in
one form or another, "7 bit characters, recognized and treated as ASCII".
The only ways to insist that a receiver interpret them in some other way
require either agreement in the transport envelope or a private agreement
that takes you outside the normal Internet transport and mail models.
Again, look at the RFC-ZZZZ draft. It explores the issues involved in
really doing headers in an alternate character set. What it comes up with
may be so complex as to not be worthwhile, or there may be an entirely
different model that would meet the same needs and be less complex. But
the thing that I think is important is that very little of the theory
there--a theory that changing the headers in basic ways really requires
announcement and agreement in the transport envelope--disappears even if
one restricts oneself to seven-bit transport.
Now the key here is to figure out what constitutes a "basic way".
Probably we can get international characters into headers without
transport announcement. But I think such a thing requires very careful
analysis and consideration, not quickly-thrown-up ideas.
To illustrate this point, I'm not even confident that Mark's "+ CharSet
String" approach is adequate. Consider a hypothetical message whose
content was "the telephone number you gave me did not work" coming from
someone with an unlucky combination of country and city codes. Might one
end up with a Subject line of
Subject: +8859-6-555-1212 doesn't work
using one of the standard models for representing such numbers?