idnits 2.17.1 draft-melnikov-5162bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5162, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4315, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4315, updated by this document, for RFC5378 checks: 2005-05-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2013) is 4089 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 933, but not defined == Missing Reference: 'UIDNEXT 550' is mentioned on line 239, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060128194045007' is mentioned on line 240, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 932, but not defined == Missing Reference: 'UIDVALIDITY 67890007' is mentioned on line 375, but not defined == Missing Reference: 'UIDNEXT 30013' is mentioned on line 376, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060115205545359' is mentioned on line 377, but not defined == Missing Reference: 'UNSEEN 7' is mentioned on line 379, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045319' is mentioned on line 585, but not defined == Missing Reference: 'HIGHESTMODSEQ 99' is mentioned on line 855, but not defined == Missing Reference: 'MODIFIED 3' is mentioned on line 851, but not defined == Missing Reference: 'HIGHESTMODSEQ 104' is mentioned on line 859, but not defined == Missing Reference: 'UIDNEXT 201' is mentioned on line 934, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 937, but not defined == Unused Reference: 'ACL' is defined on line 1062, but no explicit reference was found in the text == Unused Reference: 'NTP' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'RFC-2180' is defined on line 1073, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4551 (ref. 'CONDSTORE') (Obsoleted by RFC 7162) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft D. Cridland 4 Obsoletes: 5162 (if approved) Isode Ltd 5 Updates: 4315 (if approved) February 13, 2013 6 Intended status: Standards Track 7 Expires: August 17, 2013 9 IMAP4 Extensions for Quick Mailbox Resynchronization 10 draft-melnikov-5162bis-01.txt 12 Abstract 14 This document defines an IMAP4 extension, which gives an IMAP client 15 the ability to quickly resynchronize any previously opened mailbox as 16 part of the SELECT command, without the need for server-side state or 17 additional client round-trips. This extension also introduces a new 18 response that allows for a more compact representation of a list of 19 expunged messages (and always includes the Unique Identifiers (UIDs) 20 expunged). 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 17, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 58 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 59 3.1. QRESYNC Parameter to SELECT/EXAMINE . . . . . . . . . . . 5 60 3.2. VANISHED UID FETCH Modifier . . . . . . . . . . . . . . . 9 61 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 11 62 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 12 63 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 12 64 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 14 65 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 16 66 4. Server Implementation Considerations . . . . . . . . . . . . . 16 67 4.1. Server Implementations That Don't Store Extra State . . . 17 68 4.2. Server Implementations Storing Minimal State . . . . . . . 17 69 4.3. Additional State Required on the Server . . . . . . . . . 17 70 5. Updated Synchronization Sequence . . . . . . . . . . . . . . . 18 71 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 78 Appendix A. Changes since RFC 5162 . . . . . . . . . . . . . . . 24 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 81 1. Introduction and Overview 83 The [CONDSTORE] extension gives a disconnected client the ability to 84 quickly resynchronize IMAP flag changes for previously seen messages. 85 This can be done using the CHANGEDSINCE FETCH modifier once a mailbox 86 is opened. In order for the client to discover which messages have 87 been expunged, the client still has to issue a UID FETCH or a UID 88 SEARCH command. This document defines an extension to [CONDSTORE] 89 that allows a reconnecting client to perform full resynchronization, 90 including discovery of expunged messages, in a single round-trip. 91 This extension also introduces a new response, VANISHED, that allows 92 for a more compact representation of a list of expunged messages. 94 This extension can be useful for mobile clients that can experience 95 frequent disconnects caused by environmental factors (battery life, 96 signal strength, etc.). Such clients need a way to quickly reconnect 97 to the IMAP server, while minimizing delay experienced by the user as 98 well as the amount of traffic (and hence the expense) generated by 99 resynchronization. 101 By extending the SELECT command to perform the additional 102 resynchronization, this also allows clients to reduce concurrent 103 connections to the IMAP server held purely for the sake of avoiding 104 the resynchronization. 106 The quick resync IMAP extension is present if an IMAP4 server returns 107 "QRESYNC" as one of the supported capabilities to the CAPABILITY 108 command. 110 Servers supporting this extension MUST implement and advertise 111 support for the [ENABLE] IMAP extension. Also, the presence of the 112 "QRESYNC" capability implies support for the [CONDSTORE] IMAP 113 extension even if the "CONDSTORE" capability isn't advertised. A 114 server compliant with this specification is REQUIREd to support 115 "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE 116 enabling commands", as defined in [CONDSTORE], and have identical 117 results), but there is no requirement for a compliant server to 118 support "ENABLE CONDSTORE" by itself. The "ENABLE QRESYNC"/"ENABLE 119 QRESYNC CONDSTORE" command also tells the server that [[//// Change 120 the SHOULD to MUST?]] it SHOULD start sending VANISHED responses (see 121 Section 3.6) instead of EXPUNGE responses. This change remains in 122 effect until the connection is closed. 124 For compatibility with clients that only support the [CONDSTORE] IMAP 125 extension, servers SHOULD advertise "CONDSTORE" in the CAPABILITY 126 response as well. 128 Once a "CONDSTORE enabling command" is issued by the client, the 129 server MUST automatically include both UID and mod-sequence data in 130 all subsequent untagged FETCH responses (until the connection is 131 closed), whether they were caused by a regular STORE/UID STORE, a 132 STORE/UID STORE with UNCHANGEDSINCE modifier, FETCH/UID FETCH that 133 implicitly set \Seen flag or an external agent. Note that this rule 134 doesn't affect untagged FETCH responses caused by a FETCH command 135 that doesn't include UID and/or MODSEQ FETCH data item (and doesn't 136 implicitly set \Seen flag), or UID FETCH without the MODSEQ FETCH 137 data item. 139 A client making use of this extension MUST issue "ENABLE QRESYNC" 140 once it is authenticated. A server MUST respond with a tagged BAD 141 response if the QRESYNC parameter to the SELECT/EXAMINE command or 142 the VANISHED UID FETCH modifier is specified and the client hasn't 143 issued "ENABLE QRESYNC", or the server has not positively responded 144 to that command with the untagged ENABLED response containing 145 QRESYNC, in the current connection. 147 This document puts additional requirements on a server implementing 148 the [CONDSTORE] extension. Each mailbox that supports persistent 149 storage of mod-sequences, i.e., for which the server has sent a 150 HIGHESTMODSEQ untagged OK response code on a successful SELECT/ 151 EXAMINE, MUST increment the per-mailbox mod-sequence when one or more 152 messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the 153 server MUST associate the incremented mod-sequence with the UIDs of 154 the expunged messages. 156 A client that supports CONDSTORE but not this extension might 157 resynchronize a mailbox and discover that its HIGHESTMODSEQ has 158 increased from the value cached by the client. If the increase is 159 only due to messages having been expunged since the client last 160 synchronized, the client is likely to send a FETCH ... CHANGEDSINCE 161 command that returns no data. Thus, a client that supports CONDSTORE 162 but not this extension might incur a penalty of an unneeded round- 163 trip when resynchronizing some mailboxes (those that have had 164 messages expunged but no flag changes since the last 165 synchronization). 167 This extra round-trip is only incurred by clients that support 168 CONDSTORE but not this extension, and only when a mailbox has had 169 messages expunged but no flag changes to non-expunged messages. 170 Since CONDSTORE is a relatively new extension, it is thought likely 171 that clients that support it will also support this extension. 173 2. Requirements Notation 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 In examples, "C:" and "S:" indicate lines sent by the client and 180 server respectively. If a single "C:" or "S:" label applies to 181 multiple lines, then the line breaks between those lines are for 182 editorial clarity only and are not part of the actual protocol 183 exchange. The five characters [...] means that something has been 184 elided. 186 Understanding of the IMAP message sequence numbers and UIDs and the 187 EXPUNGE response [RFC3501] is essential when reading this document. 189 3. IMAP Protocol Changes 191 3.1. QRESYNC Parameter to SELECT/EXAMINE 193 The Quick Resynchronization parameter to SELECT/EXAMINE commands has 194 four arguments: 196 o the last known UIDVALIDITY, 198 o the last known modification sequence, 200 o the optional set of known UIDs, and 202 o an optional parenthesized list of known sequence ranges and their 203 corresponding UIDs. 205 A server MUST respond with a tagged BAD response if the Quick 206 Resynchronization parameter to SELECT/EXAMINE command is specified 207 and the client hasn't issued "ENABLE QRESYNC" in the current 208 connection, or the server has not positively responded to that 209 command with the untagged ENABLED response containing QRESYNC. 211 Before opening the specified mailbox, the server verifies all 212 arguments for syntactic validity. If any parameter is not 213 syntactically valid, the server returns the tagged BAD response, and 214 the mailbox remains unselected. Once the check is done, the server 215 opens the mailbox as if no SELECT/EXAMINE parameters are specified 216 (this is subject to processing of other parameters as defined in 217 other extensions). In particular this means that the server MUST 218 send all untagged responses as specified in Sections 6.3.1 and 6.3.2 219 of [RFC3501]. 221 After that, the server checks the UIDVALIDITY value provided by the 222 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY 223 for the mailbox being opened, then the server MUST ignore the 224 remaining parameters and behave as if no dynamic message data 225 changed. The client can discover this situation by comparing the 226 UIDVALIDITY value returned by the server. This behavior allows the 227 client not to synchronize the mailbox or decide on the best 228 synchronization strategy. 230 Example: Attempting to resynchronize INBOX, but the provided 231 UIDVALIDITY parameter doesn't match the current UIDVALIDITY 232 value. 234 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 235 41,43:211,214:541)) 236 S: * 464 EXISTS 237 S: * 3 RECENT 238 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 239 S: * OK [UIDNEXT 550] Predicted next UID 240 S: * OK [HIGHESTMODSEQ 90060128194045007] Highest mailbox 241 mod-sequence 242 S: * OK [UNSEEN 12] Message 12 is first unseen 243 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 244 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 245 \Deleted \Seen \*)] Permanent flags 246 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch 248 Modification Sequence and UID Parameters: 250 A server that doesn't support the persistent storage of mod-sequences 251 for the mailbox MUST send the OK untagged response including the 252 NOMODSEQ response code with every successful SELECT or EXAMINE 253 command, as described in [CONDSTORE]. Such a server doesn't need to 254 remember mod-sequences for expunged messages in the mailbox. It MUST 255 ignore the remaining parameters and behave as if no dynamic message 256 data changed. 258 If the provided UIDVALIDITY matches that of the selected mailbox, the 259 server then checks the last known modification sequence. 260 The server sends the client any pending flag changes (using FETCH 261 responses that MUST contain UIDs) and expunges those that have 262 occurred in this mailbox since the provided modification sequence. 264 If the list of known UIDs was also provided, the server should only 265 report flag changes and expunges for the specified messages. If the 266 client did not provide the list of UIDs, the server acts as if the 267 client has specified "1:", where is the mailbox's 268 UIDNEXT value minus 1. If the mailbox is empty and never had any 269 messages in it, then lack of the list of UIDs is interpreted as an 270 empty set of UIDs. 272 Thus, the client can process just these pending events and need not 273 perform a full resynchronization. Without the message sequence 274 number matching information, the result of this step is semantically 275 equivalent to the client issuing: 276 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE 277 "mod-sequence-value" VANISHED) 279 In particular this means that all requirement specified in 280 Section 3.2 apply. 282 Example: 283 C: A03 SELECT INBOX (QRESYNC (67890007 284 90060115194045000 41:211,214:541)) 285 S: * OK [CLOSED] 286 S: * 100 EXISTS 287 S: * 11 RECENT 288 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 289 S: * OK [UIDNEXT 600] Predicted next UID 290 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 291 sequence 292 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 293 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 294 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 295 \Deleted \Seen \*)] Permanent flags 296 S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540 297 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ 298 (90060115194045001)) 299 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ 300 (90060115194045308)) 301 S: * 51 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ 302 (90060115194045001)) 303 S: A03 OK [READ-WRITE] mailbox selected 305 In the above example flag information for the UID 42 is not returned, 306 presumably because its flags haven't changed since the MODSEQ 307 90060115194045000. 309 Message sequence match data: 311 A client MAY provide a parenthesized list of a message sequence set 312 and the corresponding UID sets. Both MUST be provided in ascending 313 order. The server uses this data to restrict the range for which it 314 provides expunged message information. 316 Conceptually, the client provides a small sample of sequence numbers 317 for which it knows the corresponding UIDs. The server then compares 318 each sequence number and UID pair the client provides with the 319 current state of the mailbox. If a pair matches, then the client 320 knows of any expunges up to, and including, the message, and thus 321 will not include that range in the VANISHED response, even if the 322 "mod-sequence-value" provided by the client is too old for the server 323 to have data of when those messages were expunged. 325 Thus, if the Nth message number in the first set in the list is 4, 326 and the Nth UID in the second set in the list is 8, and the mailbox's 327 fourth message has UID 8, then no UIDs equal to or less than 8 are 328 present in the VANISHED response. If the (N+1)th message number is 329 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox 330 has UID 25, then the lowest UID included in the VANISHED response 331 would be 9. 333 In the following two examples, the server is unable to remember 334 expunges at all, and only UIDs with messages divisible by three are 335 present in the mailbox. In the first example, the client does not 336 use the fourth parameter; in the second, it provides it. This 337 example is somewhat extreme, but shows that judicious usage of the 338 sequence match data can save a substantial amount of bandwidth. 340 Example: 341 C: A04 SELECT INBOX (QRESYNC (67890007 342 90060115194045000 1:29997)) 343 S: * 10003 EXISTS 344 S: * 4 RECENT 345 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 346 S: * OK [UIDNEXT 30013] Predicted next UID 347 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 348 sequence 349 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 350 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 351 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 352 \Deleted \Seen \*)] Permanent flags 353 S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14,[...], 354 29668:29669,29671:29996 355 S: * 1 FETCH (UID 3 FLAGS (\Seen \Answered $Important) MODSEQ 356 (90060115194045001)) 357 S: ... 358 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ 359 (90060115194045027)) 360 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ 361 (90060115194045028)) 362 S: ... 363 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ 364 (90060115194045031)) 366 S: A04 OK [READ-WRITE] mailbox selected 368 Example: 369 C: B04 SELECT INBOX (QRESYNC (67890007 370 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 371 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 372 29994,29997))) 373 S: * 10003 EXISTS 374 S: * 4 RECENT 375 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 376 S: * OK [UIDNEXT 30013] Predicted next UID 377 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 378 sequence 379 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 380 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 381 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 382 \Deleted \Seen \*)] Permanent flags 383 S: * 1 FETCH (UID 3 FLAGS (\Seen \Answered $Important) MODSEQ 384 (90060115194045001)) 385 S: ... 386 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ 387 (90060115194045027)) 388 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ 389 (90060115194045028)) 390 S: ... 391 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ 392 (90060115194045031)) 393 S: B04 OK [READ-WRITE] mailbox selected 395 3.2. VANISHED UID FETCH Modifier 397 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH 398 commands to include an optional FETCH modifier. This document 399 defines a new UID FETCH modifier: VANISHED. 401 Note, that the VANISHED UID FETCH modifier is NOT allowed with a 402 FETCH command. The server MUST return a tagged BAD response if this 403 response is specified as a modifier to the FETCH command. 405 A server MUST respond with a tagged BAD response if the VANISHED UID 406 FETCH modifier is specified and the client hasn't issued "ENABLE 407 QRESYNC" in the current connection. 409 The VANISHED UID FETCH modifier MUST only be specified together with 410 the CHANGEDSINCE UID FETCH modifier. 412 The VANISHED UID FETCH modifier instructs the server to report those 413 messages from the UID set parameter that have been expunged and whose 414 associated mod-sequence is larger than the specified mod-sequence. 415 That is, the client requests to be informed of messages from the 416 specified set that were expunged since the specified mod-sequence. 417 Note that the mod-sequence(s) associated with these messages were 418 updated when the messages were expunged (as described above). The 419 expunged messages are reported using the VANISHED response as 420 described in Section 3.6, which MUST contain the EARLIER tag. Any 421 VANISHED (EARLIER) responses MUST be returned before any FETCH 422 responses, as otherwise the client might get confused about how 423 message numbers map to UIDs. 425 Note: A server that receives a mod-sequence smaller than , 426 where is the value of the smallest expunged mod-sequence 427 it remembers minus one, MUST behave as if it was requested to report 428 all expunged messages from the provided UID set parameter. 430 Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware 431 client [CONDSTORE] needs to issue separate commands to learn of flag 432 changes and expunged messages since the last synchronization: 434 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) 435 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 436 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 437 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 438 $AutoJunk $MDNSent)) 439 S: s100 OK FETCH completed 440 C: s101 UID SEARCH 300:500 441 S: * SEARCH 404 406 407 408 410 412 442 S: s101 OK search completed 444 Where 300 and 500 are the lowest and highest UIDs from client's 445 cache. The second SEARCH response tells the client that the messages 446 with UIDs 407, 410, and 412 are still present, but their flags 447 haven't changed since the specified modification sequence. 449 Using the VANISHED UID FETCH modifier, it is sufficient to issue only 450 a single command: 452 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 453 VANISHED) 454 S: * VANISHED (EARLIER) 300:310,405,411 455 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 456 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 457 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 458 $AutoJunk $MDNSent)) 459 S: s100 OK FETCH completed 461 3.3. EXPUNGE Command 463 Arguments: none 465 Responses: untagged responses: EXPUNGE or VANISHED 467 Result: OK - expunge completed 468 NO - expunge failure: can't expunge (e.g., permission denied) 469 BAD - command unknown or arguments invalid 471 This section updates the definition of the EXPUNGE command described 472 in Section 6.4.3 of [RFC3501]. 474 The EXPUNGE command permanently removes all messages that have the 475 \Deleted flag set from the currently selected mailbox. Before 476 returning an OK to the client, those messages that are removed are 477 reported using a VANISHED response or EXPUNGE responses. 479 If the server is capable of storing modification sequences for the 480 selected mailbox, it MUST increment the per-mailbox mod-sequence if 481 at least one message was permanently removed due to the execution of 482 the EXPUNGE command. For each permanently removed message, the 483 server MUST remember the incremented mod-sequence and corresponding 484 UID. If at least one message got expunged, the server MUST send the 485 updated per-mailbox modification sequence using the HIGHESTMODSEQ 486 response code (defined in [CONDSTORE]) in the tagged OK response. 488 Example: C: A202 EXPUNGE 489 S: * 3 EXPUNGE 490 S: * 3 EXPUNGE 491 S: * 5 EXPUNGE 492 S: * 8 EXPUNGE 493 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged 495 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag 496 set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The 497 second "* 3 EXPUNGE" reports message # 4 as expunged (the message 498 number got decremented due to the previous EXPUNGE response). See 499 the description of the EXPUNGE response in [RFC3501] for further 500 explanation. 502 Note that if the server chooses to always send VANISHED responses 503 instead of EXPUNGE responses, the previous example might look like 504 this: 506 Example: C: B202 EXPUNGE 507 S: * VANISHED 405,407,410,425 508 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged 510 Here messages with message numbers 3, 4, 7, and 11 have respective 511 UIDs 405, 407, 410, and 425. 513 3.4. CLOSE Command 515 Arguments: none 517 Responses: no specific responses for this command 519 Result: OK - close completed, now in authenticated state 520 BAD - command unknown or arguments invalid 522 This section updates the definition of the CLOSE command described in 523 Section 6.4.2 of [RFC3501]. 525 The CLOSE command permanently removes all messages that have the 526 \Deleted flag set from the currently selected mailbox, and returns to 527 the authenticated state from the selected state. No untagged EXPUNGE 528 (or VANISHED) responses are sent. 530 If the server is capable of storing modification sequences for the 531 selected mailbox, it MUST increment the per-mailbox mod-sequence if 532 at least one message was permanently removed due to the execution of 533 the CLOSE command. For each permanently removed message, the server 534 MUST remember the incremented mod-sequence and corresponding UID. 535 The server MUST NOT send the updated per-mailbox modification 536 sequence using the HIGHESTMODSEQ response code (defined in 537 [CONDSTORE]) in the tagged OK response, as this might cause loss of 538 synchronization on the client. 540 Example: C: A202 CLOSE 541 S: A202 OK done 543 3.5. UID EXPUNGE Command 544 Arguments: message set 546 Responses: untagged responses: EXPUNGE or VANISHED 548 Result: OK - expunge completed 549 NO - expunge failure: can't expunge (e.g., permission denied) 550 BAD - command unknown or arguments invalid 552 This section updates the definition of the UID EXPUNGE command 553 described in Section 2.1 of [UIDPLUS]. Servers that implement both 554 [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as 555 described in this section. 557 The UID EXPUNGE command permanently removes from the currently 558 selected mailbox all messages that both have the \Deleted flag set 559 and have a UID that is included in the specified message set. If a 560 message either does not have the \Deleted flag set or has a UID that 561 is not included in the specified message set, it is not affected. 563 This command is particularly useful for disconnected mode clients. 564 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the 565 server, the client can avoid inadvertently removing any messages that 566 have been marked as \Deleted by other clients between the time that 567 the client was last connected and the time the client resynchronizes. 569 Before returning an OK to the client, those messages that are removed 570 are reported using a VANISHED response or EXPUNGE responses. 572 If the server is capable of storing modification sequences for the 573 selected mailbox, it MUST increment the per-mailbox mod-sequence if 574 at least one message was permanently removed due to the execution of 575 the UID EXPUNGE command. For each permanently removed message, the 576 server MUST remember the incremented mod-sequence and corresponding 577 UID. If at least one message got expunged, the server MUST send the 578 updated per-mailbox modification sequence using the HIGHESTMODSEQ 579 response code (defined in [CONDSTORE]) in the tagged OK response. 581 Example: C: . UID EXPUNGE 3000:3002 582 S: * 3 EXPUNGE 583 S: * 3 EXPUNGE 584 S: * 3 EXPUNGE 585 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok 587 Note: In this example, at least messages with message numbers 3, 4, 588 and 5 (UIDs 3000 to 3002) had the \Deleted flag set. The first "* 3 589 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE" 590 reports message # 4 as expunged (the message number got decremented 591 due to the previous EXPUNGE response). See the description of the 592 EXPUNGE response in [RFC3501] for further explanation. 594 3.6. VANISHED Response 596 Contents: an optional EARLIER tag 598 list of UIDs 600 The VANISHED response reports that the specified UIDs have been 601 permanently removed from the mailbox. This response is similar to 602 the EXPUNGE response [RFC3501]; however, it can return information 603 about multiple messages, and it returns UIDs instead of message 604 numbers. The first benefit saves bandwidth, while the second is more 605 convenient for clients that only use UIDs to access the IMAP server. 607 The VANISHED response has the same restrictions on when it can be 608 sent as does the EXPUNGE response (see below). 610 The VANISHED response has two forms. The first form contains the 611 EARLIER tag, which signifies that the response was caused by a UID 612 FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This 613 response is sent if the UID set parameter to the UID FETCH (VANISHED) 614 command includes UIDs of messages that are no longer in the mailbox. 615 When the client sees a VANISHED EARLIER response, it MUST NOT 616 decrement message sequence numbers for each successive message in the 617 mailbox. 619 The second form doesn't contain the EARLIER tag and is described 620 below. Once a client has issued "ENABLE QRESYNC" (and the server has 621 positively responded to that command with the untagged ENABLED 622 response containing QRESYNC), the server SHOULD use the VANISHED 623 response without the EARLIER tag instead of the EXPUNGE response. 624 The server SHOULD continue using VANISHED in lieu of EXPUNGE for the 625 duration of the connection. In particular, this affects the EXPUNGE 626 [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as well as messages 627 expunged in other connections. Such a VANISHED response MUST NOT 628 contain the EARLIER tag. 630 A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command 631 or because messages were expunged in other connections (i.e., the 632 VANISHED response without the EARLIER tag) also decrements the number 633 of messages in the mailbox; it is not necessary for the server to 634 send an EXISTS response with the new value. It also decrements 635 message sequence numbers for each successive message in the mailbox 636 (see the example at the end of this section). 638 Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or 639 messages expunged in other connections MUST only contain UIDs for 640 messages expunged since the last VANISHED/EXPUNGE response sent for 641 the currently opened mailbox or since the mailbox was opened. That 642 is, servers MUST NOT send UIDs for previously expunged messages, 643 unless explicitly requested to do so by the UID FETCH (VANISHED) 644 command. This is required to prevent a possible race condition where 645 new arrivals for which the UID is not yet known by the client are 646 expunged. 648 Note that client implementors must take care to properly decrement 649 the number of messages in the mailbox even if a server violates this 650 last SHOULD or repeats the same UID multiple times in the returned 651 UID set. In general, this means that a client using this extension 652 should either avoid using message numbers entirely, or have a 653 complete mapping of UIDs to message sequence numbers for the selected 654 mailbox. 656 Because clients handle the two different forms of the VANISHED 657 response differently, servers MUST NOT report UIDs resulting from a 658 UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same 659 VANISHED response as UIDs of messages expunged now (i.e., messages 660 expunged in other connections). Instead, the server MUST send 661 separate VANISHED responses: one with the EARLIER tag and one 662 without. 664 A VANISHED response MUST NOT be sent when no command is in progress, 665 nor while responding to a FETCH, STORE, or SEARCH command. This rule 666 is necessary to prevent a loss of synchronization of message sequence 667 numbers between client and server. A command is not "in progress" 668 until the complete command has been received; in particular, a 669 command is not "in progress" during the negotiation of command 670 continuation. 672 Note: UID FETCH, UID STORE, and UID SEARCH are different commands 673 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent 674 during a UID command. However, the VANISHED response MUST NOT be 675 sent during a UID SEARCH command that contains message numbers in the 676 search criteria. 678 The update from the VANISHED response MUST be recorded by the client. 680 Example: Let's assume that there is the following mapping between 681 message numbers and UIDs in the currently selected mailbox (here "X" 682 marks messages with the \Deleted flag set, and "x" represents UIDs 683 which are not relevant for the example): 685 Message numbers: 1 2 3 4 5 6 7 8 9 10 11 686 UIDs: x 504 505 507 508 x 510 x x x 625 687 \Deleted messages: X X X X 689 In the presence of the extension defined in this document: 691 C: A202 EXPUNGE 692 S: * VANISHED 505,507,510,625 693 S: A202 OK EXPUNGE completed 695 Without the QRESYNC extension, the same example might look like: 697 C: A202 EXPUNGE 698 S: * 3 EXPUNGE 699 S: * 3 EXPUNGE 700 S: * 5 EXPUNGE 701 S: * 8 EXPUNGE 702 S: A202 OK EXPUNGE completed 704 (Continuing previous example) If subsequently messages with UIDs 504 705 and 508 got marked as \Deleted: 707 C: A210 EXPUNGE 708 S: * VANISHED 504,508 709 S: A210 OK EXPUNGE completed 711 i.e., the last VANISHED response only contains UIDs of messages 712 expunged since the previous VANISHED response. 714 3.7. CLOSED Response Code 716 The CLOSED response code has no parameters. A server implementing 717 the extension defined in this document MUST return the CLOSED 718 response code when the currently selected mailbox is closed 719 implicitly using the SELECT/EXAMINE command on another mailbox. The 720 CLOSED response code serves as a boundary between responses for the 721 previously opened mailbox (which was closed) and the newly selected 722 mailbox: all responses before the CLOSED response code relate to the 723 mailbox that was closed, and all subsequent responses relate to the 724 newly opened mailbox. 726 There is no need to return the CLOSED response code on completion of 727 the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose 728 purpose is to close the currently selected mailbox without opening a 729 new one. 731 4. Server Implementation Considerations 733 This section describes a minimalist implementation, a moderate 734 implementation, and an example of a full implementation. 736 4.1. Server Implementations That Don't Store Extra State 738 Strictly speaking, a server implementation that doesn't remember mod- 739 sequences associated with expunged messages can be considered 740 compliant with this specification. Such implementations return all 741 expunged messages specified in the UID set of the UID FETCH 742 (VANISHED) command every time, without paying attention to the 743 specified CHANGEDSINCE mod-sequence. Such implementations are 744 discouraged, as they can end up returning VANISHED responses that are 745 bigger than the result of a UID SEARCH command for the same UID set. 747 Clients that use the message sequence match data can reduce the scope 748 of this VANISHED response substantially in the typical case where 749 expunges have not happened, or happen only toward the end of the 750 mailbox. 752 4.2. Server Implementations Storing Minimal State 754 A server that stores the HIGHESTMODSEQ value at the time of the last 755 EXPUNGE can omit the VANISHED response when a client provides a 756 MODSEQ value that is equal to, or higher than, the current value of 757 this datum, that is, when there have been no EXPUNGEs. 759 A client providing message sequence match data can reduce the scope 760 as above. In the case where there have been no expunges, the server 761 can ignore this data. 763 4.3. Additional State Required on the Server 765 When compared to the [CONDSTORE] extension, this extension requires 766 servers to store additional state associated with expunged messages. 767 Note that implementations are not required to store this state in 768 persistent storage; however, use of persistent storage is advisable. 770 One possible way to correctly implement the extension described in 771 this document is to store a queue of pairs. 772 can be represented as a sequence of 773 pairs. 775 When messages are expunged, one or more entries are added to the 776 queue tail. 778 When the server receives a request to return messages expunged since 779 a given mod-sequence, it will search the queue from the tail (i.e., 780 going from the highest expunged mod-sequence to the lowest) until it 781 sees the first record with a mod-sequence less than or equal to the 782 given mod-sequence or it reaches the head of the queue. 784 Note that indefinitely storing information about expunged messages 785 can cause storage and related problems for an implementation. In the 786 worst case, this could result in almost 64Gb of storage for each IMAP 787 mailbox. For example, consider an implementation that stores triples for each range of messages 789 expunged at the same time. Each triple requires 16 octets: 4 octets 790 for each of the two UIDs, and 8 octets for the mod-sequence. Assume 791 that there is a mailbox containing a single message with a UID of 792 2**32-1 (the maximum possible UID value), where messages had 793 previously existed with UIDs starting at 1, and have been expunged 794 one at a time. For this mailbox alone, storage is required for the 795 triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, 796 modseq4294967294>. 798 Hence, implementations are encouraged to adopt strategies to protect 799 against such storage problems, such as limiting the size of the queue 800 used to store mod-sequences for expunged messages and "expiring" 801 older records when this limit is reached. When the selected 802 implementation-specific queue limit is reached, the oldest record(s) 803 are deleted from the queue (note that such records are located at the 804 queue head). For all such "expired" records, the server needs to 805 store a single mod-sequence, which is the highest mod-sequence for 806 all "expired" expunged messages. 808 Note that if the client provides the message sequence match data, 809 this can heavily reduce the data cost of sending a complete set of 810 missing UIDs; thus, reducing the problems for clients if a server is 811 unable to persist much of this queue. If the queue contains data 812 back to the requested mod-sequence, this data can be ignored. 814 Also, note that if the UIDVALIDITY of the mailbox changes or if the 815 mailbox is deleted, then any state associated with expunged messages 816 doesn't need to be preserved and SHOULD be deleted. 818 5. Updated Synchronization Sequence 820 This section updates the description of optimized synchronization in 821 Section 6.1 of the [IMAP-DISC]. 823 An advanced disconnected mail client should use the QRESYNC and 824 [CONDSTORE] extensions when they are supported by the server. The 825 client uses the value from the HIGHESTMODSEQ OK response code 826 received on mailbox opening to determine if it needs to 827 resynchronize. Once the synchronization is complete, it MUST cache 828 the received value (unless the mailbox UIDVALIDITY value has changed; 829 see below). The client MUST update its copy of the HIGHESTMODSEQ 830 value whenever the server sends a subsequent HIGHESTMODSEQ OK 831 response code. 833 After completing a full synchronization, the client MUST also take 834 note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ 835 response codes received from the server. Whenever the client 836 receives a tagged response to a command, it checks the received 837 unsolicited responses to calculate the new HIGHESTMODSEQ value. If 838 the HIGHESTMODSEQ response code is received, the client MUST use it 839 even if it has seen higher mod-sequences. Otherwise, the client 840 calculates the highest value among all MODSEQ FETCH data items 841 received since the last tagged response. If this value is bigger 842 than the client's copy of the HIGHESTMODSEQ value, then the client 843 MUST use this value as its new HIGHESTMODSEQ value. 845 Example: 847 C: A150 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen 848 S: * 1 FETCH (UID 6 MODSEQ (103)) 849 S: * 2 FETCH (UID 7 MODSEQ (101)) 850 S: * OK [HIGHESTMODSEQ 99] VANISHED reply with MODSEQ 100 is delayed 851 S: A150 OK [MODIFIED 3] done 853 C: A151 STORE 3 +FLAGS.SILENT \Seen 854 S: * 3 FETCH (UID 8 MODSEQ (104)) 855 S: A151 OK [HIGHESTMODSEQ 99] Still delaying VANISHED 857 C: A152 NOOP 858 S: * VANISHED 8 859 S: A153 OK [HIGHESTMODSEQ 104] done 861 Note: It is not safe to update the client's copy of the HIGHESTMODSEQ 862 value with a MODSEQ FETCH data item value as soon as it is received 863 because servers are not required to send MODSEQ FETCH data items in 864 increasing modseqence order. Some commands may also delay EXPUNGE 865 (or VANISHED) replies with smaller mod-sequences. These can lead to 866 the client missing some changes in case of connectivity loss. 868 When opening the mailbox for synchronization, the client uses the 869 QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC 870 parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ 871 values, as known to the client. It can be optionally followed by the 872 set of UIDs, for example, if the client is only interested in partial 873 synchronization of the mailbox. The client may also transmit a list 874 containing its knowledge of message numbers. 876 If the SELECT/EXAMINE command is successful, the client compares 877 UIDVALIDITY as described in step d)1) in Section 3 of the 878 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 879 returned by the server and the server also returns the HIGHESTMODSEQ 880 response code, then the server reports expunged messages and returns 881 flag changes for all messages specified by the client in the UID set 882 parameter (or for all messages in the mailbox, if the client omitted 883 the UID set parameter). At this point, the client is synchronized, 884 except for maybe the new messages. 886 If upon a successful SELECT/EXAMINE (QRESYNC) command the client 887 receives a NOMODSEQ OK untagged response (instead of the 888 HIGHESTMODSEQ response code), it MUST remove the last known 889 HIGHESTMODSEQ value from its cache and follow the more general 890 instructions in Section 3 of the [IMAP-DISC]. 892 At this point, the client is in sync with the server regarding old 893 messages. This client can now fetch information about new messages 894 (if requested by the user). 896 Step d) ("Server-to-client synchronization") in Section 4 of the 897 [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is 898 amended as follows: 900 d) "Server-to-client synchronization" -- for each mailbox that 901 requires synchronization, do the following: 903 1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC] 904 for more details) after issuing SELECT/EXAMINE (QRESYNC) command. 906 If the UIDVALIDITY value returned by the server differs, the 907 client MUST 909 * empty the local cache of that mailbox; 911 * "forget" the cached HIGHESTMODSEQ value for the mailbox; 913 * remove any pending "actions" which refer to UIDs in that 914 mailbox. Note, this doesn't affect actions performed on 915 client generated fake UIDs (see Section 5 of the 916 [IMAP-DISC]); 918 2) Fetch the current "descriptors"; 920 I) Discover new messages. 922 3) Fetch the bodies of any "interesting" messages that the client 923 doesn't already have. 925 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ 926 value has changed on the server while the client was 927 offline: 929 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198)) 930 S: * 172 EXISTS 931 S: * 1 RECENT 932 S: * OK [UNSEEN 12] Message 12 is first unseen 933 S: * OK [UIDVALIDITY 3857529045] UIDs valid 934 S: * OK [UIDNEXT 201] Predicted next UID 935 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 936 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 937 S: * OK [HIGHESTMODSEQ 20010715194045007] Highest 938 mailbox mod-sequence 939 S: * VANISHED (EARLIER) 1:5,7:8,10:15 940 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) 941 FLAGS (\Deleted)) 942 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) 943 FLAGS ($NoJunk $AutoJunk $MDNSent)) 944 ... 945 S: A142 OK [READ-WRITE] SELECT completed 947 6. Formal Syntax 949 The following syntax specification uses the Augmented Backus-Naur 950 Form (ABNF) notation as specified in [ABNF]. 952 Non-terminals referenced but not defined below are as defined by 953 [RFC3501], [CONDSTORE], or [IMAPABNF]. 955 Except as noted otherwise, all alphabetic characters are case- 956 insensitive. The use of upper or lower case characters to define 957 token strings is for editorial clarity only. Implementations MUST 958 accept these strings in a case-insensitive fashion. 960 capability =/ "QRESYNC" 962 select-param = "QRESYNC" SP "(" uidvalidity SP 963 mod-sequence-value [SP known-uids] 964 [SP seq-match-data] ")" 965 ;; conforms to the generic select-param 966 ;; syntax defined in [IMAPABNF] 968 seq-match-data = "(" known-sequence-set SP known-uid-set ")" 970 uidvalidity = nz-number 972 known-uids = sequence-set 973 ;; sequence of UIDs, "*" is not allowed 975 known-sequence-set = sequence-set 976 ;; set of message numbers corresponding to 977 ;; the UIDs in known-uid-set, in ascending order. 978 ;; * is not allowed. 980 known-uid-set = sequence-set 981 ;; set of UIDs corresponding to the messages in 982 ;; known-sequence-set, in ascending order. 983 ;; * is not allowed. 985 message-data =/ expunged-resp 987 expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids 989 rexpunges-fetch-mod = "VANISHED" 990 ;; VANISHED UID FETCH modifier conforms 991 ;; to the fetch-modifier syntax 992 ;; defined in [IMAPABNF]. It is only 993 ;; allowed in the UID FETCH command. 995 resp-text-code =/ "CLOSED" 997 7. Security Considerations 999 As always, it is important to thoroughly test clients and servers 1000 implementing this extension, as it changes how the server reports 1001 expunged messages to the client. 1003 Security considerations relevant to [CONDSTORE] are relevant to this 1004 extension. 1006 This document doesn't raise any new security concerns not already 1007 raised by [CONDSTORE] or [RFC3501]. 1009 8. IANA Considerations 1011 IMAP4 capabilities are registered by publishing a standards track or 1012 IESG approved experimental RFC. The registry is currently located 1013 at: 1015 http://www.iana.org/assignments/imap4-capabilities 1017 This document defines the QRESYNC IMAP capability. IANA has added 1018 this capability to the registry. 1020 9. Acknowledgments 1022 Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging 1023 creation of this document. 1025 Valuable comments, both in agreement and in dissent, were received 1026 from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, 1027 Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp, 1028 Eric Rescorla, Mike Zraly and Alfred Hoenes. 1030 This document takes substantial text from [RFC3501] by Mark Crispin. 1032 10. References 1034 10.1. Normative References 1036 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1037 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1039 [CONDSTORE] 1040 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1041 STORE Operation or Quick Flag Changes Resynchronization", 1042 RFC 4551, June 2006. 1044 [ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP 1045 ENABLE Extension", RFC 5161, March 2008. 1047 [IMAPABNF] 1048 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1049 ABNF", RFC 4466, April 2006. 1051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1052 Requirement Levels", BCP 14, RFC 2119, March 1997. 1054 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1055 4rev1", RFC 3501, March 2003. 1057 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 1058 UIDPLUS extension", RFC 4315, December 2005. 1060 10.2. Informative References 1062 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 1063 RFC 4314, December 2005. 1065 [IMAP-DISC] 1066 Melnikov, A., Ed., "Synchronization Operations For 1067 Disconnected Imap4 Clients", RFC 4549, June 2006. 1069 [NTP] Mills, D., "Network Time Protocol (Version 3) 1070 Specification, Implementation and Analysis", RFC 1305, 1071 March 1992. 1073 [RFC-2180] 1074 Gahrns, M., Ed., "IMAP4 Multi-Accessed Mailbox Practice", 1075 RFC 2180, July 1997. 1077 [UNSELECT] 1078 Melnikov, A., "Internet Message Access Protocol (IMAP) 1079 UNSELECT command", RFC 3691, February 2004. 1081 Appendix A. Changes since RFC 5162 1083 Addressed erratum #1365: 1084 http://www.rfc-editor.org/errata_search.php?eid=1365 1086 Addressed erratum #1807: 1087 http://www.rfc-editor.org/errata_search.php?eid=1807 1089 Addressed erratum #1808: 1090 http://www.rfc-editor.org/errata_search.php?eid=1808 1092 Addressed erratum #1809: 1093 http://www.rfc-editor.org/errata_search.php?eid=1809 1095 Addressed erratum #3322: 1096 http://www.rfc-editor.org/errata_search.php?eid=3322 1098 Fixed some examples to report data that match requirements specified 1099 in the document. 1101 Authors' Addresses 1103 Alexey Melnikov 1104 Isode Ltd 1105 5 Castle Business Village 1106 36 Station Road 1107 Hampton, Middlesex TW12 2BX 1108 UK 1110 Email: Alexey.Melnikov@isode.com 1112 Dave Cridland 1113 Isode Ltd 1114 5 Castle Business Village 1115 36 Station Road 1116 Hampton, Middlesex TW12 2BX 1117 UK 1119 Email: dave.cridland@isode.com