One problem XRIs are designed to solve is
persistent addressing — how to maintain an address that does not need to change no matter how often the contact details of a person or organization change. XRIs accomplish this by adding a new
layer of abstraction over the existing
IP numbering and
DNS naming layers used on the Internet today (as well as over other type of addresses, such as phone numbers or
instant messaging addresses). Such an abstraction layer is not new —
URNs (Uniform Resource Names) and other
persistent identifier architectures have the same effect. What's different about the XRI layer is that it offers a single uniform syntax and resolution protocol for two different types of identifiers:
I-names I-names are identifiers resembling
domain names, designed for simplicity and ease of use. Though typically long-lived, i-names may, like domain names, be transferred or reassigned to another resource by their owners. For example, a company that changes its corporate name could sell its old i-name to another company, while both companies could retain their original i-numbers. What most differentiates i-names from domain names is that in practice they will have a synonymous (equivalent) persistent
i-number (below).
I-numbers I-numbers are
machine readable identifiers (similar to
IP addresses) that are assigned to a resource (for instance, a person, organization, application or file) and never reassigned. This means an i-number can always be used to address a network representation of the resource as long it remains available anywhere on the network. I-numbers, like IP addresses, are designed to be efficient for
network routers to process and resolve. XRI syntax also allows i-names and i-numbers to be combined within the same XRI. So effectively the XRI layer supports both i-name and i-number
synonyms for resources — one that reflects real-world semantics and can change over time, and one that reflects the persistent identity of a resource no matter how often its attributes (including its i-names) may change. And the same
HTTP-based XRI resolution protocol can be used to resolve either an i-name or an i-number to an
XRDS document describing the target resource. XRIs are backward-compatible with the DNS and IP addressing systems, so it is possible for domain names and IP addresses to be used as i-names (or, in rare cases, as i-numbers). Like DNS names, XRIs can also be "delegated", i.e., nested multiple levels deep, just like the directory names on a local computer file system. For example, a company can register a top-level (global) i-name for itself and then assign second- or lower-level (community) i-names to its divisions, employees, etc. Examples: =Mary.Jones*Henry @Example.Corp*Ecuador*Quito i-names are called
unified digital addresses because they can be resolved using the
XRI resolution protocol into
XRDS documents that expose various services for accessing the digital identity they represent. These services, such as
OpenID,
OAuth, or
XDI can expose any other type of data under the control of this identity. Privacy is protected because the identity owner controls access. For example, the registrant of
=Mary.Jones would not receive
spam from this i-name because it is not an email address. To resolve
=Mary.Jones into an email address would first require Mary's permission, and such requests can be verified by i-brokers to make sure they are legitimate. In addition to
=names for people and
@names for organizations, the third major type of i-names is
+names for generic concepts. This is the XRI equivalent of a generic noun in the English language, for example,
+flowers,
+phone.number, or
+table.of.contents. Generic
+names are very useful in distributed data sharing because they can be used as XRI cross-references to specify the precise type of data to be shared. For example,
=Mary.Jones/(+phone.number)/(+daytime) and
@Acme/(+phone.number)/(+daytime) can be used to request Mary's and Acme's daytime phone numbers, respectively. ==See also==