RE: [xri] Draft response to W3C TAG comment on XRI 2.0 resolution

+1

 

I think this draft is a very good response and will help 
keep dialog open between us and the W3C TAG.

 

Bill

From:  
[mailto:] On Behalf Of Gabe Wachob
Sent: 
Wednesday, February 20, 2008 2:11 PM
To: 

Subject: [xri] Draft response to W3C TAG 
comment on XRI 2.0 resolution

TC Members-
    An adhoc group of members 
has drafted the following response to the recent coment from the W3C TAG 
authored by Noah Mendelson. Please review this response and give "+1" if you 
feel happy with it. Drummond - is there any vote required on this to make it an 
official response? 

     
-Gabe

==================================================================

Noah 
and other members of the TAG:

First of all, we appreciate your review of 
XRI Resolution 2.0 Committee
Draft 02 [1] - it is clear from your questions 
that you've spent some time
reading this specification. Following are answers 
to the questions you
posed.

**********

   1) All 
access to resources identified by XRIs
      require (at 
least) two round trips, the
      first to retrieve metadata 
(XRDS, XRD or
      uri list) and the second to 
retrieve
      (a representation of) the resource 
itself?

XRI resolution defines two types of servers: 1) "authority 
servers", which
serve metadata documents (XRDS documents) describing 
resources, and 2) proxy
resolvers, which provide a layer of functionality 
that helps integrate XRI
resolution infrastructure with the WWW architecture. 
Proxy resolvers perform
XRI-specific resolution logic in a way which can hide 
XRI resolution
semantics from the client of the proxy resolver (e.g., a 
browser that is not
XRI-aware).

The answer to your question depends on 
whether we are talking about
authority servers or proxy resolvers. Authority 
servers only serve up XRDS
documents (which can contain one or more XRD 
elements, each of which
corresponds to an authority subsegment, or a 
reference to one). Thus,
authority servers serve up *only* metadata, and if 
you follow a chain of
subsegments that delegate to other authority servers, 
you could actually
have as many round trips as there are subsegments in an 
authority, minus one
(e.g. =gmw*foo*bar has four subsegments '=', 'gmw', 
'*foo', '*bar') just to
get metadata.

Of course, we are careful to 
suggest that caching semantics (both at the
HTTP level and *above* at the XRD 
level) be used aggressively to reduce
these roundtrips. And also note that an 
authority server can perform
"lookahead" resolution and thus return results 
for more than one XRI
subsegment if it is asked (and the cached XRDs have not 
expired).

A proxy resolver, on the other hand, hides the set of 
interactions with
authority servers. It performs all these resolutions round 
trips on behalf
of a client (and hopefully builds up a substantial cache in 
doing so). A
client using a proxy server will use one round trip, typically, 
to obtain
metadata, and one trip to access a resource (in a RESTful manner, 
or
whatever manner is URI-identifiable). A common example of this pattern 
is
OpenID discovery, where a proxy resolver is used to request an XRDS 
document
from which the OpenID authentication service endpoint is selected in 
order
to redirect the user for OpenID authentication [2].

Proxy 
resolvers may also be asked to redirect a client to a resource
directly (see 
question 2). While this is a separate roundtrip (a 302
response, typically), 
it is no different than any other HTTP redirect from a
client's perspective. 
The only difference is the manner in which a proxy
request URI is 
constructed.

Following are two examples of proxy resolver request 
URIs:

Example #1:
Request URI:
http://xri.example.biz/=example*foo?_xrd_r=application/xrds%2Bxml;sep=false
The 
"sep=false" media type subparameter indicates that the proxy should
perform 
authority resolution on behalf of the client, but not perform any
service 
selection. The proxy will resolve "*example" against the authority
resolution 
server for "=", then resolve "*foo" against the authority
resolution server 
for "=example". It then returns the XRDS document
containing 2 XRD elements 
(one for "*example" and another for "*foo") to the
client.

