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

Anish Karmarkar wrote:

> > (Editorial nit: Could we say "this binding assigns ... for the
> > [destination]." instead of "this specification assigns ... for the
> > [destination] in this binding."?)
>
> Sure.
>
> CR4 was about having the ability for AcksTo (in WSRX) to reuse the
> 'anon' address without having to define new things. Previous
> definition of 'anon' was scoped only to ReplyTo and FaultTo. CR4
> resolved this by saying any EPRType with 'anon' address mean the same
> thing. I don't think your wordings captures that. If I missed it,
> apologies (can you point me to it). Your new text talks about response
> endpoints. I would not call AcksTo a response endpoint.

Two separate issues:

    * The editorial nit was just that the wording seemed verbose.
    * The proposed fix to reconcile CR4 and CR15 was to define
      "underlying response message" that could be used multiple places.

As I understand it, supporting AcksTo requires talking about the
underlying response message.  Giving that message a name and a specific
meaning supports this.  E.g., "anon AcksTo means to use the underlying
response message for acks."  I'm less comfortable with asserting that
anon always means the same thing.  Right now we only define it in one
place, but this may not always be the case.  For example, I believe
Jonathan just mentioned the idea of using anon in the case of a TCP
connection that stays open for multiple requests.

Maybe this will get defined in some note or spec some day and maybe it
won't, but we can't rule it out.  In such a case, anon [destination]
means one thing and anon [reply-to] means another.  Saying that anon
always means the same thing invites confusion and/or disallows
reasonable expansions.  To avoid confusion, we have to define terms
carefully anyway.  That's what I'm trying to do by defining "underlying
response message."

I believe that either approach is consistent with resolving CR4, so I
think this is just a matter of phrasing things clearly as opposed to
re-visiting a closed issue.

>
> -Anish
> -- 
>
> David Hull wrote:
>
>> 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
>>>>
>>>>
>>>>
>>>>   
>>>
>>>
>>>
>>>  
>>>
>>
>