[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]