W3C home > Mailing lists > Public > public-ws-addressing@w3.org > October 2005

Re: Reference Parameters - using them

From: Conor P. Cahill <concahill@aol.com>
Date: Mon, 10 Oct 2005 07:46:13 -0400
To: "Pete Hendry" <peter.hendry@capeclear.com>
cc: public-ws-addressing@w3.org, "David Hull" <dmh@tibco.com>, "Marc Hadley" <Marc.Hadley@Sun.COM>
Message-ID: <434A5485.9030500@aol.com>

Pete Hendry wrote on 10/10/2005, 4:54 AM:

 > I thought I'd mention that the original thrust of my misgivings
 > was the lack of ability for the server to pass back session
 > information as reference parameters for subsequent client
 > calls (the more useful direction in my opinion). The fact
 > that the endpoint address could also be changed wasn't
 > really something I thought of originally but is a nice
 > side-effect.
 > One thing I was not aiming for was the concept of "from now on
 > when you contact me" from the server but rather that the
 > server/service would pass back the EPR in each response. For
 > the former, the client must maintain state over multiple calls
 > to the same service whereas I was just looking for a way to
 > pass an EPR in the response to one request to be used in the
 > next request by that client (not *all subsequent requests*).
 > I think the scope of these approaches is different and what
 > I am asking be consdered for inclusion is the simpler of the two
 > approaches.

I think the difference between "the next request" and "subsequent
requests" is simply a matter of degee and that the server should
be able to control this.   I'm a bit concerned about saying
just "the next request" because of the possibility of multiple
outstanding requests from a client to the server.  What does
the client do when they need to submit a second request before
the server has responded to the first request in this model?

In our world, we see the server applying a TTL on the use of
the replacement data which may or may not coincide with a TTL
elsewhere in the request (such as the TTL in a security token
included in the request).

Received on Monday, 10 October 2005 11:46:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:29 UTC