From: Jim Sermersheim [mailto:jimse@xxxxxxxxxx]
Sent: Wednesday, February 14, 2007 1:11 PM
To: andy.dale@xxxxxxxxx; Paul Trevithick
Cc: steven.churchill@xxxxxxxxx
Subject: RE: IdAS Registry conf call
This looks right to me (as far as I can comprehend). My only reservations is that this will mark some turning points in the Higgins IdAS component:
- This looks like it will add some new requirements for IdAS deployments:
-- Will need an internet connection
-- proxy resolver must be running
- We currently have no dependencies on external projects/libraries
I'm not very concerned with introducing external dependency lib's as long as they'll flow through the eclipse IP process well. I'm much more concerned about the requirements to have access to a non-local HTTP server. Can we end up with a solution that allows us to deploy (if needed) everything on a single machine, with no connectivity to any other machine? It looks to me like it's possible, if the client library is used rather than the proxy resolver. If that's true, is there a benefit in solving this first by using the proxy resolver, and then coding support via the client library later?
Jim
>>> <andy.dale@xxxxxxxxx> 2/14/07 9:10 AM >>>
While you _could_ model it that way that isn't the classic model.... Generally the result of resolving an XRI _can be_ an XRDS.
I think the confusion is this:
When one performs XRI resolution one is generally looking for the service uri and access details (SEP - Service EndPoint) for a specific service type, like OpenID or idAS.registry, etc.
One _can_ execute a 'raw' resolution in which case you will get back an XRDS, that may be the first in a delegation chain. You would then manually process the XRDS to decide if it's terminal or if you have to follow a link to another 'Authority Resolution Service' to resolve the next sub segment of the xri being resolved. Once you have found the final XRDS in the authority resolution chain you have to find the SEP of the type you are looking for and parse out the URI and any other access information that is needed, this can also contain levels of indirection that result in further authority resolution.... XRI resolution spec is _not_ trivial :-) ....
However, the heavy lifting has already been done... There is at least one Java XRI resolution client library available at OpenXRI and there is a 'highly available' proxy resolver that uses a simple http get binding. I believe that both the proxy resolver and the client library implement the functional interface in appendix E of the resolution spec.
You can invoke a method on the interface that simply says... get me the XRDS for this XRI, then you have to do all the stuff I just described. You can invoke a method that says... get me the SEP of _this_ type for _this_ XRI, which returns an XML fragment that is that SEP (having done all of the recursive authority and SEP resolution) .... OR, if all you care about is the URI for the service of the named type there is a call for that as well.
So... I think the recommendation on the table is that for the first step we plan on using the proxy resolver so we will simply resolve an xri directly to the SEP, never looking directly at an XRDS. From what I understand so far of the Higgins idAS use case we are going to want to pull more information about the SEP that _just_ the uri in which case we will use the invocation that returns that entire SEP XML fragment.
I have added Steven Churchill to this thread as he is one of the authors of the XRI resolution spec and he can correct all of the mistakes that I made in this missive :-)
Jim, I look foreword to chatting with you soon so we can get on the same page.
All the best,
Andy Dale
ooTao, Inc.
Phone: 877-213-7935
Fax: 877-213-7935
i-name: =Andy.Dale
http://xri.net/=andy.dale
***************************************************************************
If you don't have an i-name yet use this link to visit one of our partners and buy one:
http://www.ezibroker.net/partners.html
***************************************************************************
|
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
02/14/2007 03:04 AM |
|
To |
"'Jim Sermersheim'" <jimse@xxxxxxxxxx> |
|
cc |
"'Paul Trevithick'" <paul@xxxxxxxxxxxxxxxxx>, <andy.dale@xxxxxxxxx> |
|
Subject |
RE: IdAS Registry conf call |
|
Jim,
One thing to understand is that use of XRI (vs. a plain URL) is optional. If an XRI is used then it must be resolved to a URL first. With or without this resolution step, once you have the URL you do a GET and get the XRDS document.
-Paul
From: Jim Sermersheim [mailto:jimse@xxxxxxxxxx]
Sent: Tuesday, February 13, 2007 5:58 PM
To: andy.dale@xxxxxxxxx
Cc: Paul Trevithick
Subject: Re: IdAS Registry conf call
Hi Andy.
Ok, so it may be that a phone call would be a good way to start -- What time zone are you in?
Where I'm at in this is pretty much ground zero. I've seen Paul's proposal, and have some questions on the wiki (like "does this require HTTP"), but even more simplistically, I need to understand the relationship between an XRI and the specific Service element in the XRDS document. Maybe some examples would be helpful. I assume there's something in the Service element that names the service uniquely among other services. What would that be?
I probably need to get my head around XRI, XRDS, and OpenXRI in general. I've cracked open one of the oasis spec's, but only scratched the surface. I'll keep looking there, and at the javadoc in the three (client, server, and syntax) modules I got from the OpenXRI download. Do you suggest any other resources? Basically, I'm looking for a quick path to understanding how what Paul is proposing will work (from the fabrication of an XRI, to the consumption of the XRDS Service element)
Thanks,
Jim
>>> <andy.dale@xxxxxxxxx> 2/11/07 2:55 PM >>>
Hi Jim,
Good to meet you. I am really excited about being able to contribute to this effort, I will provide whatever knowledge and code I can. Monday I am in back to back meetings most of the day but Tuesday I free up again. I will look at the wiki as soon as I'm able.
Feel free to fire questions at me directly via email for quickest response. We can also schedule some phone time if we need to do some mind melding.
All the best,
Andy Dale
ooTao, Inc.
Phone: 877-213-7935
Fax: 877-213-7935
i-name: =Andy.Dale
http://xri.net/=andy.dale
***************************************************************************
If you don't have an i-name yet use this link to visit one of our partners and buy one:
http://www.ezibroker.net/partners.html
***************************************************************************
|
"Jim Sermersheim" <jimse@xxxxxxxxxx>
02/10/2007 12:02 AM |
|
To |
"'Drummond Reed'" <drummond.reed@xxxxxxxxxxxx>, "'Greg Byrd'" <gbyrd@xxxxxxxx>, "Tom Doman" <TDoman@xxxxxxxxxx>, <andy.dale@xxxxxxxxx>, "'Mary Ruddy'" <mary@xxxxxxxxxxxxx>, "'Valery Kokhan'" <valery@xxxxxxxxxxxxx>, "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> |
|
cc |
"'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx> |
|
Subject |
Re: IdAS Registry conf call |
|
I volunteered to shepherd this issue, and the first thing I did was try to update the wiki with what seemed to be consensus to me at the end of the call. Please review that and comment -- especially on the Out Of Scope Use Cases, TODO items, and Open Issues.
If there are use cases that need to be in scope, I'll move them to the Open Issues section. Unless I was spacing out, we neglected to talk about the TODO solutions.
Andy, Paul said you'd be willing to work on the IdASContextRegistry section of the Wiki, and on its implementation. There may be things that we need to explain more (in terms of requirements), and I also had some questions that you or Paul might be able to answer (search for "questions from Jim"). I'll try to sync up with you on Monday.
Thanks,
Jim
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 2/8/07 10:22 PM >>>
If you're on the "To" line of this email, then I'm expecting you to call in
(a total of 8). I've reserved 10 lines so if we get a couple more, we'll be
okay. I'm assuming this will run 1-1.5 hours.
Comments/Agenda:
* http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal
* Fielding comments, questions about the (optional) XRI resolution
technology (Drummond and Andy are the experts on this)
* Reusable abstract Registry component underneath IdASRegistry and others
* General discussion
Date:
Friday, February 09, 2007
Start Time:
11:00 AM Eastern Std Time
End Time:
12:55 PM Eastern Std Time
Dial-in Number:
1-641-696-6699 (Iowa)
Participant Access Code:
425999
-Paul
