- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Sun, 2 Mar 2008 02:59:58 +0000
- To: Gabe Wachob <gwachob@wachob.com>, "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
- CC: "www-tag@w3.org" <www-tag@w3.org>
Gabe, Thank you for taking the time to consider our input and for responding in detail. We have not had time as yet to study your response as yet or discuss it as a group. I hope to schedule time to do so in the near future. Best regards Stuart Williams co-chair W3C TAG -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England From: www-tag-request@w3.org [www-tag-request@w3.org] On Behalf Of Gabe Wachob [gwachob@wachob.com] Sent: 29 February 2008 18:17 To: noah_mendelsohn@us.ibm.com; www-tag@w3.org Subject: XRI TC response to W3C TAG Comments on XRI Resolution 2.0 [This response constitutes the official response to the comments by the W3C TAG to XRI Resolution 2.0 CD02] 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. You asked about additional opportunities for feedback. The TC has just incorporated feedback from the public review of Committee Draft 02 into a revision on which it is currently conducting a vote to promote to Committee Draft 03. We expect to commence another 15 day public review period on Committee Draft 03 running from the middle to the end of March. 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? First, we should clarify that XRI resolution defines two types of servers: 1) "authority servers", which serve metadata documents (XRDS documents) describing resources directly, 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 play essentially the same role in XRI infrastructure that nameservers play in DNS infrastructure. They 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) in answer to resolution queries from either a local resolver (one operating directly in an client's own address space) or a proxy resolver. In this case the set of resolution queries made to XRI authority servers to resolve an XRI is directly analogous to the set of resolution queries made to DNS nameservers to resolve a DNS name. There are as many of these "roundtrips" as there are subsegments in an authority, minus one (e.g. =gmw*foo*bar has four subsegments '=', 'gmw', '*foo', '*bar'). 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, just as caching is critical to good DNS performance. 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]. A proxy resolver 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 parameter 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/* media type. ********** 2) HTTP content negotiation can be used in requests for XRIs to force either metadata return or redirection to actual resource representations? Yes, local resolvers or proxy resolvers can do this on behalf of a client (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 proxy resolver does not include a Resolution Output Format paramater (_xrd_r) or the 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;sep=true The "sep=true" media type subparameter indicates the proxy resolver should perform service endpoint selection using the media type requested; the absence of an _xrd_r parameter means it must 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 / gwachob@wachob.com \ http://blog.wachob.com
Received on Sunday, 2 March 2008 03:06:29 UTC