Re: [XRI] Back to XRI

Ellotte,

It appears that you are at odds with the TAGs recommendations to the  
XRI-TC.

The contention is that http: URI can be abstract and not return a  
representation of the resource.
This would certainly be the case if http: URI are used to identify  
resources for protocols other than http:

Even in the http protocol the use of link-headers and other meta-data  
is where the XRI-TC is being directed to inform us on the use of http:  
URI as abstract identifiers.
http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt

Like URNs, XRI are abstract identifiers and were intended to be used  
with a separate scheme to make that differentiation clear.

We are exploring creating http: sub-schemes  or profiles for a section  
of the http: address space to map XRI entities into so that address  
space and prevent fragmentation of the information space.

The XRI-TC and the TAG are engaging in ongoing discussions relating to  
how best to represent the qualities of abstract and persistent XRI  
syntax using http: syntax for use in http: and other protocols.

XRI like http URI are not bound to a particular protocol.   In the XRI  
case this was part of the design criteria, where the notion for http  
appears to be more of an evolution.

Though there is the common misconception that http: URI are bound to  
the http: protocol.

This is one of the points raised in the tags issue-50: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html#iddiv2137969152 
  .

Are you opposed to the use of http: scheme URI as abstract identifiers?

Do you have some alternate proposal on how the use case for abstract  
identifiers can be satisfied?

In the case of a xri: scheme as proposed in the XRI spec, a XRI is not  
a http: uri and while there is a http: binding for resolution,  there  
others in the works for SS7 and XMPP.

It is probably best to think of the XRI as a URN.  There is no XRI  
protocol as there is with SS7, XMPP or HTTP(s).

I think that some people confuse the scheme indicating the transport  
protocol in some cases and other uses from the urn side where it  
indicates a naming syntax.

We are now trying to look at the XRI in http as being a relative URI   
to a base proxy URI for transport schemes like http, https, xmpp.

Mapping to the urn: scheme is also possible for some applications.

Thanks for your feedback.

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

On 9-Sep-08, at 8:21 AM, Elliotte Harold wrote:

> John Bradley wrote:
>
>> I take it that you are opposed to XRI being a separate scheme with  
>> the purpose of returning meta-data for abstract identifiers.
>
> Correct.
>
>> Do you have any feelings on integrating XRI into http via the HXRI  
>> mechanism we have been discussing elsewhere on this list?
>
>
> Not really, but I would object to anything that requires different  
> resolution strategies for HTTP. If you give me an HTTP URL, I want  
> to go get a representation (bit stream) without any further  
> inspection of the path or query string or fragment ID. As long as I  
> can do that, you're free to put anything in the URL or at the other  
> end that you feel like.
>
> -- 
> Elliotte Rusty Harold  elharo@metalab.unc.edu
> Refactoring HTML Just Published!
> http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/ 
> cafeaulaitA