GssPolicies/InameSyntax

I-Name Syntax and Normalization

Motivation
Background

Disallowed Characters in XRIs
Special Reserved Characters in XRIs
Reserved Characters in XRIs
Unreserved Characters in XRIs

Community I-Name Syntax Policy
Global I-Name Syntax Policy
Community I-Name Normalization Policy
Global I-Name Normalization Policy
Community I-Name Delegation Policy
Related Policies

1. Motivation

These policies specify the valid syntax and characters for Community I-Names (which include Global I-Names). They are motivated by the need for XDI.ORG Community I-Names to be:

Interoperable across the widest possible range of applications, domains, and services while not unduly sacrificing their expressive power.
As easy as possible for users to understand, remember, and employ.
Subject to as little ambiguity and confusion as possible.

2. Background

Although XDI.ORG Global Registries assign only 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 network to a common set of addressing rules. The policies in this section govern the syntax, normalization, and delegation rules that apply to the entire XRI Authority segment of an XDI.ORG Community I-Name.

2.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.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.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    = ":" / "/" / "?" / "#" / "[" / "]" / "("
                    / ")" / "*" / gcs-char

  gcs-char          = "=" / "@" / "+" / "$" / "!" 

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

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 XRI Authority prefixes. The XRI Specifications define five GCS characters:

Equals ("=") for identifiers representing individuals.
At ("@") for identifiers representing organizations or any other non-personal, non-generic entities.
Plus ("+") for identifiers representing any generic concept, subject, or topic.
Dollar sign ("$") are specialized identifiers defined by specification (such as the OASIS XRI Metadata Specification.)
Bang ("!") for identifiers independent of any other global context.

2.4. Unreserved Characters in XRIs

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

  xri-unreserved    = unreserved / ucschar

  unreserved        = ALPHA / DIGIT / "-" / "." / "_" / "~"

  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 registry authorities, such as XDI.ORG, may choose to further restrict these characters set per their own policies, which is the purpose of this section of the GSS.

3. Community I-Name Syntax Policy

An XDI.ORG Community I-Name MUST conform to the XRI Specifications for reassignable XRIs for XRI Authorities. A Community I-Name MUST begin with a Global I-Name. A Community I-Name MAY contain a Cross-Reference that also conforms to the Community I-Name Syntax Policy policies (see GssPolicies/CrossReferences). A Community I-Name MUST conform with the Community I-Name Normalization Policy.

4. Global I-Name Syntax Policy

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 contain a Cross-Reference that conforms to the Global Cross-Reference Policy (GssPolicies/CrossReferences).

5. Community I-Name Normalization Policy

Whitespace of any kind MUST NOT be used in a Community I-Name because it is not allowed an XRI. If whitespace is requested as a logical separator between other characters in any segment of a Community I-Name, it SHOULD be normalized to a dot ("."). When whitespace is requested at the start or end of any segment of a Community I-Name, it MUST be removed.

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.

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 excluding 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.

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 concerns 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 a future version of the GSS. Until such time, the registration agreement for a Global I-Name MUST require the Registrant to acknowledge that Global I-Name registrations which include non-ASCII characters disallowed by a future Global I-Name Normalization Policy MAY be subject to revision or termination. See GssRegistration.

7. Community I-Name Delegation Policy

All delegated Community I-Names assigned at any delegation level MUST conform to the Community I-Name Syntax Policy. Within the XDI.ORG Community, all Registrants MUST require this obligation in the registration agreements of all Delegates at all levels of delegation.

8. Related Policies

I-Number Syntax and Normalization – GssPolicies/InumberSyntax.
I-Name Resolution – GssPolicies/InameResolution.
I-Name Status – GssPolicies/InameStatus.
Reserved I-Names - GssPolicies/ReservedInames.
Cross-References - GssPolicies/CrossReferences.