Thanks to some intense e-mail exchanges with Drummond Reed, CTO of Cordance, I now understand much better how XRI resolution works. With his permission, I'm blogging some of the highlights, in the hope that it will be useful for others as well:

Johannes:

Where in the OASIS docs does it say how one gets from an =example XRI to an http://xri.net/=example URL? Or should it be https://xri.net/=example?

Drummond:

In XRI Resolution 2.0 Working Draft 10, the overall definition of http proxy resolution are in section 7. That's where it specifies using a "xri.*" DNS prefix, either as a second level domain (of which there are a fixed number), or any third- or lower-level domain.

XDI.org registered xri.net to serve as the domain for its public XRI proxy resolution network, which is the only publicly supported XRI proxy res network that I know of so far ... companies can run their own.

The XDI.org XRI proxy resolution network specs are part of the XDI.org Global Services Specifications (GSS). Specifically they are section 5.1 and 5.3 in this PDF.

Hope this helps.

Johannes:

Right document, wrong version! (in which I looked) Thanks!

But now I'm more confused. (Sorry.) I had been working under the assumption that, say =Drummond or any other XRI would be a globally unique identifier. Is it? What you seem to say is that, say, Boeing, could define it to mean something else. Am I correct about that?

Drummond:

No, =drummond is a globally unique identifier. The power of XRIs (and XRI proxy resolution) is that globally unique XRIs can be syntactically understood in the context of OTHER globally unique XRIs (or URIs).

For example, when it comes to proxy resolution, every XRI proxy resolver works the same way. The formula is:

[http: / https: ] xri.* / qxri

The combination of the above is called an HXRI (HTTP XRI), and it consists of putting an http proxy resolver prefix in front of an XRI (called the "query XRI" or QXRI).

The XDI.org proxy resolver network responds to either http://xri.net or https://xri.net (the only difference is the access protocol).

So the following two are equivalent:

http://xri.net/=drummond.reed
https://xri.net/=drummond.reed

In both cases, the xri.net proxy resolver is simply resolving the XRI =drummond.reed and returning the result.

If a company brings up their own XRI proxy resolver service at xri.example.com, and offers both http and https, then it too can resolve =drummond.reed, and should return exactly the same result. In that case, all four of the below are equivalent:

http://xri.net/=drummond.reed
https://xri.net/=drummond.reed
http://xri.example.com/=drummond.reed
https://xri.example.com/=drummond.reed

In all four cases, the same globally-unique XRI is being resolved: =drummond.reed. The only difference is the XRI proxy resolver you are asking, and what protocol you are using.

Johannes:

Thanks for your patience in this.

So where does it say that all XRI strings must resolve to the exact same information, regardless which resolver is used? (And I think this must be a 'must', otherwise I don't see how the identifier can be globally unique?)

Drummond:

It says that in the XRI Resolution 2.0 Working Draft 10 spec, however in section 7.7 it points out:

7.7 Differences Between Proxy Resolution Servers

An XRI proxy resolution request may be sent to any proxy resolver that will accept it. All XRI proxy resolvers SHOULD attempt to deliver uniform responses given the same QXRI and input parameters. However because proxy resolvers may potentially need to make decisions about network errors, reference processing, and trust policies on behalf of the client they are proxying, and these decisions may be based on local policy, in some cases different proxy resolvers may return different results.

This is just reality -- the same thing can happen in DNS. The point is that that XRI resolvers always SHOULD do this even if they can't enforce perfection.

Johannes:

Ah, now I'm beginning to understand this. Just like I can set up a DNS server that returns different results than an "official" DNS server would ("don't do this at home, kids"), one could set up an XRI resolver that did something different, but it is frowned upon and might have bad consequences.

Then from a logical perspective, there is only one XRI resolution service. On a networking level, there are many for reliability, distributed processing etc. etc. kinds of reasons. All of which ultimately delegate to the central repository (which in turn may delegate).

The consequence is that it really doesn't matter which instance of the resolution service I resolve against, as long as I'm okay with the QoS that I'm getting from them. And if XRIs were to become as ubiquitous as DNS, then all sorts of funny policies would be implemented that would force people further out at the edges to use services close to them instead of everybody always going to the root servers.

Do I have it right this time? ;-)

Drummond:

Yes, you got it -- with the exception that we're hoping it's not so much "funny policies would be implemented that would force people further out at the edges" rather than good OpenXRI code that caches efficiently plus the inherent advantages of persistent i-numbers (which will appear primarily as CanonicalID values) that will not need to be looked up as often as DNS, where all the identifiers are reassignable.

In many ways, XRI infrastructure is DNS done at a higher layer -- a layer truly designed for the requirements of identity services rather than just host naming. The members of the XRI TC took about 18 months to arrive at that conclusion, and now that it's up and operating, it's a lot easier to start to share that worldview.

Since we have to start to produce a new round of XRI education/ evangelism documents this fall as we finish the XRI 2.0 suite, please do tell me if you have suggestions as to how we can better communicate about it. Many of us on the TC are WAY too close to it ;-)

Well, here is suggestion number 1: I blog it. I'm hoping it helps others to understand this as well. Many thanks, Drummond, for educating us!!