idnits 2.17.1 draft-brandt-imap-replace-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2018) is 2119 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: 'UID' is mentioned on line 197, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Brandt 3 Internet-Draft Verizon 4 Intended status: Standards Track June 30, 2018 5 Expires: January 1, 2019 7 IMAP REPLACE Extension 8 draft-brandt-imap-replace-03 10 Abstract 12 This document defines an IMAP extension which can be used to replace 13 an existing message in a message store with a new message. Message 14 replacement is a common operation for clients that automatically save 15 drafts or notes as a user composes them. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 1, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . . 3 54 3.1. Advertising Support for REPLACE . . . . . . . . . . . . . 3 55 3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3 56 3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4 57 3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 4 58 3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 5 59 4. Interaction with other extensions . . . . . . . . . . . . . . 6 60 4.1. RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. RFC 4469, CATENATE . . . . . . . . . . . . . . . . . . . 6 62 4.3. RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . . 8 63 4.4. RFC 6785, IMAP Events in Sieve . . . . . . . . . . . . . 8 64 4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 8 65 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Conventions Used in This Document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 Formal syntax is defined by [RFC5234]. 82 Example lines prefaced by "C:" are sent by the client and ones 83 prefaced by "S:" by the server. 85 2. Overview 87 This document defines an IMAP [RFC3501] extension to facilitate 88 replacing an existing message with a new one. This is accomplished 89 by defining a new REPLACE command and extending the UID command to 90 allow UID REPLACE. 92 Since there is no replace function in the base IMAP specification, 93 clients have instead had to use a combination of three separate 94 commands issued in serial fashion; APPEND, STORE, EXPUNGE. 95 Pipelining of these three commands is not recommended since failure 96 of any individual command should prevent subsequent commands from 97 being executed lest the original message version be lost. 99 Because of the non-atomic nature of the existing sequence, 100 interruptions can leave messages in intermediate states which can be 101 seen and acted upon by other clients. Such interruptions can also 102 strand older revisions of messages, thereby forcing the user to 103 manually clean up multiple revisions of the same message in order to 104 avoid wasteful quota consumption. Additionally, the existing 105 sequence can fail on APPEND due to an over-quota condition even 106 though the subsequent STORE/EXPUNGE would free up enough space for 107 the newly revised message. And finally, server efficiencies may be 108 possible with a single logical message replacement operation as 109 compared to the existing APPEND/STORE/EXPUNGE sequence. 111 In its simplest form, the REPLACE command is a single-command 112 encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a 113 message, except that it avoids any of the quota implications or 114 intermediate states associated with the 3 command sequence. In 115 handling a REPLACE command, a server MUST NOT generate a response 116 code for the STORE +flags \DELETED portion of the sequence. 117 Additionally, servers supporting the REPLACE command MUST NOT infer 118 any inheritance of content, flags, or annotations from the message 119 being replaced. Finally, the replaced and replacing messages SHOULD 120 NOT be present in the mailbox at the same time. 122 3. REPLACE and UID REPLACE 124 3.1. Advertising Support for REPLACE 126 Servers that implement the REPLACE extension will return "REPLACE" as 127 one of the supported capabilities in the CAPABILITY command response. 129 3.2. REPLACE Command 131 Arguments: message sequence number 132 mailbox name 133 OPTIONAL flag parenthesized list 134 OPTIONAL date/time string 135 message literal 137 Responses: no specific responses for this command 139 Result: OK - replace completed 140 NO - replace error; can't remove specified message 141 or can't add new message content 142 BAD - command unknown or arguments invalid 144 Example: 145 C: A003 REPLACE 4 Drafts (\Seen \Draft) {312} 146 S: + Ready for literal data 147 C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) 148 C: From: Fritz Schmidt 149 C: Subject: happy new year !! 150 C: To: miss.mitzy@example.org 151 C: Message-Id: 152 C: MIME-Version: 1.0 153 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 154 C: 155 C: Just saw the best fireworks show. Wish you were here. 156 C: 157 S: * 5 EXISTS 158 S: * 4 EXPUNGE 159 S: A003 OK [APPENDUID 1 2000] Replace completed 161 3.3. UID REPLACE Command 163 This extends the first form of the UID command (see [RFC3501] 164 Section 6.4.8) to add the REPLACE command defined above as a valid 165 argument. This form of REPLACE uses a UID rather than sequence 166 number as its first parameter. 168 Example: 169 C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350} 170 S: + Ready for literal data 171 C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST) 172 C: From: Fritz Schmidt 173 C: Subject: happy new year !! 174 C: To: miss.mitzy@example.org 175 C: Message-Id: 176 C: MIME-Version: 1.0 177 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 178 C: 179 C: Just saw the best fireworks show. Wish you were here. 180 C: Hopefully next year you can join us. 181 C: 182 S: * 5 EXISTS 183 S: * 4 EXPUNGE 184 S: A004 OK [APPENDUID 1 2001] Replace completed 186 3.4. Semantics of REPLACE and UID REPLACE 188 The REPLACE and UID REPLACE commands take five arguments: a message 189 identifier, a named mailbox, an optional parenthesized flag list, an 190 optional message date/time string, and a message literal. The 191 message literal will be appended to the named mailbox, and the 192 message specified by the message identifier will be removed from the 193 selected mailbox. These operations will appear to the client as a 194 single action. This has the same effect as the following sequence: 196 1. APPEND 197 2. [UID] STORE +FLAGS.SILENT \DELETED 198 3. UID EXPUNGE 200 In the cited sequence, the quota implications of the APPEND are 201 evaluated within the context of the pending EXPUNGE so that only the 202 net quota consumption is considered. Additionally, the EXPUNGE 203 portion of the sequence only applies to the specified message, not 204 all messages flagged as \Deleted. 206 Although the effect of REPLACE is identical to the steps above, the 207 semantics are not identical; similar to MOVE [RFC6851], the 208 intermediate states produced do not occur, and the response codes are 209 different. In particular, the response codes for APPEND and EXPUNGE 210 will be returned while those for the STORE operation MUST NOT be 211 generated. 213 When an error occurs while processing REPLACE or UID REPLACE, the 214 server MUST NOT leave the selected mailbox in an inconsistent state; 215 any untagged EXPUNGE response MUST NOT be sent until all actions are 216 successfully completed. 218 While it may be common for the named mailbox argument to match the 219 selected mailbox for the common use case of replacing a draft, the 220 REPLACE extension intentionally does not require the two to be the 221 same. As an example, it's possible to use the REPLACE command to 222 replace a message in the \Drafts special-use mailbox with a message 223 in the \Sent special-use mailbox following message submission. 225 Because of the similarity of REPLACE to APPEND, extensions that 226 affect APPEND affect REPLACE in the same way. Response codes such as 227 TRYCREATE (see [RFC3501] Section 6.3.11), along with those defined by 228 extensions, are sent as appropriate. See Section 4 for more 229 information about how REPLACE interacts with other IMAP extensions. 231 3.5. IMAP State Diagram Impacts 233 Unlike the APPEND command which is valid in the authenticated state, 234 the REPLACE and UID REPLACE commands MUST only be valid in the 235 selected state. This difference from APPEND is necessary since 236 REPLACE operates on message sequence numbers. 238 4. Interaction with other extensions 240 This section describes how REPLACE interacts with some other IMAP 241 extensions. 243 4.1. RFC 4314, ACL 245 The ACL rights [RFC4314] required for UID REPLACE are the union of 246 the ACL rights required for UID STORE and UID EXPUNGE in the current 247 mailbox, and APPEND in the target mailbox. 249 4.2. RFC 4469, CATENATE 251 Servers supporting both REPLACE and CATENATE [RFC4469] MUST support 252 the addtional append-data and resp-text-code elements defined the 253 Formal Syntax section of RFC4469 in conjunction with the REPLACE 254 command. When combined with CATENATE, REPLACE can become a quite 255 efficient way for message manipulation. 257 Example: 259 User composes message and attaches photo 260 ---------------------------------------- 261 C: A010 APPEND Drafts (\Seen \Draft) {1201534} 262 S: + Ready for literal data 263 C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST) 264 C: From: Fritz Schmidt 265 C: Message-ID: 266 C: MIME-Version: 1.0 267 C: Content-Type: multipart/mixed; 268 C: boundary="------------030305060306060609050804" 269 C: 270 C: --------------030305060306060609050804 271 C: Content-Type: text/plain; charset=utf-8; format=flowed 272 C: Content-Transfer-Encoding: 7bit 273 C: 274 C: Here is picture from the fireworks 275 C: 276 C: Yours... 277 C: Fritz 278 C: 279 C: --------------030305060306060609050804 280 C: Content-Type: image/jpeg; 281 C: name="Fireworks.jpg" 282 C: Content-Transfer-Encoding: base64 283 C: Content-Disposition: attachment; 284 C: filename="Fireworks.jpg" 285 C: 286 287 C: 288 C: --------------030305060306060609050804-- 289 S: A010 OK [APPENDUID 1 3002] APPEND complete 291 User completes message with To: and Subject: fields 292 --------------------------------------------------- 293 C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71} 294 S: + Ready for literal data 295 C: To: Mitzy 296 C: Subject: My view of the fireworks 297 C: URL "/Drafts/;UID=3002") 298 S: * 5 EXISTS 299 S: * 4 EXPUNGE 300 S: A011 OK [APPENDUID 1 3003] REPLACE completed 302 4.3. RFC 4315, UIDPLUS 304 Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send 305 APPENDUID in response to a UID REPLACE command. For additional 306 information see section 3 of RFC4315. Servers implementing REPLACE 307 and UIDPLUS are also advised to send the APPENDUID response code in 308 an untagged OK before sending the EXPUNGE or replaced responses. 309 (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS 310 specification means that the client first receives an EXPUNGE for a 311 message and afterwards APPENDUID for the new message. It can be 312 unnecessarily difficult to process that sequence usefully.) 314 4.4. RFC 6785, IMAP Events in Sieve 316 REPLACE applies to IMAP events in Sieve [RFC6785] in the same way 317 that APPEND does. Therefore, REPLACE can cause a Sieve script to be 318 invoked with the imap.cause set to "APPEND". Because the 319 intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by 320 REPLACE, no action will be taken that results in a imap.cause of 321 FLAG. 323 4.5. RFC 7162, CONDSTORE/QRESYNC 325 Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] 326 MUST treat the message being replaced as if it were being removed 327 with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of RFC 7162 328 are particularly relevant for this condition. 330 5. Formal Syntax 332 The following syntax specification uses the Augmented Backus-Naur 333 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 334 the non-terminals "capability","command-select", "mailbox", and "seq- 335 number". [RFC4466] defines the non-terminal "append-message". 337 Except as noted otherwise, all alphabetic characters are case- 338 insensitive. The use of upper or lower case characters to define 339 token strings is for editorial clarity only. Implementations MUST 340 accept these strings in a case-insensitive fashion. 342 capability =/ "REPLACE" 344 command-select =/ replace 345 replace = "REPLACE" SP seq-number SP mailbox append-message 346 uid = "UID" SP (copy / fetch/ search / store / move / 347 replace) 349 6. Security Considerations 351 This document is believed to add no security problems beyond those 352 that may already exist with the base IMAP specificaiton. 354 7. IANA Considerations 356 The IANA is requested to add REPLACE to the "IMAP 4 Capabilities" 357 registry, http://www.iana.org/assignments/imap4-capabilities. 359 8. Acknowledgements 361 The author would like to thank the participants of IMAPEXT with 362 particular thanks to Arnt Gulbrandsen, Alexey Melkinov, Chris Newman, 363 and Bron Gondwana for their specific contributions. 365 9. References 367 9.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 375 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 376 . 378 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 379 RFC 4314, DOI 10.17487/RFC4314, December 2005, 380 . 382 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 383 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 384 December 2005, . 386 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 387 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 388 . 390 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 391 CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 392 2006, . 394 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 395 Specifications: ABNF", STD 68, RFC 5234, 396 DOI 10.17487/RFC5234, January 2008, 397 . 399 [RFC6785] Leiba, B., "Support for Internet Message Access Protocol 400 (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, 401 November 2012, . 403 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 404 Changes Resynchronization (CONDSTORE) and Quick Mailbox 405 Resynchronization (QRESYNC)", RFC 7162, 406 DOI 10.17487/RFC7162, May 2014, 407 . 409 9.2. Informative References 411 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 412 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 413 DOI 10.17487/RFC6851, January 2013, 414 . 416 Author's Address 418 Stuart Brandt 419 Verizon 420 22001 Loudoun County Parkway 421 Ashburn, VA 20147 422 USA 424 Email: stujenerin@aol.com