19 Sep
2006
19 Sep
'06
11:15 p.m.
Certainly. > -----Original Message----- > From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf > Of Frank Siebenlist > Sent: Tuesday, September 19, 2006 7:06 PM > To: Mailing List for OGSA-NAMING-WG > Cc: ogsa-naming-wg@ggf.org; 'OGSA WG'; 'Mailing List for OGSA-WG' > Subject: Re: [ogsa-wg] [ogsa-naming-wg] ws-naming: Returning an alias- > EPI in the referral-fault > > I do not agree with any of the arguments given in your reply. > > Could you please organize that promised telcon such that I have a chance > to make my case. > > Thanks, Frank. > > > Andrew Grimshaw wrote: > > Frank, > > We discussed this in our group this morning - and don't believe that > the > > specification requires any changes to support the use cases. I'll > explain > > below. > > > > > >> -----Original Message----- > >> From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On > Behalf > >> Of Frank Siebenlist > >> Sent: Thursday, September 14, 2006 10:24 AM > >> To: OGSA WG; ogsa-naming-wg@ggf.org > >> Subject: [ogsa-wg] ws-naming: Returning an alias-EPI in the referral- > >> fault > >> > >> I'd like to share two use cases for the return of a alias-EPI a an > >> alternative to returned referral resolver services: > >> > >> * Two EPIs are independently generated for the same resource. > >> If we associate a resource with some bio-object, the it happens that > two > >> different researchers "name" the same object independently from each > >> other. When this is discovered, one needs the option to consolidate > the > >> metadata and policy "underneath" one of those EPIs to lessen the > burden > >> of maintenance and to ensure consistency. A common solution is to > assign > >> a "master-EPI", and to let the other EPIs refer to that master-EPI > when > >> it receives resolution requests. > >> > >> > > [Andrew Grimshaw] > > A couple of things. First, we thought about this and believe that it > is > > really an upper level naming issue - there is a desire to have a human > name > > that is re-mapped to a different entity - the two resources are > DIFFERENT > > resources - the original - and the "new" one. Thus, by remapping an > RNS name > > we can accomplish the goal. > > > > Assuming for the moment that the above does not satisfy your use case > - then > > what you are trying to do is to redirect access to the "old" resource > to the > > "new" resource. Your suggestion was to return a "fault" and a new EPI. > We > > believe that is the wrong approach. Instead an EPR that points to the > new > > "resource" should be minted that still contains the old EPI (if there > was an > > EPI to begin with). Thus, to the client it is still the same resource > -- > > just at a different location. The client does not have to go through > and > > change all of their references to the old EPI at all. This way the > > semantics of what you are trying to accomplish are hidden away in your > > particular implementation - and not exposed at the semantic level. > > > > > >> * Moving metadata management to a different admin domain. > >> When a global naming system and global resolution frameworks are used, > >> like DNS, HandleSystem or LSID, then the EPI's URI will include > >> information about the naming server, i.e. the "prefix". This prefix > in > >> the name is commonly mapped to a real, physical identifier service > that > >> is used to administer the metadata/resolution bindings and such a > server > >> will be part of a certain admin domain. When the > owner/administrator/PI > >> of the individual identifier binding moves/changes-jobs, she often > wants > >> to take the data-objects with her to the new admin domain as well as > the > >> ability to administer the identifier bindings. Unless that user > "owns" a > >> whole prefix, the administration of the identifier has to remain at > the > >> original naming server. This is often not an acceptable solution both > >> for the naming server admin domain as well as the original identifier > >> owner. A common solution is to create a new EPI with a prefix that is > >> maintained in the new admin-domain, and to use that for all the > >> bindings/resolution information, and to add to the original EPI a > >> one-time referral to the new EPI. > >> > >> > >> > > [Andrew Grimshaw] > > I can see where you are coming from - especially having been deeply > involved > > in LSID's. However, the WS-Name spec specifically says that the EPI > should > > be location independent - and that clients should not assume anything > about > > the internal structure (besides it being a URI). Embedding the name of > the > > name server in the prefix is not something that implementations should > count > > on (client implementations; if you're implementation wants to do that > - fine > > - but it should not effect the overall specification.) Remember, that > the > > client can uses any resolver to attempt to resolve the name - they > don't > > have to use the one in the EPR. > > > > > >> The semantics for the referral fault is something like: > >> > >> "The resolver service that was asked for the resolution was unable to > >> provide the caller with the resolution information. However, the > >> resolution service has alternative information returned which the > caller > >> may optionally use to try to resolve." > >> > >> It seems to me that returning a alias-EPI fits very well within the > >> referral fault semantics. Furthermore, the processing of a returned > >> alias-EPI seems completely equivalent to the processing of the > original > >> EPI with some checks for looping and such. > >> > >> Enjoy the F2F without me. > >> > >> Regards, Frank. > >> > >> -- > >> Frank Siebenlist franks@mcs.anl.gov > >> The Globus Alliance - Argonne National Laboratory > >> > >> -- > >> ogsa-wg mailing list > >> ogsa-wg@ogf.org > >> http://www.ogf.org/mailman/listinfo/ogsa-wg > >> > > > > -- > > ogsa-naming-wg mailing list > > ogsa-naming-wg@ogf.org > > http://www.ogf.org/mailman/listinfo/ogsa-naming-wg > > > > > > -- > Frank Siebenlist franks@mcs.anl.gov > The Globus Alliance - Argonne National Laboratory > > -- > ogsa-wg mailing list > ogsa-wg@ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-wg