Subject: New proposed issues 9/1 - 9/7
proposed-01 Title: Processing model of NACKs Description: Although it is assumed that a NACK will trigger retransmission of a given message from the source to the destination there is no wording in the current version of the spec that describes this feature adequately. Justification: This will clarify to implementers the spirit of the spec by spelling out in more concrete terms what is currently only implied. Origin: Steve Winkler [firstname.lastname@example.org] Target: Core Type: Design Proposal: Add the following to the spec directly before the text that is incorporated as a resolution to i005: Upon the receipt of a Nack, an RM Source SHOULD retransmit the message identified by the Nack as soon as possible. proposed-02 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. Origin: Daniel Millwood [MILLWOOD@uk.ibm.com] 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.