Default service priority

[Johannes Ernst]

Thanks, Peter. This makes sense. I figured you guys would have  
defined this already ;-)

On Jan 18, 2006, at 6:14, Peter Davis wrote:

> On 1/18/2006 2:52 AM, "Martin Atkins" <mart at degeneration.co.uk> wrote:
>
>> Johannes Ernst wrote:
>>> If a service priority is not specified for a YADIS Service  
>>> element,  but
>>> all other Service elements have it, how should those Service   
>>> elements
>>> be sorted? In other words, does the priority default to 0,  to
>>> Inifinity, to -Infinity, ...?
>
> The service priority attributes semantics are defined in the XRI  
> resolution
> spec (draft section 3.3.3) which presently suggests:
>
> 1. The client SHOULD select the element instance with the lowest  
> numeric
> value of the priority attribute. For example, an element with priority
> attribute value of “10” should be selected before an element with a  
> priority
> attribute value of “11”, and an element with priority attribute  
> value of
> “11” should be selected before an element with a priority attribute  
> value of
> “15”. Zero is the highest priority attribute value. Null is the lowest
> priority attribute value.
>
> 2. If an element has no priority attribute, its priority attribute  
> value is
> considered to be null.
>
> 3. If two or more instances of the same element type have identical  
> priority
> attribute values (including the null value), the client SHOULD  
> select one of
> the instances at random. This client SHOULD NOT simply choose the  
> first
> instance that appears in XML document order (this is important in  
> order to
> support intentional round-robin behaviour).
>
> 4. An element selected according to these rules is referred to as “the
> highest priority element”. If this element is subsequently  
> disqualified from
> the set of qualified elements, the next element selected according  
> to these
> rules is referred to as “the next highest priority element”. If a  
> protocol
> operation specifying selection of the highest priority element  
> fails, the
> client SHOULD attempt to select the next highest priority element  
> unless
> otherwise specified. This process SHOULD be continued for all other  
> element
> instances until success is achieved or all instances are exhausted.
>
>
>>
>> I don't think it really makes much difference. Just pick one.
>>
>> Another possibility is to copy HTTP negotiation which (I think?)  
>> uses 1
>> as the default and expects lesser items to be fractions of 1.
>>
>> Might also be good to check to see if XRD already specifies this.
>>
>> I think what's more important is to properly explain the meaning of
>> priority; namely, that it only comes into play when the relying party
>> really has no other means to decide on an item. And even then, some
>> relying parties will probably just take the first one encountered and
>> use it no matter what the spec says, because people tend to take
>> shortcuts like that.
>>
>> In other words, if you specify both LID and OpenID auth and  
>> prioritise
>> OpenID, some relying parties might use LID anyway because they have a
>> superior LID implementation, they don't support OpenID at all, or if
>> they just like LID more, or whatever.
>>
>
> =peterd  (http://public.xdi.org/=peterd)
>

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060118/7bf54e44/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst