Re: Boeing XRI Use Cases

Hi Mark,

I forgot that you aren't on the TAG yourself.  So you are correct my  
questions were mostly directed at them.

We do honestly believe that the syntax and resolution of XRI have  
unique and valuable properties not easily achieved by the conventional  
use of http: URLs.

We also have no interest in fragmenting the information space.  Our  
goal is to open up more information to the web.

We can solve our problems using http: URLs via HXRI encoding of XRI's  
and proxy servers.
In this case a proxy server is really just another web app that  
processes input and returns the appropriate XRDS, or other document.

Applications like XDI that make use of XRI syntax to retrieve  fine  
grained structured data via field level access control can use either  
XRI-Normal form or HXRI internally as is appropriate.

Currently XRI-Normal form is the only way to use UTF-8 in openID.
I am pushing for http: scheme IRI to become part of the next openID  
spec,  but that will take time.

I think we could justify a xri: scheme,  but I am not interested in  
investing years in a debate.  In the end users will find XRI in  
whatever form useful or not.  It will become part of the established  
infrastructure or disappear with gopher and other less useful things.

The goal of the XRI 2.0 spec is to document how people who want to use  
XRI can interoperate and guarantee Royalty Free use.   No one will be  
forced to use it because the spec exists.  Those of us who have a need  
for it will be free to do so based on a documented spec.

The XRI-TC is willing to accommodate concerns and incorporate feedback.

We however cannot do mutually exclusive things simultaneously.

We have defined HXRI and the XRI scheme in XRI 2.0.

If we have to give up one of them I would choose to give up the xri:  
scheme.

I believe that HXRI is the more useful of the two.  Though I wish we  
could keep both.

HXRI will need some tweaking as a result but that is not the end of  
the world.

I would like to resolve this one way or the other as quickly as  
possible so that we can all move on with more productive work.

Do you have a proposal on how we would proceed if we were to attempt  
to get xri: as a scheme.

If there is some sort of action plan we could develop for taking that  
path it would be worth throwing into the mix.

Always good to hear from a fellow Canuck.

Best Regards
John Bradley
OASIS IDTRUST-SC
=jbradley

On 14-Jul-08, at 10:04 PM, Mark Baker wrote:

> 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 <john.bradley@wingaa.com> 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.
>
> Yes.
>
> Mark.
> -- 
> Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
> Coactus; Web-inspired integration strategies  http://www.coactus.com