Notes on XRI status

Henry S. Thompson
30 Jan 2008

Table of Contents

1. Organisational/practical situation

The OASIS XRI TC is still active, although only one document (XRI Resolution 2.0 seems to be under active development---nothing else has been published since November 2005.

Committee participation seems to be low, with less than 10 people on the weekly calls. Drummond Reed and Dave Wachob continue to be the key players, as far as I can tell.

They have succeeded in getting onto the OpenID bandwagon: XRI and OpenID, via OpenID 2.0, which mandates support for XRIs.

You can buy corporate or personal i-names (that is, XRI-syntax identifiers), but since =ht, =henry, =henry.thompson and @ibm are all available (although =hst is not), I guess not a lot have been bought.

2. Draft OASIS Specs

The XRI Syntax 2.0 spec. has "Committee Specification" status. Not clear why it hasn't progressed further.

The XRI Resolution 2.0 is an a sort-of Last Call state, with comments closing on 1 February 2008.

2.1. XRI Syntax 2.0

Defines the xri URI scheme (not registered with IETF, as far as I can tell). However, xri:// is described as "optional in absolute XRIs that use a global context symbol" so e.g. xri://@example/!something can also be written @example/!something.

XRI syntax is a generalisation of (authority-based) IRI syntax. Along side domain names and IP addresses, a new kind of authority, signalled by the use of initial =, @, + or $ for persons, organizations, 'general public' and standards bodies, respectively. The token following the initial character is known as an i-name, and there are registrars and so on for these (which are ostensibly bought, not leased).

Two other novel aspects of the syntax:

2.2. XRI Resolution 2.0

Well, at least they're eating their own cooking: Right at the top is a list of "Declared XML Namespace(s)", which begins

Given that they have made no attempt to register the xri URI scheme, I guess I think this is broken, and XML Core should encourage them to initiate registration. . .

Attempting to look up the i-name $res via the advertised public proxy resolution mechanism produced an error:

Error encountered while servicing request:

<?xml version="1.0" encoding="UTF-8"?>
<XRDS ref="xri://$res" xmlns="xri://$xrds">
 <XRD xmlns="xri://$xrd*($v*2.0)">
  <Query>xri://$res</Query>
  <Status code="215">Authority '$' is not configured</Status>
 </XRD>
</XRDS>

Basically this spec. describes an http(s)-based mechanism for resolving XRIs into XML-formated metadata (an Extensible Resource Descriptor Sequence, or XRDS, document), which in turn contains URIs which can be used to access the resource identified by the XRI.

The media type of the XRDS document is spec'ed as application/xrds+xml---neither this nor its companion application/xrd+xml appear to be registered with IANA (but there are appendices in the document with outline registration information).

Intriguingly, the specified method for bootstrapping the resolution process, which depends on the existence of a relatively small number of well-known "Community Root Authorities", points to a Wikipedia entry for a list thereof, but specifically characterizes this as non-normative. Indeed as of this writing that page does not seem to me to contain any information about root authorities. The root authorities for the single-character authorities do appear at a different wiki page maintained by the inames project. Although these root authorities do respond to a minimal probe with metadata which, if I understand it correctly, means that they do also provide an Authority Resolution Service (the basic lookup mechanism defined in the spec.), I have been unable to get them to perform a lookup, following the procedures described in section 9.1. I recommend that section 9.1 should include a worked example including the details of the HTTP requests needed to resolve a simple XRI authority segment, assuming a self-describing XRDS document of the sort currently provided by the root authorities.

The proxy resolution mechanism, which interprets http-scheme-encoded XRIs, does seem to work for some well-known XRIs, e.g. http://xri.net/=drummond does provide the metadata for Drummond Reed, whose XRI is xri://=drummond.

Here's a simplified version of the metadata retrieved from the above XRI:

<XRDS ref="xri://=drummond" xmlns="xri://$xrds">
 <XRD xmlns="xri://$xrd*($v*2.0)">
  <Query>*drummond</Query>
  <Status code="100"/>
  <Expires>2008-01-31T13:36:58.000Z</Expires>
  <ProviderID>xri://=</ProviderID>
  <LocalID priority="10">!F83.62B1.44F.2813</LocalID>
  <CanonicalID priority="10">=!F83.62B1.44F.2813</CanonicalID>
  <Service priority="10">
   <Type select="true">http://openid.net/signon/1.0</Type>
   <ProviderID/>
   <URI append="qxri" priority="2">http://2idi.com/openid/</URI>
   <URI append="qxri" priority="1">https://2idi.com/openid/</URI>
  </Service>
  <Service priority="10">
   <Type match="default"/>
   <Type select="true">xri://+i-service*(+contact)*($v*1.0)</Type>
   <ProviderID/>
   <Path select="true">(+contact)</Path>
   <Path match="null"/>
   <URI append="qxri" priority="1">http://2idi.com/contact/</URI>
  </Service>
 </XRD>
</XRDS>

The key bits here are the Services -- an XRI of the form xri://=drummond/(+contact) can be used to identify the second of those, yielding a result of (the metadata for) http://2idi.com/contact/=drummond/(+contact), or that page itself, depending on the Accept: header you send.

The net-net of all this is a re-architecting of the Web which puts metadata first, rather than data. It's this which I think the TAG should comment on.