Keld Simonsen writes:
On advice from the 822ext WG chair, Greg Vaudreuil, I have split
rfc-char up in two parts:
1. rfc-char which has all the mnemonics and charset tables
2. rfc-mnem which describes the MNEMONIC family of charsets.
In the process iso-2022-jp was removed.
Should it be included in rfc-char or have its own spec?
I think it would be useful to have a separate document for
"iso-2022-jp". My current ideas: this document should specify the
encoding as currently used in JUNET, and it should name this encoding,
so that the name can be used in MIME headers (presumably the
"charset=..." stuff).
Since the encoding that we have been calling "iso-2022-jp" has been
used for many years in Japan, it is important that we give it a name,
and provide English-language specs for future implementors and to
satisfy Internet RFC procedures. In my opinion, it would not be such a
good idea to attach the rfc-char and/or rfc-mnem anchors to
iso-2022-jp, since we want iso-2022-jp to be usable almost
immediately. In other words, I don't want iso-2022-jp to be slowed
down by any imagined or real controversy surrounding rfc-char and
rfc-mnem.
From the point of view of modular design of RFCs, it is also better to
make iso-2022-jp separate.
I am willing to help write an iso-2022-jp document, but I think it
should be subject to JUNET approval (of course).
Randall Atkinson writes:
The specification for CJK usages (which we have been
calling iso-2022-jp for a while now, though I increasingly
dislike that nomenclature because it isn't pure iso-2022
and it isn't just Japanese any more) should be a separate
distinct draft that refers back to MIME on the architecture
of the extensions.
I'm currently thinking that it may be good to separate Korean and
Chinese from iso-2022-jp. Again, from the modularity point of view.
Also, the Korean and Chinese usages would be far newer and less
established, so setting iso-2022-jp in stone separately should be no
problem.
I also have doubts about the name "iso-2022-jp" since the JUNET
encoding is really an ISO 2022 subset with an additional, non-ISO-2022
rule. We should probably discuss this issue a little more.
I should also mention that there is serious discussion
of having Vietnamese (which won't fit in 8-bits or 7-bits)
supported by the same draft that hopes to handle CJK.
I and a couple of others from the Vietnamese Standards
Group are participating in the subgroup that Erik is
sponsoring to try to see if we can make this feasible.
I am very interested in working on a multilingual encoding (that
includes Vietnamese and the CJK languages among others), but I now
feel that this should be put on a slower track, so that we can take a
better and closer look at all the issues. I.e. I'm not against the
idea, but I feel that we should separate "iso-2022-jp" from all this.
Regards,
Erik