multiple URI elements per Service in XRDs

[Drummond Reed]

First, Johannes, as Kevin pointed out, I corrected most of the instances of
"XRD" in your message below to "Service".

Second, I just want to make sure that the proposed general processing rules
for XRD/Service elements and their child XRD/Service/URI elements are clear.


1) First you select the highest priority Service element of the type you
want (i.e., whose XRD/Service/Type element contains the URI (or XRI in
URI-normal form) of the type your are looking for.)

2) Then you select the highest priority XRD/Service/URI element within that
Service and use that URI.

3) If that URI fails, and there is >1 child XRD/Service/URI element of the
selected XRD/Service element, you can optionally try the next highest
priority XRD/Service/URI child element. That process repeats until you run
out of XRD/Service/URI child elements for that Service.

4) If THAT fails, and there is >1 XRD/Service element of the Type that you
want, you can optionally switch to the next highest priority XRD/Service
element, and start again from step 2.

Now, having explained that, let me clarify a few things:

1) Those proposed processing rules for XRD subelements (specifically
XRD/Service and XRD/Service/URI) are the general rules suggested and
followed by the XRI resolution spec. Another spec/protocol that uses XRDS
can set it own rules. For example, YADIS could say that all but the first
XRD/Service/URI child element will be ignored.

2) That said, the rationale for allowing more than one XRD/Service/URI child
element of XRD/Service followed exactly the same design as DNS: you can have
more than one and set their priority, and if you don't set their priority,
it's automatic round robin. The XRI TC discussed this at some length and
decided there were good reasons to do this at the XRI layer just as at the
DNS layer. If, in practice, a site has already implemented load balancing or
redundancy using DNS round robin or IP balancing, they won't need to publish
more than one URI for a service and thus won't need this mechanism...

3) ...UNLESS they need the second key reason the XRI TC decided to allow
more than one XRD/Service/URI element: they want to expose a service via
more than one protocol (classic example: http and https.) 

Could all this be done by restricting XRD/Service to having only one
XRD/Service/URI child element and forcing XRD authors to insert multiple
XRD/Service elements of the same type if they want to offer more than one
URI? Yes. But that forces data duplication within an XRD, as well as forcing
a particular point of view about implementation/optimization, neither of
which we felt was a good practice.

I hope that helps answer your question. If not, fire back and we'll make
sure we do.

Best,

=Drummond 

-----Original Message-----
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Johannes Ernst
Sent: Wednesday, January 18, 2006 4:35 PM
To: yadis at lists.danga.com List
Subject: multiple URI elements per Service in XRDs

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 Service 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 Service, but  
having multiple Service 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 Service elements that have a child with the "LID VCard  
query" type.
  - order the found Service elements by the priority attribute
  - if there is only one highest-priority element, select a URI at  
random contained in that Service element, try it and keep trying the  
others in the same Service element. If none work, go to the next-highest  
priority element
  - if there are N>1 highest-priority elements, select an Service 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 Service, until end of set, then go to second URI in  
first Service and so forth. Keep track which we've tried already. If  
there are no more from that set, go to next-highest priority Service.

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



Johannes Ernst
NetMesh Inc.