IMAP fetch command race condition on sequence number change

I'm trying to work my way through RFC 3501 to determine what happens when you fetch from sequence number, but a CREATE or EXPUNGE command comes before the response. e.g.

> C: t fetch 32 rfc822.size
> S: * 32 FETCH (RFC822.SIZE 4085)

is easy, but what about:

> C: t fetch 32 rfc822.size
> S: * 12 EXPUNGE
> S: * 32 EXISTS
> S: * 31 FETCH (RFC822.SIZE 4085)

Does the 31 refer to the new sequence number, or the sequence number referenced in the fetch?

Solution

Section 7.4.1 of RFC 3501 specifically contains this language:

  An EXPUNGE response MUST NOT be sent when no command is in
  progress, nor while responding to a FETCH, STORE, or SEARCH
  command.  This rule is necessary to prevent a loss of
  synchronization of message sequence numbers between client and
  server.  A command is not "in progress" until the complete command
  has been received; in particular, a command is not "in progress"
  during the negotiation of command continuation.

This specifically forbids the example. It cannot have been sent unilaterally ("MUST NOT be sent when no command is in progress"), and it could not have been sent as a response to FETCH ("nor while responding to a FETCH, STORE, or SEARCH command").

Also see 5.5 which contains some information about race conditions when multiple commands are in progress. The client is forbidden from sending plain FETCH, STORE, or SEARCH while other types of commands are in progress, and vice versa.