Extensible Resource Identifier

You must add a |reason= parameter to this Cleanup template – replace it with {{Cleanup|November 2005|reason=<Fill reason here>}}, or remove the Cleanup template.
XRI (eXtensible Resource Identifier) is a scheme and resolution protocol for abstract identifiers compatible with Uniform Resource Identifiers and Internationalized Resource Identifiers, developed by the XRI Technical Committee at OASIS. The goal of XRIs is to provide a universal format for identifiers that are domain-, location-, application-, and transport-independent, so they can be shared across any number of domains and directories.

Features

Delegation - Namespaces can be delegated to other namespace authorities.
Federation - Namespaces defined separately can be joined together in a hierarchical or other fashion, and made visible and resolvable.
URI-compatibility - XRIs can be used wherever URIs are called for.
Decentralization - XRIs can be rooted in centralized or private/decentralized root authorities.
The ability to express the intent that parts (or all) of an XRI are intended to be "persistent".
Support of identifiers which can be structured and parsed by humans easily.
Support of identifiers which can be structured and parsed by machines easily.
Resolution uses a simple, extensible Internet-based resolution scheme.
Support for structured inclusion of identifiers from other schemes (identifier reuse - cross context identifiers).
Fully internationalizable, leveraging Unicode and IRI specifications.
Independence from transport mechanisms in which the identifier can be used.
Provision a trusted/secure resolution mechanism.
Resolution does not require DNS.

Why not just use HTTP URIs?

The Technical Commitee is composing a list of answers to this very frequently asked question. The following list is a summary of the main points made.

What does HTTP URI identify? Permathread at W3C TAG and elsewhere. The TC wanted to avoid this confusion. (Transport independence requirement, Requirement to be able to identify anything)

HTTP URIs don't have the delegation model needed. (Delegation requirement)

HTTP URIs don't define a clear way to get at metadata (as opposed to data) about a identified resource. A single XRI is intended to be used different ways and in ways we don't know yet. Extensibility of metadata is important. DNS is very limited in terms of what it can describe (even with NAPTR and DDDS). (Extensibility requirement, Transport-independence requirement)

HTTP URIs typically use DNS and DNS and doesn't support the trusted delegation model the TC has identified in its requirements. Resolution has to start with a trusted root and that root should be defined by the community of users. Using IP addresses instead of DNS is even worse because the delegation is limited by network topology. (Trusted resolution requirement, Delegation requirement)

Some folks don't trust DNS at all - too easy to perform DoS, for example. Pharming attacks, etc. (Trusted resolution requirement)

HTTP URIs don't support use of other identifiers in the delegation path - each part of the path is limited in its syntax. (Extensibility requirement, Cross references requirement).

HTTP URIs require use of IP Addresses or DNS names, both of which are managed in ways which may not work well with the intent behind using an XRI (ie. a DNS name may go away due to legal issues, etc, IP Addresses change). (Persistence requirement)

There's no way to discover what capabilities the resource associated with an HTTP URI have (in terms of network interaction) - all you know about is HTTP verbs (and then, unless you have a functioning OPTIONS command, you have to guess). There's no defined way to get at metadata about a resource separately from interacting with it.

Unique features

Cross-references. An XRI can contain another XRI (or a URI), to any level of nesting. (See XDI below).
Peer-to-peer addressing — XRI syntax supports the ability for any two network nodes to assign each other XRIs and perform cross-resolution. That is, a namespace (authority) can be referred to by names assigned by other parties. This aids in federating namespaces between organizations or communities of interest.
Global context symbols — a simple, human-friendly way to indicate the global context of an i-name or i-number using a single symbol (=, @, +, $, or !). These are not required, but may be used within certain communities of interest that agree on their meaning and how they are resolved.

Applications

I-name and I-number concepts use XRI.

XRIs also form the basis for the XDI trusted data sharing protocol under development by the OASIS XDI Technical Committee.

Examples

(Note that none of these show the prefix "xri://", which is optional in XRIs when they are not in URI normal form.)

Example XRIs composed entirely of reassignable segments:

 =Mary.Jones
 @Jones.and.Company
 +phone.number
 +phone.number/(+area.code)
 =Mary.Jones/(+phone.number)
 @Jones.and.Company/(+phone.number)
 @Jones.and.Company/((+phone.number)/(+area.code))

Example XRIs composed entirely of persistent segments:

 !!1002!A7C5
 !!1002!A7C5/!D90F.88

Example of XRIs with mixes of persistent and reassignable segments (XRI allows any combination of the two):

 !!1002!A745/(+phone.number)
 @Jones.and.Company/!D90F.88/(+area.code)

External links