What I mean here is, if a document's Content-Type header does not have a charset parameter at all, but it does specify an encoding using a meta element in the document itself, then that's OK.

But if a document's Content-Type header has a charset parameter but the value of that parameter is malformed such that a browser will end up ignoring the value, then that should be a document-conformance error.

The page http://greenbytes.de/tech/tc/httpcontenttype/#l-charset-parsing has examples of some Content-Type headers with malformed charset parameters, along with test results for various browsers. Some examples:

  - Content-Type: text/plain; charset = UTF-8  (whitespace around the "=" sign)
  - Content-Type: text/plain; charset='UTF-8' (single-quoted encoding name)

I recently added some code to the validator that will cause it to report errors for cases such as those, so it would be helpful to have a clearly stated explicit requirement in the spec to go along with that.

Isn't that an HTTP-level conformance error? Why does it need to be a document-level conformance error?

hsivonen: MikeSmith tells me he'd like your input on this.

text/html owns its charset parameter. So I think it would be appropriate to say that the value must be a label from the Encoding Standard and must be the label of the encoding actually used if the charset parameter is present. That should make bogus values an error.

Aah, defining it as part of text/html makes sense, yeah, dunno why I missed that.

Ok, will deal with this in January along with the rest of the MIME registry stuff.

This seems to have gotten fixed along the way.