Example 
#2:
Request URI: http://xri.example.biz/=example*foo
This is a "Null 
Resolution Output Format" according to section 11.6 of the
specification. The 
proxy performs authority resolution as above. It then
performs service 
selection on the resolved metadata, and responds with a
HTTP 302 with the 
Location header value set to the highest priority URI from
the highest 
priority selected service. If service selection is unsuccessful,
it returns a 
non-302 HTTP response code. Since this is primarily a mechanism
for providing 
compatibility to applications with no native XRI support, we
recommend a 
human-readable error message to be returned in a text/* 
MIME
type.

**********

   2) HTTP content negotiation 
can be used in
      requests for XRIs to force either 
metadata
      return or redirection to actual 
resource
      representations?

Yes, a limited 
form of content negotiation is specifically supported for
proxy resolvers 
(authority servers only handle XRDS documents).

As specified in section 11.7 of [1], a proxy resolver will 
return a redirect
if the request URI sent to the proxr resolver does not 
include a Resolution
Output Format paramater (_xrd_r) or its value is null. 
This allows XRI
authors to create a proxy resolver request URIs that can be 
used anywhere on
the web (e.g. on an HTML page) and will be resolved (via 
redirects) to a
resource representation just like any other non-XRI-related 
URL. Because of
constraints on POST/PUT, this redirect mechanism only works 
for GET/HEAD
requests.

For example, the following proxy resolver 
request URI could be used to
request a redirect to a server capable of 
returning a PDF representation of
a resource:

Example #3:
Request 
URI:
http://xri.example.biz/=example*book?_xrd_m=application/pdf

The 
lack of an _xrd_r query parameter indicates to the proxy resolver that
it 
should perform service endpoint selection using the media type requested
and 
then return a redirect as specified in section 11.7.

************

   3) Relative XRIs are of 
course allowed in the
      normal way when a full-form XRI 
has been
      established as the base URI.  Are they 
also
      allowed _without_ any full-form XRI as a
  
    base URI?  That is, for example, is "=henry"
    
  intended to be recognize as an XRI in the
      absence 
of any base URI?  If so, what is
      being done to 
ensure that both now and in
      the future, the syntax of 
such abbreviated
      XRIs is coordinated with (i.e. 
remains
      disjoint from) the syntax of both 
absolute
      and relative URIs that might be used in 
the
      same contexts?

With regard to relative XRIs, 
the XRI Syntax 2.0 specification [3] followed
the lead of RFC 3986, in 
particular section 5.1:

<quote>

5.1.  Establishing a 
Base URI

  The term "relative" implies that a "base URI" exists 
against which
  the relative reference is applied.  Aside from 
fragment-only
  references (Section 4.4), relative references are only 
usable when a
  base URI is known.  A base URI must be established 
by the parser
  prior to parsing URI references that might be relative. 
 A base URI
  must conform to the <absolute-URI> syntax rule 
(Section 4.3). If the
  base URI is obtained from a URI reference, then 
that reference must
  be converted to absolute form and stripped of any 
fragment component
  prior to its use as a base 
URI.

</quote>

So every relative XRI has by definition a base 
XRI. Section 2.4 of XRI
Syntax 2.0 defines how they are resolved as 
follows:

<quote>

2.4.1 Reference Resolution

For XRI 
references in IRI-normal form or URI-normal form, resolving a
relative XRI 
reference into an absolute XRI reference is straightforward. If
the base XRI 
and the relative XRI reference are in IRI-normal form, section
6.5 of [IRI] 
applies. If the base XRI and the relative XRI reference are in
URI-normal 
form, section 5 of [URI] applies.

It is important that XRI references 
appear in a form appropriate to their
context (i.e., in URI-normal form in 
contexts that expect URI references and
in IRI-normal form in contexts that 
expect IRI references), since the
algorithms described in [IRI] and [URI] may 
produce incorrect results when
applied to XRI references in XRI-normal form, 
particularly when those XRI
references contain cross-references.

In 
contexts that allow a native XRI reference (i.e., an XRI reference 
in
XRI-normal form), it may be useful to perform relative reference 
resolution
without first converting to IRI- or URI-normal form. In fact, it 
may be
difficult or impossible to convert to IRI- or URI-normal form without 
first
resolving the relative XRI reference to an absolute XRI. The 
algorithms
described in section 5 of [URI] apply to XRI references in 
XRI-normal form
provided that the processor:

* treats the characters 
allowed in IRI references but not in URI references
the same as it treats 
unreserved characters in URI references (as required
by section 5 of [IRI]) 
and

* treats all characters within all cross-references the same as 
unreserved
characters in URI references (i.e., treats cross-references as 
opaque with
respect to relative reference 
resolution).

</quote>

So to your question, "Is '=henry' 
intended to be recognize as an XRI in the
absence of any base URI?", the 
answer is no - it is only intended to be
recognized as a relative XRI in the 
presence of a base XRI.

It is true that if the same resource is 
identifiable with both one or more
base XRIs and one or more other base URIs 
of some other form, then a
relative reference in the context of that resource 
is relative to all of
these base identifiers. This appears to be no different 
for relative XRIs as
it would be for any other forms of 
URIs.

************

We hope these are answers are 
helpful.

-Gabe Wachob
Co-Chair, OASIS XRI TC

[1]
http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf
[2] 
http://openid.net/specs/openid-authentication-2_0.html
[3] 
http://www.oasis-open.org/committees/download.php/15377

-- 
Gabe Wachob /  \ http://blog.wachob.com