[ogsa-wg] [ogsa-naming-wg] ws-naming: Returning an alias-EPI in the referral-fault

[Andrew Grimshaw]

Certainly.

> -----Original Message-----
> From: ogsa-naming-wg-bounces at ogf.org [mailto:ogsa-naming-wg-
> bounces at 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 at ggf.org; 'OGSA WG'; 'Mailing List for OGSA-WG'
> Subject: Re: [ogsa-naming-wg] [ogsa-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 at ogf.org [mailto:ogsa-wg-bounces at ogf.org] On
> Behalf
> >> Of Frank Siebenlist
> >> Sent: Thursday, September 14, 2006 10:24 AM
> >> To: OGSA WG; ogsa-naming-wg at 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 at mcs.anl.gov
> >> The Globus Alliance - Argonne National Laboratory
> >>
> >> --
> >>   ogsa-wg mailing list
> >>   ogsa-wg at ogf.org
> >>   http://www.ogf.org/mailman/listinfo/ogsa-wg
> >>
> >
> > --
> >   ogsa-naming-wg mailing list
> >   ogsa-naming-wg at ogf.org
> >   http://www.ogf.org/mailman/listinfo/ogsa-naming-wg
> >
> >
> 
> --
> Frank Siebenlist               franks at mcs.anl.gov
> The Globus Alliance - Argonne National Laboratory
> 
> --
>   ogsa-naming-wg mailing list
>   ogsa-naming-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-naming-wg