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=falseThe
"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*fooThis 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
************
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