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:
<<<<< Start of message >>>>>>>>>
Content-type: Message
Content-charset: ISO_8859-1 <------ Outlawed?
Content-transfer-encoding: Quoted-printable <------ Outlawed?
To: H&XFard Eidnes <he(_at_)idt(_dot_)unit(_dot_)no>
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),
...
I suspect that we have all lost a few turns. I *know* I have, it is
part of why I asked earlier this week for reference documentation about
what we were talking about (not necessarily in the form of a revised
RFC-XXXX, but that would do the job).
As I understand it, none of the recent collections of megabytes have
changed this story very much. At most, you would see a syntax change to
Content-type: Message//ISO_8859-1
Content-transfer-encoding: Quoted-printable
Which should not be operationally significant to an originating or
final destination site.
... but lacking the possibility of printing non-ASCII characters
in header lines will be a SHOW-STOPPER in this part of Europe.
It certainly ought to be.
But I'm not aware that any agreement or even pseudo-agreement has been
reached on how to do this, and I don't recall from the minutes that the
Atlanta meeting managed to solve this problem while it was solving all
of the others :-).
If I correctly read the example in the original message, it is an
RFC822 violation, since an RFC822 header collection must contain To and
From. One possibility, which none of the discussions so far would
prevent, would be to do this as:
Content-type: Message//ISO_8859-1
Content-transfer-encoding: Quoted-printable
To: he(_at_)idt(_dot_)unit(_dot_)no
...
<-- note blank line
To: H&XFard Eidnes <he(_at_)idt(_dot_)unit(_dot_)no>
Or to change things around so that this was a Multipart message that
actually contained only one part and use the internal headers.
I'd consider either of those ugly enough to be in the show-stopper
class, incidentally, but I think you folks who have non-ASCII characters
in your own names should stand up for that position.
Other suggestions have included using mnemonic in the headers or,
perhaps also with mnemonic, putting an ASCII-ized form into the
822-phrase and having it point, somehow, to another header or set of
definitions which specify the extended-from-ASCII characters.
I don't think we have reached any resolution on which of these
approaches to use. But I'm fairly confident that none of the debates of
the last weeks have any impact except the argument against nested
encodings. And the correct spelling of a name in an RFC822-phrase is
much more likely to survive translation and remain clear text in the
absence of nested encodings than with them.
--john