Re: Clarification for WS-RX

Here, then, are two simple resolutions

   1. Close with no action.  Simple.  Done.
   2. Section 5 to read as below.  The rules now apply to any endpoint. 
      Simple.  Done.


        5.1.1 SOAP 1.1/HTTP

When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified for
an endpoint in a request message then there is no change to the SOAP
1.1/ HTTP binding.


        5.1.2 SOAP 1.2

When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified for
an endpoint in the request part of a SOAP request-response message
exchange [SOAP 1.2 Part 2: Adjuncts
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2>],
then any message sent to that endpoint MUST be the response part of the
same SOAP request-response message exchange [SOAP 1.2 Part 2: Adjuncts
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2>].


Yalcinalp, Umit wrote:

>It seems to me we are just making a big deal out of an issue which is
>easily fixed here in WS-A. 
>
>We separate the problem into two separate issues: 
>
>--define the anonymous URI's semantics 
>--define the WS-A MAP semantics for reply endpoint/fault endpoint with
>anonymous value. This wg can provide specific semantics for these two
>MAPs we define which builds on anonymous URI and their relationship to
>MEPs.
>
>Nothing more, nothing less. 
>
>Katy's proposal for CR23 [1] is definitely in the right direction and we
>should fix this problem in this manner, by careful decomposition of the
>problem. 
>
>Intermixing the solution of these two issues and thinking in a very
>restricted sense for the semantics of anonymous is not a good approach.
>As a matter of fact, fusing the two solutions breaks composition for
>other groups. The semantics of Anonymous should not be restricted to
>specific MEPs, but can be further used to define the semantics in
>certain MEPs and WS-A MAPs. Fusing the two prevents the composition, IMO
>and I am weary of the tendency here. 
>
>WS-RX can define the semantics of acksTo (which it owns) based on the
>anonymous URI only. It can crisply define how acksTo can be used in its
>own context and in conjunction with its own protocol exchanges/when it
>is allowed, etc. 
>
>It seems to me that resolving CR23 in this manner, we do not hinder any
>composition, not the other way around. 
>
>--umit
>
>
>[1]
>http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0167.ht
>ml
>
>  
>
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org 
>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of 
>>David Orchard
>>Sent: Wednesday, Feb 22, 2006 8:27 AM
>>To: paul.downey@bt.com; dmh@tibco.com; public-ws-addressing@w3.org
>>Subject: RE: Clarification for WS-RX
>>
>>
>>OTOH, the last thing I want is some profile to crop up that 
>>"fixes" for
>>WS-RX how "broken" WS-A is.  At the end of the day, the stuff is
>>supposed to be composable, etc.
>>
>>Cheers,
>>Dave 
>>
>>    
>>
>>>-----Original Message-----
>>>From: public-ws-addressing-request@w3.org 
>>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of 
>>>paul.downey@bt.com
>>>Sent: Wednesday, February 22, 2006 6:09 AM
>>>To: dmh@tibco.com; public-ws-addressing@w3.org
>>>Subject: RE: Clarification for WS-RX
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>I'm a bit loath to send this to the whole WS-RX list, and I think 
>>>>there are enough WS-RXperts here to answer, so ...
>>>>        
>>>>
>>>but this is Web service addressing and I'm bothered that we 
>>>do seem to keep descending into glorious detail on how WS-RX 
>>>may or may not work, rather than answering tractable LC and 
>>>CR comments from that WG wrt our specifications.
>>>
>>>Paul
>>>
>>>
>>>      
>>>
>>______________________________________________________________
>>_________
>>Notice:  This email message, together with any attachments, 
>>may contain
>>information  of  BEA Systems,  Inc.,  its subsidiaries  and  
>>affiliated
>>entities,  that may be confidential,  proprietary,  
>>copyrighted  and/or
>>legally privileged, and is intended solely for the use of the 
>>individual
>>or entity named in this message. If you are not the intended 
>>recipient,
>>and have received this message in error, please immediately 
>>return this
>>by email and then delete it.
>>
>>
>>    
>>
>
>  
>