Subject: [lemonade] [Technical Errata Reported] RFC5162 (3322)

From: RFC Errata System <[email-masked]>
Date: Thu, 16 Aug 2012 07:25:09 -0700 (PDT)

The following errata report has been submitted for RFC5162,
"IMAP4 Extensions for Quick Mailbox Resynchronization".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5162&eid=3322

--------------------------------------
Type: Technical
Reported by: Jan Kundrát <[email-masked]>

Section: 3.6

Original Text
-------------
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.

Corrected Text
--------------
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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5162 (draft-ietf-lemonade-reconnect-client-06)
--------------------------------------
Title               : IMAP4 Extensions for Quick Mailbox Resynchronization
Publication Date    : March 2008
Author(s)           : A. Melnikov, D. Cridland, C. Wilson
Category            : PROPOSED STANDARD
Source              : Enhancements to Internet email to support diverse service environments
Area                : Applications
Stream              : IETF
Verifying Party     : IESG