idnits 2.17.1 draft-melnikov-imap-expunged-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 771. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 16, 2006) is 6399 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: 'HIGHESTMODSEQ 20010715194045319' is mentioned on line 332, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 595, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 596, but not defined == Missing Reference: 'UIDNEXT 201' is mentioned on line 597, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 600, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4551 (ref. 'CONDSTORE') (Obsoleted by RFC 7162) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track October 16, 2006 5 Expires: April 19, 2007 7 IMAP4 extension for reporting expunged messages 8 draft-melnikov-imap-expunged-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 19, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines an IMAP extension, which gives a disconnected 42 client ability to quickly learn about expunged messages. This 43 extension also introduces a new response that allows for a more 44 compact representation for a list of expunged messages. 46 Table of Contents 48 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 49 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 50 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4 51 3.1. REPORTEXPUNGES UID FETCH modifier . . . . . . . . . . . . 4 52 3.2. REPORTEXPUNGES Parameter to SELECT and EXAMINE . . . . . . 5 53 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 6 54 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 7 55 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 7 56 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 9 57 4. Server implementation considerations . . . . . . . . . . . . . 11 58 4.1. Server implementations that don't store extra state . . . 11 59 4.2. Additional state required on the server . . . . . . . . . 11 60 5. Updated synchronization sequence . . . . . . . . . . . . . . . 12 61 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 67 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 Intellectual Property and Copyright Statements . . . . . . . . . . 18 71 1. Conventions Used in this Document 73 In examples, "C:" and "S:" indicate lines sent by the client and 74 server respectively. If a single "C:" or "S:" label applies to 75 multiple lines, then the line breaks between those lines are for 76 editorial clarity only and are not part of the actual protocol 77 exchange. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 Understanding of the IMAP message sequence numbers and UIDs and the 84 EXPUNGE response [RFC3501] is essential when reading this document. 86 [[anchor2: Editorial comments and questions are marked like this.]] 88 2. Introduction and Overview 90 The [CONDSTORE] extension gives a disconnected client ability to 91 quickly synchronize IMAP flag changes for previously seen messages. 92 In order for the client to discover which messages have been 93 expunged, the client still has to issue a UID FETCH or a UID SEARCH 94 command. This document defines an extension to [CONDSTORE], that 95 allows a reconnecting client to quickly learn about expunged 96 messages. This extension also introduces a new response VANISHED 97 that allows for a more compact representation for a list of expunged 98 messages. 100 The Expunged Messages Notification extension is present in any IMAP4 101 implementation which advertises "X-DRAFT-I02-EXPUNGED" [[anchor4: 102 Change before publication]] as one of the supported capabilities in 103 the CAPABILITY command response. Any server returning the capability 104 MUST also support the The [CONDSTORE] extension. 106 This document puts additional requirements on a server implementing 107 the [CONDSTORE] extension. Each mailbox that supports persistent 108 storage of mod-sequences, i.e., for which the server has sent a 109 HIGHESTMODSEQ untagged OK response code on a successful SELECT/ 110 EXAMINE, MUST increment the per-mailbox mod-sequence when one or more 111 messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the 112 server MUST associate the incremented mod-sequence with the UIDs of 113 the expunged messages. 115 This change doesn't affect a client that only supports the CONDSTORE 116 extension, however per-mailbox mod-sequence change due to expunges 117 may force the client to send FETCH CHANGEDSINCE that will return no 118 data, thus forcing additional round-trip. [[anchor5: Is this Ok?]] 119 [[anchor6: Should we have a separate per mailbox modseq (for expunged 120 messages) just to address this issue?]] 122 3. IMAP Protocol Changes 124 3.1. REPORTEXPUNGES UID FETCH modifier 126 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH 127 commands to include an optional FETCH modifier. This document 128 defines a new UID FETCH modifier: REPORTEXPUNGES. 130 Note, that the REPORTEXPUNGES UID FETCH modifier is NOT allowed with 131 a FETCH command. The server MUST return a tagged BAD response if 132 this response is specified as a modifier to the FETCH command. 134 The REPORTEXPUNGES UID FETCH modifier MUST only be specified together 135 with the CHANGEDSINCE UID FETCH modifier. [[anchor9: alternative: 136 allow REPORTEXPUNGES by itself, this will mean report all expunged 137 UIDs from the UID set specified in the UID FETCH.]] 139 The REPORTEXPUNGES UID FETCH modifier instructs the server to report 140 those messages from the UID set parameter that have been expunged and 141 whose associated modsequence is larger than the specified 142 modsequence. That is, the client requests to be informed of messages 143 from the specified set that were expunged since the specified 144 modsequence. Note that the modsequence associated with these 145 messages was incremented when the messages were expunged (as 146 described above). The expunged messages are reported using the 147 VANISHED response as described in Section 3.6, which MUST contain the 148 TAG correlator. 150 The REPORTEXPUNGES UID FETCH modifier also instructs the server to 151 replace all further EXPUNGE responses with VANISHED responses. The 152 server MUST do this until the connection is closed. 154 Example 1: Without the REPORTEXPUNGES UID FETCH modifier a CONDSTORE- 155 aware client [CONDSTORE] needs to issue separate commands to learn of 156 flag changes and expunged messages since the last synchronization: 158 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) 159 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 160 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 161 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 162 $AutoJunk $MDNSent)) 163 S: s100 OK FETCH completed 164 C: s101 UID SEARCH 300:500 165 S: * SEARCH 404 406 407 408 410 412 166 S: s101 OK search completed 168 Where 300 and 500 are the lowest and highest UIDs from client's 169 cache. The second SEARCH response tells the client that the messages 170 with UIDs 407, 410 and 412 are still present, but their flags haven't 171 changed since the specified modification sequence. 173 Using the REPORTEXPUNGES UID FETCH modifier it is sufficient to issue 174 only a single command: 176 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 177 REPORTEXPUNGES) 178 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 179 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 180 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 181 $AutoJunk $MDNSent)) 182 S: * VANISHED (TAG "s100") 300:310,405,411 183 S: s100 OK FETCH completed 185 3.2. REPORTEXPUNGES Parameter to SELECT and EXAMINE 187 The X-DRAFT-I02-EXPUNGED extension defines a single optional select 188 parameter, "REPORTEXPUNGES", which tells the server that it SHOULD 189 start sending VANISHED responses (see Section 3.6) instead of EXPUNGE 190 responses. This change remains in effect until the connection is 191 closed. 193 [[anchor11: Note that if we want to make the REPORTEXPUNGES parameter 194 to SELECT/EXAMINE also behave as if UID FETCH (REPORTEXPUNGES) were 195 specified, then we need to add 3 extra arguments to the 196 REPORTEXPUNGES parameter (a la QRESYNC): the last known UIDVALIDITY, 197 the last known modification sequence and the optional list of known 198 UIDs.]] 200 3.3. EXPUNGE Command 202 Arguments: none 204 Responses: untagged responses: EXPUNGE or VANISHED 206 Result: OK - expunge completed 207 NO - expunge failure: can't expunge (e.g., permission 208 denied) 209 BAD - command unknown or arguments invalid 211 This section updates the definition of the EXPUNGE command described 212 in section 6.4.3 of [RFC3501]. 214 The EXPUNGE command permanently removes all messages that have the 215 \Deleted flag set from the currently selected mailbox. Before 216 returning an OK to the client, those messages that are removed are 217 reported using a VANISHED response or EXPUNGE responses. 219 If the server is capable of storing modification sequences for the 220 selected mailbox, it MUST increment the per-mailbox mod-sequence if 221 at least one message was permanently removed due to the execution of 222 the EXPUNGE command. For each permanently removed message the server 223 MUST remember the incremented mod-sequence and corresponding UID. If 224 at least one message got expunged, the server MUST send the updated 225 per-mailbox modification sequence using the HIGHESTMODSEQ response 226 code (defined in [CONDSTORE]) in the tagged OK response. 228 Example: C: A202 EXPUNGE 229 S: * 3 EXPUNGE 230 S: * 3 EXPUNGE 231 S: * 5 EXPUNGE 232 S: * 8 EXPUNGE 233 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged Ok 235 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag 236 set. See the description of the EXPUNGE response in [RFC3501] for 237 further explanation. 239 Note that once the VANISHED response is enabled on the connection the 240 previous example might look like this: 242 Example: C: B202 EXPUNGE 243 S: * VANISHED 405,407,410,425 244 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged Ok 246 Here messages with message numbers 3, 4, 7 and 11 have respective 247 UIDs 405, 407, 410 and 425. 249 3.4. CLOSE Command 251 Arguments: none 253 Responses: no specific responses for this command 255 Result: OK - close completed, now in authenticated state 256 BAD - command unknown or arguments invalid 258 This section updates the definition of the CLOSE command described in 259 section 6.4.2 of [RFC3501]. 261 The CLOSE command permanently removes all messages that have the 262 \Deleted flag set from the currently selected mailbox, and returns to 263 the authenticated state from the selected state. No untagged EXPUNGE 264 (or VANISHED) responses are sent. 266 If the server is capable of storing modification sequences for the 267 selected mailbox, it MUST increment the per-mailbox mod-sequence if 268 at least one message was permanently removed due to the execution of 269 the CLOSE command. For each permanently removed message the server 270 MUST remember the incremented mod-sequence and corresponding UID. If 271 at least one message got expunged, the server MUST send the updated 272 per-mailbox modification sequence using the HIGHESTMODSEQ response 273 code (defined in [CONDSTORE]) in the tagged OK response. 275 Example: C: A202 CLOSE 276 S: A202 OK [HIGHESTMODSEQ 20010715194045319] done 278 3.5. UID EXPUNGE Command 280 Arguments: message set 282 Responses: untagged responses: EXPUNGE or VANISHED 284 Result: OK - expunge completed 285 NO - expunge failure: can't expunge (e.g., permission 286 denied) 287 BAD - command unknown or arguments invalid 289 This section updates the definition of the UID EXPUNGE command 290 described in section 2.1 of [UIDPLUS]. Servers that implement both 291 [UIDPLUS] and X-DRAFT-I02-EXPUNGED extensions must implement UID 292 EXPUNGE as described in this section. 294 The UID EXPUNGE command permanently removes from the currently 295 selected mailbox all messages that both have the \Deleted flag set 296 and have a UID that is included in the specified message set. If a 297 message either does not have the \Deleted flag set or has a UID that 298 is not included in the specified message set, it is not affected. 300 This command is particularly useful for disconnected mode clients. 301 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the 302 server, the client can avoid inadvertently removing any messages that 303 have been marked as \Deleted by other clients between the time that 304 the client was last connected and the time the client resynchronizes. 306 If the server does not support the UIDPLUS capability, the client 307 SHOULD fall back to using the STORE command to temporarily remove the 308 \Deleted flag from messages it does not want to remove, then issuing 309 the EXPUNGE command. Finally, the client SHOULD use the STORE 310 command to restore the \Deleted flag on the messages in which it was 311 temporarily removed. 313 Alternatively, the client MAY fall back to using just the EXPUNGE 314 command, risking the unintended removal of some messages. 316 Before returning an OK to the client, those messages that are removed 317 are reported using a VANISHED response or EXPUNGE responses. 319 If the server is capable of storing modification sequences for the 320 selected mailbox, it MUST increment the per-mailbox mod-sequence if 321 at least one message was permanently removed due to the execution of 322 the UID EXPUNGE command. For each permanently removed message the 323 server MUST remember the incremented mod-sequence and corresponding 324 UID. If at least one message got expunged, the server MUST send the 325 updated per-mailbox modification sequence using the HIGHESTMODSEQ 326 response code (defined in [CONDSTORE]) in the tagged OK response. 328 Example: C: . UID EXPUNGE 3000:3002 329 S: * 3 EXPUNGE 330 S: * 3 EXPUNGE 331 S: * 3 EXPUNGE 332 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok 334 Note: In this example, at least messages with message numbers 3, 4, 335 and 5 (UIDs 3000 to 3002) had the \Deleted flag set. See the 336 description of the EXPUNGE response in [RFC3501] for further 337 explanation. 339 3.6. VANISHED Response 341 Contents: optional correlators 343 list of UIDs 345 The VANISHED response reports that the specified UIDs have been 346 permanently removed from the mailbox. This response is similar to 347 the EXPUNGE response [RFC3501], however it can return information 348 about multiple messages and it returns UIDs instead of message 349 numbers. The first benefit saves bandwidth, while the second is more 350 convenient for clients which only use UIDs to access the IMAP server. 352 The VANISHED response has the same restrictions on when it can be 353 sent as does the EXPUNGE response (see below). 355 The VANISHED response starts with an optional correlator. If it is 356 present and contains the TAG correlator type, then the response is a 357 result of a UID FETCH (REPORTEXPUNGES) command. Other correlators 358 can be added in the future. 360 The VANISHED response is sent as a result of a UID FETCH 361 (REPORTEXPUNGES) command, if the UID set parameter to the UID FETCH 362 (REPORTEXPUNGES) command includes UIDs of messages that are no longer 363 in the mailbox. Such VANISHED response MUST contain the TAG 364 correlator. 366 Once a client has used "(REPORTEXPUNGES)" with a UID FETCH or SELECT/ 367 EXAMINE command, the server SHOULD use the VANISHED response instead 368 of the EXPUNGE response. The server SHOULD continue using VANISHED 369 in lieu of EXPUNGE for the duration of the connection. In particular 370 this affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] 371 commands, as well as messages expunged in other connections. Such 372 VANISHED response MUST NOT contain the TAG correlator. 374 A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command 375 or because messages were expunged in other connections also 376 decrements the number of messages in the mailbox; it is not necessary 377 for the server to send an EXISTS and/or RECENT response with the new 378 value. It also decrements message sequence numbers for each 379 successive message in the mailbox (see the example at the end of this 380 section). Note that a VANISHED response caused by EXPUNGE/UID 381 EXPUNGE/messages expunged in other connections SHOULD only contain 382 UIDs for messages expunged since the last VANISHED/EXPUNGE response 383 sent for the currently opened mailbox or since the mailbox was 384 opened. That is, servers SHOULD NOT send UIDs for previously 385 expunged messages, unless explicitly requested to do so by the UID 386 FETCH (REPORTEXPUNGES) command. 388 Note that client implementors must take care to properly decrement 389 the number of messages in the mailbox even if a server violates this 390 last SHOULD or repeats the same UID multiple times in the returned 391 UID set. In general this means that a client using this extension 392 should either avoid using message numbers entirely, or have a 393 complete map of UID-to-message mapping for the selected mailbox. 395 A VANISHED response MUST NOT be sent when no command is in progress, 396 nor while responding to a FETCH, STORE, or SEARCH command. This rule 397 is necessary to prevent a loss of synchronization of message sequence 398 numbers between client and server. A command is not "in progress" 399 until the complete command has been received; in particular, a 400 command is not "in progress" during the negotiation of command 401 continuation. 403 Note: UID FETCH, UID STORE, and UID SEARCH are different commands 404 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent 405 during a UID command. However, the VANISHED response MUST NOT be 406 sent during a UID SEARCH command that contains message numbers in the 407 search criteria. 409 The update from the VANISHED response MUST be recorded by the client. 411 Example: Let's assume that there is the following mapping between 412 message numbers and UIDs in the currently selected mailbox (here "X" 413 marks messages with the \Deleted flag set, and "x" represents UIDs 414 which are not relevant for the example): 416 Message numbers: 1 2 3 4 5 6 7 8 9 10 11 417 UIDs: x 504 505 507 508 x 510 x x x 625 418 \Deleted messages: X X X X 420 In the presence of the extension defined in this document: 422 C: A202 EXPUNGE 423 S: * VANISHED 505,507,510,625 424 S: A202 OK EXPUNGE completed 425 Without the X-DRAFT-I02-EXPUNGED [[anchor15: change before 426 publication]] extension the same example might look like: 428 C: A202 EXPUNGE 429 S: * 3 EXPUNGE 430 S: * 3 EXPUNGE 431 S: * 5 EXPUNGE 432 S: * 8 EXPUNGE 433 S: A202 OK EXPUNGE completed 435 (Continuing previous example) If subsequently messages with UIDs 504 436 and 508 got marked as \Deleted: 438 C: A210 EXPUNGE 439 S: * VANISHED 504,508 440 S: A210 OK EXPUNGE completed 442 I.e., the last VANISHED response only contains UIDs of messages 443 expunged since the previous VANISHED response. 445 4. Server implementation considerations 447 This section describes a poor implementation and an example of a good 448 implementation. 450 4.1. Server implementations that don't store extra state 452 Strictly speaking, a server implementation that doesn't remember 453 modsequences associated with expunged messages can be considered 454 compliant with this specification. Such implementations return all 455 expunged messages specified in the UID set of the UID FETCH 456 (REPORTEXPUNGES) command every time, without paying attention to the 457 specified CHANGEDSINCE modsequence. Such implementations are 458 discouraged, as they can end up returning VANISHED responses bigger 459 than the result of a UID SEARCH command for the same UID set. 461 4.2. Additional state required on the server 463 When compared to the [CONDSTORE] extension, this extension requires 464 servers to store additional state associated with expunged messages. 465 Note that implementations are not required to store this state in 466 persistent storage, however use of persistent storage is advisable. 468 One possible way to correctly implement the extension described in 469 this document would be to store a queue of 470 pairs. can be represented as a sequence of pairs. 473 When messages are expunged, one or more entry is added to the queue 474 tail. 476 When the server receives a request to return expunged messages since 477 a given modsequence, it will search the queue from the tail (i.e. 478 going from the highest expunged modsequence to the lowest), until it 479 sees the first record with a modsequence less than or equal to the 480 given modsequence, or it reaches the head of the queue. 482 Note that indefinitely storing information about expunged messages 483 can cause storage and related problems for an implementation. In the 484 worst case, this could result in almost 64Gb of storage for each IMAP 485 mailbox. For example, consider an implementation that stores triples for each range of expunged 487 messages expunged at once. Each triple requires 16 octets: 4 octets 488 for each of the two UIDs, and 8 octets for the modsequence. Assume a 489 mailbox containing a single message with a UID of 2**32-1 (the 490 maximum possible UID value), where messages had previously existed 491 with UIDs starting at 1, and have been expunged one at a time. For 492 this mailbox alone, storage is required for the triples <1, 1, 493 modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, modseq4294967294>. 495 Hence, implementations are encouraged to adopt strategies to protect 496 against such storage problems, such as limiting the size of the queue 497 used to store modsequences for expunged messages and "expiring" older 498 records when this limit is reached. When the selected 499 implementation-specific queue limit is reached, the oldest record(s) 500 are deleted from the queue (Note that such records are located at the 501 queue head). For all such "expired" records the server needs to 502 store a single modsequence, which is the highest modsequence for all 503 "expired" expunged messages. 505 Also note that if the UIDVALIDITY of the mailbox changes or if the 506 mailbox is deleted, then any state associated with expunged messages 507 MUST be deleted as well. 509 5. Updated synchronization sequence 511 This section updates the description of optimized synchronization in 512 section 6.1 of the [IMAP-DISC]. 514 An advanced disconnected mail client should use the X-DRAFT-I02- 515 EXPUNGED and [CONDSTORE] extensions when they are supported by the 516 server. The client MUST cache the value from HIGHESTMODSEQ OK 517 response code received on mailbox opening and update it whenever the 518 server sends MODSEQ FETCH data items. 520 If the client receives a NOMODSEQ OK untagged response instead of 521 HIGHESTMODSEQ, it MUST remove the last known HIGHESTMODSEQ value from 522 its cache and follow the more general instructions in section 3 of 523 the [IMAP-DISC]. 525 When the client opens the mailbox for synchronization it first 526 compares UIDVALIDITY as described in step d)1) in section 3 of the 527 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 528 returned by the server, the client MUST compare the cached value of 529 HIGHESTMODSEQ with the one returned by the server. If the cached 530 HIGHESTMODSEQ value also matches the one returned by the server, then 531 the client SHOULD NOT fetch flags for cached messages, as they 532 haven't changed. If the value returned by the server is higher than 533 the cached one, the client MAY use "SEARCH MODSEQ " to 534 find all messages with flags changed since the last time the client 535 was online and had the mailbox opened. Alternatively the client MAY 536 use "FETCH 1:* (FLAGS) (CHANGEDSINCE REPORTEXPUNGES)". 537 The latter operation combines reporting expunged messages, searching 538 for changed messages and fetching new information. 540 In all cases the client still needs to fetch information about new 541 messages (if requested by the user). If the client has used SEARCH 542 MODSEQ, it will also have to discover which messages have been 543 expunged. 545 Step d) ("Server-to-client synchronization") in section 4 of the 546 [IMAP-DISC] in the presence of the X-DRAFT-I02-EXPUNGED & CONDSTORE 547 extensions is amended as follows: 549 d) "Server-to-client synchronization" -- for each mailbox that 550 requires synchronization, do the following: 552 1a) Check the mailbox UIDVALIDITY (see section 4.1 of the 553 [IMAP-DISC] for more details) with SELECT/EXAMINE/STATUS. 554 If the UIDVALIDITY value returned by the server differs, 555 the client MUST 557 * empty the local cache of that mailbox; 559 * "forget" the cached HIGHESTMODSEQ value for 560 the mailbox; 562 * remove any pending "actions" which refer to 563 UIDs in that mailbox. Note, this doesn't 564 affect actions performed on client generated 565 fake UIDs (see section 5 of the [IMAP-DISC]); 567 * skip steps 1b and 2-II; 569 1b) Check the mailbox HIGHESTMODSEQ. If the cached value is 570 the same as the one returned by the server, skip fetching 571 message flags on step 2-II, i.e., the client only has to 572 find out which messages got expunged. 574 2) Fetch the current "descriptors"; 576 I) Discover new messages. 578 II) Discover changes to old messages and expunged messages 579 using "UID FETCH 1: (FLAGS) (CHANGEDSINCE 580 REPORTEXPUNGES)". 582 (Note, if is replaced with "*", this 583 command will return flags for new messages as well) 585 3) Fetch the bodies of any "interesting" messages that the 586 client doesn't already have. 588 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ 589 value has changed on the server while the client was 590 offline: 592 C: A142 SELECT INBOX 593 S: * 172 EXISTS 594 S: * 1 RECENT 595 S: * OK [UNSEEN 12] Message 12 is first unseen 596 S: * OK [UIDVALIDITY 3857529045] UIDs valid 597 S: * OK [UIDNEXT 201] Predicted next UID 598 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 599 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 600 S: * OK [HIGHESTMODSEQ 20010715194045007] 601 S: A142 OK [READ-WRITE] SELECT completed 602 after that: 604 C: A143 UID FETCH 1:20 (FLAGS) 605 (CHANGEDSINCE 20010715194032001 REPORTEXPUNGES) 606 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) 607 FLAGS (\Deleted)) 608 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) 609 FLAGS ($NoJunk $AutoJunk $MDNSent)) 610 ... 611 S: * VANISHED 1:5,7:8,10:15 612 S: A143 OK FETCH completed 614 6. Formal Syntax 616 The following syntax specification uses the Augmented Backus-Naur 617 Form (ABNF) notation as specified in [ABNF]. 619 Non-terminals referenced but not defined below are as defined by 620 [RFC3501], or [IMAPABNF]. 622 Except as noted otherwise, all alphabetic characters are case- 623 insensitive. The use of upper or lower case characters to define 624 token strings is for editorial clarity only. Implementations MUST 625 accept these strings in a case-insensitive fashion. 627 capability =/ "X-DRAFT-I02-EXPUNGED" 628 ;; [[Note to RFC Editor: fix before 629 ;; publication]] 631 message-data =/ expunged-resp 633 expunged-resp = "VANISHED" [expunge-correlator] SP known-uids 635 expunge-correlator = SP "(" single-exp-correlator *(SP single-exp- 636 correlator) ")" 637 ;; Unless explicitly specified otherwise, ;; 638 all correlator types must be specified ;; only 639 once. 641 single-exp-correlator = "TAG" SP tag-string ;; Correlator type 642 followed by parameters 644 known-uids = sequence-set 645 ;; sequence of UIDs, "*" is not allowed 647 rexpunges-fetch-mod = "REPORTEXPUNGES" 648 ;; REPORTEXPUNGES FETCH modifier conforms 649 ;; to the fetch-modifier syntax 650 ;; defined in [IMAPABNF]. It is only 651 ;; allowed in the UID FETCH command. 653 select-param =/ expunged-param 654 ;; conforms to the generic "select-param" 655 ;; non-terminal syntax defined in [IMAPABNF]. 657 expunged-param = "REPORTEXPUNGES" 659 7. Security Considerations 661 It is believed that this extension doesn't raise any additional 662 security concerns not already discussed in [RFC3501]. 664 As always, it is important to thoroughly test clients and servers 665 implementing this extension, as it changes how the server reports 666 expunged messages to the client. 668 8. IANA Considerations 670 IMAP4 capabilities are registered by publishing a standards track or 671 IESG approved experimental RFC. The registry is currently located 672 at: 674 http://www.iana.org/assignments/imap4-capabilities 676 This document defines the X-DRAFT-I02-EXPUNGED [[anchor23: Note to 677 RFC Editor: change before publication]] IMAP capability. IANA is 678 requested to add it to the registry. 680 9. Acknowledgments 682 Thanks to Steve Hole, Cyrus Daboo, David Cridland and Michael Wener 683 for encouraging me to write this document. 685 Valuable comments, both in agreement and in dissent, were received 686 from David Cridland, Timo Sirainen, Michael Wener, Randall Gellens, 687 Arnt Gulbrandsen, Peter Coates, Mark Crispin and Elwyn Davies. 689 This document takes substantial text from [RFC3501] by Mark Crispin. 691 10. References 693 10.1. Normative References 695 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 696 Syntax Specifications: ABNF", RFC 4234, October 2005. 698 [CONDSTORE] 699 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 700 STORE Operation or Quick Flag Changes Resynchronization", 701 RFC 4551, June 2006. 703 [IMAPABNF] 704 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 705 ABNF", RFC 4466, April 2006. 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, March 1997. 710 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 711 4rev1", RFC 3501, March 2003. 713 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 714 UIDPLUS extension", RFC 4315, December 2005. 716 10.2. Informative References 718 [IMAP-DISC] 719 Melnikov, A., "Synchronization Operations For Disconnected 720 Imap4 Clients", RFC 4549, June 2006. 722 Author's Address 724 Alexey Melnikov 725 Isode Ltd 726 5 Castle Business Village 727 36 Station Road 728 Hampton, Middlesex TW12 2BX 729 UK 731 Email: Alexey.Melnikov@isode.com 733 Full Copyright Statement 735 Copyright (C) The Internet Society (2006). 737 This document is subject to the rights, licenses and restrictions 738 contained in BCP 78, and except as set forth therein, the authors 739 retain all their rights. 741 This document and the information contained herein are provided on an 742 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 743 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 744 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 745 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 746 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 747 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Intellectual Property 751 The IETF takes no position regarding the validity or scope of any 752 Intellectual Property Rights or other rights that might be claimed to 753 pertain to the implementation or use of the technology described in 754 this document or the extent to which any license under such rights 755 might or might not be available; nor does it represent that it has 756 made any independent effort to identify any such rights. Information 757 on the procedures with respect to rights in RFC documents can be 758 found in BCP 78 and BCP 79. 760 Copies of IPR disclosures made to the IETF Secretariat and any 761 assurances of licenses to be made available, or the result of an 762 attempt made to obtain a general license or permission for the use of 763 such proprietary rights by implementers or users of this 764 specification can be obtained from the IETF on-line IPR repository at 765 http://www.ietf.org/ipr. 767 The IETF invites any interested party to bring to its attention any 768 copyrights, patents or patent applications, or other proprietary 769 rights that may cover technology that may be required to implement 770 this standard. Please address the information to the IETF at 771 ietf-ipr@ietf.org. 773 Acknowledgment 775 Funding for the RFC Editor function is provided by the IETF 776 Administrative Support Activity (IASA).