For the reasons I just sent out I think
the answer is no. This is no different, in principal, to resolving a
domain name. One makes the use of a resolver to resolve a domain name by
calling various domain name servers. We would not classify that as a
second round trip. The only thing that we have introduced to confuse the
topic is this concept of a proxy resolver that sits on the web. Since we
always point folks to xri.net to resolve an xri it feels like a 2 round trip
thing but it is not. It is just a bootstrapping mechanism. We
should talk more in the terms of generic client resolvers and resolution servers.
From: Nika Jones
[mailto:njones@ouno.com]
Sent: Wednesday, February 20, 2008
7:15 PM
To: xri@lists.oasis-open.org
Subject: Re: [xri] Draft response
to W3C TAG comment on XRI 2.0 resolution
Drummond I think that question #1 was formed from
the perspective of using a Proxy Resolver (to "access" XRI
resources), so the answer would be a "yes", as I understand it.
However as you noted, It would be cool to
have clarifications cited for using the Proxy Resolver somewhat as a
Authority Server (the sep=false directive) or querying
a Authority Server directly.
On Feb 20, 2008, at 3:07 PM, Drummond Reed wrote:
Markus, on your first point, I think that
when you’re talking to an authority server, the XRDS document IS the
metadata you are requesting, so there is no defined “second round
trip”. But we could probably clarify that more.
Your second point is valid that there is a
limited form of content negotiation with authority servers. I think we should
add that.
Anyone else, please do post your thoughts
on this thread. I just talked to Gabe and although he can’t be on the
telecon tomorrow, he’d like us to discuss it and post any final feedback,
then he’ll send the response on Friday.
Looks great to me..
Just one thought, shouldn't the answer to 1) be a "Yes" instead of a
"The answer to your question depends on whether we are talking about
authority servers or proxy resolvers"? The explanation is great, but they
are right when they say there are always at least 2 round trips, no?
For 2) one might argue that authority resolution servers also support a VERY
limited form of content negotiation (the server looks for the saml=true
subparameter). However I'm not sure if that counts as content negotiation,
since the content type stays the same......
Markus
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
|