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

Re: Negotiation in draft 01

From: Jim Seidman <jim@spyglass.com>
Date: Wed, 9 Aug 95 14:14:17 -0500
Message-Id: <9508091914.AA14316@hook.spyglass.com>
To: Roy Fielding <fielding@beach.w3.org>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In my last note, I was trying to ask if the negotiation changes were
discussed on the list.  My understanding of IETF operation (correct me if
I'm wrong) is that the working group mailing list is supposed to be the
primary forum for discussion and the meetings are to be secondary.  I get
the impression that these issues were discussed at the meeting, but not on
the list (until now, much later), which I think is wrong.

As far as assuming that any encoding or character set is equally acceptible
in the absence of Accept-* headers, image the case where a server returns a
gzip'ed text/html document.  A browser which doesn't parse Content-Encoding
(of which there are several) will try to display this to the user, which
will result in garbage being displayed.  It's possible that the browser will
even do CR-LF munging as the gzip'ed file is received, so that saving at
this point would be useless.

Similarly, a robot cataloging web content might receive a text/html document
using iso-2022-jp, even though it sent no Accept-Charset header.  If the
robot doesn't look at the returned charset, it might then record bogus
information about the page's content since it can't parse the content
correctly.  What's really upsetting is that the same document might have
been available in an iso-8859-1 version, but iso-2022-jp version was sent
instead because all charsets have qc=1.

I have two proposals:

1. Change the behavior back to draft 00 where the absence of Accept-Charset
or Accept-Encoding indicates support for only iso-8859-1 or identity
encodings, respectively.

2. In the absence of Accept-Charset or Accept-Encoding set qc to 0.001 for
all possibilities other than iso-8859-1 or identity encodings.

>I suggest that we allow
>inclusion of the default charsets, such that
>   Accept-Charset: iso-8859-1
>implies acceptance of only that charset and US-ASCII (which would always
>be implied).  No accept-charset would be the same as accepting all, and
>given an accept-charset, unlisted charsets would be qc=0.

Would this have a different effect than just saying "Accept-Charset:" (with
no charsets listed)?   In any case, do I understand correctly that you're
proposing going back to qc or qe = 0 (rather than 0.001) for unlisted types?
If that's a correct interpretation of what you're saying, it's fine with me.

Jim Seidman, Senior Software Engineer
Spyglass Inc., 1230 E. Diehl Road, Naperville IL 60563
Received on Wednesday, 9 August 1995 13:48:27 UTC

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