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