Harald Tveit Alvestrand writes:
Excuse me,
I thought at an earlier stage that I could write a Norwegian name
in the 822-phrase part of the To: field by having the message look
like this:
I can now see no way of expressing this.
I may have missed a few turns (it is easy to lose one's way in these
megabytes), but lacking the possibility of printing non-ASCII characters
in header lines will be a SHOW-STOPPER in this part of Europe.
Comments?
First of all, you are correct in saying that there is no way of expressing 822
headers in a different character set at present. However, this is not directly
linked to nested encodings. It is possible to have nested encodings without
allowing alternate character sets in headers (in fact, I believe that this is
how it was in the pre-Atlanta draft, which did allow for nested encodings). It
is also possible not to have nested encodings and allow alternate character
sets in headers. The only relationship between these concepts is that nested
encodings do provide one particular mechanism that can be used to deal with
different character sets in headers.
I also believe that you are incorrect in saying that this is necessarily a
SHOW-STOPPER for anyone (except perhaps you). RFC-XXXX originally provided a
mechanism for using alternate character sets in headers. This was shot down in
flames some time ago. In fact, I believe that at least one European meeting
contributed to its demise -- there was insufficient support for the _concept_
of alternate character sets in headers to keep our proposal in the RFC. You'd
have to check the list archives to verify this, however.
My personal feeling is that Keld's mnemonic encoding offers an excellent
approach for representing non-ASCII characters in message headers. In fact,
this could be implemented via a specification that's completely separate from
RFC-XXXX. All that would be needed is a header line that says what character
is used to introduce multi-character encoded characters in the various
text areas used in message headers. This would be an extremely convenient
mechanism from an implementation point of view, I assure you -- much more
convenient than nested encodings are.
Ned