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

Francois Yergeau (yergeau@alis.com)
Wed, 18 Dec 1996 16:22:23 -0500 

=C0 23:58 17-12-96 +0100, Koen Holtman a =E9crit :
>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 w=
ords
>are "that does not represent a change in overall function of the
>specification".  Changing the charset defaults _would_ represent a chang=
e 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 clien=
ts
assume other defaults depending on their users needs.  Netscape, Microsof=
t
and others will not stop letting their users set their own default becaus=
e
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 ha=
s
>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=E7ois Yergeau <yergeau@alis.com>
Alis Technologies Inc., Montr=E9al
T=E9l : +1 (514) 747-2547
Fax : +1 (514) 747-2561