Re: charset flap

My opinion about the "charset flap" has changed based on the resul of
searching for "charset=unknown" in any published RFC.

I've been unable to find any RFC or other Internet Draft that
describes the "charset=unknown" that Keith Moore suggested at the
HTTP-WG meeting. I'm wouldn't want to proceed without some reference;
we shouldn't actually be inventing new mechanisms if they don't exist
elsewhere. The discussion at the IETF meeting was based on the
assumption that this was actually something in use in other Internet
Standards.

I don't have any problem with the assertion that HTTP/1.1 should
strongly recommend that charset should be labelled, or even SHOULD be
labelled, if known.

I don't have the revised wording (as I promised I would) and I've
recieved no proposal from Francois or Paul Leach so far.

Here's the basics as I see them:

* HTTP/1.1 clients MUST accept text/ data with a charset parameter.
   The spec doesn't explicitly say this, but it could be deduced
   from the general language of what the content-type header means.

* HTTP/1.1 origin servers SHOULD send a charset parameter with text/
   data when the charset is known or can be reasonably deduced when
   responding to a HTTP/1.1 request.

  The spec doesn't say this now either, and the language might even
  discourage HTTP/1.1 implementors from installing this behavior.
  So fixing this is probably a good idea.

* For compatibility with older clients, HTTP/1.1 servers (and
  proxies) may want to strip (not send) US-ASCII or ISO-8859-1
  charset labels to HTTP/1.0 requestors.

  There's only so much 'backward compatibility with broken clients'
  that we should tolerate. (I'd like to say that 'any client that
  can't deal with a charset= parameter is BROKEN' rather than blaming
  the content providers.
     
As for explicitly labelling unknown charset parameters, as long as
we're careful, it would be possible to require HTTP/1.1 servers to
send "charset=unknown" to HTTP/1.1 clients and to suggest HTTP/1.1
proxies strip such designation, but we shouldn't be introducing new
parameters here.

Larry

Received on Tuesday, 2 July 1996 02:41:56 UTC