idnits 2.17.1 draft-melnikov-imap-expunged-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 443. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 9, 2006) is 6524 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: 'IMAP' is mentioned on line 76, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 300, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 301, but not defined == Missing Reference: 'UIDNEXT 201' is mentioned on line 302, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 305, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 5 errors (**), 0 flaws (~~), 7 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 Expires: December 11, 2006 June 9, 2006 6 IMAP4 extension for reporting expunged messages 7 draft-melnikov-imap-expunged-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 11, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines an IMAP extension, which gives a disconnected 41 client ability to quickly learn about expunged messages. This 42 extension also introduces a new response that allows for a more 43 compact representation for a list of expunged messages. 45 Table of Contents 47 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 48 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 49 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 3 50 3.1. REPORTEXPUNGES FETCH modifier . . . . . . . . . . . . . . 3 51 3.2. EXPUNGED Response . . . . . . . . . . . . . . . . . . . . 4 52 4. Updated synchronization sequence . . . . . . . . . . . . . . . 6 53 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 56 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 59 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 Intellectual Property and Copyright Statements . . . . . . . . . . 12 63 1. Conventions Used in this Document 65 In examples, "C:" and "S:" indicate lines sent by the client and 66 server respectively. If a single "C:" or "S:" label applies to 67 multiple lines, then the line breaks between those lines are for 68 editorial clarity only and are not part of the actual protocol 69 exchange. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 Understanding of the IMAP message sequence numbers and UIDs and the 76 EXPUNGE response [IMAP] is essential when reading this document. 78 [[anchor2: Editorial comments and questions are marked like this.]] 80 2. Introduction and Overview 82 The [CONDSTORE] extension gives a disconnected client ability to 83 quickly synchronize flag changes for previously seen messages. In 84 order for the client to discover which messages have been expunged, 85 the client still has to issue a UID FETCH or a UID SEARCH command. 86 This document defines an IMAP extension, that allows a client to 87 quickly learn about expunged messages. This extension also 88 introduces a new response EXPUNGED that allows for a more compact 89 representation for a list of expunged messages. 91 The Expunged Messages Notification extension is present in any IMAP4 92 implementation which advertises "X-DRAFT-I01-EXPUNGED" [[anchor4: 93 Change upon publication]] as one of the supported capabilities in the 94 CAPABILITY command response. 96 3. IMAP Protocol Changes 98 3.1. REPORTEXPUNGES FETCH modifier 100 [IMAPABNF] has extended the syntax of the FETCH and UID FETCH 101 commands to include an optional FETCH modifier. This document 102 defines a new UID FETCH modifier (note, it is NOT allowed with a 103 FETCH command. The server MUST return tagged BAD response if this 104 response is specified as a modifier to the FETCH command [[anchor7: 105 Should this be allowed instead and can be used as "please send me 106 EXPUNGED" in the future flag?]]): REPORTEXPUNGES 108 The REPORTEXPUNGES FETCH modifier instructs the server to report all 109 messages from the UID set parameter to the UID FETCH command that 110 were expunged. The expunged messages are reported using the EXPUNGED 111 response as described in Section 3.2. 113 Example: The following example assumes that the server supports both 114 CONDSTORE [CONDSTORE] and the extension defined in this document. 116 Without the REPORTEXPUNGES FETCH modifier a CONDSTORE-aware client 117 [CONDSTORE] must issue two commands to learn about flag changes, as 118 well as messages expunged since the last synchronization: 120 C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) 121 S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) 122 S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) 123 S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk 124 $AutoJunk $MDNSent)) 125 S: s100 OK FETCH completed 126 C: s101 UID SEARCH 1:* 127 S: * SEARCH 4 6 7 8 10 12 128 S: s101 OK search completed 130 The second SEARCH response tells the client that the messages with 131 UIDs 7, 10 and 12 are still present, but their flags haven't changed 132 since the specified modification sequence. 134 Using the REPORTEXPUNGES FETCH modifier it is sufficient to issue 135 only a single command: 137 C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 138 REPORTEXPUNGES) 139 S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) 140 S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) 141 S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk 142 $AutoJunk $MDNSent)) 143 S: * EXPUNGED 1:3,5,9,11 144 S: s100 OK FETCH completed 146 3.2. EXPUNGED Response 148 Contents: list of UIDs 150 The EXPUNGED response reports that the specified UIDs have been 151 permanently removed from the mailbox. This response is similar to 152 the EXPUNGE response [RFC3501], however it can return information 153 about multiple messages and it returns UIDs, instead of message 154 numbers. The former allows to save bandwidth, while the latter is 155 more convenient for clients which only use UIDs to access the IMAP 156 server. 158 The EXPUNGED response is sent as a result of UID FETCH 159 (REPORTEXPUNGES) command, if the UID set parameter to the UID FETCH 160 (REPORTEXPUNGES) command includes UIDs of messages that are no longer 161 in the mailbox. The EXPUNGED response SHOULD also be sent by the 162 server instead of the EXPUNGE response, once the client has indicated 163 that it supports the extension described in this document by issuing 164 the UID FETCH (REPORTEXPUNGES) command on the connection. In 165 particular this affects the EXPUNGE [RFC3501] and UID EXPUNGE 166 [UIDPLUS] commands, as well as messages expunged in other sessions. 168 The EXPUNGED response caused by EXPUNGE/UID EXPUNGE/messages expunged 169 in other sessions also decrements the number of messages in the 170 mailbox; it is not necessary for the server to send an EXISTS and/or 171 RECENT response with the new value. It also decrements message 172 sequence numbers for each successive message in the mailbox (see 173 Example at the end of this section). 175 An EXPUNGED response MUST NOT be sent when no command is in progress, 176 nor while responding to a FETCH, STORE, or SEARCH command. This rule 177 is necessary to prevent a loss of synchronization of message sequence 178 numbers between client and server. A command is not "in progress" 179 until the complete command has been received; in particular, a 180 command is not "in progress" during the negotiation of command 181 continuation. 183 Note: UID FETCH, UID STORE, and UID SEARCH are different commands 184 from FETCH, STORE, and SEARCH. An EXPUNGED response MAY be sent 185 during a UID command. 187 The update from the EXPUNGED response MUST be recorded by the client. 189 Example: Let's assume that there is the following mapping between 190 message numbers and UIDs in the currently selected mailbox (here "X" 191 marks messages with the \Deleted flag set, and "x" represents UIDs 192 which are not relevant for the example): 194 Message numbers: 1 2 3 4 5 6 7 8 9 10 11 195 UIDs: x x 5 7 x x 10 x x x 25 196 \Deleted messaged: X X X X 198 In the presence of the extension defined in this document: 200 C: A202 EXPUNGE 201 S: * EXPUNGED 5,7,10,25 202 S: A202 OK EXPUNGE completed 203 Without the X-DRAFT-I01-EXPUNGED [[anchor8: fix upon publication]] 204 extension the same example can look like: 206 C: A202 EXPUNGE 207 S: * 3 EXPUNGE 208 S: * 3 EXPUNGE 209 S: * 5 EXPUNGE 210 S: * 8 EXPUNGE 211 S: A202 OK EXPUNGE completed 213 4. Updated synchronization sequence 215 This section updates the description of optimized synchronization in 216 section 6.1 of the [IMAP-DISC]. 218 An advanced disconnected mail client should use the EXPUNGED and 219 [CONDSTORE] extensions when they are supported by the server. The 220 client MUST cache the value from HIGHESTMODSEQ OK response code 221 received on mailbox opening and update it whenever the server sends 222 MODSEQ FETCH data items. 224 If the client receives NOMODSEQ OK untagged response instead of 225 HIGHESTMODSEQ, it MUST remove the last known HIGHESTMODSEQ value from 226 its cache and follow more general instructions in section 3 of the 227 [IMAP-DISC]. 229 When the client opens the mailbox for synchronization it first 230 compares UIDVALIDITY as described in step d)1) in section 3 of the 231 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 232 returned by the server, the client MUST compare the cached value of 233 HIGHESTMODSEQ with the one returned by the server. If the cached 234 HIGHESTMODSEQ value also matches the one returned by the server, then 235 the client SHOULD NOT fetch flags for cached messages, as they 236 haven't changed. If the value on the server is higher than the 237 cached one, the client MAY use "SEARCH MODSEQ " to find 238 all messages with flags changed since the last time the client was 239 online and had the mailbox opened. Alternatively the client MAY use 240 "FETCH 1:* (FLAGS) (CHANGEDSINCE REPORTEXPUNGES)". 241 The latter operation combines reporting expunged messages, searching 242 for changed messages and fetching new information. 244 In all cases the client still needs to fetch information about new 245 messages (if requested by the user). If the client has used SEARCH 246 MODSEQ, it will also have to discover which messages have been 247 expunged. 249 Step d) ("Server-to-client synchronization") in section 4 of the 251 [IMAP-DISC] in the presence of the EXPUNGED & CONDSTORE extensions is 252 amended as follows: 254 d) "Server-to-client synchronization" - for each mailbox that 255 requires synchronization, do the following: 257 1a) Check the mailbox UIDVALIDITY (see section 4.1 of the 258 [IMAP-DISC] for more details) with SELECT/EXAMINE/STATUS. 259 If the UIDVALIDITY value returned by the server differs, 260 the client MUST 262 * empty the local cache of that mailbox; 264 * "forget" the cached HIGHESTMODSEQ value for 265 the mailbox; 267 * remove any pending "actions" which refer to 268 UIDs in that mailbox. Note, this doesn't 269 affect actions performed on client generated 270 fake UIDs (see section 5 of the [IMAP-DISC]); 272 * skip steps 1b and 2-II; 274 1b) Check the mailbox HIGHESTMODSEQ. If the cached value is 275 the same as the one returned by the server, skip fetching 276 message flags on step 2-II, i.e. the client only has to 277 find out which messages got expunged. 279 2) Fetch the current "descriptors"; 281 I) Discover new messages. 283 II) Discover changes to old messages and expunged messages 284 using "UID FETCH 1: (FLAGS) (CHANGEDSINCE 285 REPORTEXPUNGES)". 287 (Note, if is replaced with "*", this 288 command will return flags for new messages as well) 290 3) Fetch the bodies of any "interesting" messages that the 291 client doesn't already have. 293 Example: The UIDVALIDITY value is the same, but the HIGHESTMODSEQ 294 value has changed on the server while the client was 295 offline: 297 C: A142 SELECT INBOX 298 S: * 172 EXISTS 299 S: * 1 RECENT 300 S: * OK [UNSEEN 12] Message 12 is first unseen 301 S: * OK [UIDVALIDITY 3857529045] UIDs valid 302 S: * OK [UIDNEXT 201] Predicted next UID 303 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 304 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 305 S: * OK [HIGHESTMODSEQ 20010715194045007] 306 S: A142 OK [READ-WRITE] SELECT completed 308 after that: 310 C: A143 UID FETCH 1:20 (FLAGS) 311 (CHANGEDSINCE 20010715194032001 REPORTEXPUNGES) 312 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) 313 FLAGS (\Deleted)) 314 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) 315 FLAGS ($NoJunk $AutoJunk $MDNSent)) 316 ... 317 S: * EXPUNGED 1:5,7:8,10:15 318 S: A143 OK FETCH completed 320 5. Formal Syntax 322 The following syntax specification uses the Augmented Backus-Naur 323 Form (ABNF) notation as specified in [ABNF]. 325 Non-terminals referenced but not defined below are as defined by 326 [RFC3501], or [IMAPABNF]. 328 Except as noted otherwise, all alphabetic characters are case- 329 insensitive. The use of upper or lower case characters to define 330 token strings is for editorial clarity only. Implementations MUST 331 accept these strings in a case-insensitive fashion. 333 capability =/ "X-DRAFT-I01-EXPUNGED" 334 ;; [[Note to RFC Editor: fix before 335 ;; publication]] 337 message-data =/ expunged-resp 338 expunged-resp = "EXPUNGED" SP known-uids 340 known-uids = sequence-set 341 ;; sequence of UIDs, "*" is not allowed 343 rexpunges-fetch-mod = "REPORTEXPUNGES" 344 ;; REPORTEXPUNGES FETCH modifier conforms 345 ;; to the fetch-modifier syntax 346 ;; defined in [IMAPABNF]. It is only 347 ;; allowed in the UID FETCH command. 349 6. Security Considerations 351 It is believed that this extension doesn't raise any additional 352 security concerns not already discussed in [RFC3501]. 354 As always, it is important to thoroughly test clients and servers 355 implementing this extension, as it changes how the server reports 356 expunged messages to the client. 358 7. IANA Considerations 360 IMAP4 capabilities are registered by publishing a standards track or 361 IESG approved experimental RFC. The registry is currently located 362 at: 364 http://www.iana.org/assignments/imap4-capabilities 366 This document defines the X-DRAFT-I01-EXPUNGED [[anchor13: Note to 367 RFC Editor: fix before publication]] IMAP capability. IANA is 368 requested to add it to the registry. 370 8. Acknowledgments 372 Thanks to Steve Hole, Cyrus Daboo, David Cridland and Michael Wener 373 for encouraging me to write this document. 375 Thanks to David Cridland, Timo Sirainen and Michael Wener for 376 comments and corrections. 378 This document takes substantial text from [RFC3501] by Mark Crispin. 380 9. References 381 9.1. Normative References 383 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 384 Syntax Specifications: ABNF", RFC 4234, October 2005. 386 [IMAPABNF] 387 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 388 ABNF", RFC 4466, April 2006. 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, March 1997. 393 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 394 4rev1", RFC 3501, March 2003. 396 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 397 UIDPLUS extension", RFC 4315, December 2005. 399 9.2. Informative References 401 [CONDSTORE] 402 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 403 STORE Operation or Quick Flag Changes Resynchronization", 404 June 2006. 406 [IMAP-DISC] 407 Melnikov, A., "Synchronization Operations For Disconnected 408 Imap4 Clients", RFC 4549, June 2006. 410 Author's Address 412 Alexey Melnikov 413 Isode Ltd 414 5 Castle Business Village 415 36 Station Road 416 Hampton, Middlesex TW12 2BX 417 UK 419 Email: Alexey.Melnikov@isode.com 421 Intellectual Property Statement 423 The IETF takes no position regarding the validity or scope of any 424 Intellectual Property Rights or other rights that might be claimed to 425 pertain to the implementation or use of the technology described in 426 this document or the extent to which any license under such rights 427 might or might not be available; nor does it represent that it has 428 made any independent effort to identify any such rights. Information 429 on the procedures with respect to rights in RFC documents can be 430 found in BCP 78 and BCP 79. 432 Copies of IPR disclosures made to the IETF Secretariat and any 433 assurances of licenses to be made available, or the result of an 434 attempt made to obtain a general license or permission for the use of 435 such proprietary rights by implementers or users of this 436 specification can be obtained from the IETF on-line IPR repository at 437 http://www.ietf.org/ipr. 439 The IETF invites any interested party to bring to its attention any 440 copyrights, patents or patent applications, or other proprietary 441 rights that may cover technology that may be required to implement 442 this standard. Please address the information to the IETF at 443 ietf-ipr@ietf.org. 445 Disclaimer of Validity 447 This document and the information contained herein are provided on an 448 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 449 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 450 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 451 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 452 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 453 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 Copyright Statement 457 Copyright (C) The Internet Society (2006). This document is subject 458 to the rights, licenses and restrictions contained in BCP 78, and 459 except as set forth therein, the authors retain all their rights. 461 Acknowledgment 463 Funding for the RFC Editor function is currently provided by the 464 Internet Society.