[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] RE: Revised Draft W3C response
+1 for the revised response. On Feb 25, 2008, at 8:41 AM, Drummond Reed wrote: > Thanks to Marty for reminding me I still didn't fix the typo he > found. It is > fixed in this version below. > > =Drummond > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Monday, February 25, 2008 12:36 AM > To: 'XRI TC' > Cc: 'Gabe Wachob' > Subject: Revised Draft W3C response > > Gabe et al: > > Per my action item from last week's XRI TC telecon, below is a > second round > of suggested edits to the W3C response incorporating feedback from > Nika, > Bill, Steve, Les, and Wil. > > Gabe, once again write control is back over to you. Everyone else, > please do > send any further feedback to the list ASAP, as Gabe would like to > get this > off to the W3C TAG ASAP. > > Thanks, > > =Drummond > > > ================================================================== > > 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? > > 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 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, 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 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;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 > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs > in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]