Re: [xri] RE: Revised Draft W3C response

[Nika Jones <njones@ouno.com>]

+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
>