W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

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

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 17 Dec 1996 23:58:55 +0100 (MET)
Message-Id: <199612172258.XAA24870@wsooti08.win.tue.nl>
To: Francois Yergeau <yergeau@alis.com>
Cc: koen@win.tue.nl, mduerst@ifi.unizh.ch, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2103

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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:21 UTC