Re: Charsets and language

Summary:

Yes, it would be good to capitalize on best practice from elsewhere, and
synchronize the normal behavior of this information as much as is reasonable.

No, it is not best for any exact behavior to be uniquely what is associated
with any pattern of information.  There should be multiplicity in the
behavior/information association.

At 05:11 PM 4/26/99 +0900, Martin J. Duerst wrote:
>At 08:31 99/04/26 +0100, Graham Klyne wrote:
>> This post derives from an offline discussion...
>
>> The foregoing leads me to two questions:
>> (a) are registrations of features that relate to user preferences in scope
>> for our registration scheme?
>> (b) more specifically, is a registration of a feature for language
>> preference (in the same sense as that used for HTTP "accept-language")
>> appropriate?
>
>If you do, please make sure that the behaviour with respect to
>"sub-languages" is exactly the same as in HTTP (and other protocols).
>There are some subtleties involved, but repeated discussion has shown
>that this is the best way to do things.

I would be interested in the experience behind the discussion.  Can you
furnish references to backups for this conclusion?

If the overarching general rule is that there should be zero, one or many
ways to do something, then the default assumption should be 'many,' because
for universal access there should generally be at least two.

>I.e. if asked for "en", the server may send back "en-us" or "en-gb",
>but if asked for "en-us", the server must not send back "en-gb" nor
>"en", only "en-us" or "en-us-*".

This presumes that the client has the skill to recognize the distinction
between "en" and "en-us" and send a search list articulating the priorities
for each option at the maximum fineness involved in any statement.  The
argument for why this is a global optimum behavior would be interesting to
read.  It is contrary to the existing mode of operation in natural language.

I had thought the consensus best practice was that only root languages are
restrictive, and that all sublanguage designations are advisory.  In other
words, "en" always matches a request for "en-us" if there is no "en-us"
designated alternative available.

Where is the rationale for the strict version articulated in public?

Given the limited experience base of HTTP negotiation, it is not clear one
should bless the HTTP decisions as "what should be exactly replicated
everywhere."

Al

>
>Regards,   Martin.
>
>
>#-#-#  Martin J. Du"rst, World Wide Web Consortium
>#-#-#  mailto:[email protected]   http://www.w3.org
>