Re: Warnings, RFC 1522, and ISO-8859-1
Francois Yergeau (yergeau@alis.com)
Sun, 22 Dec 1996 22:05:51 -0500
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=
=2E
># 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 abou=
t
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 assum=
e
(wrongly) that all 1.0 clients support 8859-1 (#2 above), resulting in ba=
d
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 n=
ew
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 t=
he
8-bit channel with 8859-1, with no justification whatsoever, is an obstac=
le
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 oth=
er
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 internationa=
l
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 unlikel=
y.
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 RF=
C
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=E7ois Yergeau <yergeau@alis.com>
Alis Technologies Inc., Montr=E9al
T=E9l : +1 (514) 747-2547
Fax : +1 (514) 747-2561