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

[MURATA Makoto <murata@apsdc.ksp.fujixerox.co.jp>]

Martin J. Duerst wrote:
>   - "The contrapositive ... is not always true ...": In general,
>     you are right. But this spec should contain rules for when a
>     0xFFFE is a BOM, and when it's a ZWNBSP, otherwise we are not
>     interoperable, and this sentence should contain a pointer to
>     these rules.
> 
>   - "Also, some specifications mandate an initial 0xFFFE character
>     ... and specify that this signature is not to be removed.":
>     All this stuff is blurring the architectural boundary between
>     the character layer and the application layer. This is a bad
>     idea.
> 
>   - The text here should clearly say that the use of a BOM at the
>     beginning may result in desinchronization of various parts of
>     the system. For mail, that's maybe not so much of a problem,
>     but more for other systems (e.g. HTTP) that are also based on
>     MIME.
> 
> - 3.2/3.3 Serialization in UTF-16BE and UTF-16LE
>   You treat the BOM only on the receiver side. What are senders
>   supposed to do, put one in or not? My strong suggestion is to
>   say that the MUST NOT put one in. Note that for BE and LE, we
>   can still define things the way we think it's best, and we
>   should use that chance.

I have a question.  I know that many people would like to make the 
BOM optional.  But what is the reason for making it optional?  
If we can say that the BOM is mandatory and is merely an artifact for 
encoding, this RFC becomes much simpler.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: murata@apsdc.ksp.fujixerox.co.jp