Re: Boeing XRI Use Cases

Hi David/Stuart,

I would start by pointing out that the likely alternative to certainty  
is uncertainty,  and uncertainty is something that we try our best to  
avoid in computing.

The XRI-TC is being asked by the W3C not to use a URI scheme because,   
the W3C believes that no new schemes should be registered.

We are thus asked to give up a clear and certain way of identifying  
XRIs.

Other potential specs are undoubtedly looking at this as well and  
wondering how best to proceed in the light of this finding by the TAG.

Some people (they know who they are) have chosen to use unregistered  
schemes as noted by the W3C in http://www.w3.org/Addressing/schemes.html

The issue of URI schemes is not a new one I point to http://www.ietf.org/proceedings/97aug/transit97aug-30.htm 
.

The XRI-TC will not take the route of using an unregistered scheme,  
like what others are doing on a daily basis if the W3C is correct in  
its information.

If we can work though the process with the W3C of finding a general  
alternative for people to use, one that gives us the same certainty as  
a registered scheme.
I think it will be to the benefit of the community in general.

I think David Booth makes an extremely valid point regarding the clear  
chain of authority.   If the clear chain of authority is not  
maintained uncertainty is introduced.

There is currently a public HXRI proxy at http://xri.net/  , So by  
Davids argument this could be considered the root of the chain of  
authority.

However this locks people into using a single proxy in there HXRI's  
this is something ARK avoided by encoding ark: in the path.

I would prefer the proposed changes not increase the amount of  
centralization.

Currently xri://(http:boeing.com)*jbradley is recognized as a XRI by  
client apps and can be resolved through any XRI resolver without  
reference to the global registry.

I don't think the TAG's goal is to further centralize the  
administration of XRI.

An idea I have kicked around with a number of people that may fit  
David's model is to use a domain or TLD as the "clear chain of  
authority" root.

The difference being that all identifiers under that DNS root would be  
interpreted as the appropriate sub scheme.

As an example the domain name boeing.com.xri.net would be interpreted  
as an XRI by the client software.  DNS would be configured to return  
the ip address of Boeing's HXRI proxy server.

I could use http://plaxo.com.xri.net/(http://boeing.com)*jbradley if  
that was the proxy that was optimal for me,  a client application  
could also recognize it as being a synonym for http://boeing.com.xri.net/(http://boeing.com)*jbradley

DNS could be set up to provide this service by manually configuring  
CNAME records or something more sophisticated like DNAME.  I will  
defer to the DNS experts on that.

I am inclined to use designated "special" TLD's for this purpose if  
possible.

Is that a pattern that multiple people could adopt to provide the  
certainty once provided by a URI scheme?

This domain idea is one of mine based on David's input.  The XRI-TC  
remains open to all ideas at this point.

Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中




On 18-Jul-08, at 7:45 AM, Williams, Stuart (HP Labs, Bristol) wrote:

>
> Hello David,
>
> <snip/>
>
>> If an XRI-aware application needing XRI resolution is able to
>> recognize the appearance of "/xri:/" embedded in a URI like
>>
>>  http://xri.example.org/xri:/@boeing*jbradley/+home/+phone
>>
>> Then it could just as well recognize "http://xri.org/xri:/"
>> at the *beginning* of a URI like
>>
>>  http://xri.org/xri:/xri.boeing.com/@boeing*jbradley/+home/+phone
>>
>> without any risk of accidentally misinterpreting the URI
>> (assuming the owner of xri.org had declared that all URIs of
>> that form are HXRIs).  This would *not* require XRI
>> resolution of that URI to go through a central proxy at
>> xri.org!   Because the app is XRI-aware, it could know to
>> strip off "http://xri.org//xri:/" and use xri.boeing.com for
>> XRI resolution, without ever sending a request to xri.org.
>> In fact, the XRI spec could *require* this behavior.  The
>> effect is that xri.org would only receive requests from
>> clients that are *not* XRI-aware.  And for those, it could
>> send back whatever information you think would be most
>> helpful, which *might* involve acting as an XRI resolution
>> proxy, but that is a matter of choice.  It could instead back
>> general information about XRIs, or some combination thereof,
>
> Were it to do so (provide general information), I'd hope that there  
> would be some intervening redirection so that there is no confusion  
> that what is returned is a awww:representation of the referent of:
>
>   http://xri.org/xri:/xri.boeing.com/@boeing*jbradley/+home/+phone
>
> Hmmm...which, intentionally would be what?
>
> - Boeings record of jbradleys home phone number?
> - Boeings metadata about Boeings record of jbradleys home phone  
> number?
>
> Something else entirely?
>
> I'm not sure if I am supposed to be able to tell.
>
> Regards
>
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
> Berks RG12 1HN
> Registered No: 690597 England
>