GssPolicies/InamePolicies

I-Names (reassignable XRIs) are human-friendly, reassignable abstract identifiers designed to simplify communications and enable persistent, trusted data sharing relationships. See InamesAndInumbers and InameInumberTechFaq for more information.

The V1 GSS specifies two public I-Name Registry Services: Global Personal I-Name Service and Global Organizational I-Name Service. This section contains the policies governing syntax, synonyms and resolution, status, transfer, wait list, and reserved I-Names in these Registries.

2. I-Name Syntax, Normalization, and Restriction

Although the XDI.ORG GRS registers only Global I-Names (which form the first subsegment of an XDI.ORG Community I-Name), efficient resolution of XDI.ORG Community I-Names is very similar to efficient routing of DNS domain names – it requires agreement by all participants in the addressing community to a uniform set of addressing rules. The policies in this section govern the syntax, normalization, restriction, and delegation rules that apply to the entire XRI Authority segment of an XDI.ORG Community I-Name.

2.1. Background

The following topics briefly summarize key requirements of the XRI Specifications that are directly relevant to the policies in this section.

2.1.1. Disallowed Characters in XRIs

The XRI Specifications, like the URI specifications, specify that certain characters are not allowed at all. These include:

Angle brackets ("<", ">"): because they are used to enclose URIs or XRIs in XML markup.
Double quotes ("""): because they are used to enclose URIs or XRIs in XML attributes.
Curly braces ("{", "}"): because they are too easily confused with parentheses and other similar characters.
Pipe ("|"): because it is too easily confused with the letter I or number 1.
Backslash ("\"): because it can be confusing when compared with forward slash ("/").
Caret ("^"): because it causes problems with some Internet gateways.
Backtick ("`"): because it is so hard to distinguish.

In addition, all whitespace characters (space, tab, etc.) are not allowed because they can make it ambiguous where the XRI ends.

2.1.2. Special Reserved Characters in XRIs

In addition one character may appear in an XRI but has a special reserved meaning so it must not be used for any other purpose:

Percent ("%"): for the special use of "escape encoding" other characters as detailed in the XRI Specifications.

2.1.3. Reserved Characters in XRIs

Other characters can appear in an XRI but have special syntactic meanings, so in the XRI Specifications they are called "reserved". These reserved characters are defined in the following XRI 2.0 BNF productions (the reserved characters are in quotes):

  xri-reserved      = xri-gen-delims / xri-sub-delims

  xri-gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "(" / ")"
                    / "*" / "!" / rgcs-char

  rgcs-char         = "=" / "@" / "+" / "$"

  xri-sub-delims          = "&" / ";" / "," / "’"

2.1.4. GCS Characters

A special subset of the XRI reserved character set is reserved to represent the abstract global context of an identifier. Called Global Context Symbols (GCS), these characters are single-character prefixes indicating the global context of an XRI Authority. There are five defined in the XRI Specifications:

Equals ("=") represents personal authorities.
At ("@") represents organizational authorities.
Dollar sign ("$") represents standards bodies (such as OASIS).
Plus ("+") represents the general public (i.e., this is the "dictionary" namespace for generic identifiers representing general concepts, subjects, or topics.)
Bang ("!") represents persistent network authorities (this GCS character is used only to assign persistent identifiers).

2.1.5. Unreserved Characters in XRIs

Lastly, the following characters are not reserved and are legal per the XRI specification to include in XRIs.

  iunreserved       = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar

  ucschar           = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
                    / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
                    / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
                    / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
                    / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
                    / %xD0000-DFFFD / %xE1000-EFFFD

XRI Authorities, including XDI.ORG, may choose to further restrict these characters set per their own policies, which is the purpose of this section of the GSS.

2.2. Community I-Name Syntax Policy

An XDI.ORG Community I-Name MUST conform to the XRI Specifications for reassignable XRIs for XRI Authorities. In addition:

A Community I-Name MUST begin with a Global I-Name.
A Global I-Name or a Delegated I-Name MUST NOT begin or end in an XRI reserved character, a dot ("."), or a hyphen ("-").
A Global I-Name or a Delegated I-Name MUST NOT exceed 254 bytes.
A Delegated I-Name MAY be a Cross-Reference (see GssPolicies/CrossReferencePolicies) that also conforms to this Community I-Name Syntax Policy.
A Community I-Name MUST conform to the Community I-Name Normalization Policy (below).

2.3. Global I-Name Syntax Policy

A Global I-Name MUST conform to the Community I-Name Syntax Policy. In addition:

A Global Personal I-Name MUST begin with the GCS character "=".
A Global Organizational I-Name MUST begin with the GCS character "@".
A Global General I-Name MUST begin with the GCS character "+". (Global General I-Names are not supported in the V1 GSS but will be supported in a future version.)
A Global I-Name MAY be a Cross-Reference (see GssPolicies/CrossReferencePolicies) that conforms to the Global Cross-Reference Policy.
A Community I-Name MUST conform to the Global I-Name Normalization Policy (below).

2.4. Extended I-Name Syntax Policy

If a Registrant's desired Global I-Name is not available, Registrars SHOULD suggest the alternative of registering an Extended I-Name. An Extended I-Name includes a colon to distinguish the first portion (intended to reflect a real-world identifier) from the second portion (intended to establish global uniqueness.) Following are examples of Extended I-Names that extend the base I-Name "=Mary.Smith".

=Mary.Smith:Montana
=Mary.Smith:England
=Mary.Smith:Ireland
=Mary.Smith:Rose
=Mary.Smith:Rose.Water
=Mary.Smith:Iris
=Mary.Smith:2000
=Mary.Smith:2001

2.5. Community I-Name Normalization Policy

XRI reserved characters MUST NOT be used in a Community I-Name in unescaped form (non-percent-encoded) except colon (":"), which if used MUST be escaped (percent-encoded) when rendering the Community I-Name in IRI normal form as defined in the XRI Specifications. (Colons are explicitly used in the Extended I-Name Policy above.)

Subject to the Global I-Name Normalization Policy, all XRI unreserved characters MAY be used in a Community I-Name except underscore ("_") and tilde ("~"),which if used MUST be escaped (percent-encoded). The reasons for disallowing these two characters in their native form are:

Underscore: the W3C recommends not using underscores in URIs because they are easily confused with spaces when underlined (such as in a hyperlink).
Tilde: the visual representation of this character is too easily confused with hyphen ("-"), which is currently allowed in DNS name syntax and is thus more desirable as a logical separation character than tilde.

Whitespace of any kind MUST NOT be used in a Community I-Name because it is not allowed an XRI. If whitespace is desired by a Registrant as a logical separator between other characters in any segment of a Community I-Name, it SHOULD be normalized to a dot (".").

2.6. Global I-Name Normalization Policy

In the V1 GSS there are no additional rules for Global I-Name normalization beyond those of the Community I-Name Normalization Policy. However the V1 Community I-Name Normalization Policy primarily addresses character values in the ASCII range. The normalization requirements for non-ASCII characters allowed in a Global I-Name (those corresponding to the XRI "uschar" production) shall be defined in future versions of the GSS. For this reason, the Registration Agreement for a Global I-Name MUST require the Registrant to agree that registrations which include characters disallowed under a future Global I-Name Normalization Policy MAY be subject to revision or termination. See the Global Terms of Service under GssAgreements.

2.7. Community I-Name Restriction Policy

To help prevent semantic attacks using intentionally deceptive I-Names, each Delegated I-Name within a Community I-Name MUST meet the character restrictions in part III (Domain Names: Registries) of the Recommendations section of http://unicode.org/reports/tr36/. Specifically, the registered string MUST be in a single UCS script with the following exceptions:

It MAY combine characters from the following UCS scripts:

Han + Hiragana + Katakana
Han + Bopomofo
Han + Hangul

It MAY include characters from the UCS Common and Inherited script characters.

In addition, it MUST NOT include special purpose characters from the file at http://unicode.org/reports/tr36/special_purpose.txt.

In general, the GSS intends to follow the "inclusion based" model described in http://www.icann.org/committees/idn/idn-codepoint-paper.htm. Under this model, future versions of the GSS would loosen rather than tighten character restriction policies. The exception, however, may be special purpose characters or character sets falling under the Unicode recommendations regarding visually confusing characters, or any other characters or character combinations that may be used to create deceptive or confusing I-Names or otherwise exploit or compromise the integrity of the GRS.

2.8. Global I-Name Restriction Policy

In the V1 GSS there are no additional rules for restriction of the characters allowed in a Global I-Name beyond those of the Community I-Name Character Restriction Policy. However, because a future version of the GSS may further restrict the allowed characters, the Registration Agreement for a Global I-Name MUST require that the Registrant agree that registrations which include characters disallowed under a future Global I-Name Restriction Policy MAY be subject to revision or termination. See the Global Terms of Service under GssAgreements.

2.9. Community I-Name Uniqueness Policy

A Community I-Name, including the Global I-Name and each Delegated I-Name it contains, MUST be unique within the scope of the Authority that assigns it.

2.10. Community I-Name Delegation Policy

All delegated Community I-Names assigned at any delegation level MUST conform to the Community I-Name Syntax Policy, the Community I-Name Normalization Policy, the Community I-Name Restriction Policy, and the Community I-Name Uniqueness Policy. Within the XDI.ORG Community, all Registrars MUST require in their Registration Agreements that Registrants observe this obligation at all levels of delegation.

2.11. Implemention Notes

2.11.1. Determining Community I-Name Conformance

To simplify compliance by Delegated Authorities with the Community I-Name policies, particularly the Community I-Name Restriction Policy, a Delegated Authority may check with the GRS to see if a Delegated I-Name can be registered as a Global I-Name. Any Delegated I-Name that can be registered as a Global I-Name (even if that Global I-Name is already registered) should satisfy the Community I-Name requirements.

3. I-Name Synonyms

These policies specify the rules for Global I-Name synonyms.

3.1. Global I-Name Synonym Policy

A Global Personal I-Name MUST have at least one and MAY have more than one Global Personal I-Number as an Internal Synonym.
A Global Organizational I-Name MUST have at least one and MAY have more than one Global Organizational I-Number as in Interal Synonym.
A Global I-Name MUST have at least one and MAY have more than one Network I-Number as an External Synonym as specified by the Global I-Number Synonym Policy. See GssPolicies/InumberPolicies.

3.2. Global I-Name Synonym Priority Policy

If a Global I-Name has more than one Internal Synonym, the Registrant SHOULD indicate the order in which the Internal Synonyms shall be returned in a GRS resolution response.

3.3. Implementation Notes

3.3.1. Generation of Global I-Number Synonyms

Unless a Global I-Name is registered to an existing Global I-Number as an Internal Synonym, the GRS automatically generates and assigns a new Global I-Number as the Internal Synonym during the registration process. See GssPolicies/InumberPolicies and GssOpSpecs for more details.

3.3.2. Managing Global I-Name and Global I-Number Synonyms

If a Registrant wishes to register more than one Global I-Name, the Registrar should give the Registrant the choice of whether the additional Global I-Name should be registered to the same Global I-Number or to a different Global I-Number as the Internal Synonym. Note the latter option may be chosen for two different reasons:

The additional Global I-Name(s) may represent a different Authority, or
The additional Global I-Name(s) represent the same Authority but the Registrant wishes to maintain separate Global I-Numbers for privacy and/or data control purposes.

If the Registrant chooses separate Global I-Number Synonyms, the Registrar may wish to provide the Registrant with the option of linking these registrations internally (i.e., in the Registrar's own systems) in order to simplify authentication and account management for the Registrant while not revealing any external association between the Global I-Numbers. However this functionality is outside the scope of the GSS.

3.3.3. Discovery of Global I-Name Synonyms

For privacy protection purposes, the V1 GRS does not provide a facility to register or resolve a Global I-Name directly to other Global I-Name Synonyms, but only to Global I-Number Synonyms. Network Authorities may provide this functionality to Registrants who desire it via the Network Authority's own XRI Descriptor for the Registrant's Network I-Number, via a Contact Page, or via some other mechanism.

4. I-Name Resolution

The following policy specifies the rules for Global I-Name resolution.

4.1. Global I-Name Resolution Policy

The GRS resolution response for a Global I-Name MUST contain the following values in the XRI Descriptor:

Internal Synonyms: For a Global Personal I-Name, the GRS will return all Global Personal I-Numbers registered as Internal Synonyms. For a Global Organizational I-Name, the GRS will return all Global Organizational I-Numbers registered as Internal Synonyms.
External Synonyms: The GRS will return all Network I-Numbers registered as External Synonyms.
XRI Authority URIs (XAUs) and Local Access URIs (LAUs): For each Network I-Number registered as an External Synonym, if the GRS is not authoritative for the Network I-Number of the Delegating Authority, no XAU or LAU shall be returned (i.e., the GRS resolution response will be an XRI Redirect.) If the GRS is authoritative for the Network I-Number of the Delegating Authority, the GRS will return one XAU and LAU conforming to the following ABNF for each XAU and LAU registered to the Network I-Number, respectively.

  return-URI        = net-inum-URI "/" global-inum-syn
  net-inum-URI      = XAU or LAU from Network I-Number of Delegating Authority
  global-inum-syn   = priority Global I-Number Synonym for Global I-Name

4.2. Implementation Notes

4.2.1. External Synonyms and XRI Redirects

The GRS resolution response for a Global I-Name differs depending on whether the Network I-Number(s) registered as External Synonym(s) are registered to a first-level Network Authority (for which the GRS has authoritiative data) or a lower-level Network Authority (for which the GRS does not have authoritative data). In the first case, the GRS can return authoritative XAUs and LAUs according to the formula given above. In the second case, the GRS must return the External Synonym(s) as an XRI Redirect (as defined in the XRI Specifications) so the resolver can proceed to query the responsible Network Authority.

See the ResolutionTechFaq for examples.

Also note that, even in the case of a first-level Network Authority, an XRI resolution request directly to that Authority for the Network I-Number registered as an External Synonym at the GRS may produce a superset of the resolution data available from the GRS. This is due to the fact that the GRS only maintains the minimum registration data necessary to resolve a Global I-Name or Global I-Number to the responsible Network Authority.

5. I-Name Status

These policies specify the rules for changing the status of a Global I-Name, including release, suspension, termination, and expiration.

5.1. Global I-Name Release Policy

If the Registrant of a Global I-Name subsequently abandons the transaction or defaults on payment, a Registrar MAY release the Global I-Name. This release request MUST be received by the GRSP within 60 hours of the time of the initial registration. Abuse of the Global I-Name Release Policy in order to unfairly constrain availability of a Global I-Name is grounds for termination of a Registrar.

5.2. Global I-Name Suspension Policy

The Authority for a Global I-Name MUST have the option to suspend its resolution. A suspended Global I-Name MUST return a null resolution value and a status value of "Suspended" as specified in the GSS Operational Specifications (GssOpSpecs). If the registration of a suspended Global I-Name is subsequently terminated, this policy is superceded by the Global I-Name Termination Policy (below). If the registration of a suspended Global I-Name subsequently expires, this policy is superceded by the Global I-Name Expiration Policy (below).

5.3. Global I-Name Termination Policy

The Authority for a Global I-Name MUST have the option to terminate its registration. A terminated Global I-Name MUST become reavailable for registration after a 15 day waiting period following the date the termination request was received by the GRSP. During such waiting period, a terminated Global I-Name MUST return a null resolution value and a status value of "Terminated" as specified in the GSS Operational Specifications (GssOpSpecs). During the waiting period a terminated Global I-Name MAY be reactivated if the Authority requesting reactivation can provide the authentication credentials that were current at the time of termination.

5.4. Global I-Name Expiration Policy

If the registration of a Global I-Name expires and is not renewed, it MUST become reavailable for registration after a 30 day waiting period following its expiration date. During this period the Global I-Name MUST return its last registered resolution value (including a null value if it was suspended) and the status value of "Expired" as specified in the GSS Operational Specifications (GssOpSpecs). During the waiting period an expired Global I-Name MAY be reactivated if the Authority requesting reactivation can provide the authentication credentials that were current at the time of expiration.

6. I-Name Transfer

These policy specifies the transferability of Global I-Names between Registrants or Registrars.

6.1. Global I-Name Transfer Policy

The Registrant of a Global I-Name that is not subject to dispute, non-payment, or other encumbrances MUST have the right to reassign this Global I-Name to another Registrant or to another Registrar. The GSS Operational Specifications (GssOpSpecs) MUST support inter-Registrant and inter-Registrar transfers of Global I-Names, and all XDI.ORG Agents MUST support this function.

6.2. Implementation Notes

6.2.1. Opening New Accounts

The GRS registration interfaces provided by Registrars should enable new Registrants to open accounts by:

Accepting a Global I-Name transferred from another Registrant, or
Transfering a Registrant's entire existing registration from another Registrar.

See the TransferTechFaq for examples.

Note that in the first case (transfer of a Global I-Name alone), if the new Registrant does not currently have a Global I-Number for which the transferred Global I-Name will become an Internal Synonym, one will need to be assigned by the GRS. See the GssOpSpecs and the TransferTechFaq.

7. I-Name Wait List

With a Wait List function, a Registrant who desires to register a currently-registered Global I-Name will be able to register on a Wait List for that Global I-Name if and when its registration expires or is terminated.

7.1. Global I-Name Wait List Policy

Wait List functionality is not specified in the V1 GSS because XDI.ORG first needs to verify demand for this service. Once demand is demonstrated, XDI.ORG intends to specify and implement a Wait List function for all Global I-Name Registry Services. Registration on the Wait List will be on a first-come-first-served basis. When offered, Wait List registration will be available through any Registrar that wishes to offer this service. It is anticipated that the depth of Wait List registrations (meaning the number accepted for any particular Global I-Name) will not be fixed but will be dynamic according to Registrant demand.

7.2. Implementation Notes

7.2.1. Wait List Notification Service

Registrars who intend to offer Global I-Name Wait List service when it is available may wish to offer their own "wait list notification service". Such a service might allow Registrants to: a) store preferences about specific Global I-Names they would like to Wait List, and b) subscribe to an email list notifying them when Wait List functionality is available. However such a service is Registrar-specific and out of scope for the GSS.

8. Reserved I-Names

Reserved I-Names are intended to:

Establish a small set of generic Global I-Names for public use in illustrating or documenting global XRIs while avoiding conflicts with actual registered XRIs (similar to the "example" strings reserved in many DNS TLDs.)
Allow XDI.ORG to identify itself and its functions in a manner that makes it easily accessible by all members of the XDI Community.
Provide a means for GRSPs to register Global I-Names to identify themselves and their functions in a manner consistent with the GRSP Code of Conduct (to prevent conflicts of interest, GRSPs are not allowed to register any Global I-Names directly, see GssPolicies/RegistryPolicies).

8.1. Reserved Public Global I-Name Policy

The following Global I-Names are reserved by XDI.ORG for public use in XRI documentation and examples (so as to avoid conflicts with actual registered XRIs or confusion with common HTTP URIs) and MUST NOT be registered in any Global I-Name Registries:

All single-character ASCII letters and digits, but not variants that append the logical separator characters dot ("."), colon (":"), or hyphen ("-") plus additional characters.
The text strings listed below (which per the XRI specifications are case-insensitive), plus the plural form of each text string listed below (i.e., adding "s", "es", or "ies"), but not variants that append the logical separator characters dot ("."), colon (":"), or hyphen ("-") plus additional characters.
All Global I-Names that begin with the text string "example" including any variants that append the logical separator characters dot ("."), colon (":"), or hyphen ("-") plus additional characters.

example
user
individual
person
personal
personal.name
organization
organizational
organizational.name
name
iname
i-name
i.name
i:name
number
inumber
i-number
i.number
i:number
broker
ibroker
i-broker
i.broker
i:broker
com
net
org
www

These Global I-Names are reserved only at the GRS level and not as Delegated I-Names, which subject to the policies of the Delegated Authority.

8.2. Reserved XDI.ORG Global I-Name Policy

The following Global I-Names, including variants that append the logical separator characters dot ("."), colon (":"), or hyphen ("-") plus additional characters, are reserved by XDI.ORG for its own operational use as a public trust organization and MUST NOT be registered in any Global I-Name Registries.

xdi
xdiorg
xdi-org
xdi.org
xdi:org
xri
xriorg
xri-org
xri.org
xri:org
itrust
i-trust
i.trust
i:trust

The following Global I-Names, but not including variants that append the logical separator characters dot ("."), colon (":"), or hyphen ("-") plus additional characters, are reserved by XDI.ORG for its own operational use as a public trust organization and MUST NOT be registered in any Global I-Name Registries.

gsp
grsp
global.service
global.service.provider
global.registry
global.registry.service
global.registry.service.provider
public
trust
federation
global
service
provider
registry
registrar
registrant

8.3. Reserved GRSP Global I-Name Policy

The following i-names are reserved for use in identifying GRSPs in a manner consistent with the GRSP Code of Conduct Policy (see GssPolicies/RegistryPolicies) and MUST NOT be registered. Note that to avoid any potential conflict of interest, GRSPs are preventing from registering Global I-Names other than those publicly listed in this section of the GSS.

8.3.1. Cordance Corporation

cordance
cordance.corp
cordance.corporation
cordance.net