RE: Boeing XRI Use Cases

> From: Drummond Reed
> [ . . . ]
> [We] finally ended out specifying a slight
> variant on what we recently learned was the approach David
> Booth documented in his "Converting New URI Schemes or URN
> Sub-Schemes to HTTP" [1]. The only difference of what we did
> from what David specified was that in order to avoid
> specifying a single centralized XRI proxy server, we
> specified a pattern HXRIs must follow (essentially "xri.* in
> the domain name PLUS an XRI global context symbol as the
> first char of the path).

That's a critical difference though, because it means that there no longer is a clear chain of authority (URI spec, to scheme, to domain name) for determining how the URI should be interpreted.  Also, it sounds like there is still some misconception about the need for a "centralized XRI proxy server".

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,

[1] http://dbooth.org/2006/urn2http/



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.

Received on Friday, 18 July 2008 14:23:24 UTC