OASIS Extensible Resource Identifier TC

XRI 2.0 FAQ

May 2008

General Questions

What does the acronym XRI stand for?

EXtensible Resource Identifier. This is the name for digital identifiers that conform to the XRI Syntax specification.

What does the acronym XRDS stand for?

EXtensible Resource Descriptor Sequence. This is the name of the XML document format defined by the XRI Resolution specification for discovery and resolution of XRI-identified resources. (Note that XRDS-based discovery also works with URLs.)

What is an "i-name" and an "i-number"?

These two informal terms are applied to the two basic forms of XRIs:

  1. An i-name is a reassignable, human-friendly XRI such as =drummond.reed. I-names, like domain names, can be transferred to new owners and reassigned to resources.
  2. An i-number is a persistent, machine-friendly XRI such as =!F83.62B1.44F.2813 that is assigned once to a resource and never reassigned. This is the XRI equivalent of a URN (see below).

Like domain names, both i-names and i-numbers can be delegaged to any depth. Unlike domain names, i-name and i-number delegation works from left-to-right, and instead of dots, i-name delegation uses the * character and i-number delegation uses the ! character. Examples: 

    =drummond.reed
    =drummond.reed*family
    =drummond.reed*family*gardner
    =drummond.reed*family*montana
    =!f83.62b1.44f.2813
    =!f83.62b1.44f.2813!17
    =!f83.62b1.44f.2813!17!1
    =!f83.62b1.44f.2813!17!2

What is the relationship of XRI to URI and IRI?

URI (RFC 3986) is the IETF/W3C standard for addressing on the Web. IRI (Internationalized Resource Identifier, RFC 3987) builds on top of the URI specification by extending the syntax to include Unicode characters. It also defines a transformation from an IRI into a valid URI for applications that can only accept URIs.

XRI follows this same model. It builds on the IRI specification by extending the syntax to include features needed by abstract, structured identifiers intended to identify resources independent of any specific network location, domain, application, or protocol. The XRI Syntax specification also defines a transformation from an XRI into an IRI or URI for applications that only accept IRIs or URIs.

Why was XRI needed?

Early Web architecture divided Web addresses (URIs) into two types: URLs (Uniform Resource Locators) and URNs (Uniform Resource Names). URLs are "concrete" addresses that identify resources available at a specific location and protocol (and thus can "break" if a resource moves). URNs are "abstract" addresses that can persistently identify resources independent of any specific location, domain, application, or protocol.

URLs have become the most successful identifiers in history. But URNs have acheived very little adoption. Why?

The main reason is that URN systems fulfilled only two requirements for abstract identifiers: persistence (identifiers that never change) and delegation (decentralized identifiers). They did not address other requirements emerging from digital identity frameworks, semantic webs, social networks, and other "identity layer" applications, e.g., ease-of-use, resource discovery and description, trusted resolution, structured identifies, and cross-context identification.

This gap led to the formation of the XRI Technical Committee at OASIS in early 2003.

Where are XRI and XRDS being used today?

  • OpenID. The OpenID Authentication 2.0 specification supports both URL and XRI identifiers and uses the XRDS discovery format and resolution protocol defined by the XRI Resolution 2.0 specification. (For details, see OpenID Identity Discovery with XRI and XRDS, an ACM paper given at the IDtrust Symposium, March 2008.)
  • OAuth. The OAuth Discovery specification uses the XRDS discovery format.
  • LDAP directories. Companies like Boeing are using XRIs as a "universal primary key" for LDAP entries, i.e., an application-independent cross-context identifier that can be used between companies as well as internally.
  • Higgins. The Higgins Project, an open source user-centric digital identity framework, uses XRIs to identify Higgins context providers (plug-ins that expose native data repositories via the abstract Higgins data model). It also uses XRDS documents for discovery of the metadata necessary to open a Higgins context.

What open source implementations are available?

The XRI community maintains a list of XRI open source projects. As of May 2008, the best known are the OpenXRI project in Java, the Barx project in Ruby, and the MyXDI project in C++.

