W3C home > Mailing lists > Public > ietf-charsets@w3.org > January to March 1999

RE: draft-hoffman-utf16-01.txt available

From: Francois Yergeau <yergeau@alis.com>
Date: Wed, 03 Feb 1999 16:33:59 -0500
To: "Martin J. Duerst" <duerst@w3.org>
Cc: medavis2@us.ibm.com, Larry Masinter <masinter@parc.xerox.com>, Paul Hoffman / IMC <phoffman@imc.org>, MURATA Makoto <murata@apsdc.ksp.fujixerox.co.jp>, ietf-charsets@iana.org
Message-id: <3.0.5.32.19990203163359.01e6bec0@www.alis.com>
À 00:10 04/02/99 +0900, Martin J. Duerst a écrit :
>I don't understand this. Either some processor is going to do something
>with the entity for where it matters whether the entity is BE or LE.
>If it's doing this, it has to work on the content anyway. Otherwise,
>it's going to do something where endianness doesn't matter, and it
>won't have to peek inside. Do I miss something?

You're right, it's a minor problem.

>> And perhaps generate illegal stuff, because there turns out to be a BOM
>> after all.  I'm questionning the enforceability of forbidding BOMs.  Let's
>> not make a rule that cannot be obeyed by reasonable implementations in most
>> cases.
>
>I agree. But I think going the other way would be equally fatal:
>Not defining things clear enough, and just do handwaving.

It's not mere handwaving, the basic distinction between UTF-16 and
UTF-16BE/LE is that the former doesn't tell you byte order while the latter
does.  The BOM issue is secondary, is unclear and will probably remain
soemwhat unclear because of the fact that the BOM does double-duty with the
ZWNBSP.  


-- 
François
Received on Wednesday, 3 February 1999 19:15:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 June 2006 15:10:50 GMT