idnits 2.17.00 (12 Aug 2021) /tmp/idnits15978/draft-melnikov-5162bis-00.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 (October 5, 2012) is 3514 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 898, but not defined == Missing Reference: 'UIDNEXT 550' is mentioned on line 237, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060128194045007' is mentioned on line 238, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 897, but not defined == Missing Reference: 'UIDVALIDITY 67890007' is mentioned on line 363, but not defined == Missing Reference: 'UIDNEXT 30013' is mentioned on line 364, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060115205545359' is mentioned on line 365, but not defined == Missing Reference: 'UNSEEN 7' is mentioned on line 367, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045319' is mentioned on line 572, but not defined == Missing Reference: 'UIDNEXT 201' is mentioned on line 899, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 902, but not defined == Unused Reference: 'ACL' is defined on line 1027, but no explicit reference was found in the text == Unused Reference: 'NTP' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: 'RFC-2180' is defined on line 1038, 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 (~~), 15 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) October 5, 2012 6 Intended status: Standards Track 7 Expires: April 8, 2013 9 IMAP4 Extensions for Quick Mailbox Resynchronization 10 draft-melnikov-5162bis-00.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 April 8, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . 10 62 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 12 63 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 12 64 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 13 65 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 16 66 4. Server Implementation Considerations . . . . . . . . . . . . . 16 67 4.1. Server Implementations That Don't Store Extra State . . . 16 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 . . . . . . . . . . . . . . . . . . . . . 22 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 80 1. Introduction and Overview 82 The [CONDSTORE] extension gives a disconnected client the ability to 83 quickly resynchronize IMAP flag changes for previously seen messages. 84 This can be done using the CHANGEDSINCE FETCH modifier once a mailbox 85 is opened. In order for the client to discover which messages have 86 been expunged, the client still has to issue a UID FETCH or a UID 87 SEARCH command. This document defines an extension to [CONDSTORE] 88 that allows a reconnecting client to perform full resynchronization, 89 including discovery of expunged messages, in a single round-trip. 90 This extension also introduces a new response, VANISHED, that allows 91 for a more compact representation of a list of expunged messages. 93 This extension can be useful for mobile clients that can experience 94 frequent disconnects caused by environmental factors (battery life, 95 signal strength, etc.). Such clients need a way to quickly reconnect 96 to the IMAP server, while minimizing delay experienced by the user as 97 well as the amount of traffic (and hence the expense) generated by 98 resynchronization. 100 By extending the SELECT command to perform the additional 101 resynchronization, this also allows clients to reduce concurrent 102 connections to the IMAP server held purely for the sake of avoiding 103 the resynchronization. 105 The quick resync IMAP extension is present if an IMAP4 server returns 106 "QRESYNC" as one of the supported capabilities to the CAPABILITY 107 command. 109 Servers supporting this extension MUST implement and advertise 110 support for the [ENABLE] IMAP extension. Also, the presence of the 111 "QRESYNC" capability implies support for the [CONDSTORE] IMAP 112 extension even if the "CONDSTORE" capability isn't advertised. A 113 server compliant with this specification is REQUIREd to support 114 "ENABLE QRESYNC" and "ENABLE QRESYNC CONDSTORE" (which are "CONDSTORE 115 enabling commands", as defined in [CONDSTORE], and have identical 116 results), but there is no requirement for a compliant server to 117 support "ENABLE CONDSTORE" by itself. The "ENABLE QRESYNC"/"ENABLE 118 QRESYNC CONDSTORE" command also tells the server that //// it SHOULD 119 start sending VANISHED responses (see Section 3.6) instead of EXPUNGE 120 responses. This change remains in effect until the connection is 121 closed. 123 For compatibility with clients that only support the [CONDSTORE] IMAP 124 extension, servers SHOULD advertise "CONDSTORE" in the CAPABILITY 125 response as well. 127 Once a "CONDSTORE enabling command" is issued by the client, the 128 server MUST automatically include both UID and mod-sequence data in 129 all subsequent untagged FETCH responses (until the connection is 130 closed), whether they were caused by a regular STORE/UID STORE, a 131 STORE/UID STORE with UNCHANGEDSINCE modifier, FETCH/UID FETCH that 132 implicitly set \Seen flag or an external agent. Note that this rule 133 doesn't affect untagged FETCH responses caused by a FETCH command 134 that doesn't include UID and/or MODSEQ FETCH data item (and doesn't 135 set \Seen flag), or UID FETCH without the MODSEQ FETCH data item. 137 A client making use of this extension MUST issue "ENABLE QRESYNC" 138 once it is authenticated. A server MUST respond with a tagged BAD 139 response if the QRESYNC parameter to the SELECT/EXAMINE command or 140 the VANISHED UID FETCH modifier is specified and the client hasn't 141 issued "ENABLE QRESYNC", or the server has not positively responded 142 to that command with the untagged ENABLED response containing 143 QRESYNC, in the current connection. 145 This document puts additional requirements on a server implementing 146 the [CONDSTORE] extension. Each mailbox that supports persistent 147 storage of mod-sequences, i.e., for which the server has sent a 148 HIGHESTMODSEQ untagged OK response code on a successful SELECT/ 149 EXAMINE, MUST increment the per-mailbox mod-sequence when one or more 150 messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the 151 server MUST associate the incremented mod-sequence with the UIDs of 152 the expunged messages. 154 A client that supports CONDSTORE but not this extension might 155 resynchronize a mailbox and discover that its HIGHESTMODSEQ has 156 increased from the value cached by the client. If the increase is 157 only due to messages having been expunged since the client last 158 synchronized, the client is likely to send a FETCH ... CHANGEDSINCE 159 command that returns no data. Thus, a client that supports CONDSTORE 160 but not this extension might incur a penalty of an unneeded round- 161 trip when resynchronizing some mailboxes (those that have had 162 messages expunged but no flag changes since the last 163 synchronization). 165 This extra round-trip is only incurred by clients that support 166 CONDSTORE but not this extension, and only when a mailbox has had 167 messages expunged but no flag changes to non-expunged messages. 168 Since CONDSTORE is a relatively new extension, it is thought likely 169 that clients that support it will also support this extension. 171 2. Requirements Notation 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 In examples, "C:" and "S:" indicate lines sent by the client and 178 server respectively. If a single "C:" or "S:" label applies to 179 multiple lines, then the line breaks between those lines are for 180 editorial clarity only and are not part of the actual protocol 181 exchange. The five characters [...] means that something has been 182 elided. 184 Understanding of the IMAP message sequence numbers and UIDs and the 185 EXPUNGE response [RFC3501] is essential when reading this document. 187 3. IMAP Protocol Changes 189 3.1. QRESYNC Parameter to SELECT/EXAMINE 191 The Quick Resynchronization parameter to SELECT/EXAMINE commands has 192 four arguments: 194 o the last known UIDVALIDITY, 196 o the last known modification sequence, 198 o the optional set of known UIDs, and 200 o an optional parenthesized list of known sequence ranges and their 201 corresponding UIDs. 203 A server MUST respond with a tagged BAD response if the Quick 204 Resynchronization parameter to SELECT/EXAMINE command is specified 205 and the client hasn't issued "ENABLE QRESYNC" in the current 206 connection, or the server has not positively responded to that 207 command with the untagged ENABLED response containing QRESYNC. 209 Before opening the specified mailbox, the server verifies all 210 arguments for syntactic validity. If any parameter is not 211 syntactically valid, the server returns the tagged BAD response, and 212 the mailbox remains unselected. Once the check is done, the server 213 opens the mailbox as if no SELECT/EXAMINE parameters are specified 214 (this is subject to processing of other parameters as defined in 215 other extensions). In particular this means that the server MUST 216 send all untagged responses as specified in Sections 6.3.1 and 6.3.2 217 of [RFC3501]. 219 After that, the server checks the UIDVALIDITY value provided by the 220 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY 221 for the mailbox being opened, then the server MUST ignore the 222 remaining parameters and behave as if no dynamic message data 223 changed. The client can discover this situation by comparing the 224 UIDVALIDITY value returned by the server. This behavior allows the 225 client not to synchronize the mailbox or decide on the best 226 synchronization strategy. 228 Example: Attempting to resynchronize INBOX, but the provided 229 UIDVALIDITY parameter doesn't match the current UIDVALIDITY 230 value. 232 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 233 41,43:211,214:541)) 234 S: * 464 EXISTS 235 S: * 3 RECENT 236 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 237 S: * OK [UIDNEXT 550] Predicted next UID 238 S: * OK [HIGHESTMODSEQ 90060128194045007] Highest mailbox 239 mod-sequence 240 S: * OK [UNSEEN 12] Message 12 is first unseen 241 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 242 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 243 \Deleted \Seen \*)] Permanent flags 244 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch 246 Modification Sequence and UID Parameters: 248 A server that doesn't support the persistent storage of mod-sequences 249 for the mailbox MUST send the OK untagged response including the 250 NOMODSEQ response code with every successful SELECT or EXAMINE 251 command, as described in [CONDSTORE]. Such a server doesn't need to 252 remember mod-sequences for expunged messages in the mailbox. It MUST 253 ignore the remaining parameters and behave as if no dynamic message 254 data changed. 256 If the provided UIDVALIDITY matches that of the selected mailbox, the 257 server then checks the last known modification sequence. 258 The server sends the client any pending flag changes (using FETCH 259 responses that MUST contain UIDs) and expunges those that have 260 occurred in this mailbox since the provided modification sequence. 262 If the list of known UIDs was also provided, the server should only 263 report flag changes and expunges for the specified messages. If the 264 client did not provide the list of UIDs, the server acts as if the 265 client has specified "1:", where is the mailbox's 266 UIDNEXT value minus 1. If the mailbox is empty and never had any 267 messages in it, then lack of the list of UIDs is interpreted as an 268 empty set of UIDs. 270 Thus, the client can process just these pending events and need not 271 perform a full resynchronization. Without the message sequence 272 number matching information, the result of this step is semantically 273 equivalent to the client issuing: 274 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE 275 "mod-sequence-value" VANISHED) 277 Example: 278 C: A03 SELECT INBOX (QRESYNC (67890007 279 90060115194045000 41,43:211,214:541)) 280 S: * OK [CLOSED] 281 S: * 314 EXISTS 282 S: * 15 RECENT 283 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 284 S: * OK [UIDNEXT 567] Predicted next UID 285 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 286 sequence 287 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 288 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 289 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 290 \Deleted \Seen \*)] Permanent flags 291 S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540 292 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered) MODSEQ 293 (90060115194045001)) 294 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent) MODSEQ 295 (90060115194045308)) 296 S: ... 297 S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded) MODSEQ 298 (90060115194045001)) 299 S: A03 OK [READ-WRITE] mailbox selected 301 Message sequence match data: 303 A client MAY provide a parenthesized list of a message sequence set 304 and the corresponding UID sets. Both MUST be provided in ascending 305 order. The server uses this data to restrict the range for which it 306 provides expunged message information. 308 Conceptually, the client provides a small sample of sequence numbers 309 for which it knows the corresponding UIDs. The server then compares 310 each sequence number and UID pair the client provides with the 311 current state of the mailbox. If a pair matches, then the client 312 knows of any expunges up to, and including, the message, and thus 313 will not include that range in the VANISHED response, even if the 314 "mod-sequence-value" provided by the client is too old for the server 315 to have data of when those messages were expunged. 317 Thus, if the Nth message number in the first set in the list is 4, 318 and the Nth UID in the second set in the list is 8, and the mailbox's 319 fourth message has UID 8, then no UIDs equal to or less than 8 are 320 present in the VANISHED response. If the (N+1)th message number is 321 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox 322 has UID 25, then the lowest UID included in the VANISHED response 323 would be 9. 325 In the following two examples, the server is unable to remember 326 expunges at all, and only UIDs with messages divisible by three are 327 present in the mailbox. In the first example, the client does not 328 use the fourth parameter; in the second, it provides it. This 329 example is somewhat extreme, but shows that judicious usage of the 330 sequence match data can save a substantial amount of bandwidth. 332 Example: 333 C: A04 SELECT INBOX (QRESYNC (67890007 334 90060115194045000 1:29997)) 335 S: * 10003 EXISTS 336 S: * 5 RECENT 337 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 338 S: * OK [UIDNEXT 30013] Predicted next UID 339 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 340 sequence 341 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 342 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 343 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 344 \Deleted \Seen \*)] Permanent flags 345 S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...] 346 29998:29999,30001:30002,30004:30005,30007:30008 347 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ 348 (90060115194045027)) 349 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ 350 (90060115194045028)) 351 S: ... 352 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ 353 (90060115194045031)) 354 S: A04 OK [READ-WRITE] mailbox selected 356 Example: 357 C: B04 SELECT INBOX (QRESYNC (67890007 358 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 359 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 360 29994,29997))) 361 S: * 10003 EXISTS 362 S: * 5 RECENT 363 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 364 S: * OK [UIDNEXT 30013] Predicted next UID 365 S: * OK [HIGHESTMODSEQ 90060115205545359] Highest mailbox mod- 366 sequence 367 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 368 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 369 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 370 \Deleted \Seen \*)] Permanent flags 371 S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007: 372 30008 373 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered) MODSEQ 374 (90060115194045027)) 375 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent) MODSEQ 376 (90060115194045028)) 377 S: ... 378 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded) MODSEQ 379 (90060115194045031)) 380 S: B04 OK [READ-WRITE] mailbox selected 382 3.2. VANISHED UID FETCH Modifier 384 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH 385 commands to include an optional FETCH modifier. This document 386 defines a new UID FETCH modifier: VANISHED. 388 Note, that the VANISHED UID FETCH modifier is NOT allowed with a 389 FETCH command. The server MUST return a tagged BAD response if this 390 response is specified as a modifier to the FETCH command. 392 A server MUST respond with a tagged BAD response if the VANISHED UID 393 FETCH modifier is specified and the client hasn't issued "ENABLE 394 QRESYNC" in the current connection. 396 The VANISHED UID FETCH modifier MUST only be specified together with 397 the CHANGEDSINCE UID FETCH modifier. 399 The VANISHED UID FETCH modifier instructs the server to report those 400 messages from the UID set parameter that have been expunged and whose 401 associated mod-sequence is larger than the specified mod-sequence. 402 That is, the client requests to be informed of messages from the 403 specified set that were expunged since the specified mod-sequence. 404 Note that the mod-sequence(s) associated with these messages were 405 updated when the messages were expunged (as described above). The 406 expunged messages are reported using the VANISHED response as 407 described in Section 3.6, which MUST contain the EARLIER tag. Any 408 VANISHED (EARLIER) responses MUST be returned before any FETCH 409 responses, as otherwise the client might get confused about how 410 message numbers map to UIDs. 412 Note: A server that receives a mod-sequence smaller than , 413 where is the value of the smallest expunged mod-sequence 414 it remembers minus one, MUST behave as if it was requested to report 415 all expunged messages from the provided UID set parameter. 417 Example 1: Without the VANISHED UID FETCH modifier, a CONDSTORE-aware 418 client [CONDSTORE] needs to issue separate commands to learn of flag 419 changes and expunged messages since the last synchronization: 421 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) 422 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 423 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 424 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 425 $AutoJunk $MDNSent)) 426 S: s100 OK FETCH completed 427 C: s101 UID SEARCH 300:500 428 S: * SEARCH 404 406 407 408 410 412 429 S: s101 OK search completed 431 Where 300 and 500 are the lowest and highest UIDs from client's 432 cache. The second SEARCH response tells the client that the messages 433 with UIDs 407, 410, and 412 are still present, but their flags 434 haven't changed since the specified modification sequence. 436 Using the VANISHED UID FETCH modifier, it is sufficient to issue only 437 a single command: 439 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 440 VANISHED) 441 S: * VANISHED (EARLIER) 300:310,405,411 442 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 443 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 444 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 445 $AutoJunk $MDNSent)) 446 S: s100 OK FETCH completed 448 3.3. EXPUNGE Command 450 Arguments: none 452 Responses: untagged responses: EXPUNGE or VANISHED 453 Result: OK - expunge completed 454 NO - expunge failure: can't expunge (e.g., permission denied) 455 BAD - command unknown or arguments invalid 457 This section updates the definition of the EXPUNGE command described 458 in Section 6.4.3 of [RFC3501]. 460 The EXPUNGE command permanently removes all messages that have the 461 \Deleted flag set from the currently selected mailbox. Before 462 returning an OK to the client, those messages that are removed are 463 reported using a VANISHED response or EXPUNGE responses. 465 If the server is capable of storing modification sequences for the 466 selected mailbox, it MUST increment the per-mailbox mod-sequence if 467 at least one message was permanently removed due to the execution of 468 the EXPUNGE command. For each permanently removed message, the 469 server MUST remember the incremented mod-sequence and corresponding 470 UID. If at least one message got expunged, the server MUST send the 471 updated per-mailbox modification sequence using the HIGHESTMODSEQ 472 response code (defined in [CONDSTORE]) in the tagged OK response. 474 Example: C: A202 EXPUNGE 475 S: * 3 EXPUNGE 476 S: * 3 EXPUNGE 477 S: * 5 EXPUNGE 478 S: * 8 EXPUNGE 479 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged 481 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag 482 set. The first "* 3 EXPUNGE" reports message # 3 as expunged. The 483 second "* 3 EXPUNGE" reports message # 4 as expunged (the message 484 number got decremented due to the previous EXPUNGE response). See 485 the description of the EXPUNGE response in [RFC3501] for further 486 explanation. 488 Note that if the server chooses to always send VANISHED responses 489 instead of EXPUNGE responses, the previous example might look like 490 this: 492 Example: C: B202 EXPUNGE 493 S: * VANISHED 405,407,410,425 494 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged 496 Here messages with message numbers 3, 4, 7, and 11 have respective 497 UIDs 405, 407, 410, and 425. 499 3.4. CLOSE Command 501 Arguments: none 503 Responses: no specific responses for this command 505 Result: OK - close completed, now in authenticated state 506 BAD - command unknown or arguments invalid 508 This section updates the definition of the CLOSE command described in 509 Section 6.4.2 of [RFC3501]. 511 The CLOSE command permanently removes all messages that have the 512 \Deleted flag set from the currently selected mailbox, and returns to 513 the authenticated state from the selected state. No untagged EXPUNGE 514 (or VANISHED) responses are sent. 516 If the server is capable of storing modification sequences for the 517 selected mailbox, it MUST increment the per-mailbox mod-sequence if 518 at least one message was permanently removed due to the execution of 519 the CLOSE command. For each permanently removed message, the server 520 MUST remember the incremented mod-sequence and corresponding UID. 521 The server MUST NOT send the updated per-mailbox modification 522 sequence using the HIGHESTMODSEQ response code (defined in 523 [CONDSTORE]) in the tagged OK response, as this might cause loss of 524 synchronization on the client. 526 Example: C: A202 CLOSE 527 S: A202 OK done 529 3.5. UID EXPUNGE Command 531 Arguments: message set 533 Responses: untagged responses: EXPUNGE or VANISHED 535 Result: OK - expunge completed 536 NO - expunge failure: can't expunge (e.g., permission denied) 537 BAD - command unknown or arguments invalid 539 This section updates the definition of the UID EXPUNGE command 540 described in Section 2.1 of [UIDPLUS]. Servers that implement both 541 [UIDPLUS] and QRESYNC extensions must implement UID EXPUNGE as 542 described in this section. 544 The UID EXPUNGE command permanently removes from the currently 545 selected mailbox all messages that both have the \Deleted flag set 546 and have a UID that is included in the specified message set. If a 547 message either does not have the \Deleted flag set or has a UID that 548 is not included in the specified message set, it is not affected. 550 This command is particularly useful for disconnected mode clients. 551 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the 552 server, the client can avoid inadvertently removing any messages that 553 have been marked as \Deleted by other clients between the time that 554 the client was last connected and the time the client resynchronizes. 556 Before returning an OK to the client, those messages that are removed 557 are reported using a VANISHED response or EXPUNGE responses. 559 If the server is capable of storing modification sequences for the 560 selected mailbox, it MUST increment the per-mailbox mod-sequence if 561 at least one message was permanently removed due to the execution of 562 the UID EXPUNGE command. For each permanently removed message, the 563 server MUST remember the incremented mod-sequence and corresponding 564 UID. If at least one message got expunged, the server MUST send the 565 updated per-mailbox modification sequence using the HIGHESTMODSEQ 566 response code (defined in [CONDSTORE]) in the tagged OK response. 568 Example: C: . UID EXPUNGE 3000:3002 569 S: * 3 EXPUNGE 570 S: * 3 EXPUNGE 571 S: * 3 EXPUNGE 572 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok 574 Note: In this example, at least messages with message numbers 3, 4, 575 and 5 (UIDs 3000 to 3002) had the \Deleted flag set. The first "* 3 576 EXPUNGE" reports message # 3 as expunged. The second "* 3 EXPUNGE" 577 reports message # 4 as expunged (the message number got decremented 578 due to the previous EXPUNGE response). See the description of the 579 EXPUNGE response in [RFC3501] for further explanation. 581 3.6. VANISHED Response 583 Contents: an optional EARLIER tag 585 list of UIDs 587 The VANISHED response reports that the specified UIDs have been 588 permanently removed from the mailbox. This response is similar to 589 the EXPUNGE response [RFC3501]; however, it can return information 590 about multiple messages, and it returns UIDs instead of message 591 numbers. The first benefit saves bandwidth, while the second is more 592 convenient for clients that only use UIDs to access the IMAP server. 594 The VANISHED response has the same restrictions on when it can be 595 sent as does the EXPUNGE response (see below). 597 The VANISHED response has two forms. The first form contains the 598 EARLIER tag, which signifies that the response was caused by a UID 599 FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This 600 response is sent if the UID set parameter to the UID FETCH (VANISHED) 601 command includes UIDs of messages that are no longer in the mailbox. 602 When the client sees a VANISHED EARLIER response, it MUST NOT 603 decrement message sequence numbers for each successive message in the 604 mailbox. 606 The second form doesn't contain the EARLIER tag and is described 607 below. Once a client has issued "ENABLE QRESYNC" (and the server has 608 positively responded to that command with the untagged ENABLED 609 response containing QRESYNC), the server SHOULD use the VANISHED 610 response without the EARLIER tag instead of the EXPUNGE response. 611 The server SHOULD continue using VANISHED in lieu of EXPUNGE for the 612 duration of the connection. In particular, this affects the EXPUNGE 613 [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as well as messages 614 expunged in other connections. Such a VANISHED response MUST NOT 615 contain the EARLIER tag. 617 A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command 618 or because messages were expunged in other connections (i.e., the 619 VANISHED response without the EARLIER tag) also decrements the number 620 of messages in the mailbox; it is not necessary for the server to 621 send an EXISTS response with the new value. It also decrements 622 message sequence numbers for each successive message in the mailbox 623 (see the example at the end of this section). 625 Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or 626 messages expunged in other connections MUST only contain UIDs for 627 messages expunged since the last VANISHED/EXPUNGE response sent for 628 the currently opened mailbox or since the mailbox was opened. That 629 is, servers MUST NOT send UIDs for previously expunged messages, 630 unless explicitly requested to do so by the UID FETCH (VANISHED) 631 command. This is required to prevent a possible race condition where 632 new arrivals for which the UID is not yet known by the client are 633 expunged. 635 Note that client implementors must take care to properly decrement 636 the number of messages in the mailbox even if a server violates this 637 last SHOULD or repeats the same UID multiple times in the returned 638 UID set. In general, this means that a client using this extension 639 should either avoid using message numbers entirely, or have a 640 complete mapping of UIDs to message sequence numbers for the selected 641 mailbox. 643 Because clients handle the two different forms of the VANISHED 644 response differently, servers MUST NOT report UIDs resulting from a 645 UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same 646 VANISHED response as UIDs of messages expunged now (i.e., messages 647 expunged in other connections). Instead, the server MUST send 648 separate VANISHED responses: one with the EARLIER tag and one 649 without. 651 A VANISHED response MUST NOT be sent when no command is in progress, 652 nor while responding to a FETCH, STORE, or SEARCH command. This rule 653 is necessary to prevent a loss of synchronization of message sequence 654 numbers between client and server. A command is not "in progress" 655 until the complete command has been received; in particular, a 656 command is not "in progress" during the negotiation of command 657 continuation. 659 Note: UID FETCH, UID STORE, and UID SEARCH are different commands 660 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent 661 during a UID command. However, the VANISHED response MUST NOT be 662 sent during a UID SEARCH command that contains message numbers in the 663 search criteria. 665 The update from the VANISHED response MUST be recorded by the client. 667 Example: Let's assume that there is the following mapping between 668 message numbers and UIDs in the currently selected mailbox (here "X" 669 marks messages with the \Deleted flag set, and "x" represents UIDs 670 which are not relevant for the example): 672 Message numbers: 1 2 3 4 5 6 7 8 9 10 11 673 UIDs: x 504 505 507 508 x 510 x x x 625 674 \Deleted messages: X X X X 676 In the presence of the extension defined in this document: 678 C: A202 EXPUNGE 679 S: * VANISHED 505,507,510,625 680 S: A202 OK EXPUNGE completed 681 Without the QRESYNC extension, the same example might look like: 683 C: A202 EXPUNGE 684 S: * 3 EXPUNGE 685 S: * 3 EXPUNGE 686 S: * 5 EXPUNGE 687 S: * 8 EXPUNGE 688 S: A202 OK EXPUNGE completed 690 (Continuing previous example) If subsequently messages with UIDs 504 691 and 508 got marked as \Deleted: 693 C: A210 EXPUNGE 694 S: * VANISHED 504,508 695 S: A210 OK EXPUNGE completed 697 i.e., the last VANISHED response only contains UIDs of messages 698 expunged since the previous VANISHED response. 700 3.7. CLOSED Response Code 702 The CLOSED response code has no parameters. A server implementing 703 the extension defined in this document MUST return the CLOSED 704 response code when the currently selected mailbox is closed 705 implicitly using the SELECT/EXAMINE command on another mailbox. The 706 CLOSED response code serves as a boundary between responses for the 707 previously opened mailbox (which was closed) and the newly selected 708 mailbox: all responses before the CLOSED response code relate to the 709 mailbox that was closed, and all subsequent responses relate to the 710 newly opened mailbox. 712 There is no need to return the CLOSED response code on completion of 713 the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose 714 purpose is to close the currently selected mailbox without opening a 715 new one. 717 4. Server Implementation Considerations 719 This section describes a minimalist implementation, a moderate 720 implementation, and an example of a full implementation. 722 4.1. Server Implementations That Don't Store Extra State 724 Strictly speaking, a server implementation that doesn't remember mod- 725 sequences associated with expunged messages can be considered 726 compliant with this specification. Such implementations return all 727 expunged messages specified in the UID set of the UID FETCH 728 (VANISHED) command every time, without paying attention to the 729 specified CHANGEDSINCE mod-sequence. Such implementations are 730 discouraged, as they can end up returning VANISHED responses that are 731 bigger than the result of a UID SEARCH command for the same UID set. 733 Clients that use the message sequence match data can reduce the scope 734 of this VANISHED response substantially in the typical case where 735 expunges have not happened, or happen only toward the end of the 736 mailbox. 738 4.2. Server Implementations Storing Minimal State 740 A server that stores the HIGHESTMODSEQ value at the time of the last 741 EXPUNGE can omit the VANISHED response when a client provides a 742 MODSEQ value that is equal to, or higher than, the current value of 743 this datum, that is, when there have been no EXPUNGEs. 745 A client providing message sequence match data can reduce the scope 746 as above. In the case where there have been no expunges, the server 747 can ignore this data. 749 4.3. Additional State Required on the Server 751 When compared to the [CONDSTORE] extension, this extension requires 752 servers to store additional state associated with expunged messages. 753 Note that implementations are not required to store this state in 754 persistent storage; however, use of persistent storage is advisable. 756 One possible way to correctly implement the extension described in 757 this document is to store a queue of pairs. 758 can be represented as a sequence of 759 pairs. 761 When messages are expunged, one or more entries are added to the 762 queue tail. 764 When the server receives a request to return messages expunged since 765 a given mod-sequence, it will search the queue from the tail (i.e., 766 going from the highest expunged mod-sequence to the lowest) until it 767 sees the first record with a mod-sequence less than or equal to the 768 given mod-sequence or it reaches the head of the queue. 770 Note that indefinitely storing information about expunged messages 771 can cause storage and related problems for an implementation. In the 772 worst case, this could result in almost 64Gb of storage for each IMAP 773 mailbox. For example, consider an implementation that stores triples for each range of messages 775 expunged at the same time. Each triple requires 16 octets: 4 octets 776 for each of the two UIDs, and 8 octets for the mod-sequence. Assume 777 that there is a mailbox containing a single message with a UID of 778 2**32-1 (the maximum possible UID value), where messages had 779 previously existed with UIDs starting at 1, and have been expunged 780 one at a time. For this mailbox alone, storage is required for the 781 triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, 782 modseq4294967294>. 784 Hence, implementations are encouraged to adopt strategies to protect 785 against such storage problems, such as limiting the size of the queue 786 used to store mod-sequences for expunged messages and "expiring" 787 older records when this limit is reached. When the selected 788 implementation-specific queue limit is reached, the oldest record(s) 789 are deleted from the queue (note that such records are located at the 790 queue head). For all such "expired" records, the server needs to 791 store a single mod-sequence, which is the highest mod-sequence for 792 all "expired" expunged messages. 794 Note that if the client provides the message sequence match data, 795 this can heavily reduce the data cost of sending a complete set of 796 missing UIDs; thus, reducing the problems for clients if a server is 797 unable to persist much of this queue. If the queue contains data 798 back to the requested mod-sequence, this data can be ignored. 800 Also, note that if the UIDVALIDITY of the mailbox changes or if the 801 mailbox is deleted, then any state associated with expunged messages 802 doesn't need to be preserved and SHOULD be deleted. 804 5. Updated Synchronization Sequence 806 This section updates the description of optimized synchronization in 807 Section 6.1 of the [IMAP-DISC]. 809 An advanced disconnected mail client should use the QRESYNC and 810 [CONDSTORE] extensions when they are supported by the server. The 811 client uses the value from the HIGHESTMODSEQ OK response code 812 received on mailbox opening to determine if it needs to 813 resynchronize. Once the synchronization is complete, it MUST cache 814 the received value (unless the mailbox UIDVALIDITY value has changed; 815 see below). The client MUST update its copy of the HIGHESTMODSEQ 816 value whenever the server sends a subsequent HIGHESTMODSEQ OK 817 response code. 819 After completing a full synchronization, the client MUST also take 820 note of any unsolicited MODSEQ FETCH data items received from the 821 server. Whenever the client receives a tagged response to a command, 822 it calculates the highest value among all MODSEQ FETCH data items 823 received since the last tagged response. If this value is bigger 824 than the client's copy of the HIGHESTMODSEQ value, then the client 825 MUST use this value as its new HIGHESTMODSEQ value. 827 Note: It is not safe to update the client's copy of the HIGHESTMODSEQ 828 value with a MODSEQ FETCH data item value as soon as it is received 829 because servers are not required to send MODSEQ FETCH data items in 830 increasing modseqence order. This can lead to the client missing 831 some changes in case of connectivity loss. 833 When opening the mailbox for synchronization, the client uses the 834 QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC 835 parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ 836 values, as known to the client. It can be optionally followed by the 837 set of UIDs, for example, if the client is only interested in partial 838 synchronization of the mailbox. The client may also transmit a list 839 containing its knowledge of message numbers. 841 If the SELECT/EXAMINE command is successful, the client compares 842 UIDVALIDITY as described in step d)1) in Section 3 of the 843 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 844 returned by the server and the server also returns the HIGHESTMODSEQ 845 response code, then the server reports expunged messages and returns 846 flag changes for all messages specified by the client in the UID set 847 parameter (or for all messages in the mailbox, if the client omitted 848 the UID set parameter). At this point, the client is synchronized, 849 except for maybe the new messages. 851 If upon a successful SELECT/EXAMINE (QRESYNC) command the client 852 receives a NOMODSEQ OK untagged response (instead of the 853 HIGHESTMODSEQ response code), it MUST remove the last known 854 HIGHESTMODSEQ value from its cache and follow the more general 855 instructions in Section 3 of the [IMAP-DISC]. 857 At this point, the client is in sync with the server regarding old 858 messages. This client can now fetch information about new messages 859 (if requested by the user). 861 Step d) ("Server-to-client synchronization") in Section 4 of the 862 [IMAP-DISC] in the presence of the QRESYNC & CONDSTORE extensions is 863 amended as follows: 865 d) "Server-to-client synchronization" -- for each mailbox that 866 requires synchronization, do the following: 868 1a) Check the mailbox UIDVALIDITY (see Section 4.1 of the [IMAP-DISC] 869 for more details) after issuing SELECT/EXAMINE (QRESYNC) command. 871 If the UIDVALIDITY value returned by the server differs, the 872 client MUST 874 * empty the local cache of that mailbox; 876 * "forget" the cached HIGHESTMODSEQ value for the mailbox; 878 * remove any pending "actions" which refer to UIDs in that 879 mailbox. Note, this doesn't affect actions performed on 880 client generated fake UIDs (see Section 5 of the 881 [IMAP-DISC]); 883 2) Fetch the current "descriptors"; 885 I) Discover new messages. 887 3) Fetch the bodies of any "interesting" messages that the client 888 doesn't already have. 890 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ 891 value has changed on the server while the client was 892 offline: 894 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198)) 895 S: * 172 EXISTS 896 S: * 1 RECENT 897 S: * OK [UNSEEN 12] Message 12 is first unseen 898 S: * OK [UIDVALIDITY 3857529045] UIDs valid 899 S: * OK [UIDNEXT 201] Predicted next UID 900 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 901 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 902 S: * OK [HIGHESTMODSEQ 20010715194045007] Highest 903 mailbox mod-sequence 904 S: * VANISHED (EARLIER) 1:5,7:8,10:15 905 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) 906 FLAGS (\Deleted)) 907 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) 908 FLAGS ($NoJunk $AutoJunk $MDNSent)) 909 ... 910 S: A142 OK [READ-WRITE] SELECT completed 912 6. Formal Syntax 914 The following syntax specification uses the Augmented Backus-Naur 915 Form (ABNF) notation as specified in [ABNF]. 917 Non-terminals referenced but not defined below are as defined by 918 [RFC3501], [CONDSTORE], or [IMAPABNF]. 920 Except as noted otherwise, all alphabetic characters are case- 921 insensitive. The use of upper or lower case characters to define 922 token strings is for editorial clarity only. Implementations MUST 923 accept these strings in a case-insensitive fashion. 925 capability =/ "QRESYNC" 927 select-param = "QRESYNC" SP "(" uidvalidity SP 928 mod-sequence-value [SP known-uids] 929 [SP seq-match-data] ")" 930 ;; conforms to the generic select-param 931 ;; syntax defined in [IMAPABNF] 933 seq-match-data = "(" known-sequence-set SP known-uid-set ")" 935 uidvalidity = nz-number 937 known-uids = sequence-set 938 ;; sequence of UIDs, "*" is not allowed 940 known-sequence-set = sequence-set 941 ;; set of message numbers corresponding to 942 ;; the UIDs in known-uid-set, in ascending order. 943 ;; * is not allowed. 945 known-uid-set = sequence-set 946 ;; set of UIDs corresponding to the messages in 947 ;; known-sequence-set, in ascending order. 948 ;; * is not allowed. 950 message-data =/ expunged-resp 952 expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids 954 rexpunges-fetch-mod = "VANISHED" 955 ;; VANISHED UID FETCH modifier conforms 956 ;; to the fetch-modifier syntax 957 ;; defined in [IMAPABNF]. It is only 958 ;; allowed in the UID FETCH command. 960 resp-text-code =/ "CLOSED" 962 7. Security Considerations 964 As always, it is important to thoroughly test clients and servers 965 implementing this extension, as it changes how the server reports 966 expunged messages to the client. 968 Security considerations relevant to [CONDSTORE] are relevant to this 969 extension. 971 This document doesn't raise any new security concerns not already 972 raised by [CONDSTORE] or [RFC3501]. 974 8. IANA Considerations 976 IMAP4 capabilities are registered by publishing a standards track or 977 IESG approved experimental RFC. The registry is currently located 978 at: 980 http://www.iana.org/assignments/imap4-capabilities 982 This document defines the QRESYNC IMAP capability. IANA has added 983 this capability to the registry. 985 9. Acknowledgments 987 Thanks to Steve Hole, Cyrus Daboo, and Michael Wener for encouraging 988 creation of this document. 990 Valuable comments, both in agreement and in dissent, were received 991 from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, 992 Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp, 993 Eric Rescorla, Mike Zraly and Alfred Hoenes. 995 This document takes substantial text from [RFC3501] by Mark Crispin. 997 10. References 999 10.1. Normative References 1001 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1002 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1004 [CONDSTORE] 1005 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1006 STORE Operation or Quick Flag Changes Resynchronization", 1007 RFC 4551, June 2006. 1009 [ENABLE] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP 1010 ENABLE Extension", RFC 5161, March 2008. 1012 [IMAPABNF] 1013 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1014 ABNF", RFC 4466, April 2006. 1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1017 Requirement Levels", BCP 14, RFC 2119, March 1997. 1019 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1020 4rev1", RFC 3501, March 2003. 1022 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 1023 UIDPLUS extension", RFC 4315, December 2005. 1025 10.2. Informative References 1027 [ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 1028 RFC 4314, December 2005. 1030 [IMAP-DISC] 1031 Melnikov, A., Ed., "Synchronization Operations For 1032 Disconnected Imap4 Clients", RFC 4549, June 2006. 1034 [NTP] Mills, D., "Network Time Protocol (Version 3) 1035 Specification, Implementation and Analysis", RFC 1305, 1036 March 1992. 1038 [RFC-2180] 1039 Gahrns, M., Ed., "IMAP4 Multi-Accessed Mailbox Practice", 1040 RFC 2180, July 1997. 1042 [UNSELECT] 1043 Melnikov, A., "Internet Message Access Protocol (IMAP) 1044 UNSELECT command", RFC 3691, February 2004. 1046 Authors' Addresses 1048 Alexey Melnikov 1049 Isode Ltd 1050 5 Castle Business Village 1051 36 Station Road 1052 Hampton, Middlesex TW12 2BX 1053 UK 1055 Email: Alexey.Melnikov@isode.com 1057 Dave Cridland 1058 Isode Ltd 1059 5 Castle Business Village 1060 36 Station Road 1061 Hampton, Middlesex TW12 2BX 1062 UK 1064 Email: dave.cridland@isode.com