ietf-822
[Top] [All Lists]

Re: non-ASCII in headers

1991-10-02 11:12:53
Alan -

     In fact, I am tolerant of both ISO-646 national variations and ISO-2022
when they are in the *body* of a message.  Neither one breaks 7-bits, which is
by far the more important issue.  In other words, it is a difference that
really makes no difference.

     Headers are something else entirely.  Contrary to popular belief, headers
are not for humans.  They are for programs.  The programs are then supposed to
present the message in whatever form the designer thinks is for the user.  I
continue to be shocked at the number of programs which just dump out the
message, headers and all, in image form with no processing.

     It is absolutely essential that headers stay in US-ASCII, the *only*
character set that we all know about.  This is for the benefit of programs
that read it and a multi-national understanding of what header contents mean.
It is as inane to have alternate character sets in headers as it is to have a
version of BASIC which uses French keywords (I pick this as a real-life
example of stupidity).

     Now, where the problem comes up -- and where we have problems -- is that
headers do have some text that is intended for humans to read, and there is a
reasonable desire on the part of those humans to use their national language.

     We have identified that this is a complex issue and can not be solved in
the timeframe we need to get RFC-XXXX out the door.  We can not hope to
receive closure on this question between now and the next IETF.

     It therefore must be deferred to a new RFC specifically to address this
issue.  I suggest you Europeans start writing up draft RFC's NOW.

     Until that time, the status quo remains.  Whether or not it is `right'
according to RFC-822 or RFC-XXX, the status quo is and remains:
1) you can use ISO-646 or ISO-2022 in the body of your messages as long as
   you are sure the receiver has a compatible character set at his/her end.
2) you *may* be able to use ISO-646/ISO-2022 in the text items of headers
   (names and subject texts) but only with extreme care and with the US-ASCII
   interpretation of those characters *thoroughly* in mind.

     Finally -- to the guy at SUN: I too implemented ISO-2022 support for
Japanese in a mail program.  I did it more than 5 years ago and finished the
project in To^kyo^.  I too implemented it for Subjects, and was told by the
customer that I shouldn't have done so; they do NOT use it in headers because
of interoperability problems.  I correspond a fair amount with people in
Japan, and to this day message subjects of ISO-2022 kanji messages continue to
be in US-ASCII using either English or romanized Japanese.

-- Mark --


<Prev in Thread] Current Thread [Next in Thread>