Re: Boeing XRI Use Cases

On 15-Jul-08, at 8:39 AM, Julian Reschke wrote:

> John Bradley wrote:
>> ...
>> It is my belief that there is no place in the spec where xri: is  
>> used as a XML namespace name that a URL could not have been used.
>> <XRD version="2.0" xmlns="xri://$xrd*($v*2.0)">
>> This uses the XRI versioning syntax that we have some attachment to.
>> David Orchard has concerns that this is not a valid URI.
>> ...
>
> Well, it isn't, until you register "xri" as a URI scheme. I think  
> this is why many people are concerned by this: that "xri"  
> identifiers leak out into places that do only allow U^HIRIs.
>
>> That is one question I don't think has been resolved completely.
>> If the scheme were registered is this valid as a URI without  
>> further escaping?
>
> Potentially.
>
> Why does it start with "//" when it doesn't use an authority (see  
> RFC3986, Section 3)?
>
There is a authority segment it is a two subsegment XRI  $xrd is the  
first sub segment and ($v*2.0) which is a cross reference is the second.

A more typical XRI in URI-Normal form looks like xri://=jbradley/ 
+phone/+home.  =jbradley is the authority and +phone/+home is the path.

It is a big spec and I won't dig into it in detail here.

To be frank I have wondered myself if leaving the double slashes off  
might make the scheme more acceptable for people.

xri:=jbradley/+phone/+home

The only thing it changes os that URI processors would be less tempted  
to try and examine the authority segment.

The XRI-TC believe that including the indication of an authority  
segment is the more correct thing to do.

This would be a great thing to drill down on if people have the  
interest.

If there is no hope of preserving xri: as a scheme with or without an  
authority segment then the discussion would be a bit academic.



>> ...
>> My question around WEBDAV was not really directed at XML but rather  
>> the processing by WEBDAV aware clients of webdav URLs in the http:  
>> scheme?
>> WEBDAV extended the operators beyond GET and POST, and had a  
>> extended web server that dealt with information encoded in the path.
>
> No, in WebDAV there is no information encoded into the path. It only  
> uses additional methods, the HTTP URLs are the same as always.
>
>> We have not proposed new operators to extend the http protocol with  
>> HXRI.
>> If xri and webdav and http are to all share the same http: scheme  
>> addressing then how are the clients like XDI servers and possibly  
>> web browsers going to recognize these URIs?
>
> Are you asking for feature discovery? WebDAV does that through  
> OPTIONS (see <http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.10.1 
> >).
>
>> Is there something we can learn from others attempts to fit  
>> themselves into the http: scheme?
>> Some people feel that if we conform to http: scheme addressing we  
>> must still justify XRI in some way.
>> How have other people met this challenge?
>> I ask about WEBDAV because it would appear to have some of the same  
>> issues we will encounter tying to re-use the http: scheme.
>> I will have a look at RFC 2518 to see if it can shine some light on  
>> this.
>> ...
>
> I don't think WebDAV shares these issues, as it just adds new  
> methods to  manipulate otherwise standard HTTP resources. That being  
> said, you want to look at RFC 4918, not RFC 2518.
>
> BR, Julian
>
So a client must do a get on the URL first to discover if it is WEBDAV?

I can see how that would work for HXRI in some but not all  
circumstances.

I do think that we need a way for clients to recognize HXRI so that  
they can be converted to UTF-8 for display and other processing.

Thanks for your input.

Regards
John Bradley
OASIS IDTRUST-SC
=jbradley