- From: Erik van der Poel <erik@netscape.com>
- Date: Wed, 03 May 95 18:25:40 -0700
- 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 thing? 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. Erik
Received on Wednesday, 3 May 1995 18:26:47 UTC