IMAP fetch command race condition on sequence number change

Question

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?

Answer 1

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.

Answer 2

Your answer should be obvious - for the 31 in the response following the expunge to reference something other than the "current" sequence number 31 message would mean the IMAP server is maintaining an index of sequence numbers for each command-point-in-time. Obviously the IMAP protocol requires no such work on part of the server.

Furthermore note that strictly speaking the untagged responses have nothing to do with the fetch command; the association is merely a suggestion.