My understanding of invalid ack is that
the RMD has acknowledged messages that the RMS does not think it has sent, or
is otherwise fubar.
There is not enough information in the
fault for the RMD to discern exactly what was wrong with it, so it is in
possession of an invalid sequence that is different from the state of the
sequence as perceived by the RMS and is not repairable in any protocol defined
This comes close to an unrecoverable
Is the sequence useful any more? I
suggest that the consequence is that the sequence is dead. Continuation
without repair fails to achieve a reliable transfer. There is also the
possibility of an ack/fault loop.
As for sequence closed, closure is fine
with me as long as it says that to be the case. I am chagrinned in that I
assumed it to be the case when working on the state tables but cannot find that
From: Doug Davis
Sent: Thursday, July 27, 2006
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?
"Bob Freund-Hitachi" <firstname.lastname@example.org>
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
fault description deserves elucidation
"wsrm-1.1-spec-wd-15-issue140.pdf" deleted by Doug Davis/Raleigh/IBM]