multiple URI elements per Service in XRDs

[Johannes Ernst]

This question is really for the XRI guys whose XRD/S format/subset we  
are using for YADIS. Fortunately, some of you (you know who you are!)  
do seem to monitor this list ...

The question is: is it really necessary to allow multiple URI  
elements within the same XRD element?

My understanding is that this is about availability and load  
balancing: "If this URI does not work, try that one, it provides the  
same service", that kind of thing.

First, there is a question whether load balancing and availability  
should not be handled on a lower level -- Cisco routers are good at  
that, hiding all of the complexity behind a simple URL.

But even if it isn't handled on a lower level, couldn't I just simply  
express the exact same thing with only one URI element per XRD, but  
having multiple XRD elements (with the same type and whatever other  
data is carried around) and the same priority?

This would very substantially reduce the processing needed by the  
receiver of the document (such as a YADIS Relying Party). For  
example, if with the current spec, I want to determine whether or not  
a given identity URL supports, say, LID VCard queries and with which  
URI to perform the query, it appears I have to do this:
  - select all XRD elements that have a child with the "LID VCard  
query" type.
  - order the found XRD elements by the priority attribute
  - if there is only one highest-priority element, select a URI at  
random contained in that XRD element, try it and keep trying the  
others in the same XRD element. If none work, go to the next-highest  
priority element
  - if there are N>1 highest-priority elements, select an XRD element  
from that set at random, and try the first URI from that element. If  
it doesn't work, go to the first URI from the second element in that  
set. Then go to next XRD, until end of set, then go to second URI in  
first XRD and so forth. Keep track which we've tried already. If  
there are no more from that set, go to next-highest priority XRD.

This is all doable, no question ... but is the additional algorithmic  
complexity, and in particular the tracking part, perhaps across  
requests and sessions and XRD types ("I already know this URI does  
not work") commensurate with the benefits?



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/0e0fff67/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst