Re: Warnings, RFC 1522, and ISO-8859-1

On Mon, 16 Dec 1996, Koen Holtman wrote:

> Martin J. Duerst:
> >
> >Hello Koen,

> >> The TEXT encoding was US-ASCII in HTTP/1.0 (RFC1945),
> >
> >Not true. RFC1945 explicitly allows octets from character sets
> >other than US-ASCII (which means octets with the 8th bit set).
> 
> Yes, but it does not tell you how to interpret octets with the 8th bit set.
> So the bottom line is that you can depend on US-ASCII and nothing else.

If that's the bottom line, why was the ISO-8859-1 default introduced?
It's quite a lot more difficult to distinguish ISO-8859-1 from
ISO-8859-2, -3, -4, -9, and -10, than distinguishing UTF-8 from
any legacy coding whatsoever.

> [...]
> >> but it got changed
> >> into ISO-8859-1 for HTTP/1.1 because HTML uses ISO-8859-1.  
> >
> >HTML 2.0, as of Nov. 1995 (RFC1866) already contained very
> >clear language that HTML will move to ISO-10646.
> 
> RFC1866 also contains very clear language about HTML user agents supporting
> ISO-8859-1 by default, so this is what we took.

There is a big difference between what *set* of characters a client is
required to support and what kind of *encoding* should be choosen as
a default.
 

> I'm not an expert on this small draft business, but I think it will be
> difficult to have a small draft which changes HTTP/1.1 semantics (instead of
> just adding to semantics or clarifying semantics) without also having a
> procedural delay.  I believe it is ultimately up to the IESG, though.

If that is a problem, there is an easy way out: We just don't tell
the IESG about the changes we want to make until after the big
HTTP/1.1 is out. Anybody know any more details?


> As for the direction on this issue: I'm not convinced that there is anything
> that needs fixing.  I gather that the Warning header definition is extremely
> yucky from a i18n standpoint, but that does not justify changing it.  There
> are plenty of yucky headers in the protocol, but the headers are not meant
> for human consumption, so who cares about taste?  Stability is more
> important.

Are there any 1.1 server implementations that send warnings?
Are there any 1.1 server implementations that send warnings
in anything else than English? If the warning headers are not
intended for human consumption, then why are they there in the
first place? If headers are not intended for human consumption,
why bother with a small distortion of ISO-8859-1 characters
that are sent out as UTF-8 but displayed directly as ISO-8859-1,
if we can get on the right path for the future?
In an earlier mail, you have mentionned that there is always
a new version. Now you say that stability is more important.
If you cite stability already at this point, won't you stress
it much more when the issue will be raised again when going
to a new version? Isn't it better to change as fast as possible,
before existing implementations make it too difficult to change
anything?

Regards,	Martin.

Received on Tuesday, 17 December 1996 03:22:06 UTC