- From: Conor P. Cahill <concahill@aol.com>
- Date: Sat, 8 Oct 2005 08:01:23 -0400
- To: "Pete Hendry" <peter.hendry@capeclear.com>
- cc: "David Hull" <dmh@tibco.com>, "Marc Hadley" <Marc.Hadley@Sun.COM>, public-ws-addressing@w3.org
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 Saturday, 8 October 2005 12:01:16 UTC