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

[Frank Siebenlist]

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