NEW ISSUE, twin sister of i019

I realize that we should probably discuss this new issue in conjunction with i019, i.e. before closing on i019.

(it is stating a similar problem, but for normal termination cases.)

Daniel:

With the perspective of this new issue, I am leaning more toward your proposal to mark as "last" the final sequence status.

Jacques

Title: Accuracy of acknowledgement status upon normal sequence termination

Description: The specification does not address the situation where upon normal

termination of a sequence, some message that were previously sent and never acknowledged

(for which RM Source had stop any resending effort) has been received late by RM Destination,

e.g. between the sending of the last SequenceAcknowledgement and before the reception of

a TerminateSequence message. This is the twin sister of issue i019 which deals with a similar

problem but in case of fault termination.

Justification: Normal termination is actually a fairly common event (compared to sequence fault)

and it is expected that sequences will be terminated even if they have missing messages.

The specification is too lax on the loophole that permits stray messages to

"sneak-in" just before a termination, without any opportunity to be acknowledged.

Target: core

Type: design

Proposal: A final acknowledgement status could be sent back that reflects the exact state

at termination time. That could be done by sending (or by making available for polling

even after the sequence is terminated) a last SequenceAcknowledgement element, at the time

the RM Destination terminates the sequence (either at reception of TerminateSequence,

or due to timeout). Such a SequenceAcknowledgement element should have a "last" marker.

ws-rx message