Re: Fwd: Registration of 6 charsets

[erik@netscape.com (Erik van der Poel)]

"Martin J. Duerst" wrote:
> 
> JIS X 0213, for each of it's characters, lists the ISO 10646
> equivalent. That's very nice for the characters that have equivalents
> in ISO 10646.
> 
> However, JIS X 0213, for those characters that at present do not
> have an ISO 10646 equivalent, also lists a value. These values
> are given in parentheses. Some text in JIS X 0213 says that these
> are not normative, but that's difficult to find for a Japanese
> reader, and impossible for somebody not speaking Japanese.
> 
> Some of the values in parentheses may turn out to coincide
> with the  values that will eventually (hopefully rather soon)
> be assigned to these characters by the relevant groups, but some
> of them definitely won't coincide.
> 
> Those values in parentheses are therefore a serious potential threat
> to interoperability, and I consider it absolutely necessary that
> both the RFC-to-be and the registrations themselves contain a very
> clear warning on this issue.

No, I would prefer it if IANA took an even stronger stance than that.
These new charsets should be rejected on the grounds that JIS X 0213
itself seriously breaks the rules. People ought to have learned by now,
and it is simply unacceptable for a national standards body to make such
an egregious mistake at this point.

My suggestion is to ask the Japanese standards body to republish (if it
has already been published) JIS X 0213 with those parenthesized code
points either removed or at the very least changed to PUA (Private Use
Area) codes, similar to the MathML spec's use of PUA in MathML 1.0:

  http://www.w3.org/TR/REC-MathML/chapter6.html

> And there is now doubt that the things should be registered,
> with the necessary precautions.

Would that be "now doubt" or "no doubt"?

> >    Shift_JISX0213, Shift_JISX0213-plane1, EUC-JISX0213 and EUC-
> >    JISX0213-plane1 are intended to be used internal to hosts or
> >    applications and not suitable for use in MIME
> 
> As I have said before, this is wrong. 8-bit MIME has no problems
> with them.

Instead of using the technical "suitable for use in MIME" requirement,
it might be better for the spec to simply say that the iso-2022-jp-3
variants are recommended since almost all messages over TCP/IP in Japan
use iso-2022-jp, with which it is intended to be compatible (I assume).

Erik