Summary: #1746 epr-hint removal Tracker: Naming Comments by Frank Description: remove the optional parameter "epr-hint" for the renewable reference because its use and associated semantics is very confusing and doesn't add functionality. If the resolver can make use of additional information in the original EPR, then the renewable reference minter can add that to the RR-EPR's Address and/or ReferenceParameters. In other words, there is no point in putting the burden on the client to "guess" whether it makes sense to communicate the original EPR or not, because the minter can do it much better. Furthermore, the burden is still on the client to verify whether the reply is a new EPR or not. Andrew Grimshaw (2006-03-16 13:47:33) I'd rather not remove it. In our experience with an earlier re-resolution scheme it is very useful to know which EPR the client has already tried ... because if they just tried an EPR and it did not work, why give them exactly the same one back? Instead, you want to give them another, "fresher" one if one is available. For example, suppose my resolution service is really a binding cache, binding abstratnames to EPR's - or if i am not using abstract names to id services, whatever i am using in the EPR to id services. Clients use the cache service to get bindings. If they don't pass in the binding they used - they may get the same one back. Frank: Please read my comment again... the epr-minter of the renewable reference EPR can embed information about the EPR in which it was embedded. Furthermore, as the client cannot compare the EPR that is returned with its cache of already used EPRs, and because the client doesn't know whether it deals with a "smart" or "dumb" resolution service, it can only just try and give up after a number of attempts if it doesn't work. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory