RFC 5162, "IMAP4 Extensions for Quick Mailbox Resynchronization", March 2008

Note: This RFC has been obsoleted by RFC 7162

Errata ID: 3322
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Kundrát
Date Reported: 2012-08-16
Rejected by: Pete Resnick
Date Rejected: 2013-01-28

Section 3.6 says:

A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
or because messages were expunged in other connections (i.e., the
VANISHED response without the EARLIER tag) also decrements the number
of messages in the mailbox; it is not necessary for the server to
send an EXISTS response with the new value.  It also decrements
message sequence numbers for each successive message in the mailbox
(see the example at the end of this section).  Note that a VANISHED
response caused by EXPUNGE, UID EXPUNGE, or messages expunged in
other connections SHOULD only contain UIDs for messages expunged
since the last VANISHED/EXPUNGE response sent for the currently
opened mailbox or since the mailbox was opened.  That is, servers
SHOULD NOT send UIDs for previously expunged messages, unless
explicitly requested to do so by the UID FETCH (VANISHED) command.

Note that client implementors must take care to properly decrement
the number of messages in the mailbox even if a server violates this
last SHOULD or repeats the same UID multiple times in the returned
UID set.  In general, this means that a client using this extension
should either avoid using message numbers entirely, or have a
complete mapping of UIDs to message sequence numbers for the selected
mailbox.

It should say:

A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
or because messages were expunged in other connections (i.e., the
VANISHED response without the EARLIER tag) also decrements the number
of messages in the mailbox; it is not necessary for the server to
send an EXISTS response with the new value.  It also decrements
message sequence numbers for each successive message in the mailbox
(see the example at the end of this section).

Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or
messages expunged in other connections MUST only contain UIDs for
messages expunged since the last VANISHED/EXPUNGE response sent for
the currently opened mailbox or since the mailbox was opened.  That is,
servers MUST NOT send UIDs for previously expunged messages, unless
explicitly requested to do so by the UID FETCH (VANISHED) command.
This is required to prevent a possible race condition where new arrivals
for which the UID is not yet known by the client are expunged.

Notes:

If the servers were allowed to send VANISHED responses referring to non-existing UIDs, there's a possible race condition when new arrivals are expunged. This is due to the sequence-UID assymetry of EXISTS vs. VANISHED.

New arrivals are reported through EXISTS and their UIDs are not known to the client. Suppose the following scenario where two messages exist and their UIDs are 10 and 11. Two more messages arrive:

* 4 EXISTS
* VANISHED 12:20

The client has no way of knowing whether the two new arrivals have UIDs falling into the 12:20 range. As such, the client doesn't know whether there are two, three or four messages in the mailbox at this point.

See http://mailman2.u.washington.edu/pipermail/imap-protocol/2012-June/001781.html for details.
--VERIFIER NOTES--
This is a clear change to the intention of the document and is too large a change to be appropriate to an erratum. There is a problem here, but it is more properly handled by new work, which is being undertaken as http://datatracker.ietf.org/doc/draft-kundrat-qresync-arrived/

Report New Errata