+1 for InvalidAck.
The behavior on reception of such an error
could be configurable based on some policy (out of scope).
This error should actually cover more than
just the “cumulative ack invariants” (which I assume are those stated
in 2.3 Protocol invariants)
“Reason” should be: violate
the invariants stated in 2.3 OR any of the requirements in 3.6 about
valid combinations of AckRange, Nack and None in a single SequenceAcknowledgement
element or w/r to already received such elements.
Upon Receipt, the RMS should close on its
side . Do NOT terminate: It could be that the seq was closed by RMD but the RMS
did not get the notice, in which case it still wants a chance to get the final
From: Doug Davis
Sent: Thursday, July 27, 2006 8:21
To: Bob Freund-Hitachi
Subject: Re: [ws-rx] proposal to
address issue 140
for InvalidAck - should it really close the sequence? Since Acks are just
informational I'm not so sure they should initiate the closing down of a
sequence even when they have bad data - I'd prefer to let the receiver of the
InvalidAck fault make that decision for itself ( see 5.1.3).
for seqClosed - I don't think the "action upon receipt" should be to
terminate - I think 'close' would be more appropriate.
- there were changes to the expires text in the pdf - I'm assuming those were
left over from other other work and not related to this, right?
07/27/2006 05:59 AM
[ws-rx] proposal to address issue 140
Anish has been kind enough to prepare the attached draft proposal to
address issue 140.
preparing this draft, some additional points were raised which we enumerate
is no text that details under what conditions a sequence terminated fault might
be raised other than mention of a vague “protocol error”.
way to address this is to list some or all of the conditions in section 4, however
it is more concise to represent these in the state tables of appendix D were
fault description deserves elucidation
"wsrm-1.1-spec-wd-15-issue140.pdf" deleted by Doug Davis/Raleigh/IBM]