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