Re: [XRI] TAG recommendation

Thanks David,

Helpful as always,

The XRI-TC is taking members:)

The behavior of the Proxy resolution service is specified in Section  
11 of the Resolution spec.
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/xri-resolution-V2.0-cs-01.html

Sec 11.5 defines the processing of http(s) Accept Headers

Sec 11.7 defines the redirect behavior.  The relevant part for this  
discussion being:

> If the value of the Resolution Output Format is null, and the output  
> is not an error, a proxy resolver MUST follow the rules for output  
> of a URI List as defined in section 8.2.3. However, instead of  
> returning a URI list, it MUST return the highest priority URI (the  
> first one in the list) as an HTTP(S) 3XX redirect with the Accept  
> header content type set to the value of the Service Media Type  
> parameter.

The proxy resolver will never return content directly.  It will return  
the XRDS metadata if queried with the appropriate parameter.

So in the current XRI 2.0 spec if a browser queries:
1. http://beta.xri.net/=jbradley/?query&_xrd_r=application/xrds+xml  
the XRDS document for =!BF81.FD97.C81B.B4E5 is returned.

2. http://beta.xri.net/=jbradley   I receive a 302 redirect to http://ipage2.ezibroker.net/ipage/ipage.faces?iname==jbradley

These are real examples try them in a browser they work with xri.net  
as well the difference being that the content type returned by xri.net  
for 1 is text/xml to make it display in a browser for debugging.   At  
beta.xri.net it returns a content type of application/xrds+xml.

Yes we have always known the content type on a XRDS document should be  
application/xrds+xml we are testing that change now on beta.xri.net   
the incorrect content type is a holdover from debugging.

This is the current state of things in the current XRI 2.0 spec.

I think Stuart in his post points out that from a URI point of view  
these are distinct identifiers.

> "*If* the distinction is made in the URI (eg, the addition of a  
> parameter),
> then we have distinct identifiers (URI) one for <something> (above)  
> and one
> for the final XRDS document (and maybe others for any intermediate  
> XRDS
> documents)."


For clarification the proxy only returns the final XRD or XRDS as  
specified by the _xrd_r parameter.  It preforms all the resolution  
steps on behalf of the http(s) requester.

Now on to the fine points of redirects,  302 was originally chosen  
because it is supported in all browsers.  303 redirects are new to  
HTTP 1.1.   Given that HTTP 1.1 is now universally supported changing  
to a 303 redirect is one I think I can get pushed through the XRI-TC.

Would the understanding and change put this part of the issue to rest  
for people?

I think we are quite close on this.

David thanks again for the help.

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



On 22-Jul-08, at 7:45 AM, Booth, David (HP Software - Boston) wrote:

> > From: John Bradley
> > [ . . . ]
> > In the first case http://xri.net/=jbradley <http://xri.net/ 
> =jbradley>  is an abstract identifier
> > that is resolved to a CID and XML meta data.
> >
> > In the second case http://xri.net/=jbradley <http://xri.net/=jbradley 
> >  is treated as a browsers
> > request for a concrete URI resource.
> >
> > So yes the result depends on the context in which the
> > resolution occurs.
> >  [ . . . ]
> > If David or others can come up with a way to disambiguate the
> > overloading caused by scheme reuse,  I am happy to work with them to
> > incorporate it,  in the revised specs.
>
> The easy solution is to have an intervening 303-redirect.  So for  
> example, if you set up xri.net as an XRI proxy, then when http://xri.net/xri/=jbradley 
>   is dereferenced in a browser, xri.net should return a 303-redirect  
> to a different URI such as http://xri.net/content/=jbradley which  
> would give a 200 response with the desired XRI content or metadata  
> or whatever it is that you wish to return.  However, an XRI-aware  
> application would recognize the "http://xri.net/xri/" prefix and do  
> its own XRI resolution.
>
>
> Or, following your idea for exploiting DNS, a browser dereferencing http://boeing.com.xri.net/xri/=jbradley 
>  would get back a 303 redirect from the Boeing XRI proxy to a  
> content URI http://boeing.com.xri.net/content/=jbradley , which  
> would give a 200 response with the desired XRI content.  But an XRI- 
> aware application would recognize the "http://boeing.com.xri.net/ 
> xri/" prefix and do its own XRI resolution, perhaps interacting with  
> a Boeing XRI server.
>
> This is the same convention that is used for semantic web URIs, to  
> avoid creating an ambiguity between a web page (or "information  
> resource") and real-world objects:
>
> http://www.w3.org/TR/cooluris
>
>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software <http://www.hp.com/go/software>
>
> Statements made herein represent the views of the author and do not  
> necessarily represent the official views of HP unless explicitly so  
> stated.
>
>