[lemonade] [Technical Errata Reported] RFC5162 (1808)

[RFC Errata System <rfc-editor at rfc-editor.org>]

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=1808

--------------------------------------
Type: Technical
Reported by: Timo Sirainen <tss at iki.fi>

Section: 3.4

Original Text
-------------
   If at least one message got expunged, the server MUST send
   the updated per-mailbox modification
   sequence using the HIGHESTMODSEQ response code (defined in
   [CONDSTORE]) in the tagged OK response.

      Example:    C: A202 CLOSE
                  S: A202 OK [HIGHESTMODSEQ 20010715194045319] done


Corrected Text
--------------
   The server MUST NOT send the updated per-mailbox modification
   sequence using the HIGHESTMODSEQ response code (defined in
   [CONDSTORE]) in the tagged OK response, as this might cause loss of
   synchronization on the client.

      Example:    C: A202 CLOSE
                  S: A202 OK done


Notes
-----
Rationale:

The HIGHESTMODSEQ can't be used reliably unless server sends to client all changes done by other clients. Even then it's difficult for both clients and servers to implement this. For example:

C1: 2 STORE 1 +FLAGS.SILENT \Deleted
S1: * 1 FETCH (MODSEQ 1)
S1: 2 OK

C2: 1 STORE 2 +FLAGS.SILENT \Deleted
S1: * 2 FETCH (MODSEQ 2)
S2: 1 OK

C1: 3 CLOSE
S1: 3 [HIGHESTMODSEQ 3]

The client probably thought that only message 1 was expunged, so it
doesn't register the second expunge. And it probably never will if it
uses QRESYNC to find out only about new expunges.

And even worse example would be if the second client had also removed
the \Deleted flag from message 1. Then the first client would have
registered wrong message to be expunged.

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