At 10:19 99/08/15 -0700, Frank da Cruz wrote:
> Michael Everson wrote:
>
> > >UTF-16
> > >UTF-16LE
> > >UTF-16BE
> > >
> > >I need to, as area director, to know wether it is wrong or right to do this
> > >registration.
> >
> > ... my guess is that you should have a MIME alias when there is a unique
> > escape sequence in the ISO-IR. So if the ISO-IR specified 3 escape
> > sequences for UTF-16, then you'd need 3 different MIME names. But Keld will
> > doubtless correct me if I am wrong.
> Right, but the three registrations have nothing to do with byte order.
> They have to do with conformance level:
>
> Level 1: Registration 193 (no combining chars, no Hangul Jamos)
> Level 2: Registration 194 (no combining chars)
> Level 3: Registration 195 (no restrictions)
This is the wrong way round, Hangul Jamos are only alowed in Level 3.
Also, I have found no indication that the IR distinguishes byte order,
or allows only one byte order http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm.
Neither does ISO 10646 forbid one of the byte orders. Also, the idea
to use UTF-16LE and UTF-16BE came from the Unicode Technical consortium,
and UTF-16 is used in XML.
Given the vast number of useless charsets in the IANA registry,
I don't understand why there is such a discussion about this one.
It's indeed against some of the Internet principles to have these
three registrations (while Keith and Fred have both very well pointed
out that it's in accordance with a lot of MIME experience), but
the harm caused by them is fairly minimal.
> I totally agree that, if IANA should register character sets at all, they
> should follow the IR.
As already pointed out, the IR only registers numbers and byte values
for ISO 2022 escape sequences. For IETF, we need labels. Registration
of vendor-specific character sets that don't fit ISO 2022 has not been
very popular for a lot of years (although possible); I don't know
why that should suddenly change.
Regards, Martin.
#-#-# Martin J. Du"rst, World Wide Web Consortium
#-#-# mailto:duerst@w3.org http://www.w3.org
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:51 EDT