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

Re: proposed HTTP changes for charset

From: Larry Masinter <masinter@parc.xerox.com>
Date: Tue, 2 Jul 1996 23:26:00 PDT
To: erik@netscape.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <96Jul2.232600pdt."2733"@golden.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1004
> 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?

I thought about how such a requirement could be worded, but it was
difficult. First, not all subtypes of text/ take charset parameters.
It's actually up to the individal media type. So we could make a rule
for text/plain and text/html, but leave the rest alone. But what is it
that clients MUST do with text/html;charset=ISO-8859-1? Display such
characters 'properly'? Offer to save such files to disk? It got hard
to figure out what it was we were going to require.

application/x-www-form-urlencoded doesn't have a "charset" parameter,
although if something were going to be registered, it 'should', and
multipart/form-data just says that the content consists of things with
internet media.

Anyway, I'd rather just leave it alone. We've at least made it that
senders SHOULD send charset parameters, and recipients, well, they
better deal with what senders SHOULD send.

It was wishful thinking to hope that someone would go and red pencil
all of the SHOULDs and MUSTs in the current draft, but.. I wish ...

Received on Tuesday, 2 July 1996 23:29:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC