idnits 2.17.00 (12 Aug 2021) /tmp/idnits30061/draft-ietf-lemonade-reconnect-client-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1187. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1200. 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 IETF Trust 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 (September 28, 2007) is 5342 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 995, but not defined == Missing Reference: 'UIDNEXT 550' is mentioned on line 300, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060128194045007' is mentioned on line 301, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 994, but not defined == Missing Reference: 'UIDVALIDITY 67890007' is mentioned on line 456, but not defined == Missing Reference: 'UIDNEXT 567' is mentioned on line 357, but not defined == Missing Reference: 'HIGHESTMODSEQ 90060115205545359' is mentioned on line 460, but not defined == Missing Reference: 'UNSEEN 7' is mentioned on line 462, but not defined == Missing Reference: 'UIDNEXT 30013' is mentioned on line 458, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045319' is mentioned on line 674, but not defined == Missing Reference: 'UIDNEXT 201' is mentioned on line 996, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 999, 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) == Outdated reference: draft-gulbrandsen-imap-enable has been published as RFC 5161 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 4 errors (**), 0 flaws (~~), 14 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 D. Cridland 4 Intended status: Standards Track Isode Ltd 5 Expires: March 31, 2008 C. Wilson 6 Nokia 7 September 28, 2007 9 IMAP4 Extensions for Quick Mailbox Resynchronization 10 draft-ietf-lemonade-reconnect-client-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 31, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines an IMAP4 extension, which gives an IMAP client 44 the ability to quickly resynchronize any previously opened mailbox as 45 part of the SELECT command, without the need for server-side state or 46 additional client round-trips. This extension also introduces a new 47 response that allows for a more compact representation for a list of 48 expunged messages (and always includes the UIDs expunged). 50 Changes since draft-ietf-lemonade-reconnect-client-05.txt 52 o Many editorial improvements from Randy Gellens. 54 o Remove RECENT response from the list of responses that doesn't 55 need to be returned when VANISHED is also returned. 57 o Clarified that VANISHED (EARLIER) must be returned before any 58 FETCH. 60 o Fixed some typos in examples. 62 o Require that any client issues ENABLE QRESYNC first. Servers now 63 reject SELECT QRESYNC/FETCH VANISHED not preceeded by ENABLE 64 QRESYNC with BAD. 66 Changes since draft-ietf-lemonade-reconnect-client-04.txt 68 o Clarified handling of omitted list of known UIDs. 70 o Clarified interaction with the CONDSTORE extension. 72 o Renamed TAG to EARLIER and removed the associated tag parameter. 74 o Made QRESYNC extension depend on ENABLE. 76 o Removed text about client emulating UID EXPUNGE in absence of 77 UIDPLUS. 79 o Added CLOSED response code. 81 Changes since draft-ietf-lemonade-reconnect-client-03.txt 83 o Fixed several typos reported by Randy Gellens. 85 o Fixed a couple of errors in examples and text reported by Dan 86 Karp. 88 Changes since draft-ietf-lemonade-reconnect-client-02.txt 90 o Fixed description of the synchronization sequence to properly 91 describe how HIGHESTMODSEQ is used. 93 o Fixed a couple of errors in ABNF. 95 Changes since draft-ietf-lemonade-reconnect-client-01.txt 97 o Folded the EXPUNGED extension 98 (draft-melnikov-imap-expunged-02.txt) into this document. Updated 99 mailbox synchronization instructions. 101 o Added UID sequence number matching. 103 o Clarified how NOMODSEQ response affects this extension. 105 o Other minor editorial changes and fixes. 107 Changes since draft-ietf-lemonade-reconnect-client-00.txt 109 o Changed server behavior when the specified UIDVALIDITY doesn't 110 match the current. This allows the client to chose how to proceed 111 after that. 113 o If client's UIDVALIDITY doesn't match server's, the server will 114 not return any flags anymore. 116 o Clarified that SELECT (QRESYNC) is a CONDSTORE-enabling command. 118 o Other minor editorial changes and fixes. 120 Table of Contents 122 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 123 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 124 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7 125 3.1. QRESYNC parameter to SELECT/EXAMINE . . . . . . . . . . . 7 126 3.2. VANISHED UID FETCH modifier . . . . . . . . . . . . . . . 12 127 3.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . . . 13 128 3.4. CLOSE Command . . . . . . . . . . . . . . . . . . . . . . 14 129 3.5. UID EXPUNGE Command . . . . . . . . . . . . . . . . . . . 15 130 3.6. VANISHED Response . . . . . . . . . . . . . . . . . . . . 16 131 3.7. CLOSED Response Code . . . . . . . . . . . . . . . . . . . 18 132 4. Server implementation considerations . . . . . . . . . . . . . 19 133 4.1. Server implementations that don't store extra state . . . 19 134 4.2. Server implementations storing minimal state . . . . . . . 19 135 4.3. Additional state required on the server . . . . . . . . . 19 136 5. Updated synchronization sequence . . . . . . . . . . . . . . . 21 137 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23 138 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 139 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 140 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 141 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 142 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 143 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 145 Intellectual Property and Copyright Statements . . . . . . . . . . 27 147 1. Requirements notation 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 In examples, "C:" and "S:" indicate lines sent by the client and 154 server respectively. If a single "C:" or "S:" label applies to 155 multiple lines, then the line breaks between those lines are for 156 editorial clarity only and are not part of the actual protocol 157 exchange. 159 Understanding of the IMAP message sequence numbers and UIDs and the 160 EXPUNGE response [RFC3501] is essential when reading this document. 162 [[anchor2: Editorial comments and questions are marked like this.]] 164 2. Introduction and Overview 166 The [CONDSTORE] extension gives a disconnected client the ability to 167 quickly resynchronize IMAP flag changes for previously seen messages. 168 This can be done using the CHANGEDSINCE FETCH modifier once a mailbox 169 is opened. In order for the client to discover which messages have 170 been expunged, the client still has to issue a UID FETCH or a UID 171 SEARCH command. This document defines an extension to [CONDSTORE] 172 that allows a reconnecting client to perform full resynchronization, 173 including discovery of expunged messages, in a single round-trip. 174 This extension also introduces a new response VANISHED that allows 175 for a more compact representation for a list of expunged messages. 177 This extension can be useful for mobile clients that can experience 178 frequent disconnects caused by environmental factors (battery life, 179 signal strength, etc.). Such clients need a way to quickly reconnect 180 to the IMAP server, while minimizing delay experienced by the user as 181 well as the amount of traffic (and hence the expense) generated by 182 resynchronization. 184 By extending the SELECT command to perform the additional 185 resynchronization, this also allows clients to reduce concurrent 186 connections to the IMAP server held purely for the sake of avoiding 187 the resynchronization. 189 [[anchor4: Note to RFC editor: Please change the capability name 190 everywhere in the document from "X-DRAFT-W05-QRESYNC" to "QRESYNC".]] 192 The quick resync IMAP extension is present if an IMAP4 server returns 193 "X-DRAFT-W05-QRESYNC" as one of the supported capabilities to the 194 CAPABILITY command. 196 Servers supporting this extension MUST implement and advertise 197 support for the [ENABLE] IMAP extension. Also, the presence of the 198 "X-DRAFT-W05-QRESYNC" capability implies support for the [CONDSTORE] 199 IMAP extension even if the "CONDSTORE" capability isn't advertised. 200 A server compliant with this specification is REQUIREd to support 201 "ENABLE X-DRAFT-W05-QRESYNC" and "ENABLE X-DRAFT-W05-QRESYNC 202 CONDSTORE" (which are "CONDSTORE enabling commands", as defined in 203 [CONDSTORE], and have identical results), but there is no requirement 204 for a compliant server to support "ENABLE CONDSTORE" by itself. The 205 "ENABLE X-DRAFT-W05-QRESYNC"/"ENABLE X-DRAFT-W05-QRESYNC CONDSTORE" 206 command also tells the server that it SHOULD start sending VANISHED 207 responses (see Section 3.6) instead of EXPUNGE responses. This 208 change remains in effect until the connection is closed. 210 For compatibility with clients that only support the [CONDSTORE] IMAP 211 extension, servers SHOULD advertise "CONDSTORE" in the CAPABILITY 212 response as well. 214 A client making use of this extension MUST issue "ENABLE QRESYNC" 215 once it is authenticated. A server MUST respond with a tagged BAD 216 response if the QRESYNC parameter to the SELECT/EXAMINE command or 217 the VANISHED UID FETCH modifier is specified and the client hasn't 218 issued "ENABLE QRESYNC" in the current connection. 220 This document puts additional requirements on a server implementing 221 the [CONDSTORE] extension. Each mailbox that supports persistent 222 storage of mod-sequences, i.e., for which the server has sent a 223 HIGHESTMODSEQ untagged OK response code on a successful SELECT/ 224 EXAMINE, MUST increment the per-mailbox mod-sequence when one or more 225 messages are expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the 226 server MUST associate the incremented mod-sequence with the UIDs of 227 the expunged messages. 229 A client which supports CONDSTORE but not this extension might 230 resynchronize a mailbox and discover that its HIGHESTMODSEQ has 231 increased from the value cached by the client. If the increase is 232 due only to messages having been expunged since the client last 233 synchronized, the client is likely to send a FETCH ... CHANGEDSINCE 234 command that returns no data. Thus, a client which supports 235 CONDSTORE but not this extension might incur a penalty of an unneeded 236 round-trip when resynchronizing some mailboxes (those which have had 237 messages expunged but no flag changes since the last 238 synchronization). 240 This extra round-trip is only incurred by clients that supports 241 CONDSTORE but not this extension, and only when a mailbox has had 242 messages expunged but no flag changes to non-expunged messages. 243 Since CONDSTORE is a relatively new extension, it is thought likely 244 that clients that support it will also support this extension. 246 3. IMAP Protocol Changes 248 3.1. QRESYNC parameter to SELECT/EXAMINE 250 The Quick Resynchronization parameter to SELECT/EXAMINE commands has 251 four arguments: 253 o the last known UIDVALIDITY, 255 o the last known modification sequence 257 o the optional set of known UIDs 259 o an optional parenthesized list of known sequence ranges and their 260 corresponding UIDs. 262 A server MUST respond with a tagged BAD response if the Quick 263 Resynchronization parameter to SELECT/EXAMINE command is specified 264 and the client hasn't issued "ENABLE QRESYNC" in the current 265 connection. 267 The QRESYNC parameter also tells the server that it SHOULD start 268 sending VANISHED responses (see Section 3.6) instead of EXPUNGE 269 responses. This change remains in effect until the connection is 270 closed. 272 Before opening the specified mailbox the server verifies all 273 arguments for syntactic validity. If any parameter is not 274 syntactically valid, the server returns the tagged BAD response, and 275 the mailbox remains unselected. Once the check is done the server 276 opens the mailbox as if no SELECT/EXAMINE parameters are specified 277 (this is subject to processing of other parameters as defined in 278 other extensions). In particular this means that the server MUST 279 send all untagged responses as specified in Section 6.3.1/6.3.2 of 280 [RFC3501]. 282 After that the server checks the UIDVALIDITY value provided by the 283 client. If the provided UIDVALIDITY doesn't match the UIDVALIDITY 284 for the mailbox being opened, then the server MUST ignore the 285 remaining parameters and behave as if no dynamic message data 286 changed. The client can discover this situation by comparing the 287 UIDVALIDITY value returned by the server. This behaviour allows the 288 client not to synchronize the mailbox or decide on the best 289 synchronization strategy. 291 Example: Attempting to resynchronize INBOX, but the provided 292 UIDVALIDITY parameter doesn't match the current UIDVALIDITY 293 value. 295 C: A02 SELECT INBOX (QRESYNC (67890007 20050715194045000 296 41,43:211,214:541)) 297 S: * 464 EXISTS 298 S: * 3 RECENT 299 S: * OK [UIDVALIDITY 3857529045] UIDVALIDITY 300 S: * OK [UIDNEXT 550] Predicted next UID 301 S: * OK [HIGHESTMODSEQ 90060128194045007] 302 S: * OK [UNSEEN 12] Message 12 is first unseen 303 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 304 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 305 \Deleted \Seen \*)] Permanent flags 306 S: A02 OK [READ-WRITE] Sorry, UIDVALIDITY mismatch 308 Modification Sequence and UID Parameters: 310 A server that doesn't support the persistent storage of mod-sequences 311 for the mailbox MUST send the OK untagged response including the 312 NOMODSEQ response code with every successful SELECT or EXAMINE 313 command, as described in [CONDSTORE]. Such a server doesn't need to 314 remember mod-sequences for expunged messages in the mailbox. It MUST 315 ignore the remaining parameters and behave as if no dynamic message 316 data changed. 318 However, whether the server returns the HIGHESTMODSEQ or the NOMODSEQ 319 response code, the QRESYNC parameter still enables the use of the 320 VANISHED response in lieu of the EXPUNGE response (as described in 321 Section 3.6). 323 If the provided UIDVALIDITY matches that of the selected mailbox, the 324 server then checks the last known modification sequence. 325 The server sends the client any pending flag changes (using FETCH 326 responses that MUST contain UIDs) and expunges that have occurred in 327 this mailbox since the provided modification sequence. 329 If the list of known UIDs was also provided, the server should only 330 report flag changes and expunges for the specified messages. If the 331 client did not provide the list of UIDs, the server acts as if the 332 client has specified "1:", where is the mailbox's 333 UIDNEXT value minus 1. If the mailbox is empty and never had any 334 messages in it, then lack of the list of UIDs is interpreted as an 335 empty set of UIDs. 337 Thus, the client can process just these pending events and need not 338 perform a full resynchronization. Without the message sequence 339 number matching information, the result of this step is semantically 340 equivalent to the client issuing: 341 tag1 UID FETCH "known-uids" (FLAGS) (CHANGEDSINCE 342 "mod-sequence-value" VANISHED) 344 Example: 346 C: A03 SELECT INBOX (QRESYNC (67890007 347 90060115194045000 41,43:211,214:541)) 349 S: * OK [CLOSED] 351 S: * 314 EXISTS 353 S: * 15 RECENT 355 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 357 S: * OK [UIDNEXT 567] Predicted next UID 359 S: * OK [HIGHESTMODSEQ 90060115205545359] 361 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 363 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 365 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 366 \Deleted \Seen \*)] Permanent flags 368 S: * VANISHED (EARLIER) 41,43:116,118,120:211,214:540 370 S: * 49 FETCH (UID 117 FLAGS (\Seen \Answered)) 372 S: * 50 FETCH (UID 119 FLAGS (\Draft $MDNSent)) 374 S: ... 376 S: * 100 FETCH (UID 541 FLAGS (\Seen $Forwarded)) 378 S: A03 OK [READ-WRITE] mailbox selected 380 Message sequence match data: 382 A client MAY provide a parenthesized list of a message sequence set 383 and the corresponding UID sets. Both MUST be provided in ascending 384 order. The server uses this data to restrict the range for which it 385 provides expunged message information. 387 Conceptually, the client provides a small sample of sequence numbers 388 for which it knows the corresponding UIDs. The server then compares 389 each sequence number and UID pair the client provides with the 390 current state of the mailbox. If a pair matches, then the client 391 knows of any expunges up to, and including, the message, and thus 392 will not include that range in the VANISHED response, even if the 393 "mod-sequence-value" provided by the client is too old for the server 394 to have data of when those messages were expunged. 396 Thus if the Nth message number in the first set in the list is 4, and 397 the Nth UID in the second set in the list is 8, and the mailbox's 398 fourth message has UID 8, then no UIDs equal to or less than 8 are 399 present in the VANISHED response. If the (N+1)th message number is 400 12, and the (N+1)th UID is 24, and the (N+1)th message in the mailbox 401 has UID 25, then the lowest UID included in the VANISHED response 402 would be 9. 404 In the following two examples, the server is unable to remember 405 expunges at all, and only UIDs with messages divisible by three are 406 present in the mailbox. In the first example, the client does not 407 use the fourth parameter, in the second, it provides it. This 408 example is somewhat extreme, but shows that judicious usage of the 409 sequence match data can save a substantial amount of bandwidth. 411 Example: 413 C: A04 SELECT INBOX (QRESYNC (67890007 414 90060115194045000 1:29997)) 416 S: * 10003 EXISTS 418 S: * 5 RECENT 420 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 422 S: * OK [UIDNEXT 30013] Predicted next UID 424 S: * OK [HIGHESTMODSEQ 90060115205545359] 426 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 428 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 429 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 430 \Deleted \Seen \*)] Permanent flags 432 S: * VANISHED (EARLIER) 1:2,4:5,7:8,10:11,13:14 [...] 433 29998:29999,30001:30002,30004:30005,30007:30008 435 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) 437 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent)) 439 S: ... 441 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) 443 S: A04 OK [READ-WRITE] mailbox selected 445 Example: 447 C: B04 SELECT INBOX (QRESYNC (67890007 448 90060115194045000 1:29997 (5000,7500,9000,9990:9999 15000, 449 22500,27000,29970,29973,29976,29979,29982,29985,29988,29991, 450 29994,29997))) 452 S: * 10003 EXISTS 454 S: * 5 RECENT 456 S: * OK [UIDVALIDITY 67890007] UIDVALIDITY 458 S: * OK [UIDNEXT 30013] Predicted next UID 460 S: * OK [HIGHESTMODSEQ 90060115205545359] 462 S: * OK [UNSEEN 7] There are some unseen messages in the mailbox 464 S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 466 S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft 467 \Deleted \Seen \*)] Permanent flags 469 S: * VANISHED (EARLIER) 29998:29999,30001:30002,30004:30005,30007: 470 30008 472 S: * 9889 FETCH (UID 29667 FLAGS (\Seen \Answered)) 473 S: * 9890 FETCH (UID 29670 FLAGS (\Draft $MDNSent)) 475 S: ... 477 S: * 9999 FETCH (UID 29997 FLAGS (\Seen $Forwarded)) 479 S: B04 OK [READ-WRITE] mailbox selected 481 3.2. VANISHED UID FETCH modifier 483 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH 484 commands to include an optional FETCH modifier. This document 485 defines a new UID FETCH modifier: VANISHED. 487 Note, that the VANISHED UID FETCH modifier is NOT allowed with a 488 FETCH command. The server MUST return a tagged BAD response if this 489 response is specified as a modifier to the FETCH command. 491 A server MUST respond with a tagged BAD response if the VANISHED UID 492 FETCH modifier is specified and the client hasn't issued "ENABLE 493 QRESYNC" in the current connection. 495 The VANISHED UID FETCH modifier MUST only be specified together with 496 the CHANGEDSINCE UID FETCH modifier. 498 The VANISHED UID FETCH modifier instructs the server to report those 499 messages from the UID set parameter that have been expunged and whose 500 associated modsequence is larger than the specified modsequence. 501 That is, the client requests to be informed of messages from the 502 specified set that were expunged since the specified modsequence. 503 Note that the modsequence(s) associated with these messages were 504 updated when the messages were expunged (as described above). The 505 expunged messages are reported using the VANISHED response as 506 described in Section 3.6, which MUST contain the EARLIER tag. Any 507 VANISHED (EARLIER) responses MUST be returned before any FETCH 508 responses, as otherwise the client might get confused about how 509 message numbers map to UIDs. 511 Note: a server that receives a modsequence smaller than any of the 512 expunged modsequence it remembers about MUST behave as if it was 513 requested to report all expunged messages from the provided UID set 514 parameter. 516 The VANISHED UID FETCH modifier also instructs the server to replace 517 all further EXPUNGE responses with VANISHED responses. The server 518 MUST do this until the connection is closed. 520 Example 1: Without the VANISHED UID FETCH modifier a CONDSTORE-aware 521 client [CONDSTORE] needs to issue separate commands to learn of flag 522 changes and expunged messages since the last synchronization: 524 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345) 525 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 526 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 527 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 528 $AutoJunk $MDNSent)) 529 S: s100 OK FETCH completed 530 C: s101 UID SEARCH 300:500 531 S: * SEARCH 404 406 407 408 410 412 532 S: s101 OK search completed 534 Where 300 and 500 are the lowest and highest UIDs from client's 535 cache. The second SEARCH response tells the client that the messages 536 with UIDs 407, 410 and 412 are still present, but their flags haven't 537 changed since the specified modification sequence. 539 Using the VANISHED UID FETCH modifier it is sufficient to issue only 540 a single command: 542 C: s100 UID FETCH 300:500 (FLAGS) (CHANGEDSINCE 12345 543 VANISHED) 544 S: * VANISHED (EARLIER) 300:310,405,411 545 S: * 1 FETCH (UID 404 MODSEQ (65402) FLAGS (\Seen)) 546 S: * 2 FETCH (UID 406 MODSEQ (75403) FLAGS (\Deleted)) 547 S: * 4 FETCH (UID 408 MODSEQ (29738) FLAGS ($NoJunk 548 $AutoJunk $MDNSent)) 549 S: s100 OK FETCH completed 551 3.3. EXPUNGE Command 553 Arguments: none 555 Responses: untagged responses: EXPUNGE or VANISHED 557 Result: OK - expunge completed 558 NO - expunge failure: can't expunge (e.g., permission 559 denied) 560 BAD - command unknown or arguments invalid 562 This section updates the definition of the EXPUNGE command described 563 in section 6.4.3 of [RFC3501]. 565 The EXPUNGE command permanently removes all messages that have the 566 \Deleted flag set from the currently selected mailbox. Before 567 returning an OK to the client, those messages that are removed are 568 reported using a VANISHED response or EXPUNGE responses. 570 If the server is capable of storing modification sequences for the 571 selected mailbox, it MUST increment the per-mailbox mod-sequence if 572 at least one message was permanently removed due to the execution of 573 the EXPUNGE command. For each permanently removed message the server 574 MUST remember the incremented mod-sequence and corresponding UID. If 575 at least one message got expunged, the server MUST send the updated 576 per-mailbox modification sequence using the HIGHESTMODSEQ response 577 code (defined in [CONDSTORE]) in the tagged OK response. 579 Example: C: A202 EXPUNGE 580 S: * 3 EXPUNGE 581 S: * 3 EXPUNGE 582 S: * 5 EXPUNGE 583 S: * 8 EXPUNGE 584 S: A202 OK [HIGHESTMODSEQ 20010715194045319] expunged 586 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag 587 set. See the description of the EXPUNGE response in [RFC3501] for 588 further explanation. 590 Note that once the VANISHED response is enabled on the connection the 591 previous example might look like this: 593 Example: C: B202 EXPUNGE 594 S: * VANISHED 405,407,410,425 595 S: B202 OK [HIGHESTMODSEQ 20010715194045319] expunged 597 Here messages with message numbers 3, 4, 7 and 11 have respective 598 UIDs 405, 407, 410 and 425. 600 3.4. CLOSE Command 602 Arguments: none 604 Responses: no specific responses for this command 606 Result: OK - close completed, now in authenticated state 607 BAD - command unknown or arguments invalid 609 This section updates the definition of the CLOSE command described in 610 section 6.4.2 of [RFC3501]. 612 The CLOSE command permanently removes all messages that have the 613 \Deleted flag set from the currently selected mailbox, and returns to 614 the authenticated state from the selected state. No untagged EXPUNGE 615 (or VANISHED) responses are sent. 617 If the server is capable of storing modification sequences for the 618 selected mailbox, it MUST increment the per-mailbox mod-sequence if 619 at least one message was permanently removed due to the execution of 620 the CLOSE command. For each permanently removed message the server 621 MUST remember the incremented mod-sequence and corresponding UID. If 622 at least one message got expunged, the server MUST send the updated 623 per-mailbox modification sequence using the HIGHESTMODSEQ response 624 code (defined in [CONDSTORE]) in the tagged OK response. 626 Example: C: A202 CLOSE 627 S: A202 OK [HIGHESTMODSEQ 20010715194045319] done 629 3.5. UID EXPUNGE Command 631 Arguments: message set 633 Responses: untagged responses: EXPUNGE or VANISHED 635 Result: OK - expunge completed 636 NO - expunge failure: can't expunge (e.g., permission 637 denied) 638 BAD - command unknown or arguments invalid 640 This section updates the definition of the UID EXPUNGE command 641 described in section 2.1 of [UIDPLUS]. Servers that implement both 642 [UIDPLUS] and X-DRAFT-W05-QRESYNC [[anchor11: RFC editor: change 643 before publication]] extensions must implement UID EXPUNGE as 644 described in this section. 646 The UID EXPUNGE command permanently removes from the currently 647 selected mailbox all messages that both have the \Deleted flag set 648 and have a UID that is included in the specified message set. If a 649 message either does not have the \Deleted flag set or has a UID that 650 is not included in the specified message set, it is not affected. 652 This command is particularly useful for disconnected mode clients. 653 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the 654 server, the client can avoid inadvertently removing any messages that 655 have been marked as \Deleted by other clients between the time that 656 the client was last connected and the time the client resynchronizes. 658 Before returning an OK to the client, those messages that are removed 659 are reported using a VANISHED response or EXPUNGE responses. 661 If the server is capable of storing modification sequences for the 662 selected mailbox, it MUST increment the per-mailbox mod-sequence if 663 at least one message was permanently removed due to the execution of 664 the UID EXPUNGE command. For each permanently removed message the 665 server MUST remember the incremented mod-sequence and corresponding 666 UID. If at least one message got expunged, the server MUST send the 667 updated per-mailbox modification sequence using the HIGHESTMODSEQ 668 response code (defined in [CONDSTORE]) in the tagged OK response. 670 Example: C: . UID EXPUNGE 3000:3002 671 S: * 3 EXPUNGE 672 S: * 3 EXPUNGE 673 S: * 3 EXPUNGE 674 S: . OK [HIGHESTMODSEQ 20010715194045319] Ok 676 Note: In this example, at least messages with message numbers 3, 4, 677 and 5 (UIDs 3000 to 3002) had the \Deleted flag set. See the 678 description of the EXPUNGE response in [RFC3501] for further 679 explanation. 681 3.6. VANISHED Response 683 Contents: an optional EARLIER tag 685 list of UIDs 687 The VANISHED response reports that the specified UIDs have been 688 permanently removed from the mailbox. This response is similar to 689 the EXPUNGE response [RFC3501], however it can return information 690 about multiple messages and it returns UIDs instead of message 691 numbers. The first benefit saves bandwidth, while the second is more 692 convenient for clients which only use UIDs to access the IMAP server. 694 The VANISHED response has the same restrictions on when it can be 695 sent as does the EXPUNGE response (see below). 697 The VANISHED response has two forms. The first form contains the 698 EARLIER tag, which signifies that the response was caused by a UID 699 FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This 700 response is sent if the UID set parameter to the UID FETCH (VANISHED) 701 command includes UIDs of messages that are no longer in the mailbox. 702 When the client sees a VANISHED EARLIER response it MUST NOT 703 decrement message sequence numbers for each successive message in the 704 mailbox. 706 The second form doesn't contain the EARLIER tag and is described 707 below. Once a client has used "(VANISHED)" with a UID FETCH or 708 "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the 709 VANISHED response without the EARLIER tag instead of the EXPUNGE 710 response. The server SHOULD continue using VANISHED in lieu of 711 EXPUNGE for the duration of the connection. In particular this 712 affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as 713 well as messages expunged in other connections. Such VANISHED 714 response MUST NOT contain the EARLIER tag. 716 A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command 717 or because messages were expunged in other connections (i.e. the 718 VANISHED response without the EARLIER tag) also decrements the number 719 of messages in the mailbox; it is not necessary for the server to 720 send an EXISTS response with the new value. It also decrements 721 message sequence numbers for each successive message in the mailbox 722 (see the example at the end of this section). Note that a VANISHED 723 response caused by EXPUNGE, UID EXPUNGE, or messages expunged in 724 other connections SHOULD only contain UIDs for messages expunged 725 since the last VANISHED/EXPUNGE response sent for the currently 726 opened mailbox or since the mailbox was opened. That is, servers 727 SHOULD NOT send UIDs for previously expunged messages, unless 728 explicitly requested to do so by the UID FETCH (VANISHED) command. 730 Note that client implementors must take care to properly decrement 731 the number of messages in the mailbox even if a server violates this 732 last SHOULD or repeats the same UID multiple times in the returned 733 UID set. In general this means that a client using this extension 734 should either avoid using message numbers entirely, or have a 735 complete mapping of UIDs to message sequence numbers for the selected 736 mailbox. 738 Because clients handle the two different forms of the VANISHED 739 response differently, servers MUST NOT report UIDs resulting from an 740 UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same 741 VANISHED response as UIDs of messages expunged now (i.e. messages 742 expunged in other connections). Instead the server MUST send 743 separate VANISHED responses: one with the EARLIER tag and one 744 without. 746 A VANISHED response MUST NOT be sent when no command is in progress, 747 nor while responding to a FETCH, STORE, or SEARCH command. This rule 748 is necessary to prevent a loss of synchronization of message sequence 749 numbers between client and server. A command is not "in progress" 750 until the complete command has been received; in particular, a 751 command is not "in progress" during the negotiation of command 752 continuation. 754 Note: UID FETCH, UID STORE, and UID SEARCH are different commands 755 from FETCH, STORE, and SEARCH. A VANISHED response MAY be sent 756 during a UID command. However, the VANISHED response MUST NOT be 757 sent during a UID SEARCH command that contains message numbers in the 758 search criteria. 760 The update from the VANISHED response MUST be recorded by the client. 762 Example: Let's assume that there is the following mapping between 763 message numbers and UIDs in the currently selected mailbox (here "X" 764 marks messages with the \Deleted flag set, and "x" represents UIDs 765 which are not relevant for the example): 767 Message numbers: 1 2 3 4 5 6 7 8 9 10 11 768 UIDs: x 504 505 507 508 x 510 x x x 625 769 \Deleted messages: X X X X 771 In the presence of the extension defined in this document: 773 C: A202 EXPUNGE 774 S: * VANISHED 505,507,510,625 775 S: A202 OK EXPUNGE completed 777 Without the X-DRAFT-W05-QRESYNC [[anchor12: RFC editor: change before 778 publication]] extension the same example might look like: 780 C: A202 EXPUNGE 781 S: * 3 EXPUNGE 782 S: * 3 EXPUNGE 783 S: * 5 EXPUNGE 784 S: * 8 EXPUNGE 785 S: A202 OK EXPUNGE completed 787 (Continuing previous example) If subsequently messages with UIDs 504 788 and 508 got marked as \Deleted: 790 C: A210 EXPUNGE 791 S: * VANISHED 504,508 792 S: A210 OK EXPUNGE completed 794 I.e., the last VANISHED response only contains UIDs of messages 795 expunged since the previous VANISHED response. 797 3.7. CLOSED Response Code 799 The CLOSED response code has no parameters. A server implementing 800 the extension defined in this document MUST return the CLOSED 801 response code when the currently selected mailbox is closed 802 implicitly using the SELECT/EXAMINE command on another mailbox. 803 There is no need to return this response code on completion of the 804 CLOSE or the UNSELECT [UNSELECT] command (or similar) who's purpose 805 is to close the currently selected mailbox without opening a new one. 806 The CLOSED response code serves as a boundary between responses for 807 the previously opened mailbox (which was closed) and the newly 808 selected mailbox: all responses before the CLOSED response code 809 relate to the mailbox which was closed and all subsequent responses 810 relate to the newly opened mailbox. 812 4. Server implementation considerations 814 This section describes a minimalist implementation, a moderate 815 implementation, and an example of a full implementation. 817 4.1. Server implementations that don't store extra state 819 Strictly speaking, a server implementation that doesn't remember 820 modsequences associated with expunged messages can be considered 821 compliant with this specification. Such implementations return all 822 expunged messages specified in the UID set of the UID FETCH 823 (VANISHED) command every time, without paying attention to the 824 specified CHANGEDSINCE modsequence. Such implementations are 825 discouraged, as they can end up returning VANISHED responses bigger 826 than the result of a UID SEARCH command for the same UID set. 828 Clients which use the message sequence match data can reduce the 829 scope of this VANISHED response substantially in the typical case 830 where expunges have not happened, or happen only toward the end of 831 the mailbox. 833 4.2. Server implementations storing minimal state 835 A server which stores the HIGHESTMODSEQ value at the time of the last 836 EXPUNGE can omit the VANISHED response when a client provides a 837 MODSEQ value that is equal to, or higher than, the current value of 838 this datum; that is, when there have been no EXPUNGEs. 840 A client providing message sequence match data can reduce the scope 841 as above. In the case where there have been no expunges, the server 842 can ignore this data. 844 4.3. Additional state required on the server 846 When compared to the [CONDSTORE] extension, this extension requires 847 servers to store additional state associated with expunged messages. 848 Note that implementations are not required to store this state in 849 persistent storage, however use of persistent storage is advisable. 851 One possible way to correctly implement the extension described in 852 this document is to store a queue of pairs. 853 can be represented as a sequence of 854 pairs. 856 When messages are expunged, one or more entry are added to the queue 857 tail. 859 When the server receives a request to return expunged messages since 860 a given modsequence, it will search the queue from the tail (i.e. 861 going from the highest expunged modsequence to the lowest), until it 862 sees the first record with a modsequence less than or equal to the 863 given modsequence, or it reaches the head of the queue. 865 Note that indefinitely storing information about expunged messages 866 can cause storage and related problems for an implementation. In the 867 worst case, this could result in almost 64Gb of storage for each IMAP 868 mailbox. For example, consider an implementation that stores triples for each range of messages 870 expunged at the same time. Each triple requires 16 octets: 4 octets 871 for each of the two UIDs, and 8 octets for the modsequence. Assume a 872 mailbox containing a single message with a UID of 2**32-1 (the 873 maximum possible UID value), where messages had previously existed 874 with UIDs starting at 1, and have been expunged one at a time. For 875 this mailbox alone, storage is required for the triples <1, 1, 876 modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2, modseq4294967294>. 878 Hence, implementations are encouraged to adopt strategies to protect 879 against such storage problems, such as limiting the size of the queue 880 used to store modsequences for expunged messages and "expiring" older 881 records when this limit is reached. When the selected 882 implementation-specific queue limit is reached, the oldest record(s) 883 are deleted from the queue (Note that such records are located at the 884 queue head). For all such "expired" records the server needs to 885 store a single modsequence, which is the highest modsequence for all 886 "expired" expunged messages. 888 Note that if the client provides the message sequence match data, 889 this can heavily reduce the data cost of sending a complete set of 890 missing UIDs, thus reducing the problems for clients if a server is 891 unable to persist much of this queue. If the queue contains data 892 back to the requested modsequence, this data can be ignored. 894 Also note that if the UIDVALIDITY of the mailbox changes or if the 895 mailbox is deleted, then any state associated with expunged messages 896 MUST be deleted as well. 898 5. Updated synchronization sequence 900 This section updates the description of optimized synchronization in 901 section 6.1 of the [IMAP-DISC]. 903 An advanced disconnected mail client should use the X-DRAFT-W05- 904 QRESYNC [[anchor18: RFC editor: change before publication]] and 905 [CONDSTORE] extensions when they are supported by the server. The 906 client uses the value from the HIGHESTMODSEQ OK response code 907 received on mailbox opening to determine if it needs to 908 resynchronize. Once the synchronization is complete it MUST cache 909 the received value (unless the mailbox UIDVALIDITY value has changed; 910 See below). The client MUST update its copy of the HIGHESTMODSEQ 911 value whenever the server sends a subsequent HIGHESTMODSEQ OK 912 response code. 914 The client MUST also take note of any MODSEQ FETCH data items 915 received from the server. Whenever the client receives a tagged 916 response to a command, it calculates the highest value among all 917 MODSEQ FETCH data items received since the last tagged response. If 918 this value is bigger than the client's copy of the HIGHESTMODSEQ 919 value, then the client MUST use this value as its new HIGHESTMODSEQ 920 value. 922 Note: it is not safe to update the client's copy of the HIGHESTMODSEQ 923 value with a MODSEQ FETCH data item value as soon as it is received, 924 because servers are not required to send MODSEQ FETCH data items in 925 increasing modseqence order. This can lead to the client missing 926 some changes in case of connectivity loss. 928 When opening the mailbox for synchronization the client uses the 929 QRESYNC parameter to the SELECT/EXAMINE command. The QRESYNC 930 parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ 931 values, as known to the client. It can be optionally followed by the 932 set of UIDs, for example if the client is only interested in partial 933 synchronization of the mailbox. The client may also transmit a list 934 containing its knowledge of message numbers. 936 If the SELECT/EXAMINE command is successful, the client compares 937 UIDVALIDITY as described in step d)1) in section 3 of the 938 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 939 returned by the server and the server also returns the HIGHESTMODSEQ 940 response code, then the server reports expunged messages and returns 941 flag changes for all messages specified by the client in the UID set 942 parameter (or for all messages in the mailbox, if the client omitted 943 the UID set parameter). At this point the client is synchronized, 944 except for maybe the new messages. 946 If upon a successful SELECT/EXAMINE (QRESYNC) command the client 947 receives a NOMODSEQ OK untagged response (instead of the 948 HIGHESTMODSEQ response code), it MUST remove the last known 949 HIGHESTMODSEQ value from its cache and follow the more general 950 instructions in section 3 of the [IMAP-DISC]. 952 At this point the client is in sync with the server regarding old 953 messages. This client can now fetch information about new messages 954 (if requested by the user). 956 Step d) ("Server-to-client synchronization") in section 4 of the 957 [IMAP-DISC] in the presence of the X-DRAFT-W05-QRESYNC & CONDSTORE 958 extensions is amended as follows: 960 d) "Server-to-client synchronization" -- for each mailbox that 961 requires synchronization, do the following: 963 1a) Check the mailbox UIDVALIDITY (see section 4.1 of the 964 [IMAP-DISC] for more details) after issuing SELECT/ 965 EXAMINE (QRESYNC) command. If the UIDVALIDITY value 966 returned by the server differs, the client MUST 968 * empty the local cache of that mailbox; 970 * "forget" the cached HIGHESTMODSEQ value for 971 the mailbox; 973 * remove any pending "actions" which refer to 974 UIDs in that mailbox. Note, this doesn't 975 affect actions performed on client generated 976 fake UIDs (see section 5 of the [IMAP-DISC]); 978 * skip steps 1b and 2-II; 980 2) Fetch the current "descriptors"; 982 I) Discover new messages. 984 3) Fetch the bodies of any "interesting" messages that the 985 client doesn't already have. 987 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ 988 value has changed on the server while the client was 989 offline: 991 C: A142 SELECT INBOX (QRESYNC (3857529045 20010715194032001 1:198)) 992 S: * 172 EXISTS 993 S: * 1 RECENT 994 S: * OK [UNSEEN 12] Message 12 is first unseen 995 S: * OK [UIDVALIDITY 3857529045] UIDs valid 996 S: * OK [UIDNEXT 201] Predicted next UID 997 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 998 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 999 S: * OK [HIGHESTMODSEQ 20010715194045007] 1000 S: * VANISHED (EARLIER) 1:5,7:8,10:15 1001 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) 1002 FLAGS (\Deleted)) 1003 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) 1004 FLAGS ($NoJunk $AutoJunk $MDNSent)) 1005 ... 1006 S: A142 OK [READ-WRITE] SELECT completed 1008 6. Formal Syntax 1010 The following syntax specification uses the Augmented Backus-Naur 1011 Form (ABNF) notation as specified in [ABNF]. 1013 Non-terminals referenced but not defined below are as defined by 1014 [RFC3501], [CONDSTORE] or [IMAPABNF]. 1016 Except as noted otherwise, all alphabetic characters are case- 1017 insensitive. The use of upper or lower case characters to define 1018 token strings is for editorial clarity only. Implementations MUST 1019 accept these strings in a case-insensitive fashion. 1021 capability =/ "X-DRAFT-W05-QRESYNC" 1022 ;; [[Note to RFC Editor: change before 1023 ;; publication]] 1025 select-param = "QRESYNC" SP "(" uidvalidity SP 1026 mod-sequence-value [SP known-uids] 1027 [SP seq-match-data] ")" 1028 ;; conforms to the generic select-param 1029 ;; syntax defined in [IMAPABNF] 1031 seq-match-data = "(" known-sequence-set SP known-uid-set ")" 1032 uidvalidity = nz-number 1034 known-uids = sequence-set 1035 ;; sequence of UIDs, "*" is not allowed 1037 known-sequence-set = sequence-set 1038 ;; set of message numbers corresponding to 1039 ;; the UIDs in known-uid-set, in ascending order. 1040 ;; * is not allowed. 1042 known-uid-set = sequence-set 1043 ;; set of UIDs corresponding to the messages in 1044 ;; known-sequence-set, in ascending order. 1045 ;; * is not allowed. 1047 message-data =/ expunged-resp 1049 expunged-resp = "VANISHED" [SP "(EARLIER)"] SP known-uids 1051 rexpunges-fetch-mod = "VANISHED" 1052 ;; VANISHED UID FETCH modifier conforms 1053 ;; to the fetch-modifier syntax 1054 ;; defined in [IMAPABNF]. It is only 1055 ;; allowed in the UID FETCH command. 1057 resp-text-code =/ "CLOSED" 1059 7. Security Considerations 1061 As always, it is important to thoroughly test clients and servers 1062 implementing this extension, as it changes how the server reports 1063 expunged messages to the client. 1065 Security considerations relevant to [CONDSTORE] are relevant to this 1066 extension. 1068 This document doesn't raise any new security concerns not already 1069 raised by [CONDSTORE] or [RFC3501]. 1071 8. IANA Considerations 1073 IMAP4 capabilities are registered by publishing a standards track or 1074 IESG approved experimental RFC. The registry is currently located 1075 at: 1077 http://www.iana.org/assignments/imap4-capabilities 1079 This document defines the X-DRAFT-W05-QRESYNC [[anchor22: The final 1080 capability name will be chosen during AUTH48]] IMAP capability. IANA 1081 is requested to add this capability to the registry. 1083 9. Acknowledgments 1085 Thanks to Steve Hole, Cyrus Daboo and Michael Wener for encouraging 1086 creation of this document. 1088 Valuable comments, both in agreement and in dissent, were received 1089 from Timo Sirainen, Michael Wener, Randall Gellens, Arnt Gulbrandsen, 1090 Chris Newman, Peter Coates, Mark Crispin, Elwyn Davies, Dan Karp and 1091 Mike Zraly. 1093 This document takes substantial text from [RFC3501] by Mark Crispin. 1095 10. References 1097 10.1. Normative References 1099 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 1100 Syntax Specifications: ABNF", RFC 4234, October 2005. 1102 [CONDSTORE] 1103 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1104 STORE Operation or Quick Flag Changes Resynchronization", 1105 RFC 4551, June 2006. 1107 [ENABLE] Gulbrandsen, A., "The IMAP ENABLE Extension", 1108 draft-gulbrandsen-imap-enable (work in progress), 1109 March 2007. 1111 [IMAPABNF] 1112 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1113 ABNF", RFC 4466, April 2006. 1115 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1116 Requirement Levels", BCP 14, RFC 2119, March 1997. 1118 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1119 4rev1", RFC 3501, March 2003. 1121 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 1122 UIDPLUS extension", RFC 4315, December 2005. 1124 10.2. Informative References 1126 [IMAP-DISC] 1127 Melnikov, A., "Synchronization Operations For Disconnected 1128 Imap4 Clients", RFC 4549, June 2006. 1130 [UNSELECT] 1131 Melnikov, A., "Internet Message Access Protocol (IMAP) 1132 UNSELECT command", RFC 3691, February 2004. 1134 Authors' Addresses 1136 Alexey Melnikov 1137 Isode Ltd 1138 5 Castle Business Village 1139 36 Station Road 1140 Hampton, Middlesex TW12 2BX 1141 UK 1143 Email: Alexey.Melnikov@isode.com 1145 Dave Cridland 1146 Isode Ltd 1147 5 Castle Business Village 1148 36 Station Road 1149 Hampton, Middlesex TW12 2BX 1150 UK 1152 Email: dave.cridland@isode.com 1154 Corby Wilson 1155 Nokia 1156 5 Wayside Rd. 1157 Burlington, MA 01803 1158 USA 1160 Email: corby@computer.org 1162 Full Copyright Statement 1164 Copyright (C) The IETF Trust (2007). 1166 This document is subject to the rights, licenses and restrictions 1167 contained in BCP 78, and except as set forth therein, the authors 1168 retain all their rights. 1170 This document and the information contained herein are provided on an 1171 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1172 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1173 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1174 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1175 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1176 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1178 Intellectual Property 1180 The IETF takes no position regarding the validity or scope of any 1181 Intellectual Property Rights or other rights that might be claimed to 1182 pertain to the implementation or use of the technology described in 1183 this document or the extent to which any license under such rights 1184 might or might not be available; nor does it represent that it has 1185 made any independent effort to identify any such rights. Information 1186 on the procedures with respect to rights in RFC documents can be 1187 found in BCP 78 and BCP 79. 1189 Copies of IPR disclosures made to the IETF Secretariat and any 1190 assurances of licenses to be made available, or the result of an 1191 attempt made to obtain a general license or permission for the use of 1192 such proprietary rights by implementers or users of this 1193 specification can be obtained from the IETF on-line IPR repository at 1194 http://www.ietf.org/ipr. 1196 The IETF invites any interested party to bring to its attention any 1197 copyrights, patents or patent applications, or other proprietary 1198 rights that may cover technology that may be required to implement 1199 this standard. Please address the information to the IETF at 1200 ietf-ipr@ietf.org. 1202 Acknowledgment 1204 Funding for the RFC Editor function is provided by the IETF 1205 Administrative Support Activity (IASA).