Re: Charsets: Problem statement/requirements?

Gavin Nicol (gtn@ebt.com)
Fri, 10 Feb 95 08:34:19 EST

>> And so the Balkanisation begins...
>:-) my main point was that we should communicate in the most
>appropriate encoding, and Unicode is the choice in may cases, but
>not always. If we provide the protocol to choose, then all is well.

Sure. Unicode is great as a lingua franca, but we also need to support
local charsets whenever desired....

>We are talking about loosing 1/2 the bandwidth in an Unicode only
>environment.

Correct that to UCS-2....

>My only concern is "Unicode" (input) only clients inhe future in the
>same way we have Latin1 only today.

Hmmm. Interesting point. Even my proposals touch lightly on submitted
forms data... I would hope for a world in which Unicode is accepted as
a least common denominator (most?), and local charsets are used where
applicable for display, and searching....

>Yes my point was when the client says to the server
>
>Accept-Charset Unicode Accept-Language x,y,z
>
>Does it mean the client can handle each one
>individually by switching fonts etc.. as in Mosaic-l10n, or
>it can render all three in one document.

The <emph>implementation</> is beyond the scope of the spec, but I
would hope it would mean that all specified charsets can be displayed
(possibly via transliteration, transcription, or machine
translation), possibly within a single document (and if you supprt one
in a document. supporting 3 is trivial).