[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] [redefining GCS ! char] Summarizing the argument
I am continuing to not understand why the current syntax fails to meet the use case described, as I understand it. To being with, the "!" namespace is not "authority indepedent" - every XRI starts with an identifier authority, and thats because every name has to be namespaced-qualified by an assigning party (a top-level namespace authority). So we aren't really talking about a group of names that are assigned by a collective peer-to-peer agreement or in some other decentralized way (I'd find that interesting, for sure). We are STILL talking about a global namespace (under "!"), which identifies an organization assigning names under the ! namespace. So, I'd assert that using "!" for a "authority independent" XRI is functionally no different than having a organization called the "authority-independent XRI assigning organization" aka @AIXAO. @AIXAO could assign identifiers for things (though who'd pay for such assignment and the maintenance of such registration? Same issue as for a ! registrar). Specifically: instead of xri:!*:4343943 we'd have xri:@AIXAO*:4343943 There, problem solved - no need for "!", and no need to change the syntax. The *only* reason I saw for = and @ was to accomodate human desire for short identifiers and suggest that there is a benefit to everyone using shorthand to identify a few special identifier authorities. Is there a "human useability" factor to argue for using "!"? In fact, I'd argue that the @AIXAO solution is better than a single ! GCS because it is decentralized where there is no need for centralization (as there is for "!"). For example, we could have @AIXAO for general purpose "thing" identification, and @UNHCC (UN High Commission on Chairs) for identifying Chairs independent of ownership or other semantic relationship to the XRI authority, etc. We could have a true market for authority-indepenent identifiers instead of a natural monopoly as there is in the + and @ namespaces. I share Mike's concern about a slippery slope - we could justify a bazillion GCS characters for different purposes. I think we have a sufficient (at least!) set with @, =, + and $. If ! deserves special consideration, then so be it, but I think we need to be clear that ! is not adding new functionality, and evaluate it on that basis. -Gabe __________________________________________________ gwachob@visa.com Chief Systems Architect Technology Strategies and Standards Visa International Phone: +1.650.432.3696 Fax: +1.650.554.6817 > -----Original Message----- > From: Lindelsee, Mike [mailto:mlindels@visa.com] > Sent: Friday, August 06, 2004 4:19 PM > To: xri@lists.oasis-open.org > Subject: FW: [xri] [redefining GCS ! char] Summarizing the argument > > > Well, interestingly enough, I've come around on this topic. > I completely agree that it will be useful to be able to > identify things that are not organizations, concepts, or > people. I do think that if we are going to change/add a GCS > character we should break the GCS characters out of the XRI > spec and define them in an ancillary document. That way if > we ever need to add or change GCS characters again, we won't > have to completely rev the XRI specification. > > While I don't have a huge problem with redefining "!" for > this purpose, this is yet another character for people to > remember. How about taking the straightforward approach of > not changing the syntax and just redefining the "@" character > to cover organizations, services, and all other things not > covered by the remaining GCS characters? This would be an > easy change in the spec and would cover the use case. > > Thoughts? > > Mike > > > -----Original Message----- > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > Sent: Tuesday, August 03, 2004 7:47 PM > > To: xri@lists.oasis-open.org > > Subject: [xri] [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 > > . > > > > > > > > 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. > > > > > > 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]