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

The Montreal IETF took place *after* the end of the last call.

See for instance the thread about the "charset flap" in
><http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q2/thread.html>, with
>the end in Q3
><http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/thread.html> as well
>as another thread "proposed HTTP changes for charset".

Interesting reading.  I was not present in Montreal, and I did not remember
the resulting thread.  I guess I'm not very qualified as a historian of this
issue.

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

I don't think you can take advantage of the language above.  The magic words
are "that does not represent a change in overall function of the
specification".  Changing the charset defaults _would_ represent a change in
the overall function of the specification.

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

Ah, but that text only gets consumed by humans _after_ the user agent has
stripped off the yucky bits.  The complete warning header is never seen by
end users, even if it has the 99 code.

>François Yergeau <yergeau@alis.com>

Koen.

Received on Wednesday, 18 December 1996 00:14:23 UTC