- From: <michael.eder@nokia.com>
- Date: Wed, 3 Nov 2004 13:50:58 -0500
- To: <curbera@us.ibm.com>, <Bob.Freund@hitachisoftware.com>
- Cc: <public-ws-addressing@w3.org>
Stated another way, is this not analogues to the MEP question the charter review has already put out of scope for this WG? The same could be said for the lifecycle of EPRs that the resolution will be dependent on the interaction patterns and is therefore out of scope for the Web Services Addressing Working Group whose focus on the addressing mechanism only.
Michael
-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org]On Behalf Of ext Francisco
Curbera
Sent: November 03, 2004 12:31 PM
To: Bob Freund
Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
Subject: Re: Issue 012: EPR Lifetime
It seems clear that one could build not one but many mechanisms for
managing the lifecycle of EPRs. As a general approach I think WS-Addressing
should not endorse a particular one (which one and why?), rather it should
enable other specifications to define their own, so apart from maybe
refining the faults contained in Section 4 I think lifecycle mechanisms
fall outside of the scope of the WG.
Paco
"Bob Freund"
<Bob.Freund@hitachisoftw To: <public-ws-addressing@w3.org>
are.com> cc:
Sent by: Subject: Issue 012: EPR Lifetime
public-ws-addressing-req
uest@w3.org
11/03/2004 07:39 AM
Statement of issue:
At the moment there is no specification of the lifetime of an Endpoint
Reference.
What needs to be decided is:
1) Is there a need to provide a mechanism for management of EPR
lifetime? If yes then what should it do?
2) Or: Is there a need to make some statement concerning an
implied EPR lifetime? If yes then what?
Arguments Against:
1) The web has gone well enough up to now with the tacit
assumption that uri’s live forever.
2) There is nothing like a 404 to indicate that the EPR you
seek has gone missing. The service thus has complete control over
expiration.
3) Much complexity especially in request-response MEPs. A lot
of this complexity will arise from treatment of the case of EPRs
expiring between receipt of request and receipt of response. This
complexity will extend to further complicate all protocols that
permit the use of EPR expiration.
Arguments in Favor:
1) Provides a handy way for the EPR minter to control cache
contents.
General Puzzlements:
1) Would EPRs compare equal if their expiration times were not
equal?
2) If one received a message with an expired EPR in its to:,
whan ought it to be dropped?
3) If one received an expired EPR in its replyto: ought the
message be discarded?
Received on Wednesday, 3 November 2004 18:52:54 UTC