Re: Registration of new charsets UTF-32, UTF-32BE, UTF32LE

[Mark Davis <mark.davis@us.ibm.com>]

It really comes down to having unique names for unique formats. After all,
if I am going to serial LE into fields in a database, I can simply make it
clear that that is "UTF-16LE", not "UTF-16". It is then clearly identified
exactly what the format is, and does not require a BOM.

Mark
___
Mark Davis, IBM GCoC, Cupertino
(408) 777-5850 [fax: 5892], mark.davis@us.ibm.com, president@unicode.org
http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=10275+N.+De+Anza&csz=95014



Patrik Fältström <paf@cisco.com> on 05-12-2001 03:48:58

To:   Mark Davis <mark@macchiato.com>, ned.freed@mrochek.com
cc:   Harald Tveit Alvestrand <harald@alvestrand.no>, Mark
      Davis/Cupertino/IBM@IBMUS, ned.freed@mrochek.com,
      ietf-charsets@iana.org
Subject:  Re: Registration of new charsets UTF-32, UTF-32BE, UTF32LE



--On 01-05-11 10.06 -0700 Mark Davis <markdavis34@home.com> wrote:

> However, if the IETF liaison wants to present a proposal to restrict
> UTF-16 and UTF-32 -- when used as a serialization into bytes, to being
> only BE if there is no BOM, I believe that the UTC would certainly take
> that into consideration. The next meeting is happening very soon...

We have had such discussions, or rather, asked what IETF can/should do to
make sure that we don't get different byte orders inside protocols and at
the same time not override what UTC does.

As you say, UTC definitions are not only used in protocols but also stored
data on disk, and that is for historical reasons in different byte orders.
Going away from that fact is difficult -- even though it would be nice.

Can IETF do something which might help you think?

   Patrik, Liason from IETF to Unicode Consortium