Re: [XRI] Back to XRI

Hi Roy,

XRI resolution is about retrieving meta data for resources.   It is  
not about retrieving resourced http: is about that.

I have stated this a number of times.  XRI  and XRDS is an extensible  
way of describing and retrieving those resources.  Our requirement is  
around extensibility and some other properties that DNS is lacking.

On the other hand unlike DNS, XRI is not optimized for size,  I would  
not expect that XRI would be  a good replacement for looking up A  
records, in most situations.

Through the HXRI proxy mechanism XRI is better at making that meta- 
data available to web applications than DNS is.

One of the things I cant get in http: are the DNS SRV records for XMPP  
for a given host.

Oh yes I could duplicate the information in RDF in some document but  
what is the standard for that.
(hint oAuth, openID,  and Google Friend Connect use XRI 2.0 resolution  
of XRDS documents to allow service discoverability)

XRI supports a number of subsegment naming conventions besides native  
XRI nodes.  You can have a XRI comprised entirely of URI subsegments.

Am I to take it that you are opposed to any proposal that would encode  
XRI global authority resolution information in the path of a http: URI?

Is it your position that other protocols using http: uri identifiers  
should not encode other directory information in the path, and treat  
them solely as opaque name strings?

If this is the case how do you feel about ARK?

In both HXRI, ARK, and PURL the Authority segment is just used as a  
placeholder for a proxy for http: scheme computability.  The real sub- 
scheme authority is encoded in the path.

We are able able to do this without breaking the http: scheme spec  
though we may well be violating the intent of the spec as perceived by  
some people.

XRI certainly has a different graph model than http: is intended to  
have.

Fundamentally we and others want something different from a "naming  
scheme that
is delegated hierarchically by association with domain ownership,"

That is why PURL, ARK, XRI and others exist.

Despite opinions to the contrary I think that a http: sub-scheme  
system that can bridge other protocols to http via proxies is valuable,

There are still open questions about how to do that.

We may never agree on the value that XRI and XRDS add.

I suspect that your position may that HXRI and other http sub-schemes  
do not provide sufficient interlinking, and no extensions to the  
existing identifier system should be allowed.

I am however happy to try and get to the root of your objection, as  
you see it.

I look forward to an interesting conversation.

John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中



On 5-Aug-08, at 4:43 PM, Roy T. Fielding wrote:

>
> 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/>
>
>