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

>Martin Duerst:
>>I definitely don't want to delay the draft. But if we agree on
>>the direction to go in this issue, we can issue a small draft
>>(e.g. Encoding of Headers in HTTP) to clear up the issue.
>>This should neither delay the IETF process, nor will it delay
>>implementations to wait for HTTP 1.2 to do the right thing.
>
>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.

RFC 2026 (The Internet Standards Process -- Revision 3) contains this text
in section 6.2:

   [...] the standards track.  However, deferral of changes to the next
   standards action on the specification will not always be possible or
   desirable; for example, an important typographical error, or a
   technical error that does not represent a change in overall function
   of the specification, may need to be corrected immediately.  In such
   cases, the IESG or RFC Editor may be asked to republish the RFC (with
   a new number) with corrections, and this will not reset the minimum
   time-at-level clock.

IMHO, the following four points in HTTP/1.1 are in error and could (and
should!) be corrected by taking advantage of that language.  Especially
since RFC publication has not yet occurred.

1) The default charset for text entities is ISO 8859-1.

2) All clients can be assumed to support ISO 8859-1.

3) The default charset for the Warning: header is ISO 8859-1.

4) The default language for the Warning: header is English.

The first two are statements of fact that are demonstarbly wrong on today's
Web.  The last two are obstacles to i18n that are not justified by any
technical requirements.  All four should be modified or deleted.

>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.

The text in Warning: headers is meant for human consumption, especially in
the case of a 99 warning.

Regards,


-- 
François Yergeau <yergeau@alis.com>
Alis Technologies Inc., Montréal
Tél : +1 (514) 747-2547
Fax : +1 (514) 747-2561

Received on Wednesday, 18 December 1996 00:41:44 UTC