[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]