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

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

From: Larry Masinter <masinter@parc.xerox.com>
Date: Thu, 19 Dec 1996 12:57:01 PST
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <96Dec19.135701pdt."150"@palimpsest.parc.xerox.com>
# 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.  Especially
# since RFC publication has not yet occurred.

# 1) The default charset for text entities is ISO 8859-1.
# 2) All clients can be assumed to support ISO 8859-1.
# 3) The default charset for the Warning: header is ISO 8859-1.
# 4) The default language for the Warning: header is English.

- These are not typographical errors.
- These are not technical 'errors', in the sense that they were
  conscious deliberate choices made by the HTTP working group after
  lengthy discussion.

In addition, 

- Changing them WOULD result in a change in the function of the
  specification.
- They do not need to be corrected immediately.

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

# 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. I18N is perfectly possible
and supported by HTTP/1.1. None of the proposed changes would actually
IMPROVE i18n. 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.

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.

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, and I
will continue to encourage those who wish to see changes to HTTP to
write them in other Internet Drafts.

Larry
Received on Thursday, 19 December 1996 14:24:21 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:19 EDT