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

[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=1809

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

Section: 5

Original Text
-------------
   After completing a full synchronization, the client MUST also take
   note of any unsolicited MODSEQ FETCH data items received from the
   server.  Whenever the client receives a tagged response to a command,
   it calculates the highest value among all MODSEQ FETCH data items
   received since the last tagged response.  If this value is bigger
   than the client's copy of the HIGHESTMODSEQ value, then the client
   MUST use this value as its new HIGHESTMODSEQ value.

   Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
   value with a MODSEQ FETCH data item value as soon as it is received
   because servers are not required to send MODSEQ FETCH data items in
   increasing modseqence order.  This can lead to the client missing
   some changes in case of connectivity loss.


Corrected Text
--------------
   After completing a full synchronization, the client MUST also take
   note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ
   response codes received from the server.  Whenever the client receives
   a tagged response to a command, it checks the received unsolicited
   responses to calculate the new HIGHESTMODSEQ value.  If the
   HIGHESTMODSEQ response code is received, the client MUST use it even
   if it has seen higher mod-sequences.  Otherwise, the client calculates
   the highest value among all MODSEQ FETCH data items received since the
   last tagged response.  If this value is bigger than the client's copy
   of the HIGHESTMODSEQ value, then the client MUST use this value as its
   new HIGHESTMODSEQ value.

      Example:    C: A1 STORE 1:3 (UNCHANGEDSINCE 96) FLAGS.SILENT \Seen
                  S: * 1 FETCH (UID 6 MODSEQ (103))
                  S: * 2 FETCH (UID 7 MODSEQ (101))
                  S: * OK [HIGHESTMODSEQ 99] VANISHED reply with
		     MODSEQ 100 is delayed
                  S: A1 OK [MODIFIED 3] done

                  C: A2 STORE 3 +FLAGS.SILENT \Seen
                  S: * 3 FETCH (UID 8 MODSEQ (104))
                  S: A2 OK [HIGHESTMODSEQ 99] Still delaying VANISHED

                  C: A3 NOOP
                  S: * VANISHED 8
                  S: A3 OK [HIGHESTMODSEQ 104] done

   Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
   value with a MODSEQ FETCH data item value as soon as it is received
   because servers are not required to send MODSEQ FETCH data items in
   increasing modseqence order.  Some commands may also delay EXPUNGE
   (or VANISHED) replies with smaller mod-sequences. These can lead to
   the client missing some changes in case of connectivity loss.


Notes
-----
Rationale:

Otherwise clients could lose changes in case of connectivity loss.

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