I have the same concern that Bob Smart talked about with respect
to ISO-2022 as a character set. Basically, 2022 is *not* a character
set; it is a character set registry and encoding standard.
As I understand its use (mostly from how we implement iso-2022 at
sun, and from some discussions with our Asian implementation teams)
the common email usage for 2022 use the character set encoding standard
part 2022, but do not use the registry part.
First some background for those who want to follow the technical nits.
2022 defines four character sets locations (numbered zero through three).
There are escape sequences defined for indicating which character set
is actually to be used in each of these locations, There are also
escape sequences defined to switch between the four character
set positions.
However, "common use" of 2022 only uses the character set switching
functionality. As I understand it, mail in Japan never has an
internal identifier that maps the four character set positions to
ascii7/x201/x208/unused (the mappings for japan, for instance).
Instead everyone just "knows" what the mappings are.
I think that rather than trying to define a new defacto usage of
2022, we should just register the existing practice with respect
to 2022. So instead of having a content character set of "ISO-2022",
we should have one for "ISO-2022-jpn-7" (for 2022 encoding, using
the japanese character sets, using a seven bit representation).
This proposal also has the added benefit of clearly identifying,
on the *outside* of a body part, what character sets are actually
in use within that body part.
This will map very closely to existing practice in Japan, Hong Kong,
Taiwan, PRC, and Korea. I believe this is preferable to trying to
define a new and different usage for ISO-2022. If we're going to
change the way that things work today, we should transition to 10646
instead.
Neil Katin
----- Begin Included Message -----