I-names are one form of an XRI — an OASISopen standard for digital identifiers designed for sharing resources and data across domains and applications. I-names are human readable XRIs intended to be as easy as possible for people to remember and use. For example, a personal i-name could be =Mary or =Mary.Jones. An organizational i-name could be @Acme or @Acme.Corporation.
Persistence
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. Such an abstraction layer is not new — URNs 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 persistent i-number.
I-numbers
s are machine readable identifiers that are assigned to a resource 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 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. 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 i-name for itself and then assign second- or lower-level 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// and @Acme// can be used to request Mary's and Acme's daytime phone numbers, respectively.
