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.