draft-ietf-lemonade-reconnect-client-03.txt   draft-ietf-lemonade-reconnect-client-04.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft D. Cridland Internet-Draft D. Cridland
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: August 30, 2007 C. Wilson Expires: October 28, 2007 C. Wilson
Nokia Nokia
February 26, 2007 April 26, 2007
IMAP4 Extensions for Quick Mailbox Resynchronization IMAP4 Extensions for Quick Mailbox Resynchronization
draft-ietf-lemonade-reconnect-client-03.txt draft-ietf-lemonade-reconnect-client-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2007. This Internet-Draft will expire on October 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines an IMAP4 extension, which gives an IMAP client This document defines an IMAP4 extension, which gives an IMAP client
the ability to quickly resynchronize any previously opened mailbox as the ability to quickly resynchronize any previously opened mailbox as
part of the SELECT command, without the need for server-side state or part of the SELECT command, without the need for server-side state or
additional client round-trips. This extension also introduces a new additional client round-trips. This extension also introduces a new
response that allows for a more compact representation for a list of response that allows for a more compact representation for a list of
expunged messages. expunged messages.
Changes since draft-ietf-lemonade-reconnect-client-03.txt
o Fixed several typos reported by Randy Gellens.
o Fixed a couple of errors in examples and text reported by Dan
Karp.
Changes since draft-ietf-lemonade-reconnect-client-02.txt Changes since draft-ietf-lemonade-reconnect-client-02.txt
o Fixed description of the synchronization sequence to properly o Fixed description of the synchronization sequence to properly
describe how HIGHESTMODSEQ is used. describe how HIGHESTMODSEQ is used.
o Fixed a couple of errors in ABNF. o Fixed a couple of errors in ABNF.
Changes since draft-ietf-lemonade-reconnect-client-01.txt Changes since draft-ietf-lemonade-reconnect-client-01.txt
o Folded the EXPUNGED extension o Folded the EXPUNGED extension
skipping to change at page 4, line 37 skipping to change at page 4, line 37
is opened. In order for the client to discover which messages have is opened. In order for the client to discover which messages have
been expunged, the client still has to issue a UID FETCH or a UID been expunged, the client still has to issue a UID FETCH or a UID
SEARCH command. This document defines an extension to [CONDSTORE] SEARCH command. This document defines an extension to [CONDSTORE]
that allows a reconnecting client to perform full resynchronization, that allows a reconnecting client to perform full resynchronization,
including discovery of expunged messages, in a single round-trip. including discovery of expunged messages, in a single round-trip.
This extension also introduces a new response VANISHED that allows This extension also introduces a new response VANISHED that allows
for a more compact representation for a list of expunged messages. for a more compact representation for a list of expunged messages.
This extension can be useful for mobile clients that can experience This extension can be useful for mobile clients that can experience
frequent disconnects caused by environmental factors (battery life, frequent disconnects caused by environmental factors (battery life,
signal strength, etc.). Such clients would need a way to quickly signal strength, etc.). Such clients need a way to quickly reconnect
reconnect to the IMAP server, without forcing the user to experience to the IMAP server, without forcing the user to experience long delay
long delay and pay big bills for the amount of traffic generated by and pay big bills for the amount of traffic generated by
resynchronization. resynchronization.
By extending the SELECT command to perform the additional By extending the SELECT command to perform the additional
resynchronization, this also allows clients to reduce concurrent resynchronization, this also allows clients to reduce concurrent
connections to the IMAP server held purely for the sake of avoiding connections to the IMAP server held purely for the sake of avoiding
the resynchronization. the resynchronization.
[[anchor4: Note to RFC editor: Please change the capability name [[anchor4: Note to RFC editor: Please change the capability name
everywhere to "QRESYNC".]] everywhere to "QRESYNC".]]
skipping to change at page 6, line 39 skipping to change at page 6, line 39
Example: Attempting to resynchronize INBOX, but the provided Example: Attempting to resynchronize INBOX, but the provided
UIDVALIDITY parameter doesn't match the current UIDVALIDITY UIDVALIDITY parameter doesn't match the current UIDVALIDITY
value. value.
C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000
41,43:211,214:541)) 41,43:211,214:541))
S: * 464 EXISTS S: * 464 EXISTS
S: * 3 RECENT S: * 3 RECENT
S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
S: * OK [UIDNEXT 550] Predicted next UID S: * OK [UIDNEXT 550] Predicted next UID
S: * OK [HIGHESTMODSEQ 20060128194045007] S: * OK [HIGHESTMODSEQ 90060128194045007]
S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UNSEEN 12] Message 12 is first unseen
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags \Deleted \Seen \*)] Permanent flags
S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch
Modification Sequence and UID Parameters: Modification Sequence and UID Parameters:
A server that doesn't support the persistent storage of mod-sequences A server that doesn't support the persistent storage of mod-sequences
for the mailbox MUST send the OK untagged response including the for the mailbox MUST send the OK untagged response including the
skipping to change at page 7, line 33 skipping to change at page 7, line 33
Thus, the client can process just these pending events and need not Thus, the client can process just these pending events and need not
perform a full resynchronization. Without the message sequence perform a full resynchronization. Without the message sequence
number matching information, the result of this step is semantically number matching information, the result of this step is semantically
equivalent to the client issuing: equivalent to the client issuing:
tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE
"mod-sequence-value" VANISHED) "mod-sequence-value" VANISHED)
Example: Example:
C: A02 SELECT INBOX (QRESYNC (67890007 C: A02 SELECT INBOX (QRESYNC (67890007
20060115194045000 41,43:211,214:541)) 90060115194045000 41,43:211,214:541))
S: * 314 EXISTS S: * 314 EXISTS
S: 15 RECENT S: * 15 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 567] Predicted next UID S: * OK [UIDNEXT 567] Predicted next UID
S: * OK [HIGHESTMODSEQ 20060115205545359] S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags \Deleted \Seen \*)] Permanent flags
S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered))
S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent)) S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent))
skipping to change at page 9, line 8 skipping to change at page 9, line 8
In the following two examples, the server is unable to remember In the following two examples, the server is unable to remember
expunges at all, and only UIDs with messages divisible by three are expunges at all, and only UIDs with messages divisible by three are
present in the mailbox. In the first example, the client does not present in the mailbox. In the first example, the client does not
use the fourth parameter, in the second, it provides it. This use the fourth parameter, in the second, it provides it. This
example is somewhat extreme, but shows that judicious usage of the example is somewhat extreme, but shows that judicious usage of the
sequence match data can save a substantial amount of bandwidth. sequence match data can save a substantial amount of bandwidth.
Example: Example:
C: A02 SELECT INBOX (QRESYNC (67890007 C: A02 SELECT INBOX (QRESYNC (67890007
20060115194045000 1:29997)) 90060115194045000 1:29997))
S: * 10003 EXISTS S: * 10003 EXISTS
S: 5 RECENT S: * 5 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 20060115205545359] S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags \Deleted \Seen \*)] Permanent flags
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered))
skipping to change at page 9, line 43 skipping to change at page 9, line 43
S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded))
S: * VANISHED 1:2,4:5,7:8,10:11,13:14 [...] S: * VANISHED 1:2,4:5,7:8,10:11,13:14 [...]
29998:29999,30001:30002,30004:30005,30007:30008 29998:29999,30001:30002,30004:30005,30007:30008
S: A02 OK [READ-WRITE] mailbox selected S: A02 OK [READ-WRITE] mailbox selected
Example: Example:
C: A02 SELECT INBOX (QRESYNC (67890007 C: A02 SELECT INBOX (QRESYNC (67890007
20060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000,
22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991,
29994,29997)) 29994,29997))
S: * 10003 EXISTS S: * 10003 EXISTS
S: 5 RECENT S: * 5 RECENT
S: * OK [UIDVALIDITY 67890007] UIDVALIDITY S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
S: * OK [UIDNEXT 30013] Predicted next UID S: * OK [UIDNEXT 30013] Predicted next UID
S: * OK [HIGHESTMODSEQ 20060115205545359] S: * OK [HIGHESTMODSEQ 90060115205545359]
S: * OK [UNSEEN 7] There are some unseen messages in the mailbox S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)] Permanent flags \Deleted \Seen \*)] Permanent flags
S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered))
skipping to change at page 13, line 44 skipping to change at page 13, line 44
Responses: untagged responses: EXPUNGE or VANISHED Responses: untagged responses: EXPUNGE or VANISHED
Result: OK - expunge completed Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission NO - expunge failure: can't expunge (e.g., permission
denied) denied)
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
This section updates the definition of the UID EXPUNGE command This section updates the definition of the UID EXPUNGE command
described in section 2.1 of [UIDPLUS]. Servers that implement both described in section 2.1 of [UIDPLUS]. Servers that implement both
[UIDPLUS] and X-DRAFT-I02-EXPUNGED extensions must implement UID [UIDPLUS] and X-DRAFT-W02-QRESYNC [[anchor11: change before
EXPUNGE as described in this section. publication]] extensions must implement UID EXPUNGE as described in
this section.
The UID EXPUNGE command permanently removes from the currently The UID EXPUNGE command permanently removes from the currently
selected mailbox all messages that both have the \Deleted flag set selected mailbox all messages that both have the \Deleted flag set
and have a UID that is included in the specified message set. If a and have a UID that is included in the specified message set. If a
message either does not have the \Deleted flag set or has a UID that message either does not have the \Deleted flag set or has a UID that
is not included in the specified message set, it is not affected. is not included in the specified message set, it is not affected.
This command is particularly useful for disconnected mode clients. This command is particularly useful for disconnected mode clients.
By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the
server, the client can avoid inadvertently removing any messages that server, the client can avoid inadvertently removing any messages that
skipping to change at page 16, line 41 skipping to change at page 16, line 41
Message numbers: 1 2 3 4 5 6 7 8 9 10 11 Message numbers: 1 2 3 4 5 6 7 8 9 10 11
UIDs: x 504 505 507 508 x 510 x x x 625 UIDs: x 504 505 507 508 x 510 x x x 625
\Deleted messages: X X X X \Deleted messages: X X X X
In the presence of the extension defined in this document: In the presence of the extension defined in this document:
C: A202 EXPUNGE C: A202 EXPUNGE
S: * VANISHED 505,507,510,625 S: * VANISHED 505,507,510,625
S: A202 OK EXPUNGE completed S: A202 OK EXPUNGE completed
Without the X-DRAFT-W02-QRESYNC [[anchor11: change before Without the X-DRAFT-W02-QRESYNC [[anchor12: change before
publication]] extension the same example might look like: publication]] extension the same example might look like:
C: A202 EXPUNGE C: A202 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 5 EXPUNGE S: * 5 EXPUNGE
S: * 8 EXPUNGE S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed S: A202 OK EXPUNGE completed
(Continuing previous example) If subsequently messages with UIDs 504 (Continuing previous example) If subsequently messages with UIDs 504
and 508 got marked as \Deleted: and 508 got marked as \Deleted:
skipping to change at page 18, line 7 skipping to change at page 18, line 7
can ignore this data. can ignore this data.
4.3. Additional state required on the server 4.3. Additional state required on the server
When compared to the [CONDSTORE] extension, this extension requires When compared to the [CONDSTORE] extension, this extension requires
servers to store additional state associated with expunged messages. servers to store additional state associated with expunged messages.
Note that implementations are not required to store this state in Note that implementations are not required to store this state in
persistent storage, however use of persistent storage is advisable. persistent storage, however use of persistent storage is advisable.
One possible way to correctly implement the extension described in One possible way to correctly implement the extension described in
this document would be to store a queue of <UID set, modsequence> this document is to store a queue of <UID set, modsequence> pairs.
pairs. <UID set> can be represented as a sequence of <min UID, max <UID set> can be represented as a sequence of <min UID, max UID>
UID> pairs. pairs.
When messages are expunged, one or more entry is added to the queue When messages are expunged, one or more entry is added to the queue
tail. tail.
When the server receives a request to return expunged messages since When the server receives a request to return expunged messages since
a given modsequence, it will search the queue from the tail (i.e. a given modsequence, it will search the queue from the tail (i.e.
going from the highest expunged modsequence to the lowest), until it going from the highest expunged modsequence to the lowest), until it
sees the first record with a modsequence less than or equal to the sees the first record with a modsequence less than or equal to the
given modsequence, or it reaches the head of the queue. given modsequence, or it reaches the head of the queue.
skipping to change at page 19, line 11 skipping to change at page 19, line 11
Also note that if the UIDVALIDITY of the mailbox changes or if the Also note that if the UIDVALIDITY of the mailbox changes or if the
mailbox is deleted, then any state associated with expunged messages mailbox is deleted, then any state associated with expunged messages
MUST be deleted as well. MUST be deleted as well.
5. Updated synchronization sequence 5. Updated synchronization sequence
This section updates the description of optimized synchronization in This section updates the description of optimized synchronization in
section 6.1 of the [IMAP-DISC]. section 6.1 of the [IMAP-DISC].
An advanced disconnected mail client should use the X-DRAFT-W02- An advanced disconnected mail client should use the X-DRAFT-W02-
QRESYNC [[anchor17: Fix before publication]] and [CONDSTORE] QRESYNC [[anchor18: Fix before publication]] and [CONDSTORE]
extensions when they are supported by the server. The client would extensions when they are supported by the server. The client uses
use the value from the HIGHESTMODSEQ OK response code received on the value from the HIGHESTMODSEQ OK response code received on mailbox
mailbox opening to determine if it needs to resynchronize. Once the opening to determine if it needs to resynchronize. Once the
synchronization is complete it MUST cache the received value (unless synchronization is complete it MUST cache the received value (unless
the mailbox UIDVALIDITY value has changed; See below). The client the mailbox UIDVALIDITY value has changed; See below). The client
MUST update its copy of the HIGHESTMODSEQ value whenever the server MUST update its copy of the HIGHESTMODSEQ value whenever the server
sends a subsequent HIGHESTMODSEQ OK response code. sends a subsequent HIGHESTMODSEQ OK response code.
The client MUST also take note of any MODSEQ FETCH data items The client MUST also take note of any MODSEQ FETCH data items
received from the server. Whenever the client receives a tagged received from the server. Whenever the client receives a tagged
response to a command, it calculates the highest value among all response to a command, it calculates the highest value among all
MODSEQ FETCH data items received since the last tagged response. If MODSEQ FETCH data items received since the last tagged response. If
this value is bigger than the client's copy of the HIGHESTMODSEQ 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, then the client MUST use this value as its new HIGHESTMODSEQ
value. value.
Note: it is not safe to update client's copy of the HIGHESTMODSEQ 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, 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 because servers are not required to send MODSEQ FETCH data items in
increasing modseqence order. This can lead to client missing some increasing modseqence order. This can lead to the client missing
changes in case of connectivity loss. some changes in case of connectivity loss.
When opening the mailbox for synchronization the client uses QRESYNC When opening the mailbox for synchronization the client uses QRESYNC
parameter to the SELECT/EXAMINE command. The QRESYNC parameter is parameter to the SELECT/EXAMINE command. The QRESYNC parameter is
followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ values, as followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ values, as
known to the client. It can be optionally followed by the set of known to the client. It can be optionally followed by the set of
UIDs, for example if the client is only interested in partial UIDs, for example if the client is only interested in partial
synchronization of the mailbox. The client may also transmit a list synchronization of the mailbox. The client may also transmit a list
containing its knowledge of message numbers. containing its knowledge of message numbers.
If the SELECT/EXAMINE command is successful, the client compares If the SELECT/EXAMINE command is successful, the client compares
skipping to change at page 23, line 13 skipping to change at page 23, line 13
raised by [CONDSTORE] or [RFC3501]. raised by [CONDSTORE] or [RFC3501].
8. IANA Considerations 8. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located IESG approved experimental RFC. The registry is currently located
at: at:
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
This document defines the X-DRAFT-W02-QRESYNC [[anchor21: The final This document defines the X-DRAFT-W02-QRESYNC [[anchor22: The final
capability name will be chosen during AUTH48]] IMAP capability. IANA capability name will be chosen during AUTH48]] IMAP capability. IANA
is requested to add this capability to the registry. is requested to add this capability to the registry.
9. Acknowledgments 9. Acknowledgments
Thanks to Steve Hole, Cyrus Daboo and Michael Wener for encouraging Thanks to Steve Hole, Cyrus Daboo and Michael Wener for encouraging
creation of this document. creation of this document.
Valuable comments, both in agreement and in dissent, were received Valuable comments, both in agreement and in dissent, were received
from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen,
Peter Coates, Mark Crispin and Elwyn Davies. Peter Coates, Mark Crispin, Elwyn Davies and Dan Karp.
This document takes substantial text from [RFC3501] by Mark Crispin. This document takes substantial text from [RFC3501] by Mark Crispin.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005. Syntax Specifications: ABNF", RFC 4234, October 2005.
 End of changes. 24 change blocks. 
32 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/