- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Sat, 24 Apr 1999 00:50:17 -0700 (PDT)
- To: Deborah Goldsmith <goldsmith@apple.com>, Patrik Fältström <paf@swip.net>, ietf charsets mailing list <ietf-charsets@iana.org>
- Cc: Rick McGowan <rmcgowan@apple.com>
> Based on my search of the RFC database, the following RFCs refer to
> "unicode-1-1":
>
> RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0
>
> It's one of the listed character sets for HTTP headers.
Yes, but RFC 1945 is an "Informational" RFC that noted the
current practice of HTTP/1.0 at the time it was written.
There is no process for "updating" it, and no need.
> RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1
>
> Ditto.
Actually, no. "unicode-1-1" appears in RFC 2068 only in an
example, and the example is used to demonstrate the use of
"q" factors to indicate preference. In the example in RFC 2068,
"unicode-1-1" is demonstrated as having a lower preference:
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
so I don't think there's anything wrong with RFC 2068.
It appeared in RFC 1945 in a list of enumerated values,
but that was changed when we went to Proposed Standard.
> RFC 1700: ASSIGNED NUMBERS
>
> The charset database.
>
> RFC 1641: Using Unicode with MIME
>
> The original registration.
Even obsoleted charset designations should retain their assigned
numbers, so that updated software can know when it receives data
that uses the obsoleted charset. RFC 1700 notes clearly that it
is a "snapshot" of the online documentation, and does not need
any updating.
> None of these seem like they would cause a problem by being obsoleted.
Actually, it seems that none of these require any updating at all.
All that's necessary is to note in the charset registration itself
that "Unicode-1-1" is obsoleted.
> --
> Deborah Goldsmith
> Manager, International Toolbox Group
> Apple Computer, Inc.
> goldsmith@apple.com
>
>
Received on Saturday, 24 April 1999 06:06:17 UTC