I was hoping that the ISO 2022 discussion would not spill out of our
little iso2022 mailing list, but now that it has, I had better explain
a couple of things.
Some time ago, I promised (to the ietf-822 list) to get in touch with
some Asian people (from Korea, Taiwan and Japan) to discuss the use of
ISO 2022 in Internet email.
Around a week ago, I finally got around to doing something about this,
and sent a message to several people, which sparked a discussion and
later led to the formation of a little mailing list.
My personal opinion is that our intention should be to continue
discussing on the iso2022 mailing list for a while, until we have
reached consensus, and then present the output of our work to the
ietf-822 group for review and comment, and probably more changes.
On the other hand, this is an open process, so I hereby invite
interested ietf-822 participants to join our list, by sending your
email address and human name to:
iso2022-request(_at_)sran8(_dot_)sra(_dot_)co(_dot_)jp
And now to respond to some specific comments:
All this does not mean that there's no place for other uses of 2022 in
MIME. You should feel free to write a specification of how to specify 2022
usage in MIME. Just don't try to pack it all in the charset parameter -- that
is certain to be wrong. My personal favorite way is to have 2022 as a
subtype of text and then have parameters to specify the specifics of the
initial 2022 state.
I have also been thinking of making the 2022 subset a subtype of text.
The RichText specification says that literal "<" characters must be
quoted using "<lt>". If this type of change (i.e. "<" -> "<lt>") were
to occur within Japanese text encoded in ISO 2022, the resulting text
would be unreadable on unextended viewers, and the even number of
bytes would become odd. (Each Japanese character is encoded with two
bytes, whose values are equal to ASCII printable characters,
including, of course, "<".)
So, instead of writing
Content-Type: text/richtext
and having simple richtext programs fail when Japanese text is used, I
was thinking along the lines of something like
Content-Type: text/iso-2022-s; richtext
I.e. richtext is a parameter, without the "value" part of "name=value"
(since it isn't needed).
I realize that this type of comment may not be welcome at this point
in time of MIME's evolution, but I figure it's better to say this
sooner rather than later.
Don't expect to see this material incorporated into the base MIME document.
However, just because it won't be in the base document is no reason to
refrain from doing it. The whole point of MIME is that it is extensible, and
we expect to see lots of extensions made to it.
Once again, I request the removal of the ISO-2022-jp charset
definition and the associated appendix from MIME. It now seems highly
likely that the iso2022 group will come up with a separate document,
so the incomplete prose in MIME should (in my opinion) be removed.
Sincerely,
Erik M. van der Poel
erik(_at_)sra(_dot_)co(_dot_)jp
Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692