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

Re: (ACCEPT*) Draft text for Accept headers

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 3 Apr 1996 00:12:38 +0200 (MET DST)
Message-Id: <199604022212.AAA14202@wsooti04.win.tue.nl>
To: Keld J|rn Simonsen <keld@dkuug.dk>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/160
Keld J|rn Simonsen:
>Koen Holtman writes:
>> 10.2  Accept-Charset
>>    The Accept-Charset request-header field can be used to indicate what
>>    character sets are acceptable for the response. This field allows
>>    clients capable of understanding more comprehensive or
>>    special-purpose character sets to signal that capability to a server
>>    which is capable of representing documents in those character
>>    sets. The US-ASCII character set can be assumed to be acceptable to
>>    all user agents.
>> |  [##QUESTION TO BE RESOLVED: Apparently, the latest HTML spec says
>> |  that iso-8859-1 can be assumed to be acceptable to all user agents.
>> |  Should the above US-ASCII be changed to iso-8859-1??  There has
>> |  been lots of discussion on the list, but I have not been able to
>> |  detect a consensus opinion.##]
>My 2 cents: it soyld be iso-8859-1 that is the default, referring
>to previous discussion for that view.

Based on your comments and those by Albert Lunde, I think the
strongest case is for a change to iso-8859-1.

I will change the draft to say iso-8859-1.  

If anyone disagrees with the change: tell me so in private e-mail
(just say `I do not agree to iso-8859-1', there is no need to supply a
reason).  I will report to the list on the mail I get.  If I get no
comments on this issue in two days, I will do a last call to establish
that we have consensus.

>Another suggestion: there should be a quality parameter also with
>accept-charset,  a q<1 meaning that the browser may be able to display
>in a less readable fashion, for example in mnemonic or 10646 fallback,
>or that it need to shift fonts or load a special programme to
>dispaly the charset or other impeded things.

There has been some discussion that just a quality parameter on
accept-charset does not solve all problems, because different MIME
types will be rendered by different helper apps which have different
built-in charset capabilities.  You may be accepting unicode in html
text, but not in postscript text.

But it is clear to me that some people think that a q=.. parameter on
accept-charset would solve at least their problems.  Adding a
q=.. parameter won't introduce any technical problems as far as
content negotiation is concerned, it could even be seen as an obvious
generalization.  One could object to the addition of a q=.. parameter
on the grounds that the HTTP protocol should be kept simple.

Here is what I propose: anyone who wants to have a q= parameter on
accept-charset, sent me private mail saying that you do.  Anyone who
does not want it, send me private mail saying that you do not.  I will
report a count in two days, and will change text depending on the
results.  I then will do a last call to establish that we have
consensus on this issue.


Received on Tuesday, 2 April 1996 14:19:45 UTC

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