Re: qvalue *

ryah dahl wrote:
>>> But why ?  If everybody does something else the wildcard
>>> can be simply deprecated.  Or if desired fixed in some
>>> way, e.g., state that a wildcard <qvalue> greater or
>>> equal than the smallest non-zero <qvalue> elsewhere MUST
>>> be interpreted as *;q=0.001.  Or SHOULD.  Or something
>>> better than "dunno, who cares, toss a coin, get BOCU-1".
>>>       
>> Of course we can spend time on edge cases like these.
>>
>> But if we do, I'd prefer to talk about repeating Content-Length or
>> Content-Type headers first, because those may have security implications.
>>     
>
> Isn't the only use for q-value to give equal preference to several
> values? As far as I see it, the whole q-value topic is an edge case. I
> think it should be depreciated in favor of ordered lists.
>
>   
ordered lists don't allow you to specify holes in a range of acceptable 
values, e.g.

Accept-Language: en, en-us;q=0

which means any english except US.

I don't see any problem with the current spec.  If UAs really don't want 
to specify a real preference (i.e. assign same q value, either 
explicitly or implicitly to multiple options), then as long as that is 
really a representation of the human user's wishes, what's the problem?

If we start to consider having a qvalue on "*" to be a problem, we might 
be tempted to take steps which will arbitrarily limit us (and cause 
actual problems) later.  But logically, being able to specify a qvalue 
for anything is just part of being able to define logical statements.

Regards

Adrien


> In the case where this might be meaningful, Accept-Language, UA do not
> give the ability of the user to specify something more detailed than
> an ordered list of perfered languages. Accept, Accept-Charset - who
> cares? Is an ordered list ever not enough?
>
> ry
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com