OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [redefining GCS ! char] Summarizing the argument


[On the XRI Editor's SC call today, it was agreed that we would try to come
to consensus on the proposed redefinition of the GCS ! character via
discussion on the list. I volunteered to begin this process by posting a
short summary of the much longer writeup posted earlier today as
http://lists.oasis-open.org/archives/xri/200408/msg00007.html. We will try
to keep messages on this thread under the prefix [redefining GCS ! char].
=Drummond)

After much discussion, the original proposal has been both broadened and
simplified to address a general use case not contemplated by XRI 1.0. The
use case is that of a resource which, by its nature, may need to be
identified independent of any particular authority, especially because
during its lifetime it may need to be pass under the control of multiple
authorities.

Obvious examples are physical assets that may be transferred between owners,
e.g., cars, boats, computers - anything that might traditionally be assigned
a serial number or other form of unique identifier. However this class of
resources may also extend to other forms of less tangible assets such as a
network endpoint (the asset that originally gave rise to this proposal.)

The problem with identifying a resource of this class using an identifier
delegated under the GCS = or @ spaces is that this places the identifier in
the context of a person or organization, i.e., the first owner or authority
for the resource. If the resource is later transferred or sold to another
person or organization, it can become problematic to still identify the
resource in the context of the original owner.

It is less obvious why providing "identity of things" would not be a
function of the GCS + space. However the + space is designed to provide
identity for general concepts, i.e., classes, dictionaries, or ontologies of
things, rather than specific instances of things. Many assets may
participate in multiple taxonomies, and as taxonomies change over time, an
assets may also need to migrate between taxonomies just as it may migrate
between legal owners. Again it may be either desirable or necessary to be
able to identify the asset independent of its participation in a particular
taxonomy. 

The result is a need for an "authority independent" space in which the
resources registered (at any level of delegation) are identifiable
independent of any particular =, @, or + authority. Resources in this space
will then in many cases be identified using a cross-reference under the
applicable =, @, or + spaces at any particular point in time, however these
cross-references may change over time as ownership authority changes over
time.

It is proposed to repurpose the GCS character "!" for this space, both
because it is a valid RFC2396 subdelim character with good visual
characteristics, and also because the need for a GCS character for
annotations (the XRI 1.0 purpose of !) is probably more appropriately
accomplished under the XRI metadata ($) space.

=Drummond 


-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Tuesday, August 03, 2004 3:37 PM
To: xri@lists.oasis-open.org
Subject: [xri] XRI 1.1 Issues: Redefining GCS ! Character

XRI Members and Observers,

Attached below, and posted at
, is background on
one of the XRI 1.1 issues that will be discussed on the XRI Editor's SC call
today regarding the redefinition of the GCS ! character

=Drummond 


== Introduction ==

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 to assign a GCS character to represent abstract XRI
routing endpoints. Although this would simply be a standard GCS character,
and thus would support both reassignable and persistent 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.

The proposed GCS character for abstract XRI routing endpoints is "!"
because: a) this is a RFC2396bisv6 reserved character, and b) it is a
relatively 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 might 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 subsegment delimiter) 
!:8888:7777   (using colon as the subsegement delimiter)
}}}

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 "!:8888", 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.

== Response from Dave McAlpin ==

I don't understand the basic premise behind this proposal. Let's take it a
step at a time.

"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'."

So currently, a resolution request to @ for :1234 returns something like
{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>:1234</Resolved>
    <XRIAuthority>
        <URI>http://xri.acme.com</URI>
        <URI>https://xri.acme.com</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>http://xri.acme.com</URI>
    </LocalAccess>
</XRIDescriptor>}}}

and a resolution request to @ for .acme returns something like
{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>.acme</Resolved>
    <XRIAuthority>
        <URI>http://xri.acme.com</URI>
        <URI>https://xri.acme.com</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>http://xri.acme.com</URI>
    </LocalAccess>
    <Mapping>xri:@:1234</Mapping>
</XRIDescriptor>}}}

Similarly, a resolution request to @ for :5678 returns something like
{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>:5678</Resolved>
    <XRIAuthority>
        <URI>http://xri.beco.com</URI>
        <URI>https://xri.beco.com</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>http://xri.beco.com</URI>
    </LocalAccess>
</XRIDescriptor>}}}

