Re: Action Item

+1, I don't like the requirement to include an empty SOAP envelope in  
the 202 reply and note that this is contrary to the WS-I recommendation.

Marc.

On Dec 5, 2005, at 3:11 PM, Anish Karmarkar wrote:

>
> One comment below.
> -Anish
> --
>
> Yalcinalp, Umit wrote:
>
> <snip/>
>
>>  *3.1.2 SOAP 1.1/HTTP Extension Semantics by using  
>> wsaw:UsingAddressing element:*
>>  The presence of the wsaw:UsingAddressing element in the binding  
>> or endpoint (port) components of the endpoint description extends  
>> the semantics of the SOAP 1.1/HTTP binding. In the case of the  
>> WSDL SOAP/HTTP synchronous binding for request-response  
>> operations, the presence of the wsaw:UsingAddressing element  
>> changes the requirement that the response message be sent over the  
>> same HTTP channel over which the request was received. Further,  
>> the presence of the wsaw:Anonymous element may specify how  
>> anonymous addresses are treated specific to an operation defined  
>> in a binding.  Therefore, the wsa:replyTo header in the request  
>> MAY contain an address with a value different from the anonymous  
>> URI when wsaw:UsingAddressing marker is used by extending the  
>> semantics of SOAP1.1/HTTP binding.
>>  Usage of wsaw:UsingAddressing element indicates that SOAP1.1/HTTP  
>> binding is allowed to use a separate connection for sending  
>> response messages, instead of using the same HTTP connection. This  
>> extension allows SOAP 1.1/HTTP to be used asynchronously. Hence,  
>> the response message MAY be sent over the same HTTP channel over  
>> which the request was received or by opening a separate  
>> connection, depending on the following conditions:
>> ·         When the value of the [reply endpoint] in the request  
>> message contains the anonymous URI as its address, the response  
>> MUST be sent over the same HTTP channel. ·         When the value  
>> of [reply endpoint] contains an address that is different than the  
>> anonymous URI, this extension requires that
>> o       The receipt of the request message MUST be acknowledged  
>> with a status message (202) by the receiver using the HTTP  
>> connection that generated the request. The receipt message MUST  
>> contain an empty SOAP envelope. / (Lets discuss this further)/
>
> Why is the empty SOAP Envelope required?
>
> Does empty SOAP envelope mean: no SOAP headers and an empty body?
>
> What seems strange about the empty SOAP envelope is that:
> The MEP (or transmission primitive) says that the exchange is req- 
> res and the requester gets back 2 soap messages (one "empty"  
> envelope sent on the HTTP back channel and the other "real" reply  
> on the ReplyTo EPR). Where is the empty envelope processed? Is it  
> delivered to the App?
>
> Thanks.
>
> -Anish
> --
>
>> o       The actual response MUST be sent using a separate  
>> connection using the address value of the response message  
>> specified by [reply endpoint].
>>  The wsaw:Anonymous element specifies the following semantics for  
>> a specific operation in SOAP1.1/HTTP:
>>  ·         “optional” value indicates the same semantics that is  
>> defined for wsaw:UsingAddressing above, namely anonymous URIs are  
>> allowed, but not required.
>> ·         “required” value indicates that the response message be  
>> sent over the same HTTP channel over which the request was  
>> received. In essence, it indicates requirement for always using  
>> synchronous responses.
>> ·         “prohibited” value indicates that SOAP1.1/HTTP binding  
>> must always use a separate connection for sending response  
>> messages, instead of using the same HTTP connection. In essence,  
>> it indicates requirement for always using asynchronous responses.
>>  /Note: We may consider including a paragraph here as a note to  
>> indicate that SOAP processing rules dictate how responses/errors  
>> are generated and sent to appropriate destinations depending on  
>> when the extensions are processed and engaged following the  
>> discussion in the wg. **/
>> * *
>
> <snip/>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.