SourceForge : artf3071: (1746) epr-hint removal

Project: OGSA-NAMING-WG Trackers > Naming Comments by Frank > View Artifact

Artifact artf3071 : (1746) epr-hint removal

Tracker:	Naming Comments by Frank
Title:	(1746) epr-hint removal
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. .
Submitted By:	Mark Morgan
Submitted On:	02/08/2006 11:07 AM EST
Last Modified:	07/18/2006 2:57 PM EDT
Closed:	07/18/2006 2:57 PM EDT

	Status / Comments		Change Log		Associations		Attachments

Status
Group: *
Status:*	Closed
Category: *
Customer: *
Priority: *	0
Assigned To: *	Andrew Grimshaw
Reported in Release: *
Fixed in Release: *
Estimated Hours: *	0
Actual Hours: *	0

Comments

Andrew Grimshaw: 07/18/2006 2:57 PM EDT
	Comment:	Done
	Action:	Update Closed set to 07/18/2006 Status changed from Open to Closed

Mark Morgan: 05/01/2006 3:07 PM EDT

Comment:

Frank's Response from Email (28 April 2006)
----------------------------------------------------

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.

Action:

Update

Andrew Grimshaw: 03/16/2006 2:47 PM EST

Comment:

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.

Action:

Update

Andrew Grimshaw: 03/16/2006 2:47 PM EST
	Action:	Update assigned_to changed from 100 to 126

Mark Morgan: 02/08/2006 11:07 AM EST
	Action:	Create

Return

< Previous

Next >