New proposed issues 9/1 - 9/7

["Marc Goodner" <mgoodner@microsoft.com>]

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 [steve.winkler@sap.com]
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.