- From: David Hull <dmh@tibco.com>
- Date: Mon, 10 Oct 2005 00:49:16 -0400
- To: "Conor P. Cahill" <concahill@aol.com>
- Cc: Pete Hendry <peter.hendry@capeclear.com>, Marc Hadley <Marc.Hadley@Sun.COM>, public-ws-addressing@w3.org
+1, and thanks for putting it much better than I would have. Conor P. Cahill wrote: >Pete Hendry wrote on 10/7/2005, 11:13 PM: > > > > What I am arguing (and Marc too) is that there should be a means to have > > the client automatically get this EPR and use it - a standard mechanism. > > There should not have to be any code on the client to explicitely take > > this EPR, extract the parameters and put them in the next request (if > > that's what it is doing). One approach may be to allow the response to > > contain a wsa:ReplyTo header also (this would also facilitate the case > > where the logon service is the initial point of contact of a site and > > then the client can be redirected once authenticated using the Address > > field of the ReplyTo in the response - but that's getting a bit ahead of > > myself!). > >Well, I think there needs to be a standard way to update/replace >the EPR that the client used to invoke the service. However, in >the case of WSN, this isn't what's happening. The subscription >response is saying something along the lines of "Ok, if you want >to communicate further with respect to *this* subscription, you >need to use this new EPR". > >That is different than saying "From now on, when you communicate >with me, you should use this new EPR". > >I think that both situations are different and that the EPR for >the subscription related information is a application level >message that should be in the body and should be documented >by WSN as it doesn't change further invocations of the interface >that resulted in the subscription. > >I also think it would be good to standardize a method for the >recipient of a message to send back a response that indicates >that the sender should alter the logical EPR used to invoke >the service (change the endpoint, change the reference parameters, >etc.). > >Conor > > > > >
Received on Monday, 10 October 2005 04:49:53 UTC