- From: David Hull <dmh@tibco.com>
- Date: Fri, 17 Feb 2006 15:31:51 -0500
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, public-ws-addressing@w3.org
- Message-id: <43F632B7.7080603@tibco.com>
The resolution for CR15 says "an anonymous response endpoint in a request refers to the response message" and further delimits this to SOAP1.1/HTTP and SOAP 1.2 request-response. I believe the latest cut at CR18 (what does anonymous [destination] mean, as opposed to CR20, when can it default to what) says "except where you have to have an anonymous [destination] because of the reply rules, we don't say anything about anonymous [destination]." As I understand CR4, WS-RX would like to be able to say "an anonymous acksTo means send acks in the response message to any requests you get". If this is correct, there are a number of potential issues to be worked out with this approach. For example, can I send back acks for one sequence in response to a request for another sequence? To a one-way message? To a request belonging to no sequence at all? Clearly these are out of scope for WSA, but WSA needs to define the terminology for WS-RX to talk about this (or at least it would be helpful if it did). I believe the key requirement here is to be able to send back acks in HTTP responses (in the case of SOAP 1.1/HTTP), SOAP 1.2 responses (in the case of SOAP 1.2) request-response, and maybe in the otherwise-unused response message in a one-way message sent using SOAP 1.2 request-response. I think it might be useful here to define a single term for "the HTTP response message of SOAP 1.1/HTTP or the response message of a SOAP 1.2 request/response." I'll use "underlying response message" for lack of better. I don't think "back-channel" quite works here because we're talking about a message and not a channel. I tried writing the proposed text below using "back-channel' and the result was less direct. Someone else may be able to do better. Given this definition * CR 15 becomes "an anonymous response endpoint in a request refers to the underlying response message" * CR 18 remains pretty much as it is, since it's talking about anonymous in requests, not responses. * CR 4 is resolved by the definition of the term "underlying response message" for other specs to refer to * WS-RX then talks about when and how to use said underlying response message for acks Proposed text (for CR 4 and 15 -- CR 18/20 would have to go in as a separate change): 3.5 Use of Anonymous Address in SOAP In cases where the underlying protocol provides a request-response facility natively, the term /underlying response message/ refers to the response message of this facility. In particular, in the context of SOAP 1.1/HTTP, the underlying response message is simply the HTTP response message. In the context of the SOAP 1.2 request-response MEP [soap 1.2 adjuncts ref], the underlying response message is the response part of the same request-response message exchange as the request. When a response endpoint with "http://www.w3.org/@@@@/@@/addressing/anonymous" as its [address] is used to send a response, this response MUST be sent in the underlying response message. As this is normal behavior for SOAP 1.1/HTTP, the use of such a response endpoint has no effect on the SOAP 1.1/HTTP binding. Note the use of "message exchange" (instance) as opposed to "MEP" (class) in the above. I believe this maintains the resolution to CR 15 and (I hope) allows for WS-RX to talk about using the underlying response message for acks. FWIW, I believe CR 18 can be addressed along the lines of the amalgamated proposal by appending a paragraph like the following, offered as a friendly amendment (the second paragraph is taken directly from Anish's email): When such an anonymous response endpoint is used for a response, the rules in section 3.4 of the WS-Addressing Core dictate that the [destination] property of the response MUST be "http://www.w3.org/@@@@/@@/addressing/anonymous". In this case, the anonymous address refers to the use of the underlying response message. Outside of this usage, this specification assigns no particular semantics to the use of "http://www.w3.org/@@@@/@@/addressing/anonymous" for the [destination] property in this binding. (Editorial nit: Could we say "this binding assigns ... for the [destination]." instead of "this specification assigns ... for the [destination] in this binding."?) Yalcinalp, Umit wrote: > > > > >>-----Original Message----- >>From: public-ws-addressing-request@w3.org >>[mailto:public-ws-addressing-request@w3.org] On Behalf Of >>Anish Karmarkar >>Sent: Monday, Feb 13, 2006 5:16 PM >>To: public-ws-addressing@w3.org >>Subject: Was resolution of CR4 nullified by resolution of CR15? >> >> >>While working on the 'amalgamated proposal' for CR20, I >>realized that we >>removed the text that we added/changed for CR4 [1], as a >>resolution of >>CR15 [2]. Is that correct, or am I just looking at the incorrect ed. >>versions? >> >> > >It seems to me that this is an oversight and we did not see how the >resolutions will trip into each other. > > > > > >>The resolution for CR4 is quite important for WSRX (to allow >>things like >>AcksTo with 'anon' address.) >> >> > >Yes, this is why I reported this in the first place. Thanks for catching >it! I like the original wording which got discarded and we need to >retain the definition. > > > >>If I'm looking at the right version and >>this wasn't inadvertent, then I would like to raise an issue >>to add the >>resolution of CR4 back in the SOAP binding spec. >> >>{perhaps this is what Bob/Marc were asking about regd. issue >>CR15 on the >>call -- the 'such as/example' that was missing} >> >> > >I agree that we have a problem here. Probably we need to define >"response endpoint" and build the semantics into the defn appropriately. > > > > > >>-Anish >>-- >> >> > >Bob, can we get this to the agenda soon? > >--umit > > > >>[1] >>http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0111 >>[2] >>http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0085 >> >> >> >> >> > > > >
Received on Friday, 17 February 2006 20:32:18 UTC