|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
|
|
[Technical Errata Reported] RFC5162 (1809)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@...> 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 _______________________________________________ lemonade mailing list lemonade@... https://www.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade |
| Free embeddable forum powered by Nabble | Forum Help |