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

Re: proposed HTTP changes for charset

From: Erik van der Poel <erik@netscape.com>
Date: Tue, 02 Jul 1996 20:01:54 -0700
Message-Id: <31D9E2A2.2F1C@netscape.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:04 EDT