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

RE: Issue 012: Recapitulation and proposal draft 1

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Mon, 15 Nov 2004 03:10:56 -0800
Message-ID: <DD35CC66F54D8248B6E04232892B633803F7292E@RED-MSG-43.redmond.corp.microsoft.com>
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 GMT

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