Re: #428 Accept-Language ordering for identical qvalues

On 2013-01-18 11:59, Amos Jeffries wrote:
> 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.

How is it relevant whether there's a SHOULD or MUST?

If the specification describes the meaning of the message, and the 
server ignores some part of that, it's not working per spec.

> 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.

The text describes the semantics of the header field. It doesn't need to 
invoke MUSTs or SHOULDs for that.

>>> 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.

If the client says "I take A and B but prefer A", and the server has 
both, then returning B is not the right thing to do.

>>> ...
>>>> 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.

We seem to have a fundamental disagreement about the way the spec 
defines things. This is not the only place where we define things by 
simply stating facts; it doesn't mean a server can simply ignore those 
things and still be considered doing the right thing.

Best regards, Julian

Received on Friday, 18 January 2013 11:10:27 UTC