This page summarizes a new proposal for how to integrate XRIs with URIs and WWW architecture that has arisen from discussions between the OASIS XRI TC and the W3C TAG starting in July 2008.


When the XRI Technical Committee was founded in 2003, it was assumed that the TC would fulfill its charter to develop a uniform abstract identifier syntax and resolution architecture by defining a new URI scheme. It was widely believed that this was the best way to ensure compatability with the Architecture of the World Wide Web (AWWW), since a fundamental tenant of AWWW is that all resources on the Web are URI-addressable.

However as the Web has evolved, so has the W3C TAG's view of new URI schemes. The TAG now strongly discourages the use of new URI schemes whenever existing schemes, particularly the http: URI scheme, can be adapted to fulfill new resource identification requirements.

Overview of the Proposed New Approach

In discussions about the TAG’s concerns regarding XRI 2.0, the XRI TC clarified that XRIs have always been defined to be fully abstract identifiers –- identifiers that, if resolved, never return a concrete representation of the identified resource but only a descriptor of the resource. One could say, "XRIs are to URI-identified resources what DNS names are to IP-addressable resources". Furthermore, though resolution of an XRI is optional, if it is resolved then the XRI Resolution 2.0 protocol specifies that the XRI is always "bound" to a concrete http(s): URI to obtain the resource descriptor. This binding between an XRI and an http: or https: URI has been called an HXRI.

Therefore the "pure XRI" used to identify the target abstract resource has always been separate from the identifier produced by binding the XRI to a specific scheme such as http: or https:. It was the XRI TC's assumption that it would need a default scheme binding for "unbound XRIs" and thus defined the xri: scheme starting with XRI Syntax 1.0. However discussions with the TAG helped reveal that if the purpose of XRIs is to establish a syntax and semantics for abstract identifiers that can be shared across domains and applications, then such syntax and semantics can also be shared across multiple URI schemes. Furthermore, reuse of these schemes via extension is more attractive than introduction of a new URI scheme.

The conclusion was that, rather than define a new URI scheme, the goals of XRI architecture can also be met by:

  1. Formally defining XRI syntax as form of relative URI.
  2. Defining bindings between this form of relative URI and base URIs in URI schemes where XRI syntax and semantics can add value.

Revisions This Will Require in XRI 3.0

If the XRI TC takes this new approach, the following revisions will be required to XRI 2.0 architecture:

  1. Remove the xri: scheme from the ABNF. The pure abstract XRI would no longer have any defined scheme.

  2. Define requirements for bindings to other URI schemes. Each binding definition would need to include:

    1. A definition of an unambiguous base URI or base URI pattern in the target scheme.
    2. A definition of any encoding requirements.
    3. A definition of any synonmity requirements.
  3. Define bindings. The initial proposed bindings are:

    1. http:
    2. https:
    3. info:
    4. Other bindings that may be considered in the future: ftp:, xmpp:, urn:.

  4. Revise XRI forms and transformations. XRI 2.0 defined a set of forms and transformations between XRI, IRI, and URI forms. These would need to be adapted to the specific URI scheme bindings.

  5. Specify XRI resolution in terms of the http: and https: bindings. This is primarily an editorial change since XRI 2.0 resolution architecture is already based on http(s): URIs. However it is important to also mention that other resolution protocols may also be defined using other protocols or other URI scheme bindings.

  6. Define application dispatch rules. In most URI processors (such as browser address bars), URI dispatch is based on the URI scheme. Under this proposal, XRI-aware user agents need to be able to parse and dispatch XRIs regardless of scheme.


When XRIs are bound to other URI schemes, it can become confusing what is "the XRI". To help avoid confusion, we are suggesting the following terms:

Examples of Scheme Bindings

Background – HXRIs in XRI Resolution 2.0

The XRI Resolution 2.0 specification defined an http(s): URI form of an XRI using the following pattern...


...where {xri} is the XRI of the target resource expressed in XRI normal form as defined in XRI Syntax 2.0 but explicitly excluding the optional xri://.

Examples of such identifiers:

Because this binding relies on the combination of a least-significant domain name and the first character of the path, the TAG has recommended that a stronger binding be defined, ideally one that relies only on the authority segment (domain name path).

Proposed HTTP and HTTPS Bindings

Following the TAG's advice, the proposed http-xri and https-xri bindings are:


Since all http(s)-XRIs represent XRI proxy resolvers, the proposed management of the *.xri.net namespace is to use "auto-delegation". This means any domain name can be automatically addressed in the context of the xri.net domain name (e.g., boeing.com.xri.net, oasis-open.org.xri.net) without registration or permission from xri.net. DNS queries to the xri.net nameservers will result in a lookup for a special SRV or NAPTR record in the target subdomain that indicates the IP address of its XRI proxy resolver.

