XRI
XRI (eXtensible Resource Identifier) is a URI-compatible scheme and resolution protocol for abstract 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.
| Contents |
XRI Documents
XRI 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.
- XRIs have the ability to express the intent that parts (or all) of an XRI are intended to be "persistent".
- XRI supports identifiers which can be structured and parsed by humans easily.
- XRI supports identifiers which can be structured and parsed by machines easily.
- XRIs are resolvable using a simple, extensible Internet-based resolution scheme.
- XRI support for structured inclusion of identifiers from other schemes (identifier reuse - cross context identifiers).
- XRIs are independent of transport mechanisms in which the identifier can be used.
- XRI provides a trusted/secure resolution mechanism.
- XRIs and XRI resolution do not require DNS.
Why not just use HTTP URIs?
The TC 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 URL 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 URLs don't have the delegation model needed. (Delegation requirement)
- HTTP URLs 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 URLs 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 URLs don't support use of other identifiers in the delgation path - each part of the path is limited in its syntax. (Extensibility requirement, Cross references requirement).
- HTTP URLs 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 of XRI
- 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, an 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 of XRI
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)
See Also
External Links
- OASIS XRI Technical Committee
- OASIS XDI Technical Committee
- W3C Internationalized Resource Identifier (IRI)
- XDI.ORG