Re: (ACCEPT*) Draft text for Accept headers

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.

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