1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc5162.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,1291 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                        A. Melnikov
    1.11 +Request for Comments: 5162                                   D. Cridland
    1.12 +Category: Standards Track                                      Isode Ltd
    1.13 +                                                               C. Wilson
    1.14 +                                                                   Nokia
    1.15 +                                                              March 2008
    1.16 +
    1.17 +
    1.18 +          IMAP4 Extensions for Quick Mailbox Resynchronization
    1.19 +
    1.20 +Status of This Memo
    1.21 +
    1.22 +   This document specifies an Internet standards track protocol for the
    1.23 +   Internet community, and requests discussion and suggestions for
    1.24 +   improvements.  Please refer to the current edition of the "Internet
    1.25 +   Official Protocol Standards" (STD 1) for the standardization state
    1.26 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.27 +
    1.28 +Abstract
    1.29 +
    1.30 +   This document defines an IMAP4 extension, which gives an IMAP client
    1.31 +   the ability to quickly resynchronize any previously opened mailbox as
    1.32 +   part of the SELECT command, without the need for server-side state or
    1.33 +   additional client round-trips.  This extension also introduces a new
    1.34 +   response that allows for a more compact representation of a list of
    1.35 +   expunged messages (and always includes the Unique Identifiers (UIDs)
    1.36 +   expunged).
    1.37 +
    1.38 +
    1.39 +
    1.40 +
    1.41 +
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Melnikov, et al.            Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
    1.64 +
    1.65 +
    1.66 +Table of Contents
    1.67 +
    1.68 +   1.  Introduction and Overview  . . . . . . . . . . . . . . . . . .  2
    1.69 +   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
    1.70 +   3.  IMAP Protocol Changes  . . . . . . . . . . . . . . . . . . . .  4
    1.71 +     3.1.  QRESYNC Parameter to SELECT/EXAMINE  . . . . . . . . . . .  4
    1.72 +     3.2.  VANISHED UID FETCH Modifier  . . . . . . . . . . . . . . .  8
    1.73 +     3.3.  EXPUNGE Command  . . . . . . . . . . . . . . . . . . . . . 10
    1.74 +     3.4.  CLOSE Command  . . . . . . . . . . . . . . . . . . . . . . 11
    1.75 +     3.5.  UID EXPUNGE Command  . . . . . . . . . . . . . . . . . . . 11
    1.76 +     3.6.  VANISHED Response  . . . . . . . . . . . . . . . . . . . . 12
    1.77 +     3.7.  CLOSED Response Code . . . . . . . . . . . . . . . . . . . 15
    1.78 +   4.  Server Implementation Considerations . . . . . . . . . . . . . 15
    1.79 +     4.1.  Server Implementations That Don't Store Extra State  . . . 15
    1.80 +     4.2.  Server Implementations Storing Minimal State . . . . . . . 16
    1.81 +     4.3.  Additional State Required on the Server  . . . . . . . . . 16
    1.82 +   5.  Updated Synchronization Sequence . . . . . . . . . . . . . . . 17
    1.83 +   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 19
    1.84 +   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
    1.85 +   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
    1.86 +   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
    1.87 +   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    1.88 +     10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
    1.89 +     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
    1.90 +
    1.91 +1.  Introduction and Overview
    1.92 +
    1.93 +   The [CONDSTORE] extension gives a disconnected client the ability to
    1.94 +   quickly resynchronize IMAP flag changes for previously seen messages.
    1.95 +   This can be done using the CHANGEDSINCE FETCH modifier once a mailbox
    1.96 +   is opened.  In order for the client to discover which messages have
    1.97 +   been expunged, the client still has to issue a UID FETCH or a UID
    1.98 +   SEARCH command.  This document defines an extension to [CONDSTORE]
    1.99 +   that allows a reconnecting client to perform full resynchronization,
   1.100 +   including discovery of expunged messages, in a single round-trip.
   1.101 +   This extension also introduces a new response, VANISHED, that allows
   1.102 +   for a more compact representation of a list of expunged messages.
   1.103 +
   1.104 +   This extension can be useful for mobile clients that can experience
   1.105 +   frequent disconnects caused by environmental factors (battery life,
   1.106 +   signal strength, etc.).  Such clients need a way to quickly reconnect
   1.107 +   to the IMAP server, while minimizing delay experienced by the user as
   1.108 +   well as the amount of traffic (and hence the expense) generated by
   1.109 +   resynchronization.
   1.110 +
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Melnikov, et al.            Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.120 +
   1.121 +
   1.122 +   By extending the SELECT command to perform the additional
   1.123 +   resynchronization, this also allows clients to reduce concurrent
   1.124 +   connections to the IMAP server held purely for the sake of avoiding
   1.125 +   the resynchronization.
   1.126 +
   1.127 +   The quick resync IMAP extension is present if an IMAP4 server returns
   1.128 +   "QRESYNC" as one of the supported capabilities to the CAPABILITY
   1.129 +   command.
   1.130 +
   1.131 +   Servers supporting this extension MUST implement and advertise
   1.132 +   support for the [ENABLE] IMAP extension.  Also, the presence of the
   1.133 +   "QRESYNC" capability implies support for the [CONDSTORE] IMAP
   1.134 +   extension even if the CONDSTORE capability isn't advertised.  A
   1.135 +   server compliant with this specification is REQUIREd to support
   1.136 +   "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE
   1.137 +   enabling commands", as defined in [CONDSTORE], and have identical
   1.138 +   results), but there is no requirement for a compliant server to
   1.139 +   support "ENABLE CONDSTORE" by itself.  The "ENABLE QRESYNC"/"ENABLE
   1.140 +   QRESYNC CONDSTORE" command also tells the server that it SHOULD start
   1.141 +   sending VANISHED responses (see Section 3.6) instead of EXPUNGE
   1.142 +   responses.  This change remains in effect until the connection is
   1.143 +   closed.
   1.144 +
   1.145 +   For compatibility with clients that only support the [CONDSTORE] IMAP
   1.146 +   extension, servers SHOULD advertise CONDSTORE in the CAPABILITY
   1.147 +   response as well.
   1.148 +
   1.149 +   A client making use of this extension MUST issue "ENABLE QRESYNC"
   1.150 +   once it is authenticated.  A server MUST respond with a tagged BAD
   1.151 +   response if the QRESYNC parameter to the SELECT/EXAMINE command or
   1.152 +   the VANISHED UID FETCH modifier is specified and the client hasn't
   1.153 +   issued "ENABLE QRESYNC" in the current connection.
   1.154 +
   1.155 +   This document puts additional requirements on a server implementing
   1.156 +   the [CONDSTORE] extension.  Each mailbox that supports persistent
   1.157 +   storage of mod-sequences, i.e., for which the server has sent a
   1.158 +   HIGHESTMODSEQ untagged OK response code on a successful SELECT/
   1.159 +   EXAMINE, MUST increment the per-mailbox mod-sequence when one or more
   1.160 +   messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the
   1.161 +   server MUST associate the incremented mod-sequence with the UIDs of
   1.162 +   the expunged messages.
   1.163 +
   1.164 +   A client that supports CONDSTORE but not this extension might
   1.165 +   resynchronize a mailbox and discover that its HIGHESTMODSEQ has
   1.166 +   increased from the value cached by the client.  If the increase is
   1.167 +   only due to messages having been expunged since the client last
   1.168 +   synchronized, the client is likely to send a FETCH ...  CHANGEDSINCE
   1.169 +   command that returns no data.  Thus, a client that supports CONDSTORE
   1.170 +
   1.171 +
   1.172 +
   1.173 +Melnikov, et al.            Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.176 +
   1.177 +
   1.178 +   but not this extension might incur a penalty of an unneeded round-
   1.179 +   trip when resynchronizing some mailboxes (those that have had
   1.180 +   messages expunged but no flag changes since the last
   1.181 +   synchronization).
   1.182 +
   1.183 +   This extra round-trip is only incurred by clients that support
   1.184 +   CONDSTORE but not this extension, and only when a mailbox has had
   1.185 +   messages expunged but no flag changes to non-expunged messages.
   1.186 +   Since CONDSTORE is a relatively new extension, it is thought likely
   1.187 +   that clients that support it will also support this extension.
   1.188 +
   1.189 +2.  Requirements Notation
   1.190 +
   1.191 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   1.192 +   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   1.193 +   document are to be interpreted as described in [RFC2119].
   1.194 +
   1.195 +   In examples, "C:" and "S:" indicate lines sent by the client and
   1.196 +   server respectively.  If a single "C:" or "S:" label applies to
   1.197 +   multiple lines, then the line breaks between those lines are for
   1.198 +   editorial clarity only and are not part of the actual protocol
   1.199 +   exchange.  The five characters [...] means that something has been
   1.200 +   elided.
   1.201 +
   1.202 +   Understanding of the IMAP message sequence numbers and UIDs and the
   1.203 +   EXPUNGE response [RFC3501] is essential when reading this document.
   1.204 +
   1.205 +3.  IMAP Protocol Changes
   1.206 +
   1.207 +3.1.  QRESYNC Parameter to SELECT/EXAMINE
   1.208 +
   1.209 +   The Quick Resynchronization parameter to SELECT/EXAMINE commands has
   1.210 +   four arguments:
   1.211 +
   1.212 +   o  the last known UIDVALIDITY,
   1.213 +
   1.214 +   o  the last known modification sequence,
   1.215 +
   1.216 +   o  the optional set of known UIDs, and
   1.217 +
   1.218 +   o  an optional parenthesized list of known sequence ranges and their
   1.219 +      corresponding UIDs.
   1.220 +
   1.221 +   A server MUST respond with a tagged BAD response if the Quick
   1.222 +   Resynchronization parameter to SELECT/EXAMINE command is specified
   1.223 +   and the client hasn't issued "ENABLE QRESYNC" in the current
   1.224 +   connection.
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Melnikov, et al.            Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.232 +
   1.233 +
   1.234 +   Before opening the specified mailbox, the server verifies all
   1.235 +   arguments for syntactic validity.  If any parameter is not
   1.236 +   syntactically valid, the server returns the tagged BAD response, and
   1.237 +   the mailbox remains unselected.  Once the check is done, the server
   1.238 +   opens the mailbox as if no SELECT/EXAMINE parameters are specified
   1.239 +   (this is subject to processing of other parameters as defined in
   1.240 +   other extensions).  In particular this means that the server MUST
   1.241 +   send all untagged responses as specified in Sections 6.3.1 and 6.3.2
   1.242 +   of [RFC3501].
   1.243 +
   1.244 +   After that, the server checks the UIDVALIDITY value provided by the
   1.245 +   client.  If the provided UIDVALIDITY doesn't match the UIDVALIDITY
   1.246 +   for the mailbox being opened, then the server MUST ignore the
   1.247 +   remaining parameters and behave as if no dynamic message data
   1.248 +   changed.  The client can discover this situation by comparing the
   1.249 +   UIDVALIDITY value returned by the server.  This behavior allows the
   1.250 +   client not to synchronize the mailbox or decide on the best
   1.251 +   synchronization strategy.
   1.252 +
   1.253 +   Example: Attempting to resynchronize INBOX, but the provided
   1.254 +            UIDVALIDITY parameter doesn't match the current UIDVALIDITY
   1.255 +            value.
   1.256 +
   1.257 +   C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000
   1.258 +            41,43:211,214:541))
   1.259 +            S: * 464 EXISTS
   1.260 +            S: * 3 RECENT
   1.261 +            S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY
   1.262 +            S: * OK [UIDNEXT 550] Predicted next UID
   1.263 +            S: * OK [HIGHESTMODSEQ 90060128194045007]
   1.264 +            S: * OK [UNSEEN 12] Message 12 is first unseen
   1.265 +            S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
   1.266 +            S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
   1.267 +            \Deleted \Seen \*)] Permanent flags
   1.268 +            S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch
   1.269 +
   1.270 +   Modification Sequence and UID Parameters:
   1.271 +
   1.272 +   A server that doesn't support the persistent storage of mod-sequences
   1.273 +   for the mailbox MUST send the OK untagged response including the
   1.274 +   NOMODSEQ response code with every successful SELECT or EXAMINE
   1.275 +   command, as described in [CONDSTORE].  Such a server doesn't need to
   1.276 +   remember mod-sequences for expunged messages in the mailbox.  It MUST
   1.277 +   ignore the remaining parameters and behave as if no dynamic message
   1.278 +   data changed.
   1.279 +
   1.280 +   If the provided UIDVALIDITY matches that of the selected mailbox, the
   1.281 +   server then checks the last known modification sequence.
   1.282 +
   1.283 +
   1.284 +
   1.285 +Melnikov, et al.            Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.288 +
   1.289 +
   1.290 +   The server sends the client any pending flag changes (using FETCH
   1.291 +   responses that MUST contain UIDs) and expunges those that have
   1.292 +   occurred in this mailbox since the provided modification sequence.
   1.293 +
   1.294 +   If the list of known UIDs was also provided, the server should only
   1.295 +   report flag changes and expunges for the specified messages.  If the
   1.296 +   client did not provide the list of UIDs, the server acts as if the
   1.297 +   client has specified "1:<maxuid>", where <maxuid> is the mailbox's
   1.298 +   UIDNEXT value minus 1.  If the mailbox is empty and never had any
   1.299 +   messages in it, then lack of the list of UIDs is interpreted as an
   1.300 +   empty set of UIDs.
   1.301 +
   1.302 +   Thus, the client can process just these pending events and need not
   1.303 +   perform a full resynchronization.  Without the message sequence
   1.304 +   number matching information, the result of this step is semantically
   1.305 +   equivalent to the client issuing:
   1.306 +   tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE
   1.307 +   "mod-sequence-value" VANISHED)
   1.308 +
   1.309 +   Example:
   1.310 +      C: A03 SELECT INBOX (QRESYNC (67890007
   1.311 +         90060115194045000 41,43:211,214:541))
   1.312 +      S: * OK [CLOSED]
   1.313 +      S: * 314 EXISTS
   1.314 +      S: * 15 RECENT
   1.315 +      S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
   1.316 +      S: * OK [UIDNEXT 567] Predicted next UID
   1.317 +      S: * OK [HIGHESTMODSEQ 90060115205545359]
   1.318 +      S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
   1.319 +      S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
   1.320 +      S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
   1.321 +         \Deleted \Seen \*)] Permanent flags
   1.322 +      S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540
   1.323 +      S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ
   1.324 +         (90060115194045001))
   1.325 +      S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ
   1.326 +         (90060115194045308))
   1.327 +      S: ...
   1.328 +      S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ
   1.329 +         (90060115194045001))
   1.330 +      S: A03 OK [READ-WRITE] mailbox selected
   1.331 +
   1.332 +   Message sequence match data:
   1.333 +
   1.334 +   A client MAY provide a parenthesized list of a message sequence set
   1.335 +   and the corresponding UID sets.  Both MUST be provided in ascending
   1.336 +   order.  The server uses this data to restrict the range for which it
   1.337 +   provides expunged message information.
   1.338 +
   1.339 +
   1.340 +
   1.341 +Melnikov, et al.            Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.344 +
   1.345 +
   1.346 +   Conceptually, the client provides a small sample of sequence numbers
   1.347 +   for which it knows the corresponding UIDs.  The server then compares
   1.348 +   each sequence number and UID pair the client provides with the
   1.349 +   current state of the mailbox.  If a pair matches, then the client
   1.350 +   knows of any expunges up to, and including, the message, and thus
   1.351 +   will not include that range in the VANISHED response, even if the
   1.352 +   "mod-sequence-value" provided by the client is too old for the server
   1.353 +   to have data of when those messages were expunged.
   1.354 +
   1.355 +   Thus, if the Nth message number in the first set in the list is 4,
   1.356 +   and the Nth UID in the second set in the list is 8, and the mailbox's
   1.357 +   fourth message has UID 8, then no UIDs equal to or less than 8 are
   1.358 +   present in the VANISHED response.  If the (N+1)th message number is
   1.359 +   12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox
   1.360 +   has UID 25, then the lowest UID included in the VANISHED response
   1.361 +   would be 9.
   1.362 +
   1.363 +   In the following two examples, the server is unable to remember
   1.364 +   expunges at all, and only UIDs with messages divisible by three are
   1.365 +   present in the mailbox.  In the first example, the client does not
   1.366 +   use the fourth parameter; in the second, it provides it.  This
   1.367 +   example is somewhat extreme, but shows that judicious usage of the
   1.368 +   sequence match data can save a substantial amount of bandwidth.
   1.369 +
   1.370 +   Example:
   1.371 +      C: A04 SELECT INBOX (QRESYNC (67890007
   1.372 +         90060115194045000 1:29997))
   1.373 +      S: * 10003 EXISTS
   1.374 +      S: * 5 RECENT
   1.375 +      S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
   1.376 +      S: * OK [UIDNEXT 30013] Predicted next UID
   1.377 +      S: * OK [HIGHESTMODSEQ 90060115205545359]
   1.378 +      S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
   1.379 +      S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
   1.380 +      S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
   1.381 +         \Deleted \Seen \*)] Permanent flags
   1.382 +      S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...]
   1.383 +         29998:29999,30001:30002,30004:30005,30007:30008
   1.384 +      S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
   1.385 +         (90060115194045027))
   1.386 +      S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
   1.387 +         (90060115194045028))
   1.388 +      S: ...
   1.389 +      S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
   1.390 +         (90060115194045031))
   1.391 +      S: A04 OK [READ-WRITE] mailbox selected
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Melnikov, et al.            Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.400 +
   1.401 +
   1.402 +   Example:
   1.403 +      C: B04 SELECT INBOX (QRESYNC (67890007
   1.404 +         90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000,
   1.405 +         22500,27000,29970,29973,29976,29979,29982,29985,29988,29991,
   1.406 +         29994,29997)))
   1.407 +      S: * 10003 EXISTS
   1.408 +      S: * 5 RECENT
   1.409 +      S: * OK [UIDVALIDITY 67890007] UIDVALIDITY
   1.410 +      S: * OK [UIDNEXT 30013] Predicted next UID
   1.411 +      S: * OK [HIGHESTMODSEQ 90060115205545359]
   1.412 +      S: * OK [UNSEEN 7] There are some unseen messages in the mailbox
   1.413 +      S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
   1.414 +      S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
   1.415 +         \Deleted \Seen \*)] Permanent flags
   1.416 +      S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007:
   1.417 +         30008
   1.418 +      S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ
   1.419 +         (90060115194045027))
   1.420 +      S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ
   1.421 +         (90060115194045028))
   1.422 +      S: ...
   1.423 +      S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ
   1.424 +         (90060115194045031))
   1.425 +      S: B04 OK [READ-WRITE] mailbox selected
   1.426 +
   1.427 +3.2.  VANISHED UID FETCH Modifier
   1.428 +
   1.429 +   [IMAPABNF] has extended the syntax of the FETCH and UID FETCH
   1.430 +   commands to include an optional FETCH modifier.  This document
   1.431 +   defines a new UID FETCH modifier: VANISHED.
   1.432 +
   1.433 +   Note, that the VANISHED UID FETCH modifier is NOT allowed with a
   1.434 +   FETCH command.  The server MUST return a tagged BAD response if this
   1.435 +   response is specified as a modifier to the FETCH command.
   1.436 +
   1.437 +   A server MUST respond with a tagged BAD response if the VANISHED UID
   1.438 +   FETCH modifier is specified and the client hasn't issued "ENABLE
   1.439 +   QRESYNC" in the current connection.
   1.440 +
   1.441 +   The VANISHED UID FETCH modifier MUST only be specified together with
   1.442 +   the CHANGEDSINCE UID FETCH modifier.
   1.443 +
   1.444 +   The VANISHED UID FETCH modifier instructs the server to report those
   1.445 +   messages from the UID set parameter that have been expunged and whose
   1.446 +   associated mod-sequence is larger than the specified mod-sequence.
   1.447 +   That is, the client requests to be informed of messages from the
   1.448 +   specified set that were expunged since the specified mod-sequence.
   1.449 +   Note that the mod-sequence(s) associated with these messages were
   1.450 +
   1.451 +
   1.452 +
   1.453 +Melnikov, et al.            Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.456 +
   1.457 +
   1.458 +   updated when the messages were expunged (as described above).  The
   1.459 +   expunged messages are reported using the VANISHED response as
   1.460 +   described in Section 3.6, which MUST contain the EARLIER tag.  Any
   1.461 +   VANISHED (EARLIER) responses MUST be returned before any FETCH
   1.462 +   responses, as otherwise the client might get confused about how
   1.463 +   message numbers map to UIDs.
   1.464 +
   1.465 +   Note: A server that receives a mod-sequence smaller than <minmodseq>,
   1.466 +   where <minmodseq> is the value of the smallest expunged mod-sequence
   1.467 +   it remembers minus one, MUST behave as if it was requested to report
   1.468 +   all expunged messages from the provided UID set parameter.
   1.469 +
   1.470 +   Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware
   1.471 +   client [CONDSTORE] needs to issue separate commands to learn of flag
   1.472 +   changes and expunged messages since the last synchronization:
   1.473 +
   1.474 +   C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345)
   1.475 +   S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
   1.476 +   S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
   1.477 +   S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
   1.478 +       $AutoJunk $MDNSent))
   1.479 +   S: s100 OK FETCH completed
   1.480 +   C: s101 UID SEARCH 300:500
   1.481 +   S: * SEARCH 404 406 407 408 410 412
   1.482 +   S: s101 OK search completed
   1.483 +
   1.484 +   Where 300 and 500 are the lowest and highest UIDs from client's
   1.485 +   cache.  The second SEARCH response tells the client that the messages
   1.486 +   with UIDs 407, 410, and 412 are still present, but their flags
   1.487 +   haven't changed since the specified modification sequence.
   1.488 +
   1.489 +   Using the VANISHED UID FETCH modifier, it is sufficient to issue only
   1.490 +   a single command:
   1.491 +
   1.492 +   C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345
   1.493 +       VANISHED)
   1.494 +   S: * VANISHED (EARLIER) 300:310,405,411
   1.495 +   S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen))
   1.496 +   S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted))
   1.497 +   S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk
   1.498 +       $AutoJunk $MDNSent))
   1.499 +   S: s100 OK FETCH completed
   1.500 +
   1.501 +
   1.502 +
   1.503 +
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Melnikov, et al.            Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.512 +
   1.513 +
   1.514 +3.3.  EXPUNGE Command
   1.515 +
   1.516 +   Arguments: none
   1.517 +
   1.518 +   Responses: untagged responses: EXPUNGE or VANISHED
   1.519 +
   1.520 +   Result: OK - expunge completed
   1.521 +           NO - expunge failure: can't expunge (e.g., permission denied)
   1.522 +           BAD - command unknown or arguments invalid
   1.523 +
   1.524 +   This section updates the definition of the EXPUNGE command described
   1.525 +   in Section 6.4.3 of [RFC3501].
   1.526 +
   1.527 +   The EXPUNGE command permanently removes all messages that have the
   1.528 +   \Deleted flag set from the currently selected mailbox.  Before
   1.529 +   returning an OK to the client, those messages that are removed are
   1.530 +   reported using a VANISHED response or EXPUNGE responses.
   1.531 +
   1.532 +   If the server is capable of storing modification sequences for the
   1.533 +   selected mailbox, it MUST increment the per-mailbox mod-sequence if
   1.534 +   at least one message was permanently removed due to the execution of
   1.535 +   the EXPUNGE command.  For each permanently removed message, the
   1.536 +   server MUST remember the incremented mod-sequence and corresponding
   1.537 +   UID.  If at least one message got expunged, the server MUST send the
   1.538 +   updated per-mailbox modification sequence using the HIGHESTMODSEQ
   1.539 +   response code (defined in [CONDSTORE]) in the tagged OK response.
   1.540 +
   1.541 +      Example:    C: A202 EXPUNGE
   1.542 +                  S: * 3 EXPUNGE
   1.543 +                  S: * 3 EXPUNGE
   1.544 +                  S: * 5 EXPUNGE
   1.545 +                  S: * 8 EXPUNGE
   1.546 +                  S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged
   1.547 +
   1.548 +   Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag
   1.549 +   set.  The first "* 3 EXPUNGE" reports message # 3 as expunged.  The
   1.550 +   second "* 3 EXPUNGE" reports message # 4 as expunged (the message
   1.551 +   number got decremented due to the previous EXPUNGE response).  See
   1.552 +   the description of the EXPUNGE response in [RFC3501] for further
   1.553 +   explanation.
   1.554 +
   1.555 +   Note that if the server chooses to always send VANISHED responses
   1.556 +   instead of EXPUNGE responses, the previous example might look like
   1.557 +   this:
   1.558 +
   1.559 +      Example:    C: B202 EXPUNGE
   1.560 +                  S: * VANISHED 405,407,410,425
   1.561 +                  S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged
   1.562 +
   1.563 +
   1.564 +
   1.565 +Melnikov, et al.            Standards Track                    [Page 10]
   1.566 +
   1.567 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.568 +
   1.569 +
   1.570 +   Here messages with message numbers 3, 4, 7, and 11 have respective
   1.571 +   UIDs 405, 407, 410, and 425.
   1.572 +
   1.573 +3.4.  CLOSE Command
   1.574 +
   1.575 +   Arguments: none
   1.576 +
   1.577 +   Responses: no specific responses for this command
   1.578 +
   1.579 +   Result: OK - close completed, now in authenticated state
   1.580 +           BAD - command unknown or arguments invalid
   1.581 +
   1.582 +   This section updates the definition of the CLOSE command described in
   1.583 +   Section 6.4.2 of [RFC3501].
   1.584 +
   1.585 +   The CLOSE command permanently removes all messages that have the
   1.586 +   \Deleted flag set from the currently selected mailbox, and returns to
   1.587 +   the authenticated state from the selected state.  No untagged EXPUNGE
   1.588 +   (or VANISHED) responses are sent.
   1.589 +
   1.590 +   If the server is capable of storing modification sequences for the
   1.591 +   selected mailbox, it MUST increment the per-mailbox mod-sequence if
   1.592 +   at least one message was permanently removed due to the execution of
   1.593 +   the CLOSE command.  For each permanently removed message, the server
   1.594 +   MUST remember the incremented mod-sequence and corresponding UID.  If
   1.595 +   at least one message got expunged, the server MUST send the updated
   1.596 +   per-mailbox modification sequence using the HIGHESTMODSEQ response
   1.597 +   code (defined in [CONDSTORE]) in the tagged OK response.
   1.598 +
   1.599 +      Example:    C: A202 CLOSE
   1.600 +                  S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
   1.601 +
   1.602 +3.5.  UID EXPUNGE Command
   1.603 +
   1.604 +   Arguments: message set
   1.605 +
   1.606 +   Responses: untagged responses: EXPUNGE or VANISHED
   1.607 +
   1.608 +   Result: OK - expunge completed
   1.609 +           NO - expunge failure: can't expunge (e.g., permission denied)
   1.610 +           BAD - command unknown or arguments invalid
   1.611 +
   1.612 +   This section updates the definition of the UID EXPUNGE command
   1.613 +   described in Section 2.1 of [UIDPLUS].  Servers that implement both
   1.614 +   [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as
   1.615 +   described in this section.
   1.616 +
   1.617 +
   1.618 +
   1.619 +
   1.620 +
   1.621 +Melnikov, et al.            Standards Track                    [Page 11]
   1.622 +
   1.623 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.624 +
   1.625 +
   1.626 +   The UID EXPUNGE command permanently removes from the currently
   1.627 +   selected mailbox all messages that both have the \Deleted flag set
   1.628 +   and have a UID that is included in the specified message set.  If a
   1.629 +   message either does not have the \Deleted flag set or has a UID that
   1.630 +   is not included in the specified message set, it is not affected.
   1.631 +
   1.632 +   This command is particularly useful for disconnected mode clients.
   1.633 +   By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the
   1.634 +   server, the client can avoid inadvertently removing any messages that
   1.635 +   have been marked as \Deleted by other clients between the time that
   1.636 +   the client was last connected and the time the client resynchronizes.
   1.637 +
   1.638 +   Before returning an OK to the client, those messages that are removed
   1.639 +   are reported using a VANISHED response or EXPUNGE responses.
   1.640 +
   1.641 +   If the server is capable of storing modification sequences for the
   1.642 +   selected mailbox, it MUST increment the per-mailbox mod-sequence if
   1.643 +   at least one message was permanently removed due to the execution of
   1.644 +   the UID EXPUNGE command.  For each permanently removed message, the
   1.645 +   server MUST remember the incremented mod-sequence and corresponding
   1.646 +   UID.  If at least one message got expunged, the server MUST send the
   1.647 +   updated per-mailbox modification sequence using the HIGHESTMODSEQ
   1.648 +   response code (defined in [CONDSTORE]) in the tagged OK response.
   1.649 +
   1.650 +   Example:    C: . UID EXPUNGE 3000:3002
   1.651 +               S: * 3 EXPUNGE
   1.652 +               S: * 3 EXPUNGE
   1.653 +               S: * 3 EXPUNGE
   1.654 +               S: . OK [HIGHESTMODSEQ 20010715194045319] Ok
   1.655 +
   1.656 +   Note: In this example, at least messages with message numbers 3, 4,
   1.657 +   and 5 (UIDs 3000 to 3002) had the \Deleted flag set.  The first "* 3
   1.658 +   EXPUNGE" reports message # 3 as expunged.  The second "* 3 EXPUNGE"
   1.659 +   reports message # 4 as expunged (the message number got decremented
   1.660 +   due to the previous EXPUNGE response).  See the description of the
   1.661 +   EXPUNGE response in [RFC3501] for further explanation.
   1.662 +
   1.663 +3.6.  VANISHED Response
   1.664 +
   1.665 +   Contents:  an optional EARLIER tag
   1.666 +
   1.667 +   list of UIDs
   1.668 +
   1.669 +   The VANISHED response reports that the specified UIDs have been
   1.670 +   permanently removed from the mailbox.  This response is similar to
   1.671 +   the EXPUNGE response [RFC3501]; however, it can return information
   1.672 +   about multiple messages, and it returns UIDs instead of message
   1.673 +
   1.674 +
   1.675 +
   1.676 +
   1.677 +Melnikov, et al.            Standards Track                    [Page 12]
   1.678 +
   1.679 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.680 +
   1.681 +
   1.682 +   numbers.  The first benefit saves bandwidth, while the second is more
   1.683 +   convenient for clients that only use UIDs to access the IMAP server.
   1.684 +
   1.685 +   The VANISHED response has the same restrictions on when it can be
   1.686 +   sent as does the EXPUNGE response (see below).
   1.687 +
   1.688 +   The VANISHED response has two forms.  The first form contains the
   1.689 +   EARLIER tag, which signifies that the response was caused by a UID
   1.690 +   FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command.  This
   1.691 +   response is sent if the UID set parameter to the UID FETCH (VANISHED)
   1.692 +   command includes UIDs of messages that are no longer in the mailbox.
   1.693 +   When the client sees a VANISHED EARLIER response, it MUST NOT
   1.694 +   decrement message sequence numbers for each successive message in the
   1.695 +   mailbox.
   1.696 +
   1.697 +   The second form doesn't contain the EARLIER tag and is described
   1.698 +   below.  Once a client has issued "ENABLE QRESYNC", the server SHOULD
   1.699 +   use the VANISHED response without the EARLIER tag instead of the
   1.700 +   EXPUNGE response.  The server SHOULD continue using VANISHED in lieu
   1.701 +   of EXPUNGE for the duration of the connection.  In particular, this
   1.702 +   affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as
   1.703 +   well as messages expunged in other connections.  Such a VANISHED
   1.704 +   response MUST NOT contain the EARLIER tag.
   1.705 +
   1.706 +   A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
   1.707 +   or because messages were expunged in other connections (i.e., the
   1.708 +   VANISHED response without the EARLIER tag) also decrements the number
   1.709 +   of messages in the mailbox; it is not necessary for the server to
   1.710 +   send an EXISTS response with the new value.  It also decrements
   1.711 +   message sequence numbers for each successive message in the mailbox
   1.712 +   (see the example at the end of this section).  Note that a VANISHED
   1.713 +   response caused by EXPUNGE, UID EXPUNGE, or messages expunged in
   1.714 +   other connections SHOULD only contain UIDs for messages expunged
   1.715 +   since the last VANISHED/EXPUNGE response sent for the currently
   1.716 +   opened mailbox or since the mailbox was opened.  That is, servers
   1.717 +   SHOULD NOT send UIDs for previously expunged messages, unless
   1.718 +   explicitly requested to do so by the UID FETCH (VANISHED) command.
   1.719 +
   1.720 +   Note that client implementors must take care to properly decrement
   1.721 +   the number of messages in the mailbox even if a server violates this
   1.722 +   last SHOULD or repeats the same UID multiple times in the returned
   1.723 +   UID set.  In general, this means that a client using this extension
   1.724 +   should either avoid using message numbers entirely, or have a
   1.725 +   complete mapping of UIDs to message sequence numbers for the selected
   1.726 +   mailbox.
   1.727 +
   1.728 +
   1.729 +
   1.730 +
   1.731 +
   1.732 +
   1.733 +Melnikov, et al.            Standards Track                    [Page 13]
   1.734 +
   1.735 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.736 +
   1.737 +
   1.738 +   Because clients handle the two different forms of the VANISHED
   1.739 +   response differently, servers MUST NOT report UIDs resulting from a
   1.740 +   UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same
   1.741 +   VANISHED response as UIDs of messages expunged now (i.e., messages
   1.742 +   expunged in other connections).  Instead, the server MUST send
   1.743 +   separate VANISHED responses: one with the EARLIER tag and one
   1.744 +   without.
   1.745 +
   1.746 +   A VANISHED response MUST NOT be sent when no command is in progress,
   1.747 +   nor while responding to a FETCH, STORE, or SEARCH command.  This rule
   1.748 +   is necessary to prevent a loss of synchronization of message sequence
   1.749 +   numbers between client and server.  A command is not "in progress"
   1.750 +   until the complete command has been received; in particular, a
   1.751 +   command is not "in progress" during the negotiation of command
   1.752 +   continuation.
   1.753 +
   1.754 +   Note: UID FETCH, UID STORE, and UID SEARCH are different commands
   1.755 +   from FETCH, STORE, and SEARCH.  A VANISHED response MAY be sent
   1.756 +   during a UID command.  However, the VANISHED response MUST NOT be
   1.757 +   sent during a UID SEARCH command that contains message numbers in the
   1.758 +   search criteria.
   1.759 +
   1.760 +   The update from the VANISHED response MUST be recorded by the client.
   1.761 +
   1.762 +   Example: Let's assume that there is the following mapping between
   1.763 +   message numbers and UIDs in the currently selected mailbox (here "X"
   1.764 +   marks messages with the \Deleted flag set, and "x" represents UIDs
   1.765 +   which are not relevant for the example):
   1.766 +
   1.767 +   Message numbers:   1    2    3    4    5  6   7  8  9 10  11
   1.768 +   UIDs:              x  504  505  507  508  x 510  x  x  x 625
   1.769 +   \Deleted messages:           X    X           X            X
   1.770 +
   1.771 +   In the presence of the extension defined in this document:
   1.772 +
   1.773 +   C: A202 EXPUNGE
   1.774 +   S: * VANISHED 505,507,510,625
   1.775 +   S: A202 OK EXPUNGE completed
   1.776 +
   1.777 +   Without the QRESYNC extension, the same example might look like:
   1.778 +
   1.779 +   C: A202 EXPUNGE
   1.780 +   S: * 3 EXPUNGE
   1.781 +   S: * 3 EXPUNGE
   1.782 +   S: * 5 EXPUNGE
   1.783 +   S: * 8 EXPUNGE
   1.784 +   S: A202 OK EXPUNGE completed
   1.785 +
   1.786 +
   1.787 +
   1.788 +
   1.789 +Melnikov, et al.            Standards Track                    [Page 14]
   1.790 +
   1.791 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.792 +
   1.793 +
   1.794 +   (Continuing previous example) If subsequently messages with UIDs 504
   1.795 +   and 508 got marked as \Deleted:
   1.796 +
   1.797 +   C: A210 EXPUNGE
   1.798 +   S: * VANISHED 504,508
   1.799 +   S: A210 OK EXPUNGE completed
   1.800 +
   1.801 +   i.e., the last VANISHED response only contains UIDs of messages
   1.802 +   expunged since the previous VANISHED response.
   1.803 +
   1.804 +3.7.  CLOSED Response Code
   1.805 +
   1.806 +   The CLOSED response code has no parameters.  A server implementing
   1.807 +   the extension defined in this document MUST return the CLOSED
   1.808 +   response code when the currently selected mailbox is closed
   1.809 +   implicitly using the SELECT/EXAMINE command on another mailbox.  The
   1.810 +   CLOSED response code serves as a boundary between responses for the
   1.811 +   previously opened mailbox (which was closed) and the newly selected
   1.812 +   mailbox: all responses before the CLOSED response code relate to the
   1.813 +   mailbox that was closed, and all subsequent responses relate to the
   1.814 +   newly opened mailbox.
   1.815 +
   1.816 +   There is no need to return the CLOSED response code on completion of
   1.817 +   the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose
   1.818 +   purpose is to close the currently selected mailbox without opening a
   1.819 +   new one.
   1.820 +
   1.821 +4.  Server Implementation Considerations
   1.822 +
   1.823 +   This section describes a minimalist implementation, a moderate
   1.824 +   implementation, and an example of a full implementation.
   1.825 +
   1.826 +4.1.  Server Implementations That Don't Store Extra State
   1.827 +
   1.828 +   Strictly speaking, a server implementation that doesn't remember mod-
   1.829 +   sequences associated with expunged messages can be considered
   1.830 +   compliant with this specification.  Such implementations return all
   1.831 +   expunged messages specified in the UID set of the UID FETCH
   1.832 +   (VANISHED) command every time, without paying attention to the
   1.833 +   specified CHANGEDSINCE mod-sequence.  Such implementations are
   1.834 +   discouraged, as they can end up returning VANISHED responses that are
   1.835 +   bigger than the result of a UID SEARCH command for the same UID set.
   1.836 +
   1.837 +   Clients that use the message sequence match data can reduce the scope
   1.838 +   of this VANISHED response substantially in the typical case where
   1.839 +   expunges have not happened, or happen only toward the end of the
   1.840 +   mailbox.
   1.841 +
   1.842 +
   1.843 +
   1.844 +
   1.845 +Melnikov, et al.            Standards Track                    [Page 15]
   1.846 +
   1.847 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.848 +
   1.849 +
   1.850 +4.2.  Server Implementations Storing Minimal State
   1.851 +
   1.852 +   A server that stores the HIGHESTMODSEQ value at the time of the last
   1.853 +   EXPUNGE can omit the VANISHED response when a client provides a
   1.854 +   MODSEQ value that is equal to, or higher than, the current value of
   1.855 +   this datum, that is, when there have been no EXPUNGEs.
   1.856 +
   1.857 +   A client providing message sequence match data can reduce the scope
   1.858 +   as above.  In the case where there have been no expunges, the server
   1.859 +   can ignore this data.
   1.860 +
   1.861 +4.3.  Additional State Required on the Server
   1.862 +
   1.863 +   When compared to the [CONDSTORE] extension, this extension requires
   1.864 +   servers to store additional state associated with expunged messages.
   1.865 +   Note that implementations are not required to store this state in
   1.866 +   persistent storage; however, use of persistent storage is advisable.
   1.867 +
   1.868 +   One possible way to correctly implement the extension described in
   1.869 +   this document is to store a queue of <UID set, mod-sequence> pairs.
   1.870 +   <UID set> can be represented as a sequence of <min UID, max UID>
   1.871 +   pairs.
   1.872 +
   1.873 +   When messages are expunged, one or more entries are added to the
   1.874 +   queue tail.
   1.875 +
   1.876 +   When the server receives a request to return messages expunged since
   1.877 +   a given mod-sequence, it will search the queue from the tail (i.e.,
   1.878 +   going from the highest expunged mod-sequence to the lowest) until it
   1.879 +   sees the first record with a mod-sequence less than or equal to the
   1.880 +   given mod-sequence or it reaches the head of the queue.
   1.881 +
   1.882 +   Note that indefinitely storing information about expunged messages
   1.883 +   can cause storage and related problems for an implementation.  In the
   1.884 +   worst case, this could result in almost 64Gb of storage for each IMAP
   1.885 +   mailbox.  For example, consider an implementation that stores <min
   1.886 +   UID, max UID, mod-sequence> triples for each range of messages
   1.887 +   expunged at the same time.  Each triple requires 16 octets: 4 octets
   1.888 +   for each of the two UIDs, and 8 octets for the mod-sequence.  Assume
   1.889 +   that there is a mailbox containing a single message with a UID of
   1.890 +   2**32-1 (the maximum possible UID value), where messages had
   1.891 +   previously existed with UIDs starting at 1, and have been expunged
   1.892 +   one at a time.  For this mailbox alone, storage is required for the
   1.893 +   triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2,
   1.894 +   modseq4294967294>.
   1.895 +
   1.896 +
   1.897 +
   1.898 +
   1.899 +
   1.900 +
   1.901 +Melnikov, et al.            Standards Track                    [Page 16]
   1.902 +
   1.903 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.904 +
   1.905 +
   1.906 +   Hence, implementations are encouraged to adopt strategies to protect
   1.907 +   against such storage problems, such as limiting the size of the queue
   1.908 +   used to store mod-sequences for expunged messages and "expiring"
   1.909 +   older records when this limit is reached.  When the selected
   1.910 +   implementation-specific queue limit is reached, the oldest record(s)
   1.911 +   are deleted from the queue (note that such records are located at the
   1.912 +   queue head).  For all such "expired" records, the server needs to
   1.913 +   store a single mod-sequence, which is the highest mod-sequence for
   1.914 +   all "expired" expunged messages.
   1.915 +
   1.916 +   Note that if the client provides the message sequence match data,
   1.917 +   this can heavily reduce the data cost of sending a complete set of
   1.918 +   missing UIDs; thus, reducing the problems for clients if a server is
   1.919 +   unable to persist much of this queue.  If the queue contains data
   1.920 +   back to the requested mod-sequence, this data can be ignored.
   1.921 +
   1.922 +   Also, note that if the UIDVALIDITY of the mailbox changes or if the
   1.923 +   mailbox is deleted, then any state associated with expunged messages
   1.924 +   doesn't need to be preserved and SHOULD be deleted.
   1.925 +
   1.926 +5.  Updated Synchronization Sequence
   1.927 +
   1.928 +   This section updates the description of optimized synchronization in
   1.929 +   Section 6.1 of the [IMAP-DISC].
   1.930 +
   1.931 +   An advanced disconnected mail client should use the QRESYNC and
   1.932 +   [CONDSTORE] extensions when they are supported by the server.  The
   1.933 +   client uses the value from the HIGHESTMODSEQ OK response code
   1.934 +   received on mailbox opening to determine if it needs to
   1.935 +   resynchronize.  Once the synchronization is complete, it MUST cache
   1.936 +   the received value (unless the mailbox UIDVALIDITY value has changed;
   1.937 +   see below).  The client MUST update its copy of the HIGHESTMODSEQ
   1.938 +   value whenever the server sends a subsequent HIGHESTMODSEQ OK
   1.939 +   response code.
   1.940 +
   1.941 +   After completing a full synchronization, the client MUST also take
   1.942 +   note of any unsolicited MODSEQ FETCH data items received from the
   1.943 +   server.  Whenever the client receives a tagged response to a command,
   1.944 +   it calculates the highest value among all MODSEQ FETCH data items
   1.945 +   received since the last tagged response.  If this value is bigger
   1.946 +   than the client's copy of the HIGHESTMODSEQ value, then the client
   1.947 +   MUST use this value as its new HIGHESTMODSEQ value.
   1.948 +
   1.949 +   Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
   1.950 +   value with a MODSEQ FETCH data item value as soon as it is received
   1.951 +   because servers are not required to send MODSEQ FETCH data items in
   1.952 +   increasing modseqence order.  This can lead to the client missing
   1.953 +   some changes in case of connectivity loss.
   1.954 +
   1.955 +
   1.956 +
   1.957 +Melnikov, et al.            Standards Track                    [Page 17]
   1.958 +
   1.959 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
   1.960 +
   1.961 +
   1.962 +   When opening the mailbox for synchronization, the client uses the
   1.963 +   QRESYNC parameter to the SELECT/EXAMINE command.  The QRESYNC
   1.964 +   parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ
   1.965 +   values, as known to the client.  It can be optionally followed by the
   1.966 +   set of UIDs, for example, if the client is only interested in partial
   1.967 +   synchronization of the mailbox.  The client may also transmit a list
   1.968 +   containing its knowledge of message numbers.
   1.969 +
   1.970 +   If the SELECT/EXAMINE command is successful, the client compares
   1.971 +   UIDVALIDITY as described in step d)1) in Section 3 of the
   1.972 +   [IMAP-DISC].  If the cached UIDVALIDITY value matches the one
   1.973 +   returned by the server and the server also returns the HIGHESTMODSEQ
   1.974 +   response code, then the server reports expunged messages and returns
   1.975 +   flag changes for all messages specified by the client in the UID set
   1.976 +   parameter (or for all messages in the mailbox, if the client omitted
   1.977 +   the UID set parameter).  At this point, the client is synchronized,
   1.978 +   except for maybe the new messages.
   1.979 +
   1.980 +   If upon a successful SELECT/EXAMINE (QRESYNC) command the client
   1.981 +   receives a NOMODSEQ OK untagged response (instead of the
   1.982 +   HIGHESTMODSEQ response code), it MUST remove the last known
   1.983 +   HIGHESTMODSEQ value from its cache and follow the more general
   1.984 +   instructions in Section 3 of the [IMAP-DISC].
   1.985 +
   1.986 +   At this point, the client is in sync with the server regarding old
   1.987 +   messages.  This client can now fetch information about new messages
   1.988 +   (if requested by the user).
   1.989 +
   1.990 +   Step d) ("Server-to-client synchronization") in Section 4 of the
   1.991 +   [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is
   1.992 +   amended as follows:
   1.993 +
   1.994 +   d) "Server-to-client synchronization" -- for each mailbox that
   1.995 +      requires synchronization, do the following:
   1.996 +
   1.997 +   1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC]
   1.998 +       for more details) after issuing SELECT/EXAMINE (QRESYNC) command.
   1.999 +
  1.1000 +       If the UIDVALIDITY value returned by the server differs, the
  1.1001 +       client MUST
  1.1002 +
  1.1003 +       *   empty the local cache of that mailbox;
  1.1004 +
  1.1005 +       *   "forget" the cached HIGHESTMODSEQ value for the mailbox;
  1.1006 +
  1.1007 +
  1.1008 +
  1.1009 +
  1.1010 +
  1.1011 +
  1.1012 +
  1.1013 +Melnikov, et al.            Standards Track                    [Page 18]
  1.1014 +
  1.1015 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
  1.1016 +
  1.1017 +
  1.1018 +       *   remove any pending "actions" which refer to UIDs in that
  1.1019 +           mailbox.  Note, this doesn't affect actions performed on
  1.1020 +           client generated fake UIDs (see Section 5 of the
  1.1021 +           [IMAP-DISC]);
  1.1022 +
  1.1023 +   2)  Fetch the current "descriptors";
  1.1024 +
  1.1025 +       I) Discover new messages.
  1.1026 +
  1.1027 +   3)  Fetch the bodies of any "interesting" messages that the client
  1.1028 +       doesn't already have.
  1.1029 +
  1.1030 +   Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ
  1.1031 +            value has changed on the server while the client was
  1.1032 +            offline:
  1.1033 +
  1.1034 +    C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198))
  1.1035 +    S: * 172 EXISTS
  1.1036 +    S: * 1 RECENT
  1.1037 +    S: * OK [UNSEEN 12] Message 12 is first unseen
  1.1038 +    S: * OK [UIDVALIDITY 3857529045] UIDs valid
  1.1039 +    S: * OK [UIDNEXT 201] Predicted next UID
  1.1040 +    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  1.1041 +    S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
  1.1042 +    S: * OK [HIGHESTMODSEQ 20010715194045007]
  1.1043 +    S: * VANISHED (EARLIER) 1:5,7:8,10:15
  1.1044 +    S: * 2 FETCH (UID 6 MODSEQ (20010715205008000)
  1.1045 +        FLAGS (\Deleted))
  1.1046 +    S: * 5 FETCH (UID 9 MODSEQ (20010715195517000)
  1.1047 +        FLAGS ($NoJunk $AutoJunk $MDNSent))
  1.1048 +       ...
  1.1049 +    S: A142 OK [READ-WRITE] SELECT completed
  1.1050 +
  1.1051 +6.  Formal Syntax
  1.1052 +
  1.1053 +   The following syntax specification uses the Augmented Backus-Naur
  1.1054 +   Form (ABNF) notation as specified in [ABNF].
  1.1055 +
  1.1056 +   Non-terminals referenced but not defined below are as defined by
  1.1057 +   [RFC3501], [CONDSTORE], or [IMAPABNF].
  1.1058 +
  1.1059 +   Except as noted otherwise, all alphabetic characters are case-
  1.1060 +   insensitive.  The use of upper or lower case characters to define
  1.1061 +   token strings is for editorial clarity only.  Implementations MUST
  1.1062 +   accept these strings in a case-insensitive fashion.
  1.1063 +
  1.1064 +
  1.1065 +
  1.1066 +
  1.1067 +
  1.1068 +
  1.1069 +Melnikov, et al.            Standards Track                    [Page 19]
  1.1070 +
  1.1071 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
  1.1072 +
  1.1073 +
  1.1074 +   capability          =/ "QRESYNC"
  1.1075 +
  1.1076 +   select-param        =  "QRESYNC" SP "(" uidvalidity SP
  1.1077 +                       mod-sequence-value [SP known-uids]
  1.1078 +                       [SP seq-match-data] ")"
  1.1079 +                       ;; conforms to the generic select-param
  1.1080 +                       ;; syntax defined in [IMAPABNF]
  1.1081 +
  1.1082 +   seq-match-data      =  "(" known-sequence-set SP known-uid-set ")"
  1.1083 +
  1.1084 +   uidvalidity         =  nz-number
  1.1085 +
  1.1086 +   known-uids          =  sequence-set
  1.1087 +                       ;; sequence of UIDs, "*" is not allowed
  1.1088 +
  1.1089 +   known-sequence-set  =  sequence-set
  1.1090 +                       ;; set of message numbers corresponding to
  1.1091 +                       ;; the UIDs in known-uid-set, in ascending order.
  1.1092 +                       ;; * is not allowed.
  1.1093 +
  1.1094 +   known-uid-set       =  sequence-set
  1.1095 +                       ;; set of UIDs corresponding to the messages in
  1.1096 +                       ;; known-sequence-set, in ascending order.
  1.1097 +                       ;; * is not allowed.
  1.1098 +
  1.1099 +   message-data        =/ expunged-resp
  1.1100 +
  1.1101 +   expunged-resp       =  "VANISHED" [SP "(EARLIER)"] SP known-uids
  1.1102 +
  1.1103 +   rexpunges-fetch-mod =  "VANISHED"
  1.1104 +                       ;; VANISHED UID FETCH modifier conforms
  1.1105 +                       ;; to the fetch-modifier syntax
  1.1106 +                       ;; defined in [IMAPABNF].  It is only
  1.1107 +                       ;; allowed in the UID FETCH command.
  1.1108 +
  1.1109 +   resp-text-code      =/ "CLOSED"
  1.1110 +
  1.1111 +7.  Security Considerations
  1.1112 +
  1.1113 +   As always, it is important to thoroughly test clients and servers
  1.1114 +   implementing this extension, as it changes how the server reports
  1.1115 +   expunged messages to the client.
  1.1116 +
  1.1117 +   Security considerations relevant to [CONDSTORE] are relevant to this
  1.1118 +   extension.
  1.1119 +
  1.1120 +   This document doesn't raise any new security concerns not already
  1.1121 +   raised by [CONDSTORE] or [RFC3501].
  1.1122 +
  1.1123 +
  1.1124 +
  1.1125 +Melnikov, et al.            Standards Track                    [Page 20]
  1.1126 +
  1.1127 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
  1.1128 +
  1.1129 +
  1.1130 +8.  IANA Considerations
  1.1131 +
  1.1132 +   IMAP4 capabilities are registered by publishing a standards track or
  1.1133 +   IESG approved experimental RFC.  The registry is currently located
  1.1134 +   at:
  1.1135 +
  1.1136 +      http://www.iana.org/assignments/imap4-capabilities
  1.1137 +
  1.1138 +   This document defines the QRESYNC IMAP capability.  IANA has added
  1.1139 +   this capability to the registry.
  1.1140 +
  1.1141 +9.  Acknowledgments
  1.1142 +
  1.1143 +   Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging
  1.1144 +   creation of this document.
  1.1145 +
  1.1146 +   Valuable comments, both in agreement and in dissent, were received
  1.1147 +   from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen,
  1.1148 +   Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp,
  1.1149 +   Eric Rescorla, and Mike Zraly.
  1.1150 +
  1.1151 +   This document takes substantial text from [RFC3501] by Mark Crispin.
  1.1152 +
  1.1153 +10.  References
  1.1154 +
  1.1155 +10.1.  Normative References
  1.1156 +
  1.1157 +   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
  1.1158 +                Specifications: ABNF", STD 68, RFC 5234, January 2008.
  1.1159 +
  1.1160 +   [CONDSTORE]  Melnikov, A. and S. Hole, "IMAP Extension for
  1.1161 +                Conditional STORE Operation or Quick Flag Changes
  1.1162 +                Resynchronization", RFC 4551, June 2006.
  1.1163 +
  1.1164 +   [ENABLE]     Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
  1.1165 +                ENABLE Extension", RFC 5161, March 2008.
  1.1166 +
  1.1167 +   [IMAPABNF]   Melnikov, A. and C. Daboo, "Collected Extensions to
  1.1168 +                IMAP4 ABNF", RFC 4466, April 2006.
  1.1169 +
  1.1170 +   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
  1.1171 +                Requirement Levels", BCP 14, RFC 2119, March 1997.
  1.1172 +
  1.1173 +   [RFC3501]    Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
  1.1174 +                4rev1", RFC 3501, March 2003.
  1.1175 +
  1.1176 +   [UIDPLUS]    Crispin, M., "Internet Message Access Protocol (IMAP) -
  1.1177 +                UIDPLUS extension", RFC 4315, December 2005.
  1.1178 +
  1.1179 +
  1.1180 +
  1.1181 +Melnikov, et al.            Standards Track                    [Page 21]
  1.1182 +
  1.1183 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
  1.1184 +
  1.1185 +
  1.1186 +10.2.  Informative References
  1.1187 +
  1.1188 +   [IMAP-DISC]  Melnikov, A., Ed., "Synchronization Operations For
  1.1189 +                Disconnected Imap4 Clients", RFC 4549, June 2006.
  1.1190 +
  1.1191 +   [UNSELECT]   Melnikov, A., "Internet Message Access Protocol (IMAP)
  1.1192 +                UNSELECT command", RFC 3691, February 2004.
  1.1193 +
  1.1194 +Authors' Addresses
  1.1195 +
  1.1196 +   Alexey Melnikov
  1.1197 +   Isode Ltd
  1.1198 +   5 Castle Business Village
  1.1199 +   36 Station Road
  1.1200 +   Hampton, Middlesex  TW12 2BX
  1.1201 +   UK
  1.1202 +
  1.1203 +   EMail: Alexey.Melnikov@isode.com
  1.1204 +
  1.1205 +
  1.1206 +   Dave Cridland
  1.1207 +   Isode Ltd
  1.1208 +   5 Castle Business Village
  1.1209 +   36 Station Road
  1.1210 +   Hampton, Middlesex  TW12 2BX
  1.1211 +   UK
  1.1212 +
  1.1213 +   EMail: dave.cridland@isode.com
  1.1214 +
  1.1215 +
  1.1216 +   Corby Wilson
  1.1217 +   Nokia
  1.1218 +   5 Wayside Rd.
  1.1219 +   Burlington, MA  01803
  1.1220 +   USA
  1.1221 +
  1.1222 +   EMail: corby@computer.org
  1.1223 +
  1.1224 +
  1.1225 +
  1.1226 +
  1.1227 +
  1.1228 +
  1.1229 +
  1.1230 +
  1.1231 +
  1.1232 +
  1.1233 +
  1.1234 +
  1.1235 +
  1.1236 +
  1.1237 +Melnikov, et al.            Standards Track                    [Page 22]
  1.1238 +
  1.1239 +RFC 5162               IMAP Quick Mailbox Resync              March 2008
  1.1240 +
  1.1241 +
  1.1242 +Full Copyright Statement
  1.1243 +
  1.1244 +   Copyright (C) The IETF Trust (2008).
  1.1245 +
  1.1246 +   This document is subject to the rights, licenses and restrictions
  1.1247 +   contained in BCP 78, and except as set forth therein, the authors
  1.1248 +   retain all their rights.
  1.1249 +
  1.1250 +   This document and the information contained herein are provided on an
  1.1251 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  1.1252 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
  1.1253 +   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
  1.1254 +   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
  1.1255 +   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  1.1256 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1.1257 +
  1.1258 +Intellectual Property
  1.1259 +
  1.1260 +   The IETF takes no position regarding the validity or scope of any
  1.1261 +   Intellectual Property Rights or other rights that might be claimed to
  1.1262 +   pertain to the implementation or use of the technology described in
  1.1263 +   this document or the extent to which any license under such rights
  1.1264 +   might or might not be available; nor does it represent that it has
  1.1265 +   made any independent effort to identify any such rights.  Information
  1.1266 +   on the procedures with respect to rights in RFC documents can be
  1.1267 +   found in BCP 78 and BCP 79.
  1.1268 +
  1.1269 +   Copies of IPR disclosures made to the IETF Secretariat and any
  1.1270 +   assurances of licenses to be made available, or the result of an
  1.1271 +   attempt made to obtain a general license or permission for the use of
  1.1272 +   such proprietary rights by implementers or users of this
  1.1273 +   specification can be obtained from the IETF on-line IPR repository at
  1.1274 +   http://www.ietf.org/ipr.
  1.1275 +
  1.1276 +   The IETF invites any interested party to bring to its attention any
  1.1277 +   copyrights, patents or patent applications, or other proprietary
  1.1278 +   rights that may cover technology that may be required to implement
  1.1279 +   this standard.  Please address the information to the IETF at
  1.1280 +   ietf-ipr@ietf.org.
  1.1281 +
  1.1282 +
  1.1283 +
  1.1284 +
  1.1285 +
  1.1286 +
  1.1287 +
  1.1288 +
  1.1289 +
  1.1290 +
  1.1291 +
  1.1292 +
  1.1293 +Melnikov, et al.            Standards Track                    [Page 23]
  1.1294 +