RE: Revised proposal for UTF-16

[Dan Kegel <dank@alumni.caltech.edu>]

At 04:33 PM 5/25/98 PDT, Larry Masinter wrote:
>> Perhaps the key is to ALWAYS send a BOM.  
>> Then the language becomes exceedingly clear and simple.
>
>Wait!  If you want something clear and simple:
>Always send big-endian.
>
>Very clear. Simple. If you do anything else, well, you're non-standard.
>
>I don't know why people want to make this more complicated than it
>needs to be.

True, that would be acceptably simple, and technically good.
But I suspect Redmondians (is that a new synonym for 
little-endians?) would take more kindly to
"insert these two bytes" than to "admit that
your way of looking at the world is wrong".

The underlying standard has the BOM.  
The authors of that standard knew the issue was
a hot potato, and decided to go both ways.

It is false to compare this situation to the
TIFF fiasco.  There is only one bit in question
here, not zillions of vendor-defined extensions.
Going both ways is not the end of the world.

I suggest that if you want to tackle this issue,
and mandate big-endian UTF-16, you should get a few 
people at Microsoft to support you.  That would
probably clinch the deal.  And you'd have my full
support.  But we should write a decisive standard
one way or the other- make it clear that BOM's
are ALWAYS to be used, or NEVER to be used.  
Anything else is too murky to document, IMHO,
and the resulting standard might not be strong
enough to actually follow in the field without
looking over one's shoulder at what the big boys
are doing.
- Dan