XRI 1.1 change issue - Proposal for a new GCS char

["Drummond Reed" <drummond.reed@cordance.net>]

XRI TC Members and Observers:

Per the current request that any new changes for XRI 1.1 be submitted to the
TC, the following is a proposal for a new GCS character representing XRI
routing authorities. The full proposal is included below and also on the
XRI/XDI wiki at:

	http://xrixdi.idcommons.net/moin.cgi/XriChangeNewGcsChar


= Proposal for a new GCS Character for XRI Routing Authorities =

This page explains the rationale for adding another GCS character ("&") to
the XRI 1.1 specification.

== Supporting Use Case ==

In designing XRI global context registries (GCRs) based on XRI 1.0, the
following use case arose:

 1. An individual or organization is registered as an XRI authority and
serves as the current owner of its own XRI resolution service.
 2. This current owner decides to transfer or sell its XRI resolution
service as an asset to another individual or organization that is also
registered as an XRI authority (the "new owner".)
 3. The current owner is NOT itself being acquired by the new owner. The
current owner and the new owner only wish to transfer ownership of a
specific asset (the XRI resolution service). 
 4. Both the current owner and the new owner have a registered global
i-number (persistent XRIs registered under "=" or "@") that represents their
persistent identity as an individual or organization, and both wish to keep
these i-numbers after the transaction.

The problem is obvious: how can the asset be transferred if the i-number
that represents the persistent identity of the current owner also represents
the persistent identity of the network endpoint offering the XRI resolution
service. If fact, even if the current owner decided to transfer this
i-number, it cannot be transferred to the new owner because i-numbers are
not reassignable.

To illustrate, say a company named Acme has registered the global i-name
"@Acme" and the global i-number "@:1234". In addition Acme also operates its
own XRI resolution service at a set of concrete URIs to which the "@:1234"
is mapped. Now say Acme wishes to sell its XRI resolution business to
another company, Beco, with the global i-name "@Beco", and global i-number
"@:5678".

Acme cannot simply transfer ownership of "@:1234" to Beco because "@:1234"
represents the identity of Acme as an organization, not the identity of the
network endpoint that is the root of Acme's XRI resolution business. Nor can
Acme simply update the URIs to which "@:1234" resolves to point to Beco
because "@:1234" still represents Acme's network identity.

What Acme would really like to do is sell authority over the set of concrete
URIs that point to Acme's XRI resolution service. But Acme has no way to do
this because under the limitations of the existing XRI GCS character set,
those XRIs must be tied to its own global organizational i-number.

== The Proposed Solution ==

The proposed solution is a new GCS character that represents abstract XRI
routing endpoints. Although in the XRI 1.1 ABNF this would simply be another
GCS character, and thus would syntactically support both reassignable and
persistent segments/subsegments like any other GCS character, in practice it
would only be used for i-numbers. The reason is that the global context
established by this new GCS character is that of the network itself. The
i-numbers registered under this GCS character represent the abstract
identity of a network routing endpoint as a resource. This i-number is then
mapped to the set of concrete URIs that represent the concrete network
services available at this endpoint.

Since any real-world identity associated with a network routing endpoint as
a resource must be established by placing it in the context of an individual
or organization who exerts administrative authority over this endpoint, and
it is only those authorities who require i-names, there is no need for
resources identified under this GCS character to have i-names.

Therefore the proposed GCS character for abstract XRI routing endpoints is
"&" because: a) this is a RFC2396bisv6 reserved character, and b) it is a
relative unattractive character for human-friendly identifiers (hard to
write and hard to say, at least in English). 

== Terminology and Examples ==

In practice i-numbers in this new GCS space would be referred to as "XRI
routing numbers". The individual or organization responsible for registering
the set of concrete URIs to which an XRI routing number resolves and
operating the XRI resolution services available at those endpoints would be
called an "XRI routing authority".

XRI routing numbers assigned directly by a GCR would be called "global
routing numbers". Example:

&:8888

XRI routing numbers delegated under global routing number to other XRI
routing authorities would be called "subrouting numbers". Examples:

&:8888*:7777  (using star as the secondary hierarchy character) 
&:8888:7777   (using colon as the secondary hierarchy character)

XRI routing numbers assigned within the domain of an XRI routing authority
would be called "local routing numbers." Example:

&:8888/:21

== How this Meets the Requirements of the Use Case ==

To return to the example of Acme above, first let's assume that GCRs require
XRI routing authorities to also be independently identifiable XRI
authorities. Now if Acme wished to be an XRI routing authority, it would
need to register both a global organizational i-number ("@:1224") and a
global XRI routing number (say "&:8888".) These are separate registrations
representing separate XRI-addressable resources. 

Next the GCR would register a ''resource ownership relationship''
(composition) between Acme's global i-number "@:1234" (as the owning
resource) and the global XRI routing number "&:8888" (as the owned
resource). This is expressable as: "@1234/(&:8888)".

Now when Acme wishes to sell its XRI routing authority business to Beco
which has registered the global i-number "@:5678", all that happens is that
the GCR deletes the resource ownership relationship between "@:1234" and
"&:8888" and creates a new resource ownership relationship between "@:5678"
and "&:8877", i.e., "@:5678/(&:8888)". Now Beco is the new XRI routing
authority, yet there is no affect of any kind to the XRI-addressable
resources at the endpoint "&:8888", because they continue to be directly
XRI-addressable under the global routing number "&:8888".

In fact, if Acme's own internal organizational data was located at a local
routing number under the global routing number "@:8888" - for example, at
"&:8888/(@:1234)" - this subrouting number would not need to change either. 

(If you're wondering how one XRI authority - the GCR for "@" - can register
the resource ownership relationship "@:1234/(&:8888)" while another XRI
authority - the XRI routing authority for "&:8888" - can register the
resource ownership relationship "&:8888/(@:1234)", it is because they
represent different abstractions. "@" resources represent real-world
organizations. "&" resources represent network endpoints. "@:1234/(&:8888)"
represents ownership by a real-world organization of a network endpoint.
"&:8888/(@:1234)" represents a ownership by a network endpoint of the
network representation of a real-world organization. And 5 angels can dance
on the head of a pin...)

== Conclusion ==

By adding a GCS character representing the context of the network itself, we
have a means of representing the abstract identity of a network endpoint.
This allows us to: 
 a. separate the identity of a network endpoint as a resource from the
identity of its individual or organizational authority as a resource, and
 b. model this authority relationship as a hierarchical ownership
relationship that can be changed if real-world ownership of the network
endpoint changes.