Re: Accept-Charset support

> > How about using a more compact representation of Accept-Charset. E.g.
> > bit masks corresponding to the number in the charset registry.
> 
> Do they have canonical numbers?

Yes. Here is an excerpt from the registry:

#The value space for MIBenum values has been divided into three
#regions. The first region (3-999) consists of coded character sets
#that have been standardized by some standard setting organization.
#This region is intended for standards that do not have subset
#implementations. The second region (1000-1999) is for the Unicode and
#ISO/IEC 10646 coded character sets together with a specification of a
#(set of) sub-repetoires that may occur.  The third region (>1999) is
#intended for vendor specific coded character sets.
#...
#Name: ANSI_X3.4-1968                                   [RFC1345,KXS2]
#MIBenum: 3
#Source: ECMA registry
#Alias: iso-ir-6
#Alias: ANSI_X3.4-1986
#Alias: ISO_646.irv:1991
#Alias: ASCII
#Alias: ISO646-US
#Alias: US-ASCII

The registry is at the following URL:

  ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets


> > This
> > would omit the "q" parameter, but I'm not sure this is needed in the
> > Accept-Charset case anyway.
> 
> Since this would be a new representation, one could also add a
> requirement that the charsets in such a binary representation are
> sorted in decreasing order of q.

Do we really need the "q" in the Accept-Charset case? What does it mean?
(Especially since we don't want to expose any UI to the user for
Accept-Charset.)


> > Servers cannot send UTF-8 to clients unless they know that the client is
> > capable of decoding it
> 
> which is indicated by the client sending an Accept-Charset. Quite.

I don't like the tone of this. I've known you personally for a (little)
while, and I doubt that you intended it to come across this way.


Erik