Re: [XRI] Back to XRI

Thanks Paul,

Good summery.

I posted separately to Mark's comments.

I will only add that the XRI-TC recognized the value of David  Booth's  
comments two years ago.
We created HXRI as an adjunct to the xri: scheme not a replacement for  
We believe HXRI is valuable and have no intention of dropping it.  The  
only question is how should HXRI be extended.

If we are asked to replace the functionality of a URI scheme entirely  
with HXRI the requirements for HXRI change as a result.

The question for XRI and others is:

Is it possible to create  sub-schemes within http: without breaking  

The proposed sub-scheme mechanism must be a standard!

I do not want ARK using the path XRI using part of DNS, Skype using  
the user name, and sip using a port number.

If we are going to use the http: scheme for non-DNS authority  
resolution lets pick one way to do it.

John Bradley

On 26-Jul-08, 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:
> 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.
> 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.
> 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.
> It would be incredibly valuable for XRIs to be backwards compatible
> with HTTP clients through the use of HTTP URIs.
> Therefore the current proposal as I understand it is to treat HTTP
> URIs in subdomains of as XRIs.
> Paul Prescod

Received on Saturday, 26 July 2008 17:17:12 UTC