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

[Andrew Grimshaw]

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