and a resolution request to @ for .beco returns something like
{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>.beco</Resolved>
    <XRIAuthority>
        <URI>http://xri.beco.com</URI>
        <URI>https://xri.beco.com</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>http://xri.beco.com</URI>
    </LocalAccess>
    <Mapping>xri:@:5678</Mapping>
</XRIDescriptor>}}}

So far, so good. But what _is_ xri:@:1234 anyway? We can confidently say
that xri:@:1234 is an identifier for a resource. Furthermore, because it's
an i-number it identifies that resource forever and may never be assigned to
a different resource. Because xri:@:1234 is composed only of an authority
and because it is intended to be resolvable, at least one digital
representation of the resource is defined - an XRIDescriptor for :1234
maintained by @, shown above. This XRIDescriptor describes attributes of the
resource, like the URIs that provide resolution services for sub-segments in
its namespace (XRIAuthority) and descriptions of operations that may be
performed on the resource (LocalAccess). While the identifier for the
resource, the XRI, permanently identifies that resource, the attributes of
the resource can obviously change over time.

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

Ahhh, so now we have a better understanding of the resource xri:@:1234 is
intended to identify - the "identity of Acme as an organization". The second
half of the sentence is then obviously correct; the network endpoint
answering resolution requests is clearly an attribute of Acme as an
organization, not the thing being identified.

"Nor can Acme simply update the URIs to which '@:1234' resolves to point to
Beco because '@:1234' still represents Acme's network identity."

Of course it can. The network endpoint that answers resolution requests for
"Acme as an organization" can exist anywhere and be administered by anyone
without changing the resource being identified. The URIs in the XRIAuthority
portion of its XRIDescriptor will change, but that doesn't change the
resource being identified.

After the transfer of resolution responsibilities, a resolution request to @
for :1234 will return something like
{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>:1234</Resolved>
    <XRIAuthority>
        <URI>http://xri.acme.beco.com</URI>
        <URI>https://xri.acme.beco.com</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>http://xri.acme.com</URI>
    </LocalAccess>
</XRIDescriptor>}}}

and a resolution request to @ for .acme will return something like
{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>.acme</Resolved>
    <XRIAuthority>
        <URI>http://xri.acme.beco.com</URI>
        <URI>https://xri.acme.beco.com</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>http://xri.acme.com</URI>
    </LocalAccess>
    <Mapping>xri:@:1234</Mapping>
</XRIDescriptor>}}}

The only differences between these and the XRIDs before the transfer are the
URIs in XRIAuthority. Of course there are other possible representations of
these URIs, like http://xri.beco.com?ns=acme or whatever. With either of
these representations, resolution requests to @ for .beco or :5678 could
stay the same as above. 

It seems obvious to me that changing the network endpoint responding to
resolution requests changes an attribute of the identified resource, not
which resource is identified. Am I missing something fundamental here?

== Restating the problem ==

Ok, so my summary above turned out to be right, but it missed the problem
Drummond was trying to solve. When Acme outsourced resolution services to
Beco, we had to make a change to Acme's XRID. That doesn't seem so bad, but
imagine the consequences if Acme also provided hosted services for people in
the = namespace. For example, imagine there's an identifier =dave that
represents me, so a resolution request to = for .dave returns something like

{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>.dave</Resolved>
    <XRIAuthority>
        <URI>http://xri.acme.com</URI>
        <URI>https://xri.acme.com</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>http://xri.acme.com</URI>
    </LocalAccess>
    <Mapping>xri:=:234</Mapping>
</XRIDescriptor>}}}

Then Acme transfers its hosted services, both resolution and local access,
to Beco. The XRID would need to change to something like

{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>.dave</Resolved>
    <XRIAuthority>
        <URI>http://xri.acme.beco.com</URI>
        <URI>https://xri.acme.beco.com</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>http://xri.acme.beco.com</URI>
    </LocalAccess>
    <Mapping>xri:=:234</Mapping>
</XRIDescriptor>}}}

