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

Re: Registration of new IBM Char Sets

From: Erik van der Poel <erik@netscape.com>
Date: Tue, 30 May 2000 14:51:43 -0700
To: Keld Jørn Simonsen <keld@dkuug.dk>
Cc: tamer@ca.ibm.com, ietf-charsets@iana.org, iana@iana.org, iana@isi.edu, Antoine Leca <Antoine.Leca@renault.fr>, Harald Tveit Alvestrand <Harald@Alvestrand.no>
Message-id: <393437EF.8B8C2886@netscape.com>
Keld Jørn Simonsen wrote:
> 
> The idea was to document it for applications to be used at a platform
> but not on the wire. And this was deemed needed as IETF specifications
> are also about the things that happen with the protocols at
> the platforms.
> 
> On the other hand, it was decided that only some selected charsets
> should be used for interchange, on the wire. Maybe we should add
> that as a property to each of the registrations, that is,
> "recommended for use on the wire". I believe some of these
> recommendations are already done in the rfcs specifying the
> protocols.

The charset names are quite useful. In fact, Mozilla uses them to
identify converters that convert to and from Unicode. Mozilla uses
Unicode internally, and converts to and from whatever charsets are used
in the underlying software (OS, etc) and on the Net.

But as things stand, there is not very much guidance in the use of the
many charset names in the registry, and people may feel free to use any
of them on the wire, when the working group's intention was to minimize
the number of charsets on the wire.

So I would tend to agree with you that we should do something about
this, but I don't know whether an additional property in the registry is
the best way to go. Perhaps some protocols would prefer to be very
strict and only allow a very small number of charsets, while other
protocols would prefer to be quite liberal, allowing a larger variety of
charsets.

Comments?

Erik
Received on Tuesday, 30 May 2000 17:58:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 June 2006 15:10:51 GMT