How should an IMAP4rev2 client associate untagged responses for multiple pipelined IMAP commands?

Question

rfc 9051 defines Multiple Commands in Progress (Command Pipelining)

• pipelining allows the client to send another command without waiting for the completion result response of a command
• IMAP uses tags to uniquely identify each command sent from the client
• IMAP has untagged responses that the server may send eg. one for each message affected

.

How can the IMAP client properly associate such untagged response with any of several pending commands?

• for example, the client may concurrently send multiple identical commands with different arguments and may then possibly receive indistinguishable identical untagged responses
• One legacy imap client broadcasts untagged responses to all pending commands which likely violates integrity mxk Go IMAP 2015
• All other Go clients as of 2024 has proven to be inoperable junk, and there are many, mostly miserable forks of mxk
• Is it so that the server may execute commands in parallel and out of order but sends all responses for one command in an uninterrupted sequence prior to responses to another command?
• The standard only preoccupies with aspects of previous bugs, ie. one command re-sequencing messages, not how concurrency integrity can be guaranteed
• There is always a failure source by multiple concurrent clients using the server so there will never be guaranteed error-free operation

Answer 1

The answer depends on why you want to associate the untagged responses with commands.

The answer to the perhaps most common variant of the question is: Parse the untagged responses as you receive them and store them in RAM as structured information, and when you receive a tagged response, look up the relevant information in that data structure.

For example, if the RFC says that you should've received such-and-such FETCH responses by the time you receive the tagged response to your command (e.g. UID STORE), parse the FETCH messages when they arrive and store the per-message information in a data structure, and when you handle the tagged response, look up the messages in that data structure and return the information from it. You might say that this doesn't associate untagged responses with tagged responses, but rather the information within the untagged responses. Yes. That's right.

This approach works well for all of IMAP except SEARCH.