i always thought that having a separate, specific NOOP operation would
be helpful in such cases [not to be mixed up with NOOP control] because
similar kinda problems tend to surface in various scenarios and while
there are workarounds, they are well, workarounds. some deployments out
there might want to have such operation disabled since it can be abused
by clients, in which case it can have a response defined and servers
can send unwilling to perform or something similar if that is the case.
Hallvard B Furuseth wrote:

Ralf Haferkamp writes:

Btw, you mentioned that sending Abandon 0 will be sufficient as a no-op. How's
that going to work?

It's a no-op, thus it can be sent when you just want to send some message:
* The Abandon request has no reponse.
* rfc4511 §4.11: "Servers MUST discard Abandon requests for messageIDs
they do not recognize, for operations that cannot be abandoned, (...)
* No request may have Message ID 0 (§4.1.1.1); 0 is reserved for
Unsolicited Notifications. Yet Message IDs are just defined as
0..2^^31-1, so abandon(0) is not a protocolError.
Thus abandon(0) is a no-op.
I can imagine some implementation treating it as protocolError anyway
though. It's not as if everyone agrees what the letter of the standard
means, and follow it to the letter.