Re: Charset support (was: Accept-Charset support)

On Dec 15,  1:49pm, Klaus Weide wrote:

> On Fri, 13 Dec 1996, Martin J. Duerst wrote:

> > Then let's make this file (and a little bit of code to
> > extract the desired warning) available to implementors,

good so far

> > and let's ask them to just send the strings out as is,
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > and just silently ignore the antiquated ISO-8859-1 default
>       ^^^^^^^^^^^^^^^^^^^^
> > for warnings, and silently change that to UTF-8.
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is it possible for any Unicode character, when converted to
UTF-8, to contain a byte which is 0D or 0A? I suspect, looking at
the UTF-8 algorithm, that this is the case. How then should a
compliant HTTP/1.1 implementation tell when the HTTP reason code is
finished, if it can contain bytes that look like CR and LF?

> Sounds like an extremely bad idea.

I agree.

> The HTTP 1.1 draft is accepted and is going to become an RFC.  That
> is done and over.

It ain't over til the RFC editor sings.

> If you think that
> part of it is really unacceptable, you should try to take that up with
> the http-wg

Yes, there is always room for a compelling and well argued case. However,
is this really the number one i18N issue? Response codes are for human
debugging; it is probably more important to ensure that multilingual
content can be delivered, multilingual response codes are really just
icing.


> > Interestingly enough, with this solution, the server side
> > does not have to worry AT ALL about what encoding the
> > warnings are in, how to convert that encoding to something
> > allowed, how to implement RFC1522, or whatever.

This is all good and true. It does need to worry about how to display
Tibetan and Urdu translations of "OK". Then again, so does the current
scenario, given a full implementation. Are there any browsers or servers
that generate or decode response phrases encoded a la RFC1522?


>   I found no requirement in HTTP 1.1
>   that a client must use the Warning text sent to it, so I assume it is
>   compliant behaviour if the _client_ creates a message in the appropriate
>   language (after recognizing the number).

Yes, of course.

>   The client program is in a
>   better position to know the user's preferred language(s).  Maybe that
>   is the approach that will be taken by implemetations.

The client can also personalise the human-readable response based on the
expertise of the user.


--

Received on Monday, 16 December 1996 09:02:06 UTC