Re: Boeing XRI Use Cases

Thanks Dave,

This is sounding suspiciously like the start of a workable compromise.

David Booth and I have been batting around some specific refinements  
to Resolution and Syntax, off list that could address this.

As one of the Stewards of the IDTRUST member section at OASIS,  I  
should point out that the XRI-TC operates under RF on Limited Terms.

The relevant OASIS document is:  http://www.oasis-open.org/who/intellectualproperty.php

For those people who belong to OASIS member companies please consider  
joining the XRI-TC this is the simplest way to provide feedback under  
the IPR rules.   This also gives you a vote inside the TC before  
revised specs are put before OASIS as a whole.

For those people wanting to encage in discussions regarding specific  
changes to the Specs, but who are not OASIS members for some reason,  
there is a Feedback License in Appendix A of the IPR document.

Once we get down to the specifics of changes we must consider the IPR  
issues.

If there is concencus on the TAG that this would meet there  
objections, I will personally undertake to move this forward inside  
the XRI-TC with the goal of producing draft changes that could be  
reviewed by the TAG and others before it is put to a committee draft  
vote.

I would hope to involve David Booth and other interested parties in  
drafting the changes inside the TC.

Thank you all for this progress.

Regards
John Bradley
OASIS IDTRUST-SC

On 14-Jul-08, at 2:44 PM, David Orchard wrote:

> My objections would be removed with those 2 changes.
>
> Cheers,
> Dave
>
> On Sat, Jul 12, 2008 at 10:15 PM, Booth, David (HP Software -  
> Boston) <dbooth@hp.com> wrote:
>
> Hi John,
>
> > From: John Bradley [mailto:john.bradley@wingaa.com]
> > [ . . . ]
> > There are actually separate specs for XRI syntax and resolution.
> > This is common with OASIS specs.
> >
> > http://www.oasis-open.org/committees/download.php/15376/xri-sy
> > ntax-V2.0-cs.html
> > http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/x
> > ri-resolution-V2.0-cs-01.html
> >
> > I suspect that you may not have read the resolution spec.
>
> Correct.  Thanks for telling me about it.
>
> >
> > I would point you to Section 11 of the resolution spec that in large
> > measure deals with your suggestion.
>
> I skimmed through it (though not in great detail), and it looks like  
> an effort has been made toward making it implementable over HTTP.   
> And although that sounds like it would benefit your users, it does  
> not address my key concern: the creation of a new URI scheme.
>
> 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?
>
> > [ . . . ]
> > I don't know if there is something special about [purl.org] that  
> makes
> > it more likely to continue running a proxy resolver than the current
> > operators of the XRI Global Registry Service.
>
> Purl.org (not perl.org) is run by OCLC, "a nonprofit membership  
> organization serving more than 69,000 libraries and cultural  
> heritage institutions in 112 countries".  From their site: "OCLC has  
> fiduciary responsibilities of the highest order. We assist our  
> members in organizing and preserving the human record, providing  
> access to it, and passing it on to future generations."
>
> I suggested purl.org (not perl.org) as an example, only because: (a)  
> I know it has credibility in its commitment to maintain persistent  
> URLs; (b) it is widely regarded as a neutral party; and (c) it is  
> the most well-known way to create persistent URLs.  However, the XRI  
> TC could just as well choose something else.
>
> > [ . . . ]
> > If there is some other arrangement for the proxy resolvers operation
> > that would make people more comfortable then we should open that
> > discussion, . . . .
>
> Purl.org only does URL forwarding -- it would not act as an XRI  
> proxy resolver -- but it could *forward* HTTP requests to an XRI  
> proxy resolver.
>
> >
> > If we:
> > 1.  Use http://xri.net/=some-xri  as the scheme for URLs through a
> > proxy resolver.
> > 2.  Use =some-xri as the normal form for native resolution
> > 3.  Stop using xri://=some-xri as a IRI
> >
> > Would this be satisfactory to remove the TAGs objections?
>
> I am not on the TAG, but from my perspective, #3 alone would remove  
> my objections.  My sole objection is the creation of a new URI  
> scheme.  It is not necessary for obtaining the benefits of XRIs, it  
> creates a higher barrier to use that http URI, and it is harmful to  
> the web.
>
> I want to stress that the point of my suggestion to piggyback XRIs  
> on top of http URIs was *not* to suggest that all XRI resolution  
> should go through an HTTP proxy or even use the HTTP protocol.  My  
> points are:
>
> 1. An http URI can still act as an XRI identifier even if the HTTP  
> protocol is not used in resolving it.  XRI-aware software could  
> recognize a http://xri.net/ or http://purl.org/xri/ prefix and use  
> XRI's special resolution rules without using HTTP at all, thus  
> obtaining all of the benefits of XRIs that you value.
>
> 2. An http URI will work better in *other* circumstances, for  
> software that is *not* yet XRI aware or only partially XRI aware,  
> because it can potentially be dereferenced using good old HTTP.   
> Think of http URIs as offering graceful degradation: for software  
> that is not (or only partially) XRI aware, it can *still* get some  
> potentially useful information by dereferencing the URI, wherease  
> with the xri: scheme, the software is *totally* stuck.
>
> > [ . . . ]
> > I believe, and please correct me if I am wrong in my belief
> > from last
> > weeks call that the TAG position is, (I am paraphrasing now):
> > 1. There should be no new URI schemes registered.
> > 2. The http scheme should be the only namespace, to prevent
> > fragmentation.
> >
> > I ask simply is this the bar we must meet?
>
> (Again, speaking for myself -- I am not on the TAG)  Yes.  It is as  
> simple as that.
>
>
>
> 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.
>
>