Re: #428 Accept-Language ordering for identical qvalues

[Amos Jeffries <[e-mail]>]

On 18/01/2013 10:07 p.m., Julian Reschke wrote:
> On 2013-01-18 09:46, Amos Jeffries wrote:
>> ...
>> ...
>> I'm with Roy on this one. It's not adding any new requirement about
>> interpretation, simply stating that the list is ordered, as is actually
>> the case from most senders.
>> There is no requirement added/removed about server interpretation so
>> those servers implementing random selection out of the ordered set are
>> still compliant. Those servers implementing ordered interpretation are
> > ...
>
> They are? How so?
>
> If the client sends
>
>     Accept-Language: en, de
>
> and the server returns German text, although English would have been 
> available, is it still compliant?

Where is the text saying the server MUST or even SHOULD return the 
clients first preference?
I could not find any in RFC 2068, 2616 or the current Draft.

The server gets to decide what it returns, the text is lacking in 
normative requirements, so we are quibbling over 
compliance/non-compliance with textual guidance on best interoperable 
practice.

>
>> now compliant - where before with the list defined as un-ordered they
>> would be non-compliant due to mis-interpreting an un-ordered list as
>> ordered.
>
> That doesn't make sense, sorry.
>
> If the list ordering is defined to be irrelevant it's totally ok to 
> pick the first match.
>

If the ordering is defined as relevant to the clients preference, why is 
it non-compliant to pick one of the *available* ones randomly? a bit 
daft, but as you say that used to be prescribed so tose who opted to 
follow the old text see no harm in it. They have the option of 
optimizing a bit or ignoring the new text.


>> ...
>>> Right now they interoperate as specified by the spec. If we change the
>>> spec, they do not anymore (or only some of the time).
>>>
>>
>> The new spec does not forbid random selection. Merely states that the
>> client *wants* it to be interpreted non-randomly. Obeying that client
>> preference is still optional.
>> ...
>
> Again, that doesn't make any sense at all.
>
> If we say that the list is ordered by preference (in absence of 
> qvalues), this implies that a recipient should pick the *first* 
> matching language. If it does not, it's not interpreting the message 
> as defined.

Sure it is both unfriendly to the client and requires sub-optimal code 
to actually perform. But there is still no requirement to return the 
*first* matching language after the change. Just the implication that 
more optimal code may be used.

Amos