Re: (ACCEPT*) Draft text for Accept headers
Koen Holtman (koen@win.tue.nl)
Wed, 3 Apr 1996 00:12:38 +0200 (MET DST)
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.
>Keld
Koen.