Capability discovery

[Ernst Johannes]

Here is what I wrote down the consensus of the meeting attendees was  
on capability discovery. (Other attendees: did I get it right?)

Given an identity URL, the capabilities of this URL must be  
discoverable through at least one of the following mechanisms:

1) An HTTP GET with the Accept MIME type of "application/xrd+xml"  
returns the capabilities document directly.

2) A response to an HTTP GET to the identity URL returns a custom  
HTTP header, 'X-YADIS-Location' with a value that is a URL. The  
capabilities document is returned from that second URL.

3) A response to an HTTP GET to the identity URL returns an HTML  
document that contains a META HTTP-EQUIV statement, whose value is a  
URL. The capabilities document is returned from that second URL.

If the capabilities aren't discovered after all three methods have  
been tried, the given URL is not a YADIS-enabled URL. According to  
this consensus, we do not prescribe an algorithm for evaluating those  
three means, i.e. software is free to try, say, an HTTP HEAD request  
first to see whether or not the X-YADIS-Location header is returned  
from the URL. Standard HTTP HTTP-EQUIV rules govern the relative  
precedence of #2 and #3. No statement is made about the precedence of  
#1 vs #2 and #3.

The capabilities document itself is an XML document with root note  
XRDS, which has one XRD sub-element, which in turn contains 1..N  
Service elements, each describing a capability (no change there).

As you can probably read between the lines, there are some hard- 
fought technical compromises in this approach -- but at least from my  
particular vantage point, it's a good solution to a hard problem. For  
example, it meets the requirements of 1) user-centric deployment, 2)  
provider-centric deployment and 3) geek-centric deployment, and it is  
still quite simple to implement.

I recommend that discussion of this agreement on the mailing list  
focus on whether use cases can be found where this approach does not  
work (we couldn't think of any in San Francisco, but then, more eyes  
see more things ... ) rather than whether it is "optimal" for an any  
particular use case. People in the meeting generally agreed that this  
is good-enough for a YADIS version 1.0, we can always fiddle a bit  
for YADIS 1.1 based on what we learn during implementation.

The current plan is that the next draft of the YADIS spec will  
contain this protocol.


Johannes Ernst
-------------- 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/20051205/666dee28/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst