Re: Issue 012: EPR Lifetime

+1

----- Original Message -----
From: "Francisco Curbera" <curbera@us.ibm.com>
To: "Bob Freund" <Bob.Freund@hitachisoftware.com>
Cc: <public-ws-addressing@w3.org>; <public-ws-addressing-request@w3.org>
Sent: Wednesday, November 03, 2004 5:30 PM
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 Thursday, 4 November 2004 10:13:36 UTC