Re: Boeing XRI Use Cases

David,

I think you make a good point.  We have discussed a couple of ideas  
that would address the chain of authority issue.

This has not gone to the XRI-TC so things we talk about are for  
discussion only at this point.

HXRI as it stands will need to be modified if we drop xri:.

Given your excellent feedback it should probably be modified anyway to  
account for the chain of authority issue.

For convenience XDI.ORG could purchase the TLD xri

Consider if you will that any domain name ending in xri.  would be  
considered a HXRI.

For convenience XDI.ORG could purchase the TLD xri.

DNS could map all domain names as sub-domains of xri.

So if you entered https://xri/=jbradley   This would be interpreted as  
a GRS HXRI.  and be =jbradley in XRI-Normal Form
So if you entered https://boeing.com.xri/*jbradley   This would be  
interpreted as a Community HXRI. and be (http://boeing.com)*jbradley  
in XRI-Normal Form.

Note that the community registry (http://boing.com) is independent of  
GRS but for some DNS trickery that we have introduced in the HXRI form.
http://boeing.com/(http://boeing.com)*jbradley  would be a way of  
expressing the same community XRI without the DNS trick.

Boeing could still use there community @boeing*jbradley as a HXRI as  
ether:
1. http://xri/@boeing*jbradley   using the public proxy
2. http://boeing.com.xri/@boeing*jbradley using there private proxy.

Boeing would publish a DNS SRV record under boeing.com  for there XRI  
proxy that they want used for boeing.com.xri

There would need to be some different transformations depending on the  
GCS symbol that starts the path segment.

This is only one idea that might work.  Yes I probably have unworkable  
details.

Is finding a solution like tis a direction people want us to explore.
(that is if I don't wind up getting lynched by both the W3C-TAG and  
the XRI-TC)

Regards
John  Bradley
OASIS IDTRUST-SC
=jbradley

On 15-Jul-08, at 9:21 AM, Booth, David (HP Software - Boston) wrote:

>> From: Paul Prescod
>> [ . . . ]
>> I feel like there are certain irreconcilable goals here:
>>
>> 1. use HTTP URIs (and protocol) for HTTP-only applications
>>
>> 2. add additional functionality beyond HTTP for XRI-aware
>> applications
>>
>> 3. encode the trigger for that functionality *in the URI*
>> and not in markup or elsewhere
>>
>> 4. keep URIs opaque
>
> 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.
>
>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not  
> necessarily represent the official views of HP unless explicitly so  
> stated.