Re: Boeing XRI Use Cases

Hi Paul,

A recommendation by the TAG or other authoritative body would be  
appreciated.

However I want to restate a post from David Booth that needs to be  
kept in mind.

Appending a sub scheme in the path may violate Davids chain of  
authority principle.

I don't want to loose sight of that in the discussion of relative  
merits.

You should also look at how we solve your failover use case in the  
XRDS.  It is something we have considered.
It is used in openID if the agent is smart enough.  Most there are a  
couple of RP libraries that make use of this behavior.

Reminds me I need to create an OSIS test for that, thanks for the  
reminder:)

> The AWWW says:
> http://www.w3.org/TR/webarch/#pr-uri-opacity
> [[
>    Good practice: URI opacity
>
>    Agents making use of URIs SHOULD NOT attempt to infer
>    properties of the referenced resource.
> ]]
>
> But I think the words "opaque" and "infer" may be a bit misleading  
> in the context of this discussion.
>
> When this TAG advice was written, the main concern was that some  
> agents were looking at ".html" at the end of a URI and using that to  
> "infer" (i.e., *guess*) that the result would be an HTML document.
>
> The important principle behind this advice is that there must be an  
> unambiguous, well-defined chain of authority for interpreting the  
> meaning of the URI and what it denotes, starting with the scheme.   
> This is the same principle behind the TAG finding on Authoritative  
> Metadata:
> http://www.w3.org/2001/tag/doc/mime-respect-20060412
>
> This does *not* mean that an agent must not look at components of  
> the URI in order to determine its meaning.  It means that it must  
> not *guess*. How a URI is interpreted must be explicitly licensed  
> within this chain of authority.  So when presented with a URI such as
>
>    http://xri.example/foo.html
>
> the agent should *not* look at the ".html" suffix and *guess* that  
> it will return an HTML document, nor should it look at the "xri."  
> component and *guess* that the URI is really an HXRI-encoded XRI.   
> However, when presented with a URI such as
>
>    http://xri.net/xri/foo
>
> *If* the owner of the xri.net domain has explicitly said all URIs  
> under the http://xri.net/* space are actually HXRI-encoded XRIs,  
> then an agent does have license to interpret the URI that way.  It  
> would *not* be a guess.

Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley

On 16-Jul-08, at 6:19 PM, Paul Prescod wrote:

> Let me make a concrete proposal.
>
> Could the W3C (the TAG? Or someone else?) issue a recommendation to  
> the effect that URIs of the following form are special:
>
> http://xri.example.org/SOMETHING:/@boeing*jbradley/+home/+phone
>
> It would be permissable for an application detecting a URI of that  
> form to interpret the URI *either* according to the HTTP  
> specification *or* according to some other specification attached to  
> the word SOMETHING.
>
> SOMETHING's should probably be managed in a registry but I don't  
> know whether to use the domain name registry or something else. For  
> the sake of continuing, let's presume the domain name registry:
>
> http://xri.example.org/uri.xri.org:/@boeing*jbradley/+home/+phone
>
> It might be a best practice that "http://xri.org/" have a prominent  
> link to documentation of how the URI is used.
>
> Once the W3C had issued such a recommendation, the chances of  
> someone minting these URIs by accident would drop (even below the  
> really tiny current chance).
>
> I see a use-case that's been bugging me for years;
>
> http://my.vital.service.com/failover_uri:/path/failover_uris=URI2+URI3
>
> (I'd have to think more about how exactly the escaping works to get  
> the three URIs embedded)
>
> Today's HTTP clients would contact me with the full URI and I'd  
> discard URI2 and URI3. But a smart HTTP client might try URI2 if it  
> couldn't contact my.vital.service.com.
>
>  Paul Prescod
>