What specifications are part of XRI 2.0?

Two XRI 2.0 specifications have been submitted for an OASIS Standard vote in May 2008:

  1. XRI Syntax 2.0 defines the syntax, relative reference rules, normalization/comparison rules, and IRI/URI transformation rules.
  2. XRI Resolution 2.0 defines a simple XML discovery document format called XRDS together a lightweight HTTP(S) resolution protocol. It also defines a trusted version based on signed SAML 2.0 assertions.

A third Committee Draft specification, XRI Metadata 2.0, defines a small set of globally interoperable XRIs that may be used as cross-references within other XRIs to "markup" an identifier, including its language, date, or version.

Are there any intellectual property restrictions on XRI?

No. The XRI TC operates under the OASIS RF-on-Limited-Terms IPR mode, which means all XRI TC specification are available royalty free without restriction. This has always been a requirement of the XRI TC charter. See the XRI TC IPR page for details.

Example XRIs

What kinds of things can XRIs be used to identify?

XRIs -- like URIs or IRIs — can identify any type of resource: people, organizations, applications, machines, digital objects, or even abstract concepts like "love" or "the number 21". There is no requirement that the resource be "resolvable" or tangible in any form.

What do example XRI i-names look like?

I-numbers are the simple, human-friendly form of an XRI. Note that in their native form, they start with a single symbol. Also, they may contain dots within a name (the dot is not part of XRI syntax, just a character in the name). The delegation character for i-names is a star ("*"). 

    =gmw
    =用例 
    @boeing
    @cordance*drummond.reed
    +flower
    $xml

What do example XRI i-numbers look like?

I-numbers are the persistent, machine-friendly form of an XRI. I-numbers start with a symbol followed by a bang ("!"). Bang is also the delegation character for i-numbers. (Note that "i-numbers" can actually consist of any string of valid XRI characters, not just numbers. Hex values are commonly used.) 

    =!7a42.cd93.40f4.18e5
    =!7a42.cd93.40f4.18e5!283
    @!b3a7.5537.9fea.31ec
    +!3792
    +!3792!14

What do example XRI cross-references look like?