Now imagine that Acme provided hosted services for 100,000 other resources
in the = namespace. 100,000 XRIDs would need to change. That sounds kind of
bad. The problem is that the network endpoints in XRIAuthority and
LocalAccess are identified concretely. It would have been nice if we'd used
a URI that provided a level of indirection away from the concrete endpoint.
Imagine that we'd used an XRI to provide indirection in XRIAuthority and
LocalAccess. Something like

{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>.dave</Resolved>
    <XRIAuthority>
        <URI>xri:@acme*resolution</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>xri:@acme*(xri:$r.a/X2R)</URI>
    </LocalAccess>
    <Mapping>xri:=:234</Mapping>
</XRIDescriptor>}}}

That would be an improvement because the concrete network endpoint could be
changed in a couple of XRIDs and   affect 100,000 records. But it still
seems wrong that the XRI is rooted on @acme when acme is no longer in the
picture. What we'd really like to do is to treat the resolution service and
the local access service as top level identifiable resources independent of
Acme. Something like

{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>.dave</Resolved>
    <XRIAuthority>
        <URI>xri:@:12341234</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>xri:@:809708987</URI>
    </LocalAccess>
    <Mapping>xri:=:234</Mapping>
</XRIDescriptor>}}}

Now that the service offered by Acme is identified idependent of Acme, it
can be transfered freely and unambigously. Note, however, that in the XRID
immediately above I put the "resolution service" and the "local access
service" in the @ namespace. That doesn't really seem right - the @
namespace is for organizations. Thus the motivation for creating a new
global namespace, so we could have something like

{{{
<XRIDescriptor xmlns="xri:$r.s/XRIDescriptor">
    <Resolved>.dave</Resolved>
    <XRIAuthority>
        <URI>xri:!:12341234</URI>
    </XRIAuthority>
    <LocalAccess>
        <Service> xri:$r.a/X2R</Service>
        <Type>application/rddl+xml</Type>
        <URI>xri:!:809708987</URI>
    </LocalAccess>
    <Mapping>xri:=:234</Mapping>
</XRIDescriptor>}}}

Now we've down a couple of things. We've decoupled the resolution authority
(http://xri.acme.com) from a concrete network endpoint using an XRI
(xri:@acme*resolution), we've decoupled that XRI from a particular
organization by registering it in a context free manner (xri:@:12341234),
and we've taken it out of the the @ namespace and put it under !
(xri:!:12341234). In the next section we'll try to define what this new !
namespace means.

== A generalization of the problem and the ! namespace ==

The problem above is a special case of a general problem - there are
resources that are neither a person nor an organization that we'd like to
identify independent of any personal or organizational context.

We already recognized this problem for personal names. If the = namespace
didn't exist, global personal names would have to be registered in the
context of an organization. I'd have to be xri:@epok*dave or
xri:@IdentityCommons*Dave. But there are times I'd like an identifier that
doesn't depend on an organizational context, thus xri:=dave. The same holds
true for resources that aren't people. If I want to identify the keyboard
I'm typing on, I could do something like xri:=dave*office.keyboard or
xri:@epok*daves.keyboard. Those are fine for some purposes, but if I leave
the company or give the keyboard to someone else, those identifiers stop
making sense. There are cases where I need an identifier for this keyboard
outside any organizational or personal context.

The generalized proposal, then, is to create a new namespace ! for resources
that aren't people or organizations that need to be identified independent
of any person or organization. This keyboard would then become, in addition
to xri:=dave*office.keyboard or xri:@epok*daves.keyboard, xri:!:2304897789.
Now even if it's transfered away from me or away from Epok, it has an
identifier that continues to make sense.

This is the same problem we had above. We needed to identify a service in a
way that didn't bind it to a specific network endpoint so we used an XRI,
and we needed to identify it in a way that didn't bind it to a particular
provider so we used xri:!:12341234.

(DrummondReed adds) This suggests two potential labels in the 1.1 spec for
this new GCS namespace:

 1. '''The authority-independent namespace''' because it provides a means
for identifying resources independent of their current authority.
 1. '''The physical namespace''' because it provides a means for identifying
a physical instance of a resource.






To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php
.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]