DDSIRTP23 — Semantics of AckNack's Final Flag

Users found that OpenDDS and CoreDX did not interoperate due to different interpretations of the Final Flag in AckNack.

The use of FinalFlag in Heartbeat is pretty clear, but its extension to AckNack seems to be under-specified.

This section tells us little:

The FinalFlag indicates whether a response by the Writer is expected by the Reader or if the decision is left to the Writer. The use of this flag is described in 8.4.

That last sentence is unhelpful as section 8.4 takes up about 60 pages. Searching through 8.4 results in very little about the AckNack's Final Flag.

The key question is what is meant by "response by the Writer". Considering AckNacks that are both Final and have at least one "1" bit in the bitmap, is the Writer obligated to send the nacked DATA?

a. One interpretation is that the Final Flag is a simple (constant-time) indication that the Writer need not resend DATA even with a "1" in the bitmap – in this scenario the Writer need not even read the bitmap. The AckNack is still useful because the bitmapBase can bump up the acknowledge sequence number.

b. The other interpretation is that the presence of a "1" in the bitmap overrides the Final flag and the Writer must reply with DATA. In this interpretation the Final flag is used to indicate whether or not another HEARTBEAT is sent "soon" (instead of waiting for periodic heartbeat), but has no impact on sending DATA.

Clarify the meaning of the ACKNACK Final Flag

The description of the ACKNACK final flag is not clear as to what is the expected behavior. The description needs to be updated to make clear that the absence of the Final Flag requires that the Writer send a HB and the presence of the flag leaves the decision up to the Writer.