Re: Accept-Charset support

On Wed, 11 Dec 1996, Larry Masinter wrote:

> Martin,
> 
> You haven't really said what's wrong with HTTP/1.1's choice of using
> RFC 1522

Larry,

I didn't really oppose the choice of RFC 1522. Therefore you
indeed did not see much arguments against it. What I (and others)
strongly oppose is the exception for ISO-8859-1.

>for warning messages except that
> 
>  - you think it is brainless stupidity
>  - RFC 1522 was originally designed for something else
>  - there's no reason to not have chosen something else
>  - 'everybody in the i18n business' uses UTF-8
> 
> However, it wasn't 'brainless stupidity', in that the issue got fair
> consideration and a reasonable amount of thought. I believe that our
> consideration was that operating systems and web configurations on
> servers that normally do not use unicode internally should not be
> constrainted to convert the warning message strings to unicode merely
> to display an error message.
> 
> Furthermore, the design doesn't preclude using Unicode, albeit RFC
> 1522's =?UTF-8?Q?method?= is a bit awkward, it's only a 12-byte
> overhead on a warning message.

I haven't specifically argued against RFC 1522. If it was only
RFC 1522, I would not object. I agree that it may still
be too early to have implementations convert their messages
to Unicode, and that there fore a way to transmit and label
legacy codings is needed, and that in the context of HTTP
warnings, RFC 1522 may be a reasonable solution given these
requirements.

However, what I (and others) object against very strongly is
the combination of RFC 1522 with the exception for ISO-8859-1.
If everybody has to use RFC 1522, there must not be an
exception for ISO-8859-1. ISO-8859-1 and Western Europe is
not really anything special. If we choose RFC 1522, then
everybody should use it, there should not be any exceptions.

And if we choose to make an exception, i.e. to use full 8-bit
with a special encoding, that should be something that is
useable globally, and has long-term perspectives, such as UTF-8.
Clogging up the 8-bit channel with something as limited as
ISO-8859-1 is where the problem lies, not using RFC 1522 for
tagging.

While you give reasons for why RFC 1522 was choosen, and I
can accept these reasons, you don't give any reasons for
the ISO-8859-1 exception, and I couldn't immagine such
reasons. In contrary to HTML pages, there is not a large
base of existing HTTP 1.1 implementations that use raw ISO-8859-1
for warnings, and even if there should be one or two implementations
around at the moment, there certainly weren't enough at the
time this was discussed.

So my main request is clearly to remove the exception for
ISO-8859-1. Whether this is replaced by an exception for
UTF-8 or not is a minor issue (I would advocate it).
In case there are really strong reasons for the ISO-8859-1
exception (which I doubt), my proposal is to allow an
exception for both ISO-8859-1 and UTF-8, and to gradually
move the implementations to only use UTF-8 with raw encoding
and switch to using RFC 1522 for everything else including
ISO-8859-1.

We really know we have to get serious about internet
internationalization. And we know the direction we have
to go and the ways to go there. There is really no need to
set a bad example in an otherwise well-designed protocol
such as HTTP 1.1.


Regards,	Martin.

Received on Thursday, 12 December 1996 05:47:59 UTC