idnits 2.17.1 draft-melnikov-imap-expunged-00.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 504. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** Missing revision: the document name given in the document, 'draft-melnikov-imap-expunged', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-melnikov-imap-expunged', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-melnikov-imap-expunged', but the file name used is 'draft-melnikov-imap-expunged-00' == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 552 lines 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 2005) is 7013 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 184, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 372, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 373, but not defined == Missing Reference: 'HIGHESTMODSEQ 20010715194045007' is mentioned on line 376, but not defined == Unused Reference: 'TRANS-CAPA' is defined on line 447, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- Possible downref: Non-RFC (?) normative reference: ref. 'ABNF' -- No information found for draft-ietf-imapext-condstore-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CONDSTORE' -- No information found for draft-melnikov-imap-disc-XX - is the name correct? -- No information found for draft-melnikov-imap-transitional-capa-XX - is the name correct? Summary: 9 errors (**), 1 flaw (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. Melnikov 3 Document: draft-melnikov-imap-expunged Isode Ltd 4 Expires: July 2005 January 2005 6 IMAP4 extension to CONDSTORE for reporting messages expunged since 7 last synchronization 8 draft-melnikov-imap-expunged-00 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 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. Internet Drafts are draft documents valid for a maximum of 21 six months. Internet Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet Drafts as reference material or to cite them other than as 24 ''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 A revised version of this draft document will be submitted to the 33 RFC editor as a Standard Track RFC for the Internet Community. 34 Discussion and suggestions for improvement are requested, and 35 should be sent to ietf-imapext@imc.org and/or lemonade@ietf.org. 36 Distribution of this memo is unlimited. 38 Abstract 40 This document defines an extension to IMAP Conditional Store 41 extension, which gives a disconnected client ability to receive 42 notifications about messages expunged since last synchronization. 44 Table of Contents 46 1. Conventions Used in this Document 2 47 2. Introduction 2 48 3. IMAP Protocol Changes 3 49 3.1 EXPUNGE Command 3 50 3.2 CLOSE Command 4 51 3.3 "REPORTEXPUNGES" FETCH modifier 5 52 3.4 EXPUNGED Response 6 53 3.5 Other issues 7 54 4. Updated synchronization sequence 7 55 5. Formal Syntax 9 56 6. Security Considerations 10 57 7. IANA Considerations 10 58 8. References 10 59 8.1 Normative References 10 60 8.2 Informative References 10 61 9. Acknowledgments 10 62 10. Author's Addresses 11 63 11. Full Copyright Statement 11 64 12. Intellectual Property 11 65 13. Appendix A. Editorial. 12 66 13.1 Change Log 12 67 13.2 Open Issues for Discussion 12 68 13.3 To Do 12 70 1. Conventions Used in this Document 72 In examples, "C:" and "S:" indicate lines sent by the client and 73 server respectively. 75 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 76 in this document are to be interpreted as defined in "Key words for 77 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 79 <> 81 2. Introduction 83 The [CONDSTORE] extension gives a disconnected client ability to 84 quickly synchronize flag (and annotation) changes for previously 85 seen messages. In order for the client to discover which messages 86 have been expunged since the last syncronization, the client still 87 has to issue a UID FETCH or a UID SEARCH command. This document 88 defines an extension to [CONDSTORE], that allows a compliant client 89 to quickly learn about expunged messages. 91 The Expunged Messages Notification extension is present in any 92 IMAP4 implementation which advertises "X-DRAFT-I00-EXPUNGED" as one 93 of the supported capabilities in the CAPABILITY command response. 94 Any server returning the capability MUST also support the 95 [CONDSTORE] extension. 97 This document puts additional requirements on a server implementing 98 the [CONDSTORE] extension. Each mailbox that supports persistent 99 storage of mod-sequences, i.e. for which the server has sent 100 HIGHESTMODSEQ untagged OK response code on a successful 101 SELECT/EXAMINE, MUST increment per-mailbox mod-sequence when one or 102 more message is expunged due to EXPUNGE, UID EXPUNGE or CLOSE; the 103 server MUST associate the incremented mod-sequence with the UID of 104 the expunged message(s). 105 <> 107 This change doesn�t affect a client that only supports the 108 CONDSTORE extension, however per-mailbox mod-sequence change due to 109 expunges may force the client to send FETCH CHANGEDSINCE that will 110 return no data, thus forcing additional round-trip. <> 112 3. IMAP Protocol Changes 114 3.1 EXPUNGE Command 116 Arguments: none 118 Responses: untagged responses: EXPUNGE 120 Result: OK - expunge completed 121 NO - expunge failure: can't expunge (e.g., permission 122 denied) 123 BAD - command unknown or arguments invalid 125 This section updates definition of the EXPUNGE command described in 126 section 6.4.3 of [IMAP4]. 128 The EXPUNGE command permanently removes all messages that have the 129 \Deleted flag set from the currently selected mailbox. Before 130 returning an OK to the client, an untagged EXPUNGE response is sent 131 for each message that is removed. 133 If the server is capable of storing modification sequences for the 134 selected mailbox, it MUST increment per-mailbox mod-sequence if at 135 least one message was permanently removed due to the execution of 136 the EXPUNGE command. For each permanently removed message the 137 server MUST remember the incremented mod-sequence and corresponding 138 UID. If at least one message got expunged, the server MUST send the 139 updated per-mailbox modification sequence using the HIGHESTMODSEQ 140 untagged response code. 142 <> 145 Example: C: A202 EXPUNGE 146 S: * 3 EXPUNGE 147 S: * 3 EXPUNGE 148 S: * 5 EXPUNGE 149 S: * 8 EXPUNGE 150 S: * OK [HIGHESTMODSEQ 20010715194045319] 151 S: A202 OK EXPUNGE completed 153 Note: In this example, messages 3, 4, 7, and 11 had the 154 \Deleted flag set. See the description of the EXPUNGE 155 response in [IMAP4] for further explanation. 157 3.2 CLOSE Command 159 Arguments: none 161 Responses: no specific responses for this command 163 Result: OK - close completed, now in authenticated state 164 BAD - command unknown or arguments invalid 166 This section updates definition of the CLOSE command described in 167 section 6.4.2 of [IMAP4]. 169 The CLOSE command permanently removes all messages that have the 170 \Deleted flag set from the currently selected mailbox, and returns 171 to the authenticated state from the selected state. No untagged 172 EXPUNGE responses are sent. 174 If the server is capable of storing modification sequences for the 175 selected mailbox, it MUST increment per-mailbox mod-sequence if at 176 least one message was permanently removed due to the execution of 177 the CLOSE command. For each permanently removed message the server 178 MUST remember the incremented mod-sequence and corresponding UID. 179 If at least one message got expunged, the server MUST send the 180 updated per-mailbox modification sequence using the HIGHESTMODSEQ 181 untagged response code. 183 Example: C: A202 CLOSE 184 S: * OK [HIGHESTMODSEQ 20010715194045319] 185 S: A202 OK EXPUNGE completed 187 3.3 "REPORTEXPUNGES" FETCH modifier 189 [CONDSTORE] has extended the syntax of the FETCH and UID FETCH 190 commands to include an optional FETCH modifier. This document 191 defines a new UID FETCH modifier (note, it is NOT allowed with a 192 FETCH command <>): 194 REPORTEXPUNGES 196 The REPORTEXPUNGES FETCH modifier MUST only be specified together 197 with the CHANGEDSINCE FETCH modifier. 198 <> 208 The REPORTEXPUNGES FETCH modifier instructs the server to also 209 report all messages from the FETCH message set that were expunged 210 and their associated expunge mod-sequence is bigger than the mod- 211 sequence specified in the CHANGEDSINCE FETCH modifier. 212 The expunged messages are reported using the EXPUNGED response as 213 described in section 3.4. 215 <> 220 Example: Without the REPORTEXPUNGES FETCH modifier a CONDSTORE- 221 aware client must issue two commands to learn about flag changes, 222 as well as messages expunged since the last synchronization: 224 C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345) 225 S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) 226 S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) 227 S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk 228 $MDNSent)) 229 S: s100 OK FETCH completed 230 C: s101 UID SEARCH 1:* 231 S: * SEARCH 4 6 7 8 10 12 232 S: s101 OK search completed 234 The second SEARCH response tells the client that the messages with 235 UIDs 7, 10 and 12 are still present, but their flags haven�t 236 changed since the specified modification sequence. 238 Using the REPORTEXPUNGES FETCH modifier it is sufficient to issue 239 only a single command: 241 C: s100 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 12345 242 REPORTEXPUNGES) 243 S: * 1 FETCH (UID 4 MODSEQ (65402) FLAGS (\Seen)) 244 S: * 2 FETCH (UID 6 MODSEQ (75403) FLAGS (\Deleted)) 245 S: * 4 FETCH (UID 8 MODSEQ (29738) FLAGS ($NoJunk $AutoJunk 246 $MDNSent)) 247 S: * EXPUNGED 5,9 248 S: s100 OK FETCH completed 250 The EXPUNGED response tells the client that messages with UIDs 5 251 and 9 have been expunged since the specified modification sequence. 252 Messages with UIDs 1,2,3,4 and 11 have been expunged earlier. 254 3.4 EXPUNGED Response 256 Contents: list of UIDs 258 The EXPUNGED response reports that the specified UIDs have been 259 permanently removed from the mailbox. This response is similar to 260 the EXPUNGE response [IMAP4], however it may return information 261 about multiple messages and it returns UIDs, instead of message 262 numbers. 264 <> <> 268 An EXPUNGED response MUST NOT be sent when no command is in 269 progress, nor while responding to a FETCH, STORE, or SEARCH 270 command. This rule is necessary to prevent a loss of 271 synchronization of message sequence numbers between client and 272 server. A command is not "in progress" until the complete command 273 has been received; in particular, a command is not "in progress" 274 during the negotiation of command continuation. 276 Note: UID FETCH, UID STORE, and UID SEARCH are different 277 commands from FETCH, STORE, and SEARCH. An EXPUNGED 278 response MAY be sent during a UID command. 280 <> 283 The update from the EXPUNGED response MUST be recorded by the 284 client. 286 Example: S: * EXPUNGED 5,7,9,15:21 288 3.5 Other issues 290 <> 292 4. Updated synchronization sequence 294 This section updates the description of optimized synchronization 295 in section 6.1 of the [IMAP-DISC]. 297 An advanced disconnected mail client should use the EXPUNGED and 298 [CONDSTORE] extensions when they are supported by the server. The 299 client must cache the value from HIGHESTMODSEQ OK response code 300 received on mailbox opening and update it whenever the server sends 301 MODSEQ FETCH data items. 303 If the client receives NOMODSEQ OK untagged response instead of 304 HIGHESTMODSEQ, it MUST remove the last known HIGHESTMODSEQ value 305 from its cache and follow more general instructions in section 3 of 306 the [IMAP-DISC]. 308 When the client opens the mailbox for synchronization it first 309 compares UIDVALIDITY as described in step d)1) in section 3 of the 310 [IMAP-DISC]. If the cached UIDVALIDITY value matches the one 311 returned by the server, the client MUST compare the cached value of 312 HIGHESTMODSEQ with the one returned by the server. If the cached 313 HIGHESTMODSEQ value also matches the one returned by the server, 314 then the client MUST NOT fetch flags for cached messages, as they 315 hasn't changed. If the value on the server is higher than the 316 cached one, the client MAY use "SEARCH MODSEQ " to 317 find all messages with flags changed since the last time the client 318 was online and had the mailbox opened. Alternatively the client MAY 319 use "FETCH 1:* (FLAGS) (CHANGEDSINCE 320 REPORTEXPUNGES)". The latter operation combines reporting expunged 321 messages, searching for changed messages and fetching new 322 information. 324 In all cases the client still needs to fetch information about new 325 messages (if requested by the user). If the client has used SEARCH 326 MODSEQ, it will also have to discover which messages have been 327 expunged. 329 Step d) ("Server-to-client synchronization") in section 4 of the 330 [IMAP-DISC] in the presence of the EXPUNGED & CONDSTORE extensions 331 is amended as follows: 333 d) "Server-to-client synchronization" - for each mailbox 334 that requires synchronization, do the following: 336 1a) Check the mailbox UIDVALIDITY (see section 4.1 of the 337 [IMAP-DISC] for more details) with SELECT/EXAMINE/STATUS. If the 338 UIDVALIDITY value returned by the server differs, the client MUST 340 * empty the local cache of that mailbox; 341 * "forget" the cached HIGHESTMODSEQ value for 342 the mailbox; 343 * remove any pending "actions" which refer to UIDs in 344 that mailbox. Note, this doesn't affect actions 345 performed on client generated fake UIDs 346 (see section 5 of the [IMAP-DISC]); 347 * skip steps 1b and 2-II; 349 1b) Check the mailbox HIGHESTMODSEQ. If the cached value 350 is the same as the one returned by the server, skip fetching 351 message flags on step 2-II, i.e. the client only has to find out 352 which messages got expunged. 354 2) Fetch the current "descriptors"; 356 I) Discover new messages. 358 II) Discover changes to old messages using 359 "UID FETCH 1:* (FLAGS) (CHANGEDSINCE 360 REPORTEXPUNGES)". 362 3) Fetch the bodies of any "interesting" messages that the 363 client doesn't already have. 365 Example (the UIDVALIDITY value is the same, but the 366 HIGHESTMODSEQ value has changed on the server while the client was 367 offline): 369 C: A142 SELECT INBOX 370 S: * 172 EXISTS 371 S: * 1 RECENT 372 S: * OK [UNSEEN 12] Message 12 is first unseen 373 S: * OK [UIDVALIDITY 3857529045] UIDs valid 374 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 375 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 376 S: * OK [HIGHESTMODSEQ 20010715194045007] 377 S: A142 OK [READ-WRITE] SELECT completed 379 after that: 380 C: A143 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 381 20010715194032001 REPORTEXPUNGES) 382 S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) FLAGS 383 (\Deleted)) 384 S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) FLAGS 385 ($NoJunk 386 $AutoJunk $MDNSent)) 387 ... 388 S: * EXPUNGED 7,10:15 389 S: A143 OK FETCH completed 391 5. Formal Syntax 393 The following syntax specification uses the Augmented Backus-Naur 394 Form (ABNF) notation as specified in [ABNF]. 396 Non-terminals referenced but not defined below are as defined by 397 [IMAP4] or [CONDSTORE]. 399 Except as noted otherwise, all alphabetic characters are case- 400 insensitive. The use of upper or lower case characters to define 401 token strings is for editorial clarity only. Implementations MUST 402 accept these strings in a case-insensitive fashion. 404 capability =/ "X-DRAFT-I00-EXPUNGED" 406 message-data =/ expunged-resp 408 expunged-resp = "EXPUNGED" SP known-uids 410 known-uids = sequence-set 411 ;; sequence of UIDs, "*" is not allowed 413 chgsince-fetch-mod = "REPORTEXPUNGES" 414 ;; REPORTEXPUNGES FETCH modifier conforms 415 ;; to the fetch-modifier syntax 417 6. Security Considerations 419 <> 421 7. IANA Considerations 423 <> 425 8. References 427 8.1 Normative References 429 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", RFC 2119, March 1997. 432 [IMAP4], Crispin, M., "Internet Message Access Protocol - Version 433 4rev1", RFC 3501, University of Washington, March 2003. 435 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF 436 for Syntax Specifications: ABNF", Work in Progress. 438 [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for 439 Conditional STORE", draft-ietf-imapext-condstore-XX.txt. 441 8.2 Informative References 443 [IMAP-DISC] Melnikov, A. "Synchronization Operations For 444 Disconnected Imap4 Clients", work in progress, draft-melnikov-imap- 445 disc-XX.txt 447 [TRANS-CAPA] Melnikov, A., "Transitional IMAP capabilities", work 448 in progress, draft-melnikov-imap-transitional-capa-XX.txt 450 9. Acknowledgments 452 Thanks to Steve Hole, Cyrus Daboo and Michael Wener for encouraging 453 me to write this document. 455 10. Author's Addresses 457 Alexey Melnikov 458 Isode Limited 459 5 Castle Business Village 460 36 Station Road 461 Hampton, Middlesex, TW12 2BX 462 UK 464 Email: Alexey.Melnikov@isode.com 466 11. Full Copyright Statement 468 Copyright (C) The Internet Society (2005). This document is 469 subject to the rights, licenses and restrictions contained in BCP 470 78, and except as set forth therein, the authors retain all their 471 rights. 473 This document and the information contained herein are provided on 474 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 475 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 476 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 477 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 478 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 479 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 480 PARTICULAR PURPOSE. 482 12. Intellectual Property 484 The IETF takes no position regarding the validity or scope of any 485 Intellectual Property Rights or other rights that might be claimed 486 to pertain to the implementation or use of the technology described 487 in this document or the extent to which any license under such 488 rights might or might not be available; nor does it represent that 489 it has made any independent effort to identify any such rights. 490 Information on the procedures with respect to rights in RFC 491 documents can be found in BCP 78 and BCP 79. 493 Copies of IPR disclosures made to the IETF Secretariat and any 494 assurances of licenses to be made available, or the result of an 495 attempt made to obtain a general license or permission for the use 496 of such proprietary rights by implementers or users of this 497 specification can be obtained from the IETF on-line IPR repository 498 at http://www.ietf.org/ipr. 500 The IETF invites any interested party to bring to its attention any 501 copyrights, patents or patent applications, or other proprietary 502 rights that may cover technology that may be required to implement 503 this standard. Please address the information to the IETF at ietf- 504 ipr@ietf.org. 506 Acknowledgement 508 Funding for the RFC Editor function is currently provided by the 509 Internet Society. 511 13. Appendix A. Editorial. 513 <> 515 13.1 Change Log 517 00 Initial Revision. 519 13.2 Open Issues for Discussion 521 13.3 To Do 523 1. Add section about rationale?