- From: Erik van der Poel <erik@netscape.com>
- Date: Tue, 02 Jul 1996 20:01:54 -0700
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter wrote: > > My proposal: > > < The "charset" parameter is used with some media types to define the > < character set (section 3.4) of the data. Origin servers SHOULD > < include an appropriate charset parameter for those media types which > < allow one (including text/html and text/plain) to avoid ambiguity. > < In the absence of a charset parameter, the default charset value MAY > < be assumed to be "ISO-8859-1" when received from a HTTP/1.1 server. > > < Unfortunately, some HTTP/1.0 clients do not properly deal with > < explicit charset parameters for text/html data, and some HTTP/1.0 > < server sites send no charset parameter, even when the charset of the > < data is not ISO-8859-1. For compatibility with older clients and > < servers, implementations may need to be careful when communicating > < with older versions, by not sending a charset parameter when the > < data is ISO-8859-1, and by allowing local configuration when > < recieving unlabelled data from HTTP/1.0 servers. This is great, but I get this feeling that we need to "push" people a bit more. There are a lot of SHOULDs and MAYs in your prose, but no MUSTs. How about having some MUSTs for the receiving side of things. I.e. HTTP/1.1 clients MUST be able to accept explicit charset parameters. Same for HTTP/1.1 servers (and their CGIs). It may be a good idea to list some of the common cases, e.g. "text/*" subtypes, application/x-www-form-urlencoded, maybe even multipart/form-data? Erik
Received on Tuesday, 2 July 1996 20:07:22 UTC