RE: [higgins-dev] RE: About OpenXRI

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Jim, here are some notes from the meeting. Sorry for the delay.

Tony raised two IP-related issues:

1. There is an issue with how the reciprocal licensing clause is worded that
may make it broader than intended. 

2. As it is currently worded, Cordance has the ability to revoke the license
granted at any time, though it must reassign it to another non-profit public
trust for the same purpose. This does not make it completely clear that the
license is irrevocable. 

Drummond said he understood the issues and that neither was the intention of
Cordance or XDI.org. He believed they can be speedily addressed. He has
already arranged for the Cordance and XDI.org general counsels to speak with
the IBM IPR team to discuss the specifics, and they are currently waiting on
Tony to arrange that telecon.

-Paul

________________________________________
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Tuesday, April 03, 2007 11:56 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: RE: [higgins-dev] RE: About OpenXRI

Were there meeting notes posted as a result of this phone call?

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 3/14/07 11:33 AM >>>
Let's have a conf call to discuss this. We've set up this call: 

The dial in number for 2PM PT/ 4PM CT / 5PM ET on Thursday Is 1-641-297-5600
passcode 762425

We're expecting: Mary, Tony, Drummond, possibly an associate of Durmmond's
and me. If more folks wish to call in let me or Mary know and we may have to
regenerate the call with more lines.

-Paul


Tony wrote:
> 
> I guess I have IP issues bringing XRI into Higgins. See the OASIS IPR
> statement for XRI which leads you to
> http://www.xdi.org/docref/legal/xdi-org-ipr-agreement-v2-2004-09-13.html
> 
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> 
> 
> 
>              "Tan, William"
>              <William.Tan@neus
>              tar.biz>                                                   To
>              Sent by:                  Steve Churchill
>              higgins-dev-bounc         <steven.churchill@xxxxxxxxx>
>              es@xxxxxxxxxxx                                             cc
>                                        "'Drummond Reed'"
>                                        <drummond.reed@xxxxxxxxxxxx>,
>              03/09/2007 01:14          "Chasen,  Les"
>              PM                        <les.chasen@xxxxxxxxxxx>, "'Higgins
>                                        \(Trust Framework\) Project
>                                        developer discussions'"
>              Please respond to         <higgins-dev@xxxxxxxxxxx>
>              "Higgins \(Trust                                      Subject
>                 Framework\)            Re: [higgins-dev] RE: About OpenXRI
>              Project developer
>                discussions"
>              <higgins-dev@ecli
>                  pse.org>
> 
> 
> 
> 
> 
> 
> When NeuStar inherited the OpenXRI code from Epok, the server component
> consisted of proxy and resolution server (registry) code. The resolution
> server code, however, has not been updated to XRI resolution working
> draft 11 because of the lack of human resource and there was no audience
> for it (we don't use the resolution server code for the global iname
> registry.) Effectively, the server component distills down to the proxy
> servlet.
> 
> However, should there be interests for the resolution server, we can
> certainly revive (or rewrite) it. In any case, it is somewhere along the
> roadmap.
> 
> =wil
> 
> Steve Churchill wrote:
> >
> > Jim (and Wil),
> >
> > OpenXRI does contain a registry component, but (1) it has fallen out
> > of use and (2) it does not have a persistence mechanism -- the storage
> > interface has only a trivial in-memory implementation. You would need
> > to add a persistent implementation. I have not visited this code for
> > well over a year, so perhaps Wil can add some more comments about it.
> >
> > ~ Steve
> >
> > ------------------------------------------------------------------------
> >
> > *From:* higgins-dev-bounces@xxxxxxxxxxx
> > [mailto:higgins-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Jim Sermersheim
> > *Sent:* Thursday, March 08, 2007 7:22 PM
> > *To:* 'Higgins (Trust Framework) Project developer discussions'
> > *Subject:* [higgins-dev] RE: About OpenXRI
> >
> >
> >
> > One of the proposals is to also allow for a locally-deployed
> > registries.  For that, I assume we'd need the server package.  Or is
> > the server package actually a proxy resolver, and we'd need something
> > else to "serve up" the local registry?
> >
> >
> >
> > Jim
> >
> >
> > >>> "Steve Churchill" <steven.churchill@xxxxxxxxx> 3/8/07 6:52 PM >>>
> >
> > Paul (and Wil),
> >
> > Your XRI resolver client Java code will want to invoke the XRI resolver
> > functional interface defined in Appendix E of the XRI Resolution Spec
> > (WD10.)
> >
> > The OpenXRI resolver client package has a Java binding to this. It can
> be
> > configured to (a) invoke a "local" resolver where the resolver
> > algorithm is
> > performed inside your JVM, or (b) forward the request off to an "HTTP
> > proxy
> > resolver" on another server.
> >
> > Whichever you choose, you will only need the OpenXRI client package
> > and thus
> > you will only need these dependencies. I am sure they are very light.
> >
> > I have Cc'd Wil Tan of Neustar (the author) to shed some more light on
> > this.
> > Wil, what are exactly the client dependencies?
> >
> > Thx,
> >
> > ~ Steve
> >
> > -----Original Message-----
> > From: Paul Trevithick
> >
> > Hi Steven,
> >
> > I don't know if you've been following all this, but Higgins is in the
> > process of re-implementing the IdAS Registries (see [1]). As I
> understand
> > it, Tom of Novell and perhaps others are going to start trying to
> > implement
> > this stuff. And as you can see it depends on xri resolution.
> >
> > In parallel Mary and I are looking at OpenXRI from the point of view of
> > putting together a CQ (Contribution Questionnaire) for Eclipse legal. In
> > doing so I see that the readme says OpenXRI has the following
> > dependencies:
> >
> >    - Apache Xerces (DOM3 for building, DOM2 or DOM3 at runtime)
> >    - Apache Xalan
> >    - Apache XML Security
> >    - Apache Commons Logging
> >    - Apache Log4J
> >    - IBM ICU4J
> >    - JUG
> >    - JUnit (only needed for test classes)
> >    - Java Servlet API (for building, server can be deployed in any
> >                        compliant servlet container)
> >
> > This raises a number of questions. First, from a legal review work
> > minimization point of view, do you think that we need *all* of the
> openxri
> > code (and thus all of the above 3rd party dependencies)? OpenXRI has a
> > number of components (e.g. server, client, etc). Do you think we need
> > all of
> > these?
> >
> > If we do need all of these. We will probably need some help doing the
> > following: (1) tracking down the exact version number of the above 3rd
> > party
> > libraries and comparing those versions with the versions of those
> > components
> > that have already been approved (2) making sure that all of the source
> > files
> > have headers, copyrights, licenses, etc.
> >
> > [1] http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> >
> 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev