W3C home > Mailing lists > Public > ietf-charsets@w3.org > April to June 1999

Re: Deprecating charset "unicode-1-1"

From: Patrik Fältström <paf@swip.net>
Date: Thu, 22 Apr 1999 09:07:11 +0200
To: Deborah Goldsmith <goldsmith@apple.com>, IETF Charsets Mailing List <ietf-charsets@iana.org>
Cc: Rick McGowan <rmcgowan@apple.com>
Message-id: <v04204d01b3447a024358@[]>
At 15.27 -0700 1999-04-16, Deborah Goldsmith wrote:
>Is it possible to deprecate or invalidate an existing, registered character
>set? What process would be involved? Should we be looking at some other
>process to discourage use of "unicode-1-1"?

You have to identify what RFCs reference this version which is to be 
deprecated, and ideally update those RFCs by writing one new RFC 
which updates all of these, identifying what they should do.

I.e. an RFC can update (not replace) a whole bunch of other RFCs. 
That happens now and then for clearifications etc. I see this as one 
of these situations when an update is ok.

The process is because of that:

+ Someone checks the RFCs existing for references that will be wrong
+ Check more carefully if the change have impact on the RFC itself
+ Write one Internet-Draft about the two above things. I.e. about how 
and what version of UNICODE to use at the moment -- and clearify what 
impact it had on old protocols.
+ Let me know that the Internet-Draft is published, and I'll see that 
it become an RFC, via the normal process.

If the impact on a certain RFC is "not negliable", the RFC itself 
might have to be replaced by a new one, but this descision have to be 
made in step 2 above.

Area Director, Applications Area               Email: paf@swip.net
IETF                                             URL: http://paf.se
                                          PGP Key ID: 0xBD236602

   In theory there is no difference between theory and practice,
   but in practice, there is.
Received on Sunday, 25 April 1999 13:13:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:52:16 UTC