[Prev][Next][Index][Thread]
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
Follow-Ups:
References: