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:

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  

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  

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

Thank you all for this progress.

John Bradley

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) <> wrote:
> Hi John,
> > From: John Bradley []
> > [ . . . ]
> > There are actually separate specs for XRI syntax and resolution.
> > This is common with OASIS specs.
> >
> >
> > ntax-V2.0-cs.html
> >
> > 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 [] that  
> makes
> > it more likely to continue running a proxy resolver than the current
> > operators of the XRI Global Registry Service.
> (not 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 (not 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, . . . .
> 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  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 or 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  |
> 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 Monday, 14 July 2008 22:23:12 UTC