Centralization, Delegation, and Minting XRIs

A key principle shared by IP addressing architecture, DNS naming architecture, and URI identifier architecture (for URIs using the hierarchical URI syntax) is that any authority, once registered into these namespaces, may then further delegate and assign its own identifiers without further reference to the registration authority.

XRI architecture has always followed this same delegation principle, and that does not change under the XRI-as-relative-URI proposal. However it is not widely understood that XRI architecture actually offers three different delegation options, two of which do not involve registration at all. Here's how they work:

Option #1: Proxy Delegation

This is described under the Proposed HTTP and HTTPS Bindings above. In essence, the xri.net root proxy resolver will auto-delegate to any other domain that maintains the necessary SRV or NAPTR record that points to its XRI proxy resolver. So any domain may run its own http-XRI or https-XRI proxy resolver. Examples:


Secondly, the XRI being resolved by that proxy may be a relative XRI (this is indicated by starting with a * or ! character). Examples:


Since * and ! represent local contexts, Boeing and OASIS respectively completely control these relative XRI namespaces in the same way that they control their own URI namespaces today. No registration with any other XRI authority is involved.

Option #2: Private Root Communities

The second option uses XRI cross-reference architecture to enable every http(s): URI authority implement its own XRI root namespace without reference to any other registration authority. To do this, the http(s): URIs authority identifies their root community using a top-level XRI cross-reference. Examples:


Under the XRI-as-relative-URI proposal, the resolution rule for top-level cross-references would be that the http(s): URI inside the cross-reference is the identifier of the root XRI authority server from which XRI resolution begins. Again, Boeing and OASIS respectively would completely control these absolute XRI namespaces in the same way that they control their own URI namespaces today, and again, no registration with any other XRI authority is involved.

Option #3: Public Root Communities

The third option uses public root registries based on the XRI global context symbols = (for individuals) and @ (for organizations). This option is similar to registering a domain name in DNS top-level domain (TLDs). One key difference is that every reassignable XRI "i-name" registered in these registries is automatically assigned a synonymous persistent XRI "i-number". Examples:


This is the only one of the three options that involves centralized registration in the same manner as DNS. The delegation model is identical to DNS, i.e., once registered, any authority then has complete control of its own XRI namespace, i.e., it can mint new delegate XRI authorities, local XRIs, or XRI cross-references without reference to any other authority.

Currently these public XRI registry services are operated by XDI.org, a public non-profit organization. XDI.org and several of its XRI registry services contractors and subcontractors (Cordance and NeuStar are members of the XRI TC.

Next Steps

Following are the proposed next steps for moving forward with this proposal.

  1. Solicit feedback on the OASIS XRI TC and W3C TAG public mailing lists (October 2008).
  2. Agree on XRI 3.0 requirements and assign spec drafting tasks. (XRI TC face-to-face meeting Nov. 13-14 following Internet Identity Workshop, Mountain View CA, Nov. 10-12, 2008).

  3. Complete XRI 3.0 Committee Draft specifications (January 2009).
  4. Begin XRI 3.0 public review (by end of Q1 2009).


The XRI TC actively solicits feedback on this proposal. Discussion is currently underway on the W3C TAG public mailing list, which is open to anyone to join. Look for threads marked with the tag [XRI] in the subject line. You can also send feedback directly to the XRI TC chairs via the email addresses listed at the top of the XRI TC home page.

XRI TC members are of course welcome to leave feedback here on this wiki page.

A Comment on Possible URN Scheme Binding for XRIs

Looking over RFC 2141 all of the delimiter characters in an XRI seem to be allowed in the other group, except for '/', '?', and '#'. I have no problem if XRIs do not have query strings or fragment identifiers as I think that can be encoded within the XRI easily enough. That would eliminate the need for '?' and '#'. '/' is more problematic as a key component of XRIs is hierarchy.

One option is % encoding. This would allow keeping current XRI syntax but would mean every URN XRI will be encoded,decoded.

Another option is ':'. This fits nicely with URN syntax and I think probably the best choice, though it is not as intuitive for the average user as '/'. If we chose this character to replace '/' in XRI URNs then do we have '::' to replace context delimiter sequence '//'? Given that the context concept seems to play a large role in current implementations what is thought about using ';' as a context delimiter?

If the above work for URN XRIs and we're already breaking compatibility with prior XRI syntax, then what about making the above changes in the primary XRI syntax?

XriAsRelativeUri (last edited 2009-08-12 18:07:23 by localhost)