idnits 2.17.1 draft-brandt-imap-replace-02.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 (January 19, 2016) is 3019 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 195, 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 AOL 4 Intended status: Standards Track January 19, 2016 5 Expires: July 22, 2016 7 IMAP REPLACE Extension 8 draft-brandt-imap-replace-02 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 http://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 July 22, 2016. 34 Copyright Notice 36 Copyright (c) 2016 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 (http://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: * 4 EXPUNGE 158 S: A003 OK [APPENDUID 1 2000] Replace completed 160 3.3. UID REPLACE Command 162 This extends the first form of the UID command (see [RFC3501] 163 Section 6.4.8) to add the REPLACE command defined above as a valid 164 argument. This form of REPLACE uses a UID rather than sequence 165 number as its first parameter. 167 Example: 168 C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350} 169 S: + Ready for literal data 170 C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST) 171 C: From: Fritz Schmidt 172 C: Subject: happy new year !! 173 C: To: miss.mitzy@example.org 174 C: Message-Id: 175 C: MIME-Version: 1.0 176 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 177 C: 178 C: Just saw the best fireworks show. Wish you were here. 179 C: Hopefully next year you can join us. 180 C: 181 S: * 4 EXPUNGE 182 S: A004 OK [APPENDUID 1 2001] Replace completed 184 3.4. Semantics of REPLACE and UID REPLACE 186 The REPLACE and UID REPLACE commands take five arguments: a message 187 identifier, a named mailbox, an optional parenthesized flag list, an 188 optional message date/time string, and a message literal. The 189 message literal will be appended to the named mailbox, and the 190 message specified by the message identifier will be removed from the 191 selected mailbox. These operations will appear to the client as a 192 single action. This has the same effect as the following sequence: 194 1. APPEND 195 2. [UID] STORE +FLAGS.SILENT \DELETED 196 3. UID EXPUNGE 198 In the cited sequence, the quota implications of the APPEND are 199 evaluated within the context of the pending EXPUNGE so that only the 200 net quota consumption is considered. Additionally, the EXPUNGE 201 portion of the sequence only applies to the specified message, not 202 all messages flagged as \Deleted. 204 Although the effect of REPLACE is identical to the steps above, the 205 semantics are not identical; similar to MOVE [RFC6851], the 206 intermediate states produced do not occur, and the response codes are 207 different. In particular, the response codes for EXPUNGE and APPEND 208 will be returned while those for the STORE operation MUST NOT be 209 generated. 211 When an error occurs while processing REPLACE or UID REPLACE, the 212 server MUST NOT leave the selected mailbox in an inconsistent state; 213 any untagged EXPUNGE response MUST NOT be sent until all actions are 214 successfully completed. 216 While it may be common for the named mailbox argument to match the 217 selected mailbox for the common use case of replacing a draft, the 218 REPLACE extension intentionally does not require the two to be the 219 same. As an example, it's possible to use the REPLACE command to 220 replace a message in the \Drafts special-use mailbox with a message 221 in the \Sent special-use mailbox following message submission. 223 Because of the similarity of REPLACE to APPEND, extensions that 224 affect APPEND affect REPLACE in the same way. Response codes such 225 TRYCREATE (see [RFC3501] Section 6.3.11), as well as those defined by 226 extensions, are sent as appropriate. See Section 4 for more 227 information about how REPLACE interacts with other IMAP extensions. 229 3.5. IMAP State Diagram Impacts 231 Unlike the APPEND command which is valid in the authenticated state, 232 the REPLACE and UID REPLACE commands MUST only be valid in the 233 selected state. This difference from APPEND is necessary since 234 REPLACE operates on message sequence numbers. 236 4. Interaction with other extensions 238 This section describes how REPLACE interacts with some other IMAP 239 extensions. 241 4.1. RFC 4314, ACL 243 The ACL rights [RFC4314] required for UID REPLACE are the union of 244 the ACL rights required for UID STORE and UID EXPUNGE in the current 245 mailbox, and APPEND in the target mailbox. 247 4.2. RFC 4469, CATENATE 249 Servers supporting both REPLACE and CATENATE [RFC4469] MUST support 250 the addtional append-data and resp-text-code elements defined the 251 Formal Syntax section of RFC4469 in conjunction with the REPLACE 252 command. When combined with CATENATE, REPLACE can become a quite 253 efficient way for message manipulation. 255 Example: 257 User composes message and attaches photo 258 ---------------------------------------- 259 C: A010 APPEND Drafts (\Seen \Draft) {1201534} 260 S: + Ready for literal data 261 C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST) 262 C: From: Fritz Schmidt 263 C: Message-ID: 264 C: MIME-Version: 1.0 265 C: Content-Type: multipart/mixed; 266 C: boundary="------------030305060306060609050804" 267 C: 268 C: --------------030305060306060609050804 269 C: Content-Type: text/plain; charset=utf-8; format=flowed 270 C: Content-Transfer-Encoding: 7bit 271 C: 272 C: Here is picture from the fireworks 273 C: 274 C: Yours... 275 C: Fritz 276 C: 277 C: --------------030305060306060609050804 278 C: Content-Type: image/jpeg; 279 C: name="Fireworks.jpg" 280 C: Content-Transfer-Encoding: base64 281 C: Content-Disposition: attachment; 282 C: filename="Fireworks.jpg" 283 C: 284 285 C: 286 C: --------------030305060306060609050804-- 287 S: A010 OK [APPENDUID 1 3002] APPEND complete 289 User completes message with To: and Subject: fields 290 --------------------------------------------------- 291 C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71} 292 S: + Ready for literal data 293 C: To: Mitzy 294 C: Subject: My view of the fireworks 295 C: URL "/Drafts/;UID=3002") 296 S: * 5 EXISTS 297 S: * 4 EXPUNGE 298 S: A011 OK [APPENDUID 1 3003] REPLACE completed 300 4.3. RFC 4315, UIDPLUS 302 Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send 303 APPENDUID in response to a UID REPLACE command. For additional 304 information see section 3 of RFC4315. Servers implementing REPLACE 305 and UIDPLUS are also advised to send the APPENDUID response code in 306 an untagged OK before sending the EXPUNGE or replaced responses. 307 (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS 308 specification means that the client first receives an EXPUNGE for a 309 message and afterwards APPENDUID for the new message. It can be 310 unnecessarily difficult to process that sequence usefully.) 312 4.4. RFC 6785, IMAP Events in Sieve 314 REPLACE applies to IMAP events in Sieve [RFC6785] in the same way 315 that APPEND does. Therefore, REPLACE can cause a Sieve script to be 316 invoked with the imap.cause set to "APPEND". Because the 317 intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by 318 REPLACE, no action will be taken that results in a imap.cause of 319 FLAG. 321 4.5. RFC 7162, CONDSTORE/QRESYNC 323 Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] 324 MUST treat the message being replaced as if it were being removed 325 with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of RFC 7162 326 are particularly relevant for this condition. 328 5. Formal Syntax 330 The following syntax specification uses the Augmented Backus-Naur 331 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 332 the non-terminals "capability","command-select", "mailbox", and "seq- 333 number". [RFC4466] defines the non-terminal "append-message". 335 Except as noted otherwise, all alphabetic characters are case- 336 insensitive. The use of upper or lower case characters to define 337 token strings is for editorial clarity only. Implementations MUST 338 accept these strings in a case-insensitive fashion. 340 capability =/ "REPLACE" 342 command-select =/ replace 343 replace = "REPLACE" SP seq-number SP mailbox append-message 344 uid = "UID" SP (copy / fetch/ search / store / move / 345 replace) 347 6. Security Considerations 349 This document is believed to add no security problems beyond those 350 that may already exist with the base IMAP specificaiton. 352 7. IANA Considerations 354 The IANA is requested to add REPLACE to the "IMAP 4 Capabilities" 355 registry, http://www.iana.org/assignments/imap4-capabilities. 357 8. Acknowledgements 359 The author would like to thank the participants of IMAPEXT with 360 particular thanks to Arnt Gulbrandsen, Alexey Melkinov, and Chris 361 Newman for their specific contributions. 363 9. References 365 9.1. Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 373 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 374 . 376 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 377 RFC 4314, DOI 10.17487/RFC4314, December 2005, 378 . 380 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 381 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 382 December 2005, . 384 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 385 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 386 . 388 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 389 CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 390 2006, . 392 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 393 Specifications: ABNF", STD 68, RFC 5234, 394 DOI 10.17487/RFC5234, January 2008, 395 . 397 [RFC6785] Leiba, B., "Support for Internet Message Access Protocol 398 (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, 399 November 2012, . 401 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 402 Changes Resynchronization (CONDSTORE) and Quick Mailbox 403 Resynchronization (QRESYNC)", RFC 7162, 404 DOI 10.17487/RFC7162, May 2014, 405 . 407 9.2. Informative References 409 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 410 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 411 DOI 10.17487/RFC6851, January 2013, 412 . 414 Author's Address 416 Stuart Brandt 417 AOL 418 43623 Preddy Ct 419 Ashburn, VA 20147 420 USA 422 Email: stujenerin@aol.com