RE: Cool URIs don't change? Was Re: Perisistence

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
> Henry S. Thompson
> Sent: Monday, September 15, 2008 11:38 AM
> To: John Bradley
> Cc: Williams, Stuart (HP Labs, Bristol); Mark Baker; www-tag@w3.org
> Subject: Cool URIs don't change? Was Re: Perisistence
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've been re-reading this tangled thread, and want to pull out one
> tiny bit to test my understanding:
> 
> John Bradley wrote:
> 
> > If =skw is assigned to you along with =!BF81.FD97.C81B.B4E5 and at
> > some point you stop paying for =skw and TBL wants to purchase it he
> > can get =skw but not =!BF81.FD97.C81B.B4E5,  a new CID would be
> > created if he needed it.
> 
> Would I be correct in saying that it's because you feel obliged to
> acknowledge that the injunction "Cool URIs don't change" is
> unrealistic, indeed that it you allow naming authorities to recycle names
> under their control, e.g. after non-payment of annual rental fees,
> that the corresponding URIs _will_ change, that you then need to
> make a distinction between what you call persistent vs. non-persistent
> URIs?  That is, a ! is the way a naming authority indicates that it
> will _not_ recycle a name.

Yes. In XRI syntax, the! delimiter at the start of any XRI subsegment (in
XRI, segments can contain delimited subsegments) means the identifier
authority is making the assertion that it will not recycle that subsegment.
The * delimiter (or no delimiter if used after an XRI global context symbol,
i.e, =, @, +, $) means the subsegment is reassignable.

> Would I furthermore be correct in concluding that it follows that if a
> naming authority leases a _persistent_ name to someone, and they stop
> paying, that all the naming authority is committed to doing is
> retiring the name and never re-issuing it?  It continues to identify
> what it always did, in principle at least, although in practice it may
> not (will definitely not?) be possible to retrieve either metadata or
> representations using it.

Yes. From the XRI specification level, the commitment by the identifier
authority is defined as being the same as it is for a URN as defined in RFC
1738. The ability to continue to serve metadata (or not) is an operational
policy of the identifier authority. As one example, in its XRI registration
policies, XDI.org [1] published its operational practices in the XDI.org
Global Services Specifications [2]. They currently require the registry to
maintain the original registration authentication credential so that even if
a persistent XRI registration (an "i-number") lapses, it can be reactivated
later in the future.

> And that the guarantee that a persistent name always identifies the
> same resource depends on the good behaviour of the leasee of that
> name?

Yes. Other mechanisms for verifying the binding between the persistent
identifier and the target resource, e.g., cryptographic hashes, are of
course possible but to my knowledge neither the XRI TC nor any implementers
have specified any yet.

> And finally, that persistence does _not_ imply continuity of
> ownership?  That is, I may lease a persistent name from some naming
> authority, and then sell that name on to someone else.  It's then up
> to _their_ good behaviour to continue to use that name to identify the
> same resource.

Yes. The XRI TC has discussed this particular use case extensively with
respect to corporate entities. For example, if Company A registers
reassignable XRI @a and persistent XRI @!1, and is then bought by Company B,
Company B may let reassignable XRI @a lapse but continue to maintain
persistent XRI @!1 to identify the same legal entity, perhaps now as a
subsidiary of Company B.

However I am not aware of any technical solution that prevents Company B
from starting to use @!1 to reference Company B. In fact it gets fuzzy, if
Company B "swallowed" Company A in a merger, whether in fact Company B is or
is not now Company A. The XRI TC called this the "merger use case" and
developed a synonym mechanism for XRDS documents in XRI Resolution 2.0 (see
section 5 of [3]) to help address this.

Hope this helps,

=Drummond 

[1] http://www.xdi.org
[2] http://gss.xdi.org
[3] http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html

Received on Monday, 15 September 2008 20:16:14 UTC