ACK_TIMER corner cases

[ggallant]

Hey guys, I have two unusual ACK_TIMER response cases I'd like to think are illegal, but the RDM spec doesn't expressly forbid:

1. ACK_TIMER following ACK_OVERFLOW for the same pid

For example:

GET LAMP_HOURS
GET_RESPONSE ACK_OVERFLOW LAMP_HOURS
GET LAMP_HOURS
GET_RESPONSE ACK_TIMER LAMP_HOURS
Is this legal? Has anyone seen or created a responder that does this?
Spec 6.3.2 says:
The responder shall abort a partial transfer of overflow data for a PID when receiving a command for a different PID before the overflow data transfer is complete. A subsequent command for the overflow PID will result in a new data transfer starting at the beginning of the data set.

and Spec 6.3.3 says:
This mechanism allows the controller to [shall] retrieve deferred Get command data by issuing GET QUEUED_MESSAGE
The combination of both of these clauses indicates to me that it's illegal, because the correct controller followup to the ACK_TIMER (GET QUEUED_MESSAGE) would reset the overflow sequence; i.e. the responder would violate 6.3.3 by allowing the partial transfer to continue.

If I'm right, the Spec should expressly state that once a responder returns ACK_OVERFLOW for a given pid, it may not subsequently return ACK_TIMER for that pid until it has returned an ACK/NACK.

2. ACK_TIMER response to GET QUEUED_MESSAGE.

Is this legal? It seems slippery to me, e.g.:

GET QUEUED_MESSAGE
GET_RESPONSE ACK_TIMER LAMP_HOURS

To me, that response says, "responder's ACK_TIMER timeout on the original GET LAMP_HOURS was wrong; it needs more time to respond". Yah, it's hokey, but plausible.

There's also:

GET QUEUED_MESSAGE
GET_RESPONSE ACK_TIMER QUEUED_MESSAGE

This response to me says, "responder needs more time to prepare its queued messages".

Has anyone seen this?

Section 10.3.1 says:
Each QUEUED_MESSAGE response shall be composed of a single message response

I'm not sure what "single message" is supposed to mean.

Aside, and this is just me ranting... since the Spec allows lock-step sequencing, it should have stipulated which sequence patterns are valid. Also, RDM should not have dual-purposed QUEUED_MESSAGE for both change reporting and delayed response. Delayed response should have been handled with a "pending write, latest read" pair common to other SCADA systems. This would have made ACK_TIMER congruent to ACK_OVERFLOW, eliminated the above confusion as to which order and pids are valid for ACK_TIMER, and most importantly, saved controllers from having to flush a queue of (typically unrelated) messages to get to the data they originally asked for.