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

Re: proposed HTTP changes for charset

From: Benjamin Franz <snowhare@netimages.com>
Date: Mon, 8 Jul 1996 07:36:08 -0700 (PDT)
To: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Cc: Francois Yergeau <yergeau@alis.ca>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.93.960708071322.9727B-100000@ns.viet.net>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1051
On Mon, 8 Jul 1996, Benjamin Franz wrote:

> On Fri, 5 Jul 1996, Roy T. Fielding wrote:  
> > 4) Labellingthe charset with its realvalue if it is different than 
> > iso-8859-1 *always* works, both in old an new practice, because 
> > any user agent incapable of handling a charset value is also 
> >incapable of handling a charset other than iso-8859-1.  The only 
> > time problems occur is when iso-8859-1 data is labelled as such 
> > and then delivered to an older client.

> This isn't true. I was recently writing a chat CGI program and tried 
> labelling something as ISO-2022-JP. It caused an otherwise Japanese 
> display capable browser client (MSIE 3.0b1 with NJWIN running) to choke. 
> It refused to display the charset labelled file, instead attempting to
> download to a file. If I *didn't* label it I was fine. The issue of
> charset labelling breaking browsers cannot be neatly shoved off that
> way. It breaks non-latin1 1.0 browsers just as badly as latin1 1.0
> browsers. If it is unacceptable to mandate charset labelling becasue
> it breaks latin1 > browsers - it is equally unacceptable to break
> non-latin 1 browsers. 
> I am trying to figure out why charset being a MUST for 1.1 is even an 
> issue at all.  Let's see if I have this right. 

Reading this over I realized I had failed to insert a necessary logical
step here. The discussion after this point assumed that we were simply
going to live with the fact that under rare circumstances a 1.1 response
was going to be passed to a 1.0 client and break it (presumably through a 

Since labelling non-ISO-8859-1 charsets in the Content-Type is *proven* to
break at least some 1.0 browsers, making charset a MUST for non-ISO8859-1
charsets is an incompatible change from 1.0. If this is going to be
inserted into 1.1 - there is no reason at all other than local bias not to
make it a MUST for *ALL* charsets including ISO-8859-1.  Otherwise the
MUST language for non-ISO-8859-1 charsets should be abandoned as being a
political (it doesn't break MY browser) rather than a technical (it
doesn't break ANY browser) statement.

If charset is going to be inserted in a *compatible* way - it will have
to be done via its own header (Charset: ISO-8859-1). I wasn't here for the
debates on that - so if someone knows why that was rejected, please pipe
up with a summary.

Benjamin Franz
Received on Monday, 8 July 1996 07:41:53 UTC

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