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

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. "