W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2006

Re: Was resolution of CR4 nullified by resolution of CR15?

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

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. 
>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.
>Bob, can we get this to the agenda soon? 
Received on Friday, 17 February 2006 20:32:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:13 UTC