W3C home > Mailing lists > Public > ietf-charsets@w3.org > April to June 2001

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

From: Mark Davis <mark.davis@us.ibm.com>
Date: Mon, 14 May 2001 10:48:14 -0700
To: Patrik Fältström <paf@cisco.com>
Cc: ned.freed@mrochek.com, Harald Tveit Alvestrand <harald@alvestrand.no>, ietf-charsets@iana.org
Message-id: <OF15C5D119.27334F47-ON88256A4C.0061936F@rchland.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 Davis, IBM GCoC, Cupertino
(408) 777-5850 [fax: 5892], mark.davis@us.ibm.com, president@unicode.org

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,
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
Received on Monday, 14 May 2001 13:53:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:52:17 UTC