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