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

They are technical errors, in the sense that either they will result in
widespread disregard for the spec (esp. 1 & 2) or they are simply poor
technical choices, or both.

>- They do not need to be corrected immediately.

IMHO, they need to be corrected before going to Draft Standard. See below.

># The first two are statements of fact that are demonstarbly wrong on
># today's Web. 
>
>They are not statements of fact, they are descriptions of the protocol
>being defined, HTTP/1.1, which did not exist before.

It is amusing that you are making this argument now.  The exact opposite
was made at the Montreal IETF, when I cited the IAB charset committee's
recommendation of using UTF-8 in new protocols: even though the Warning
header was new, HTTP was not a new protocol so the recommendation did not
apply.

Whether 1.1 is a new protocol is indeed debatable.  Take for example the
current thread about response version numbers: the arguments revolve about
a larger model for HTTP, with for instance claims that all 1.x clients
should accept responses of the same major version number.  In that larger
model, 1.1 is not a new, distinct protocol, although it certainly has new
features.

Also, HTTP servers will for a long time have to talk to 1.0 proxies and
clients (and vice versa). In fact, it was a very basic design goal of 1.1
that this can work smoothly.  Yet conforming 1.1 servers can simply assume
(wrongly) that all 1.0 clients support 8859-1 (#2 above), resulting in bad
interoperability. Why is that basic design goal disregarded in this case,
when the fix is so simple? Probably because the 1.0 "spec" had the same
(false) statement; 1.1 carried it over, in which it did not behave as a new
protocol.  1.1 bought compatibility with the 1.0 spec, at the expense of
real interoperability.

># The last two are obstacles to i18n that are not justified by any
># technical requirements.  All four should be modified or deleted.
>
>They do not represent obstacles to i18n.

Yes, #3 does, and #4 does not even deserve further comment.  Cluttering the
8-bit channel with 8859-1, with no justification whatsoever, is an obstacle
to i18n: it becomes impossible to use 8-bit octets with any other charset,
and 8859-1 is not a proper i18n solution.

>None of the proposed changes would actually
>IMPROVE i18n. 

Tongue in cheek?  Having UTF-8 instead of 8859-1 in the 8-bit channel of
the Warning header is not an improvement?  Stopping the lies about the
charset of entities is not an improvement?  Come on!

>Eliminating any other charset than UTF-8 would seriously
>hamper I18N, and if other charsets are to be allowed, RFC1522 encoding
>or some other equivalent is mandatory.

Nobody is asking for the elimination of other charsets. It's 8859-1 that's
in the way as the default in Warning, just change that to UTF-8.  All other
charsets remain as before, under the RFC 1522 umbrella.

>I believe we have heard clearly from a number of working group members
>that they would like to see this change made urgently. However, I also
>believe we have heard clearly from other working group members that
>they would not like to see this change made. In some cases, the
>current scheme is supported as is, and no change is desired. In some
>other cases, working group members believe that the issue could be
>addressed in some future specification, but not in HTTP/1.1.

If 1.1 is to move to Draft, it will have to address this.  Let's look at
the near future, the few-month horizon when 1.1 is due to progress.
Interoperable implementations are needed for that, clients and servers.

Do you think that browser makers will suddenly abandon their international
markets and force their products to always assume 8859-1 as the default
charset for entities?  Not a chance!  Non-western users *need* other
defaults, since servers do not generally label charset, a direct
consequence of the "official" 8859-1 default.

Do you think that substantially all browsers will start supporting 8859-1
on all platforms (incl. code page) on which they might run?  Very unlikely.

Thus, even in the brave new 1.1 world, the #1 prescription will be widely
disregarded, and the #2 assumption will remain very wrong.  The spec will
not be in sync with implementations, for very good reasons, and will not be
suitable for progression to Draft Standard.  Better fix it ASAP.

>In any case, I don't intend to act further on suggestions that we try
>to halt the progression of draft-ietf-http-v11-spec-07.* to RFC,

No such suggestions have been made.  The language I cited earlier from RFC
2026 allows those changes *without* halting publication of draft-07, and
without resetting the clock to Draft Standard. The idea is republication
with a new RFC number and no impact on time-at-level.

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 Sunday, 22 December 1996 19:14:36 UTC