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

À 23:58 17-12-96 +0100, Koen Holtman a écrit :
>The Montreal IETF took place *after* the end of the last call.

I'm afraid not. The deadline was July 5th, see
<http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q2/thread.html>.  It
was late, very late (mea culpa, I was too busy before) but not too late.

>>RFC 2026 (The Internet Standards Process -- Revision 3) contains ...
>
>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.

Let's review my 4 points in this light:

1) (Default entity charset is Latin-1) This is plain wrong, various clients
assume other defaults depending on their users needs.  Netscape, Microsoft
and others will not stop letting their users set their own default because
the spec says Latin-1.  Dropping that language would not change the
protocol, it would align the spec with reality.

2) (All clients support Latin-1) This is not true, implementers will have
to live with it, and again dropping the false claim would align the spec
with reality, not change the functionning of anything.  I just don't
believe all low-end browsers will automagically start supporting Latin-1 on
non-Latin-1 platforms because the HTTP/1.1 says so. Implementers relying on
that statement will be misled.

3&4) (Latin-1 and English defaults for Warning:) Since the text is not
processed by the protocol (only the numeric code), the functionning would
not be impacted by changing the defaults to something sensible (like UTF-8
and None).

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

UTF-8 bits are no more yucky than ASCII; both are just encodings for
characters.


This is not an issue for HTTP 1.2, but with 1.1.  If Latin-1 goes as the
Warning header default, I'm sure arguments will be made when designing 1.2
that compatibility with 1.1 must be preserved at all cost, just as this
argument was made repeatedly for 1.1 vs 1.0.  There is no coming back.

I think RFC 2026 allows the WG to fix those problems without delaying
HTTP/1.1 at all, without endangering its status as Proposed Standard and
without resetting the clock for Draft Standard.

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 13:31:19 UTC