Re: Boeing XRI Use Cases

Hi John,

I suspect you're asking a lot of questions here to the TAG, rather
than specifically to myself, so forgive me for just responding to
those questions that I feel I'm in a position to respond to.

On 7/15/08, John Bradley <> wrote:
> Hi Mark,
> If we were to proceed with David's recommendation to remove the xri: scheme
> from the spec and use the HXRI form for web compatibility through a proxy,
> then we would need some way for XRI aware applications to recognize what the
> actual protocol of a http scheme URL is.   We are open to finding the
> optimal way to achieve this.
> We had been operating under the impression that the scheme of a URI was
> designed to do that.
> This we are told is outdated information.

No, you were correct to use a new URI scheme.

Just because new URI schemes are more often than not a bad idea,
doesn't mean one should standardize a way to replace URI-scheme
functionality elsewhere in the syntax of a URI.

IMO, the advice you've been given to avoid new URI schemes should have
been rephrased to make it clearer where the problem was.  The advice
should have been to try and solve the problems that XRIs are intended
to solve using http URIs (without additional license ala HXRIs).

> I ask, are all protocols and transports that are requested to use the http
> scheme going to be subjected to the same level of scrutiny?

Absolutely.  The bar is pretty high over on uri-review, where we
regularly have to educate folks about the value of reusing existing
schemes such as http.

> Just for my clarification, is your position that, if XRI can be shown to
> meet certain standards of utility it should register the xri: scheme? This
> will allow the authority segment of the http scheme to remain opaque.


Mark Baker.  Ottawa, Ontario, CANADA.
Coactus; Web-inspired integration strategies

Received on Tuesday, 15 July 2008 05:05:21 UTC