RE: [xri] [Issue 6] Versions and profiles

["Drummond Reed" <drummond.reed@onename.com>]

Mike,

There are two primary use cases I'm thinking of. The first is pretty
straightforward. Because XRI-URIs are reassignable, it may be important
for a user (e.g., for legal, research, or data verification reasons) to
be able to specify that they want the resource that resolved to a
top-level identitier such as "@Foo" at a particular point in time, i.e.:

	xri://@Foo(+version/datetime/2001-03-04T20:15:40Z)

The second is more subtle but I believe can have a big impact on URN
resolution efficiency. Even though XRI-URNs are not reassignable, the
metadata associated with a URN that describes the current location of
the target resource on the network will change when the resource moves
on the network. It may be important for an XRI itself to be able
communicate this new state, especially to other resolver caches. For
example, the XRI-URN:

	xri://.A563.9E4F(+v/7)/9852.14

would clearly inform all XRI resolver caches that the metadata
associated with the resource represented by ".A563.9E4F" is at version
7, and that any cache with a lower version value should request an
update of the current location of "9E4F" from ".A563".

Especially when XRI-URNs are machine-generated (which I suspect most
will be), the automatic inclusion of that version info (when known) into
the XRI-URN value itself would be a whole lot more efficient than
resolvers having to either a) periodically timeout and request new
copies of the resolution metadata from the next higher authority the way
DNS resolution typically works today, or b) trying the current cached
value until it produces an error (because the resource has moved) and
then requesting an update of the resolution metadata.

Note that the version value associated with an XRI-URN can never be
considered authoritative because the version value included with a
particular XRI-URN may be out of date. So if a resolver saw the above
example but its own cache was at version 9, it would go ahead and
attempt to use its cached value.

=Drummond 

-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com]
Sent: Monday, April 28, 2003 10:02 AM
To: xri@lists.oasis-open.org
Subject: RE: [xri] [Issue 6] Versions and profiles

Drummond,

I'm not following the use case that you are referring to.  Actually, to
be more specific, I believe that I follow what you are saying and don't
see the extra value in the case of an XDI resolution mechanism.  Could
you spell it out?

Thanks,

Mike

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@onename.com]
> Sent: Monday, April 28, 2003 9:05 AM
> To: Dave McAlpin; Wachob, Gabe; xri@lists.oasis-open.org
> Subject: RE: [xri] [Issue 6] Versions and profiles
>
>
> Just to go on record, I'm not on board that versioning syntax
> should not
> be available at all levels. There is one perspective - an all
> XDI-based
> resolution mechanism - where versioning of top-level authorities for
> either XRI-URIs or XRI-URNs would be a valuable use case.
>
> I understand that versioning may not be advantageous at the top level
> when using other resolution mechanisms, but I don't think this should
> automatically disqualify it from any consideration. I think
> it would be
> cleaner to make it an optional feature at the top level for certain
> resolution mechanisms.
>
> =Drummond
>