XRID proposal for YADIS

Drummond Reed drummond.reed at cordance.net
Mon Nov 7 13:30:40 PST 2005

>-----Original Message-----
>From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
>On Behalf Of Lukas Leander Rosenstock
>Sent: Monday, November 07, 2005 12:10 PM
>To: yadis at lists.danga.com
>Subject: Re: XRID proposal for YADIS
>Hello everybody,
>I'm still not getting all this XRI stuff. I've understood that there is 
>an XML format for metadata which can used also for service discovery but 
>that's just a - better - alternative to the text-based format 
>application/x-meta-identity. But what about addressing, I thought there 
>was something about addressing. How exactly should such an XRI-URI look 
>like compared to the HTTP-URIs currently used by OpenID/LID/Yadis and 
>how can the server handle one when the user entered it?

Great question. First, per my last message, just to clarify, there is NO
requirement to use an XRI to get an XRID. 

However, if a website that supports YADIS wants to accept XRIs in addition
to HTTP URLs (e.g., wants to be able to accept "=drummond.reed" in addition
to "http://public.xdi.org/=drummond.reed" or "http://equaldrummond.name",
etc.), then the website would plug-in an XRI resolver that implements the
XRI resolution protocol. See www.openxri.org for one open-source XRI
resolver/resolution server project.

XRI resolution is a simple process of converting XRIs into HTTP URIs (URLs)
and then retrieving XRIDs in order to continue resolution of delegated XRIs,
exactly the same way DNS resolution resolves delegated DNS names by doing
DNS lookups to the nameserver for each delegation point.

The final XRID in the process would be the YADIS document describing the
services available.

The previous XRI Resolution draft, published by the XRI TC in March,
describes all this in great detail w/lots of examples:


However, after the public review period last spring, and after much
subsequent discussion and implementation feedback, the TC decided to make
several changes to that draft:

1) Refactor the spec to make it much shorter and move most of the examples
to a separate, non-normative document.

2) Refactor the XRID structure to make it easier and more intuitive to
describe non-XRI-resolution services (which is exactly what YADIS is all

3) Fully specify a standard method by which any XRI can be expressed as an
HTTP URI so as to provide full backwards compatability with HTTP URI (better
known as URL) infrastructure.

These changes are in process right now, so look for the new XRI Resolution
Working Draft 09 by the end of this week (I'll send a link to this list as
soon as it's out).


More information about the yadis mailing list