NEW ISSUE: consistency in controlling the binding of SequenceAcknowledgement and of seq management responses

[Jacques Durand <JDurand@us.fujitsu.com>]

Description

 

The protocol makes it possible to control how SequenceAcknowledgement can be returned to the RMS, w/r to the binding-specific channel of the underlying protocol, via the use of the WS-Addressing anonymous URI in the CreateSequence message (see i061 resolution). However the protocol does not offer any similar control on how the sequence management response messages (CSR, CloseSequenceResponse, and TSR) are making use of the underlying protocol binding-specific channel.

 

 

Justification

The deployment requirements that may lead to return SequenceAcknowledgement  headers

over the back-channel of an underlying 2-way protocol such as HTTP, will also require that sequence management response messages be also returned on the back-channel of the protocol. If not, it will not be possible to satisfy these requirements.

For example, these requirements may be: an RMS may not be able to receive incoming requests due to security restrictions, or to addressing restrictions. It is not consistent - and potentially an interop issue - to address these for Seq-Acks and not for sequence management responses.

 

 

Target: core

 

Proposal:

After, or soon after the addition from i061:

[ When the wsrm:AcksTo EPR specifies  the WS-Addressing anonymous URI as its address, the RMD MUST transmit any wsrm:SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be transmitted on the protocol binding-specific channel. ]

add:

"When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the CreateSequenceResponse MUST also be transmitted by the RMD on the protocol binding-specific channel provided by the context of the CreateSequence message. This MUST also be the case for any response message (CLoseSeqResponse, TerminateSeqResponse) to related sequence management messages that concern the same sequence. "