- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Mon, 15 Nov 2004 03:10:56 -0800
- To: "Francisco Curbera" <curbera@us.ibm.com>, "Bob Freund" <Bob.Freund@hitachisoftware.com>
- Cc: <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
I'm happy with this resolution. Gudge > -----Original Message----- > From: public-ws-addressing-request@w3.org > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > Francisco Curbera > Sent: 09 November 2004 12:09 > To: Bob Freund > Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org > Subject: Re: Issue 012: Recapitulation and proposal draft 1 > > > > > > After the discussion of this issue in yesterday's phone call, > the following > refined resolution was proposed: > > 1) The specification will not define a lifetime/lifecycle model or > mechanism for endpoint references; it will however state that > WS-Addressing > does not prevent lifecycle models for EPRs from being built by other > specifications that use WS-Addressing. > > 2) The specification will explicitly state that the time to > live of an EPR > is not being defined. > > It was agreed to drop 3) from the proposal, based on the > the arguments > that the language is ambiguous, and that its applicability is > limited to > the http binding only. > > Paco > > > > > > > "Bob Freund" > > > <Bob.Freund@hitachisoftw To: > <public-ws-addressing@w3.org> > > are.com> cc: > > > Sent by: > Subject: Issue 012: Recapitulation and proposal draft 1 > > public-ws-addressing-req > > > uest@w3.org > > > > > > > > > 11/04/2004 06:02 PM > > > > > > > > > > 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 providing a lifetime mechanism: > 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. > 4) Timeout option behavior would probably involve > dealing with > clock skew. Though only some specs (like WS-Security) deal with > skew.[DaveO] > 5) Timeout option behavior could inappropriately constrain > derivative works.[DaveO] > 6) Defining a lifetime mechanism in WS-A is > inappropriate in > that such mechanisms are more meaningful at higher protocol or > application levels where behaviors appropriate to need may be > defined.[Paco paraphrased] > 7) Every usage of an potentially expiring EPR > would need to > develop ways of dealing with a whole lot of new exceptions > 8) Not appropriate for an addressing mechanism [MichaelE > paraphrased] > > Arguments in favor of providing a lifetime mechanism: > 1) Provides a handy way for the EPR minter to > control cache > contents. > 2) Potentially better distributed behavior under > ReplyTo/FaultTo with just WS-Addressing[DaveO] > 3) Potential re-use of timeout construct across layered > specifications.[DaveO] > > 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? > 4) Would such a lifetime mechanism encourage > implementers to do > unnatural acts with expiring addresses? > > Proposal: > 1) WS-A will not define a lifetime mechanism for EPRs > 2) EPRs will be considered to live indefinitely. Such > statement shall be made simply in the spec > 3) Error 404 shall be returned for any EPR not > recognized by an > endpoint. Such statement shall be made in in the > faults section of > the spec > > > > > >
Received on Monday, 15 November 2004 13:11:49 UTC