A cross-reference is an identifier from one context reused in another context. In XRI syntax, a cross-reference is enclosed in parentheses. 

    =(mailto:gabe.wachob@example.com)
    =(http://equalsdrummond.name)/blog-stats
    @(http://boeing.com)
    @cordance*(urn:isbn:0-395-36341-1) 
    +flower*(http://en.wikipedia.org/rose)

What do XRIs transformed into URIs look like?

When an XRI is transformed into "URI-normal form", "xri://" is added as a prefix and any characters outside the narrow range of ASCII characters allowed in a URI are percent-encoded. 

    xri://=drummond.reed
    xri://=%E7%94%A8%E4%BE%8B
    xri://@!b3a7.5537.9fea.31ec!133/path?query
    xri://=(mailto:gabe.wachob@gmail.com)
    xri://@cordance*(urn:isbn:0-395-36341-1)/book-description.html

XRI Syntax

What are the major components of XRI syntax?

The structure of XRIs is based directly from the structure of URIs. XRIs usually start with the string "xri://" followed by an authority component and then the path component (if any). As with in generic URI syntax, the authority and path parts may be followed by optional query and fragment components.

For example, the XRI "xri://@oasis*xri/docs/syntax?section=security#encoding" can be broken into the following parts:

Scheme xri://
Authority @oasis*xri
Path /docs/syntax
Query  ?section=security
Fragment #encoding

Note that in the authority (and potentially in the path), there is a further structure consisting of a list of subsegments separated by subsegment delimiters. In the example above, "*" is the subsegment delimiter used to separate "oasis" and "xri" subsegments. (Technically, the "@" sign, called a global context symbol (GCS), is also a separate subsegment. An "*" is implied when it is not present after a GCS character such as "@". See the Authority section below.)

How are cross-references expressed?

Cross-references are a special type of XRI subsegment, enclosed in parentheses, that allow any URI, IRI or XRI value (i.e., an XRI without the xri:// part) to be inserted in an XRI. Following is an example of using an URN ISBN number for a book used as a cross-reference within the XRI for a library: 

    @city*library/(urn:isbn:23232232)

Here's another example of a cross-reference used to indicate a well-known concept (email address) relative to an XRI authority: 

    =joe.smith*(+email)

Cross-references encapsulate the referenced identifier so it can be reused within the context of another identifier. Identifier reuse across contexts is highly useful in semantic applications. It supports both the English-language concept of "proper nouns" (identifiers for people or organizations) and "generic nouns" (identifiers used for general dictionary terms). Note that during XRI resolution, a cross-reference is treated as a single subsegment, regardless of the syntax of the identifier in parentheses.

What is a subsegment?

First, a segment is any portion of a URI, IRI, or XRI delimited by forward slashes ("/segment1/segment2/"). The authority component is the first segment of an absolute URI, IRI, or XRI, which always beings with a double forward slash ("xri://authoritysegment/").

In XRI syntax a subsegment is a portion inside a segment delimited by "*" or "!". (See below for more about the difference.) For example, the XRI segment /city*seattle*roadmap!1234/ has four subsegments, three delimited with "*" and one with "!".

URIs and IRIs also have subsegments but only within DNS names or IP addresses used in the authority component. In the case of DNS names and IPv4 addresses, the subsegment delimiter is "." (period); in the case of IPv6 addresses, it is ":" (colon).

What do the "*" and "!" delimiters mean?

The "*" (asterisk, star) delimiter indicates that the authority who assigned the following subsegment might reassign it to a different resource at some future date. Formally this is called a "reassignable subsegment"; informally an "i-name".

The "!" (exclamation point, bang) delimiter indicates the authority who assigned the following subsegment intends never to reassign it to a different resource. Formally this is called a "persistent subsegment"; informally an "i-number".

Note that merely declaring a subsegment persistent using the "!" delimiter does not by itself make it persistent. As explained in the IETF URN specification (RFC 2141), persistence is an operational characteristic that can only be maintained by identifier authorities. Such management is outside of the scope of the XRI specification.

How do you express a fully persistent XRI?

By using all persistent subsegments (including persistent cross-references), both in the authority component and in any path segments. For example, all of the examples below are fully-persistent XRIs: 

 xri://@!1002.eb52.a9c9.38b5
 xri://@!1002.eb52.a9c9.38b5!82a7
 xri:// @!1002.eb52.a9c9.38b5!82a7/!c345.d22a

Although these XRIs do not use the URN scheme, they fulfill the requirements of fully persistent identifiers as defined by RFC 1737. You may also create a persistent XRI using a cross-reference to one or more fully persistent identifiers such as a URN. For example: 

 xri://@!(urn:isbn:0-395-36341-1)
 xri://@!1002.eb52.a9c9.38b5!(urn:isbn:0-395-36341-1)
 xri://@!1002.eb52.a9c9.38b5!(urn:isbn:0-395-36341-1)/!4!7!92
 xri://@!1002.eb52.a9c9.38b5!82A7/!(hdl:18975/22745)

Note that while it is valid to include both reassignable and persistent subsegments in an XRI, an XRI that includes at least one reassignable subsegment is not persistent as a whole.

Authorities

What is an authority?

In the context of identifiers, an authority is the entity that controls a namespace. With XRIs, an authority typically hosts a server that provides XRI resolution services. These servers are analogous to nameservers in DNS. Just as in DNS, multiple authority namespaces may be hosted on a single XRI server.

What types of authorities does XRI support?

XRI supports two overall types of authorities:

  • IRI authorities, which include the same two types of authorities supported in URIs and IRIs, i.e., IP addresses and DNS names.
  • XRI authorities, which include two new types of authority identifiers: GCS characters and cross-references (see below.)

Since XRI authority syntax is a superset of URI/IRI authority syntax, any authority identifier than can be used in a URI or IRI may also be used in an XRI.

What are the two new XRI authority options?

The two new types of authorities supported by XRI syntax are:

  • Global context symbols (GCS) -- single-character symbols used to indicate the global context of the authority type (see below).
  • Cross-references, which enable any identifier to be used to identify a peer-to-peer authority (see below).

Both GCS characters and cross-references support delegation to other authorities. Note that a GCS character may only be used as the first authority subsegment, called the community root authority, while a cross-reference may be used as the root or at any level of delegation.

What is a community root authority?

A community root authority is the first subsegment in an XRI authority component. A community root authority may either be a GCS character or a cross-reference. For example, xri://@example*bar uses the "@" community root authority and xri://(http://example.com) uses the (http://example.com) community root authority.

Community root authorities enable community members to share a common namespace for shared resources. XRI resolver clients must be configured with the "bootstrap" resolution metadata necessary to locate a community root authority, similar to the configuration of root DNS servers in a DNS resolver. See the XRI Resolution section below.

Community root authorities may be established by any community that requires interoperable identifier resolution, e.g., governments, telecommunications networks, industry consortia, etc. There are also non-profit organizations that offer public community root authorities for global context symbols. For more information, see the Wikipedia article on XRI.

What is a global context symbol (GCS)?

A global context symbol is one option for specifying a community root authority. There are five GCS characters, each specifying the type of identifier authority they represent:

GCS Character Identifier Authority
= Individual persons
@ Organizations
+ Generic dictionary concepts or "tags"
$ Specified identifiers from standards bodies
 ! Persistent identifier authorities

Examples of GCS symbols at work: 

    xri://=john.smith
    xri://@joes.grill
    xri://=(mailto:john.doe@yahoo.com)
    xri://+tel
    xri://=john.smith/(+tel)
    xri://$v    (version)
    xri://=john.smith*(+tel)*($v*3)
    xri://$l    (language)
    xri://@joes.grill*($l*fr)*fran�ois
    xri://!!1002

Is "xri://" optional if an XRI begins with a GCS character?

Yes. This is a specific feature of XRI syntax to aid in human usability. It enables very simple strings to be recognized and interpreted as XRIs by electronic editing software. Examples: 

    =john.smith
    @example
    +flower
    $xml

What is a community root cross-reference?

A community root cross-reference is a community root authority expressed with a cross-reference. This enables peer-to-peer identifier communities to form and evolve without registration. Using a globally unique identifier as the community root cross-reference helps ensure against name collisions (however there is no ironclad guarantee that two or more communities will not choose the same cross-reference for their root.)

Typically a community root cross-reference is identified by a URI. For example: 

    xri://(mailto:john.smith@example.com)*friends/name
    xri://(http://example.com/john.smith)*friends/name

As with GCS authorities, an XRI resolver must be preconfigured to recognize a community root cross-reference.

How does XRI authority delegation work?

Each subsegment in the authority component of an XRI corresponds to a separate authority. For example, in @us*california*oakland, the following XRIs identify four separate authorities: 

    @
    @us
    @us*california
    @us*california*oakland

Note that an authority may be identified with multiple XRIs, and these XRIs may not always at the same level of delegation. For example, the following two XRIs may resolve to the same real-world authority: 

    @city*san.francisco*baseball
    @mlb*giants

If so, they are called XRI synonyms. If two XRIs are synonyms for the same authority, any subsegments underneath these two authority identifiers will always resolve to the same resource. For example, if the previous XRIs are synonyms, then the following XRIs will also resolve to the same resource: 

    @mlb*giants*manager
    @city*san.francisco*baseball*manager

How can I use DNS with XRI?

As discussed above, the authority component of an XRI may contain an IRI authority, which may be either a DNS name or an IP address. These always start with either a letter or a number, respectively, while a GCS authority is always a symbol and a cross-reference always starts with a left parentheses. For example, the following are all valid IRI authority components in an XRI. 

    xri://www.example.com
    xri://10.0.0.1/index
    xri://[32c6::7]/user/docs/some.html

XRI resolution, which is based on HTTP(S), resolves this type of authority by requesting an XRDS document from an HTTP URL constructed from the domain name or IP address. See XRI Resolution 2.0, Section 9.2.

A DNS name or IP address can also be used as community root cross-reference. Since cross-references are opaque strings from the standpoint of XRI resolution, this method only uses the DNS name or IP address as a unique identifier for the authority.

Normalization and Comparison

What are XRI-normal, IRI-normal, and URI-normal forms?

Just as the IRI specification (RFC 3987) defines a transformation of an IRI into a valid URI for applications that can only accept URIs, the XRI Syntax specification defines a transformation of an XRI into an IRI for applications that can only accept an IRI (which can then be transformed into a URI following the rules in the IRI specification.)

Thus an XRI can exist in three different normalization forms, depending on where it is being used. These forms differ only in what characters are percent-encoded and which ones are not. An XRI is considered equivalent in all three normal forms.

  • XRI normal form is the most minimally escaped form. In this form, any Unicode characters allowed by IRI syntax but not URI syntax are normalized according to Unicode Normalization Form KC (NFKC) and UTF-8 encoded. Other than this, no further escaping is performed. This is the preferred form for applications, languages, and protocols that accept XRIs.
  • IRI normal form requires escaping of the small set of delimiter characters that have special purposes in an XRI but may be misinterpreted in the transformation to IRI syntax as defined by RFC 3987. No other escaping is necessary. This is the preferred form for applications, languages, and protocols that accept IRIs (such as XML).
  • URI normal form requires escaping of the UTF-8 encoded characters allowed in an IRI but not in a URI to be fully compliant with RFC 3986. This transformation is defined in RFC 3987.

Note that XRI resolution requires an XRI be converted to URI-normal form in order to be compatible with the HTTP(S) protocol, which requires URIs.

How can I tell if two XRIs are equivalent?

Exactly the same way URI or IRI comparison is performed, i.e., by doing a character-by-character comparison after applying a small set normalization and comparison rules defined in XRI Syntax 2.0, Section 2.5.

How can I tell if two XRIs identify the same resource?

Other than the simple case where the two XRIs are character-for-character equivalent (as discussed above), the answer is by resolving them to see if they return either: a) the same XRDS document, b) separate XRDS documents that reference each other as synonyms (see XRI Resolution 2.0, Section 5), or c) a redirect to the same actual resource representation.

XRI Resolution

What is meant by XRI resolution?

Resolution is the process of converting an identifier into metadata describing the resource it identifies. In XRI resolution, this is implemented as an HTTP(S) request for an XRDS document.

What is an XRDS document?

XRDS is an XML-based discovery document format specified by XRI Resolution 2.0, Section 4. XRDS documents contain one or more XRDs (Extensible Resource Descriptors) — at least one for each XRI subsegment being resolved. Each XRD typically includes one or more service endpoints.

For more details, see the Wikipedia article on XRDS.

What is a service endpoint?

A service endpoint (often abbreviated SEP) is a set of elements contained inside a Service element that describe a concrete network endpoint at which to obtain further metadata or otherwise interact with the resource described by the XRD. SEP elements include:

  • Type - an XRI, IRI, or URI specifying the type of the service.
  • MediaType - a string that specifies a media type supported by this endpoint (for use in HTTP(S) content negotation).
  • URI - an URI that specifies the concrete network endpoint at which to obtain this service.

An unlimited number of services can be defined using the contents of these elements without the need to extend the XRD schema. The XRI resolution protocol itself is defined via a set of service endpoint types.

What is authority resolution?

Authority resolution is the first phase of XRI resolution in which the authority component of an XRI is resolved into an XRD describing the final target authority (the authority identified by the rightmost subsegment).

The authority resolution protocol uses HTTP(S) and a URI construction algorithm to resolve each subsegment from left to right, starting with the community root authority subsegment (identified either by a Global Context Symbol or a cross-reference).

Authority resolution is also defined for IRI authorities (DNS names or IP addresses) via a single HTTP(S) request to an HTTP URL composed of the DNS name or IP address as the authority component.

What is service endpoint selection?

Service endpoint selection is the optional second phase of XRI resolution in which a resolver can automatically select a specific set of service endpoints based on the Type, Path, or MediaType specified in the resolution query. See XRI Resolution 2.0, Section 13.

What is trusted resolution?

Trusted resolution refers to the use of secure protocols during the resolution process. XRI Resolution 2.0 offers three trusted resolution modes:

  1. Use of HTTPS endpoints throughout the resolution chain.
  2. Use of signed SAML assertions throughout the resolution chain.
  3. Both of the above.

Trusted resolution is an optional feature of an XRI resolver and an XRI authority server and need not be implemented by every resolution client or server.

What is lookahead resolution?

Lookahead resolution is when an XRI resolver asks an authority server to try to resolve more than one authority subsegment at a time. If the authority server complies with this request, it will return a chain of XRDs wrapped in an XRDS document.

Note that the difference between this functionality and proxy resolution (below) is subtle and interested parties should consult the XRI Resolution specification for more details.

What is proxy resolution?

Proxy resolution refers to sending an XRI resolution request encoded in a URL to an HTTP(S) server that operates as an XRI resolver. The encoding format is called an HXRI (HTTP(S) XRI). The proxy resolution interface is defined in XRI Resolution 2.0, Section 11.

This "on behalf of" resolution is very similar to the notion of recursive resolution in DNS.

XRI proxy resolvers use HTTP content negotiation to determine the resolution response. If asked for an XRDS document in the HTTP Accept header, the proxy resolver will return the complete chain of XRDs corresponding to all authority subsegments (and, if requested, service endpoint selection). If the client is non-XRI-aware and does not specify an Accept content type, the proxy resolver will automatically perform service endpoint selection and return an HTTP redirect based on the results. This allows HXRIs to work in non-XRI-aware browsers.

What are examples of HXRIs?

The first portion, before the path, is called the proxy resolver prefix. 

    http://xri.example.com/=john.smith
    http://xri.example.com/=john.smith/(+contact)
    http://xri.example.org/@company*division/!1234.5678
    http://xri.example.net/@!1002.9876.a4c2.ff3c/!98!8!14

HXRIs may include proxy resolution parameters to control the return type and service endpoint selection. Following is an example that specifies the return type XRDS document and request service endpoint selection for an OpenID 1.0 login service: 

    http://xri.example.com/=john.smith?_xrd_r=application/xrds+xml;sep=true
    &_xrd_t=http://openid.net/server/1.0

How does a cross-reference get resolved?

In XRI resolution, a cross-reference is treated as a single opaque subsegment, no matter how complicated its structure is.

For example, in the context of the following ficional XRI... 

    xri://@whitehouse*(=bill.clinton*brother)

...the following are subsegments for the purpose of resolution: 

    @
    *whitehouse
    *(=bill.clinton*brother)

Note that even though =bill.clinton*brother is itself a standalone XRI with its own authority component, when contained within a cross-reference its subsegments are NOT resolved independently. Instead, the entire XRI =bill.clinton*brother is treated as an opaque set of characters and treated identically to the *whitehouse subsegment.

How is XRI resolution and XRDS documents extensible?

XRDS documents are designed to be pure container elements for XRDs as well as elements from any other XML namespace can be added.

XRDs, for their part, are a very simple and highly extensible resource descriptor format. The XRD schema has a very small set of defined elements used for XRI resolution and service endpoint description. However, there are numerous places where arbitrary XML may be added. Examples of such XML are service attributes, alternate identifiers, RDF statements, security tokens, or almost any other metadata about the described resource. For full details see XRI Resolution 2.0, Section 17.

XRI Metadata

Note: the XRI Metadata 2.0 Committee Draft 01 specification is not currently being submitted for an OASIS Standard vote.

What types of identifier metadata are defined in this specification?

The XRI Metadata 2.0 specification is intended to define a small set of XRIs for general-purpose identifier metadata that aids cross-context interoperability. It includes three primary metadata types:

  • Language - metadata that specifies the language in which an identifier is intended to be understood, interpreted, or pronounced (using RFC 3066 language tags.)
  • DateTime - metadata representing the date and time an identifier was assigned (in XML datetime format.)
  • Version - metadata representing the version of an identifier (in simple dot- or dash-delimited integer format.)

The XRI TC intends to add metadata types added over time if they have very broad applicability.

How is this metadata used?

The metadata is specified in the form of XRIs assigned using the global context symbol "$", which is reserved for specifications such as this. All metadata in this specification is assigned using single character namespaces — $l for language, $d for date, and $v for version ($- is also specified for annotations).

This metadata is then intended to be used in XRI cross-references to describe other segments or subsegments of an XRI. Following are several examples: 

    xri://@example*($l*fr)*françois
    xri://=john.smith/(+tel)*($d*2004-09-23T11:52:45-05:00Z)
    xri://@example*division/resource*($v*3.2)

XRI and other Identifier Schemes

Why not just use HTTP URIs?

Note: this question is also answered in Section 1 where the motivations for XRI are discussed.

First, with the XRI Resolution 2.0 specification, there is now a defined HTTP URI format in which all XRIs can be expressed. So in essence, XRIs can be treated entirely as HTTP URIs for the purpose of backwards compatability with HTTP infrastructure.

Second, XRI Resolution 2.0, Section 6, defines how the XRDS discovery protocol can be used with conventional HTTP(S) URIs. So this is another area of compatability with URLs.

From a broader perspective, the reason HTTP URI syntax itself was not used for XRIs is that it does not fulfill several of the key requirements for abstract structured identifiers. Specifically:

  • HTTP URIs are bound to a specific transport protocol. A fully abstract identifier scheme needs to be independent of any specific transport or access protocol.
  • HTTP URIs do not support sharing structured, "tagged" identifiers across contexts. A fully abstract identifier scheme will enable "identifier markup" just like XML enables data markup.
  • HTTP URIs do not define a clear way to obtain metadata (as opposed to data) about a resource. A fully abstract identifier scheme can cleanly distinguish access to resource metadata vs. access to a resource itself.
  • HTTP URIs offer only a very limited authority delegation model. Abstract identifiers need to be able to express logical authorities and authority delegation relationships at any level of hierarchy.
  • HTTP URIs do not offer a trusted resolution mechanism. A fully abstract identifier scheme can define a trusted resolution protocol independent of DNS.
  • HTTP URIs do not offer a standard syntax for persistence. A fully abstract identifier scheme can syntactically distinguish between persistent and reassignable identifiers.

Can you provide a specific example?

Perhaps the best example is the one used on the Wikipedia article on XRI, which illustrates the use of XRI cross-references. Say a library system uses URNs in the ISBN namespace to identify books and DNS subdomains to identify its library branches. HTTP URI syntax does not provide a standard way to express the URN for the book title in the context of the DNS name for the library branch. XRI cross-reference syntax solves this problem by allowing the library (and even automated programs running at the library) to programmatically construct the XRIs necessary to address any book at any branch. Examples: 

    xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)
    xri://shoreline.library.example.com/(urn:isbn:0-395-36341-1)
    xri://northgate.library.example.com/(urn:isbn:0-395-36341-1)

This ability to create structured, self-describing identifiers can be extended to many other uses. For example, say the library wanted to indicate the type of each book available. By establishing a simple XRI dictionary of book types, it can now programmatically construct XRIs that include this metadata, 

    xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)/(+hardcover)
    xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)/(+softcover)
    xri://broadview.library.example.com/(urn:isbn:0-395-36341-1)/(+reference)

Should I use XRIs instead of URNs?

Fully persistent XRIs are functionally equivalent to URNs. They also have the advantage of the other features of XRI syntax, resolution, and metadata. In addition, XRI architecture is unique in that it allows resources to be simultaneously identified with both persistent and reassignable synonyms - the former for unambigous, long-lived identification and the latter for human usability.

Notices

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.

Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS President.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS President.

Copyright © OASIS Open 2008. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 

TOP OF PAGE

Gear Image