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

Issue 012: Recapitulation and proposal draft 1

From: Bob Freund <Bob.Freund@hitachisoftware.com>
Date: Thu, 4 Nov 2004 18:02:29 -0500
Message-ID: <3587D6FDF44881459313970A8DE75A8101B68DA3@exchange.quadrasis.com>
To: <public-ws-addressing@w3.org>
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 Thursday, 4 November 2004 23:03:00 GMT

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