- 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