NEW ISSUE: Fault handling of piggy-backed Acks

[Daniel Millwood <MILLWOOD@uk.ibm.com>]

Title: If a fault is generated whilst processing a piggy-backed
AckRequested or SequenceAcknowledgement header, should this stop processing
of the entire message?

Description: In Section 3.2 of the spec, it states that 'The
<SequenceAcknowledgment> header block MAY be transmitted independently, or
included on return messages'.  A similar statement is made in Section 3.3,
'The RM Source endpoint requests this Acknowledgment by including an
<AckRequested> header block in the message'.  In both cases, the header can
be piggy-backed on a message going to the relevant endpoint.

If during the processing of this header, a fault occurs, the spec does not
state what should happen.  Consider the case where an AckRequested is
piggy-backed on a non WS-RM message that happens to be going to the correct
endpoint.  If the AckRequested turns out to be for an UnknownSequence, the
spec states that the fault processing should be as per WS-Addressing,
however any EPRs defined in the message are potentially application EPRs
and not WS-RM EPRs, so sending a fault to the applications FaultTo EPR may
not be the correct thing to do.

Justification: The piggy-backing of headers is an optimization and as such,
it is questionable whether their processing should affect the processing of
the original message.  The spec should be clear on the expected behaviour
of the RM Source and the RM Destination in these cases.

Target: core
Type: design

Proposal:  Change the wording of the spec to be along the lines of "If a
fault occurs when processing an RM Header that was piggy-backed on another
message, a fault MUST be generated, but the processing of the original
message MUST NOT be affected.


Thanks,  Dan

WebSphere Platform Development
MP 211
Hursley
Tel. Internal 248617
Tel. External +44 1962 818617
Email. millwood@uk.ibm.com