Re: Revised proposal for UTF-16

[Chris Newman <Chris.Newman@INNOSOFT.COM>]

On Sat, 23 May 1998, Martin J. Duerst wrote:
> I don't think that we should forbid little-endian. I understand Eric's
> and Chris' arguments, but there is too much practice out there to handle
> both endiannesses together in the context of UTF-16 that I think we
> would just get ignored.

I always find the computer industry's ability to repeat the mistakes of
the past astounding.

When TIFF was defined, it was permitted to be either big-endian or
little-endian.  This led to a chain of events:
* Both versions were generated, although one more than the other.
* Some programs were released which only supported one of the endians
because they only tested against programs generating one of the variants
or assumed files would never be transferred from the other architecture.
* As a result, interoperability problems occurred
* Today many programs include an option to create "PC-style" or
"Mac-style" TIFF images.  This confuses users to no end (although it's
less confusing than trying to explain endian problems to users).

Meanwhile, GIF, JFIF/JPG and PNG have no such problems.  They always work.

The cost of byte-swapping when saving a file is negligable compared to the
cost of supporting two different formats and the interoperability problems
which result.  Ditto for sending data over the network.

Unfortunately, Unicode/ISO-10646 didn't consider these problems when they
defined UTF-16.  But with a historical record so clear on this issue, I
think we would be well justified in choosing not to repeat this mistake.

We should forbid use of little-endian UTF-16 in IETF protocols.  Otherwise
we risk giving the community which opposes Unicode some legitimate
ammunition to fight it.

		- Chris