W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: ISO/IEC 10646 as Document Character Set

From: Erik van der Poel <erik@netscape.com>
Date: Wed, 03 May 95 18:25:40 -0700
Message-Id: <199505040125.BAA16488@slice.mcom.com>
To: glenn@stonehand.com
Cc: erik@netscape.com, Multiple recipients of list <html-wg@oclc.org>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>We could say that the default encoding scheme is base line "ISO-2022".
>How does this compromise sound?  Brain dead or what?

ISO 2022 actually does allow you to include info about the charsets
used in a document, but then we would be tied to 2022, and might end
up excluding other charsets (Big5?  KOI8?).  Which might be a good

It might be better to stick to the charset parameter, as defined by MIME.

My question is not "Can we do 2022 please?"

It's "How do we get from the current situation to one where the charsets
are labelled?"  This is the pressing issue that I think Amanda is also
concerned about.

Preferably, any proposed solution would also take into account the
installed base and migration issues.

Has anybody done any extensive testing with the charset parameter in
HTTP?  Here at Netscape, a few tests were done before I joined, and they
showed that Netscape 1.0 does not handle the charset parameter well.

All I'm saying is, let's exercise some caution before blindly getting
our servers to append the charset parameter to the content-type line.

If we decide that we're willing to accept any pain and suffering caused
by introducing the charset parameter blindly, then that's OK too.  As long
as we consciously decide to do so.

Received on Wednesday, 3 May 1995 18:26:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:13 UTC