Re: Back to XRI

On Jul 26, 2008, at 9:13 AM, Paul Prescod wrote:
> Mark asked me to start a new thread re-summarizing the XRI
> requirements. Given the history of the issue I think that the XRI
> folks deserve some focused discussion on their specifics. Here is a
> summary of my understanding:

Please don't confuse requirements with presupposed design.

> XRI is a way of representing identifiers that are designed to be
> resolved with a protocol that is more distributed and reliable than
> the standard HTTP resolution mechanism.

Aside from the fact that it is impossible to be both "more distributed"
and "more reliable" than DNS, the fundamental error here is the
assumption that the resolution mechanism is determined by the URI  
scheme.
It isn't.

   http://labs.apache.org/webarch/uri/rfc/rfc3986.html#identification

Think about how caches and proxies work and it should be apparent that
naming and resolution are independent.  HTTP can be used to resolve any
URI scheme, and resources identified by the "http" URI scheme can be
used far outside the context or need for HTTP.

In other words, any system for decentralized resolution can operate
using any naming scheme that is suitably unambiguous. Consider how
often social security numbers are used in the U.S. for things that
have nothing to do with the person's social security account.
Consider how many information systems use vehicle identification
numbers without needing to pass around the VIN stamped engine block.

The "http" URI is an interesting case.  It is a naming scheme that
is delegated hierarchically by association with domain ownership,
TCP port, and HTTP listener.  However, once named, HTTP is no more
inherent in "http" name resolution than access to the U.S. Treasury
is to SSN name resolution.

If I want to find an http-named resource, then I tell my software
to get it (or metadata about it) from whatever set of repositories
I may have access.  Sometimes those repositories are local disks,
sometimes they are remote proxies, sometimes they are archives
stored on CD-ROM, sometimes they are queries with Google's spider
cache, and sometimes they involve HTTP access over TCP port 80 to
a server that my name lookup daemon has been told to be the owner
of that URI.

In other words, the requirements for XRI can be entirely satisfied
by a service (or set of services) that use "http" identifiers that
are resolved by a decentralized, redundant, distributed name lookup
service that uses the entire URI as its key.  Such a specialized
content distribution network could be easily run by these same
companies that are convinced the world needs another Lotus Notes,
or it can be contracted out to a company that runs such services on
a regular basis (e.g., Akamai).

> In order to invoke that extra resolution machinery, it must be
> possible for client apps to recognize these identifiers when they are
> used as URIs. This recognition must necessarily happen before
> resolution, not after.

No, it could just as easily be invoked always in parallel, or only
upon cache miss, or only upon response failure, ... just as folks
have done in the past for cache hierarchies, shared annotation
services, etc.

> XRIs will be used (as http or FTP URIs are used) in contexts where
> there is no hypermedia to be the engine of state, or where the goal is
> to bootstrap the hypermedia-based communication.

*shrug*

> It would be incredibly valuable for XRIs to be backwards compatible
> with HTTP clients through the use of HTTP URIs.

It would be more valuable to abandon the NIH syndrome.

> Therefore the current proposal as I understand it is to treat HTTP
> URIs in subdomains of XRI.net as XRIs.

I think that proposal completely misses the point of the TAG's  
objection.

The WWW is the web of interlinked worldwide information.  It has  
value as
a function of its interlinking.  If you introduce yet another identifier
mechanism that takes (mostly) the same set of potential information
sources but identifies them via a different and mostly incompatible
set of names, then you have either bifurcated the Web or duplicated the
Web.  Both results are bad for users, bad for Web technologists, and
bad for W3C member organizations.  Hence, W3C members should not support
such a technology because its design is contrary to the Web's design
and because the same requirements can be satisfied without introducing
a new system of identification.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Tuesday, 5 August 2008 23:44:00 UTC