Re: Boeing XRI Use Cases

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.

We are now told that:
1.  No new schemes should be registered.
2. That all protocols and transports should use http: URLs for  
addressing to prevent fragmentation of the information space.

Clearly that requires having some way to distinguish between the  
different types of http: URLs that will be required to achieve this  
across multiple protocols.

I admit that this unfortunately requires the URL authority segment to  
not be opaque to applications.
I certainly agree that the authority part of the http URL would need  
to be unambiguous to correctly identify  HXRI encoded XRI's for  
applications that want to do native resolution or other processing  
like XDI.

Having the HXRI begin with https://xri.  was intended as a convenience  
for people who wanted to run there own proxy servers.

In contemplating this change there are a number of things that will  
need to be changed with HXRI resolution and community XRI  
registries.   It will certainly be more than a search and replace  
operation for the XRI-TC if the change is to be made properly to  
everyones satisfaction.

If we take this step and encode all information in the path component  
of a HTTP URL are we still obligated to justify the existence of XRI  
to the W3C TAG?

It is not that we don't have compelling use cases, and unique  
applications.   It is simply that I doubt that any use case could be  
compelling or unique enough to reach the bar that has been referred to  
by the TAG.  Is this bar only applicable only to new URI schemes, or  
anything that proposes to use http URLS for processing things other  
than web pages?

if we must justify XRI being documented as a standard.  We are willing  
to engage in a mutually agreeable education process.

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?

If we must meet some objective standard of utility that the W3C has  
set,  then please provide us with the appropriate documentation  
regarding that standard.   We will endeavor to comply.

If there is a document stating how others like webdav were able to  
navigate this process, perhaps that could be of some help to the XRI-TC.

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.

I can personally see some merit in at least the latter half of the  
above statement.

So how do other TAG members feel?  Independent of the merits of XRI,   
should people use URI schemes to indicate a protocol other than http  
is being used for applications,  or should all applications use or at  
least expose http: scheme urls for addressing, even over alternate  
protocols.

I believe the XRI-TC and others are in need of that answer before we  
can move forward with specifications that are known to be satisfactory.

Regards
John Bradley
OASIS IDTRUST-SC
=jbradley


On 14-Jul-08, at 8:06 PM, Mark Baker wrote:

>
> On 7/13/08, Booth, David (HP Software - Boston) <dbooth@hp.com> wrote:
>> Also, I note in section 11.2, that an HXRI is intended to be  
>> recognizable by starting with "http://xri." (or "https://xri.").   
>> Wouldn't this potentially cause a regular (non-HXRI) URI that  
>> happens to start with that sequence to be erroneously interpreted  
>> as an HXRI?
>
> It would AFAICT, counter to advice from the AWWW[1].  This is why none
> of the suggested fixes, alone or together, address my concerns.
>
> If you're trying to extend the Web in a way that requires providing
> license to agents to extract information from URIs - which appears to
> be a key part of the functionality XRIs are trying to provide (see
> 1.1.1 of xri-syntax) - then you need a new URI scheme.
>
> So I think the discussion of URI schemes for XRIs is pretty much a red
> herring.  What we should, IMO, be talking about, is why http URIs and
> hypermedia weren't used to provide the functionality mentioned in
> 1.1.1.
>
> Cheers,
>
> [1] http://www.w3.org/TR/webarch/#uri-opacity
>
> Mark.
>