W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

Re: Issue 012: Recapitulation and proposal draft 1

From: Francisco Curbera <curbera@us.ibm.com>
Date: Tue, 9 Nov 2004 07:08:47 -0500
To: "Bob Freund" <Bob.Freund@hitachisoftware.com>
Cc: public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OF56AF0FA7.74E5CA56-ON85256F46.00761383-85256F47.0042B98B@us.ibm.com>




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 Tuesday, 9 November 2004 12:08:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT