idnits 2.17.1 draft-ietf-extra-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 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 date (October 25, 2018) is 2009 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) -- Looks like a reference, but probably isn't: '1' on line 463 == Missing Reference: 'UID' is mentioned on line 205, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 October 25, 2018 5 Expires: April 28, 2019 7 IMAP REPLACE Extension 8 draft-ietf-extra-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 April 28, 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 . . . . . . . . . . 5 58 3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 6 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 4.6. RFC 8474, OBJECTID . . . . . . . . . . . . . . . . . . . 8 66 4.7. RFC 3502, MULTIAPPEND . . . . . . . . . . . . . . . . . . 8 67 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 9.2. Informative References . . . . . . . . . . . . . . . . . 10 74 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Conventions Used in This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [1] [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 Formal syntax is defined by [RFC5234]. 87 Example lines prefaced by "C:" are sent by the client and ones 88 prefaced by "S:" by the server. 90 2. Overview 92 This document defines an IMAP [RFC3501] extension to facilitate 93 replacing an existing message with a new one. This is accomplished 94 by defining a new REPLACE command and extending the UID command to 95 allow UID REPLACE. 97 Since there is no replace function in the base IMAP specification, 98 clients have instead had to use a combination of three separate 99 commands issued in serial fashion; APPEND, STORE, EXPUNGE. 100 Pipelining of these three commands is not recommended since failure 101 of any individual command should prevent subsequent commands from 102 being executed lest the original message version be lost. 104 Because of the non-atomic nature of the existing sequence, 105 interruptions can leave messages in intermediate states which can be 106 seen and acted upon by other clients. Such interruptions can also 107 strand older revisions of messages, thereby forcing the user to 108 manually clean up multiple revisions of the same message in order to 109 avoid wasteful quota consumption. Additionally, the existing 110 sequence can fail on APPEND due to an over-quota condition even 111 though the subsequent STORE/EXPUNGE would free up enough space for 112 the newly revised message. And finally, server efficiencies may be 113 possible with a single logical message replacement operation as 114 compared to the existing APPEND/STORE/EXPUNGE sequence. 116 In its simplest form, the REPLACE command is a single-command 117 encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a 118 message, except that it avoids any of the quota implications or 119 intermediate states associated with the 3 command sequence. Server 120 developers are encouraged to implement REPLACE as an atomic operation 121 to simplify error handling, minimize operational concerns, and reduce 122 potential security problems. For systems where this is not possible, 123 communication with the requesting client must ensure no confusion of 124 message store state. A server MUST NOT generate a response code for 125 the STORE +flags \DELETED portion of the sequence. Additionally, 126 servers supporting the REPLACE command MUST NOT infer any inheritance 127 of content, flags, or annotations from the message being replaced. 129 3. REPLACE and UID REPLACE 131 3.1. Advertising Support for REPLACE 133 Servers that implement the REPLACE extension will return "REPLACE" as 134 one of the supported capabilities in the CAPABILITY command response. 136 3.2. REPLACE Command 137 Arguments: message sequence number 138 mailbox name 139 OPTIONAL flag parenthesized list 140 OPTIONAL date/time string 141 message literal 143 Responses: no specific responses for this command 145 Result: OK - replace completed 146 NO - replace error; can't remove specified message 147 or can't add new message content 148 BAD - command unknown or arguments invalid 150 Example: 151 C: A003 REPLACE 4 Drafts (\Seen \Draft) {312} 152 S: + Ready for literal data 153 C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) 154 C: From: Fritz Schmidt 155 C: Subject: happy new year !! 156 C: To: miss.mitzy@example.org 157 C: Message-Id: 158 C: MIME-Version: 1.0 159 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 160 C: 161 C: Just saw the best fireworks show. Wish you were here. 162 C: 163 S: * OK [APPENDUID 1 2000] Replacement Message ready 164 S: * 5 EXISTS 165 S: * 4 EXPUNGE 166 S: A003 OK Replace completed 168 3.3. UID REPLACE Command 170 This extends the first form of the UID command (see [RFC3501] 171 Section 6.4.8) to add the REPLACE command defined above as a valid 172 argument. This form of REPLACE uses a UID rather than sequence 173 number as its first parameter. 175 Example: 176 C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350} 177 S: + Ready for literal data 178 C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST) 179 C: From: Fritz Schmidt 180 C: Subject: happy new year !! 181 C: To: miss.mitzy@example.org 182 C: Message-Id: 183 C: MIME-Version: 1.0 184 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 185 C: 186 C: Just saw the best fireworks show. Wish you were here. 187 C: Hopefully next year you can join us. 188 C: 189 S: * OK [APPENDUID 1 2001] Replacement Message ready 190 S: * 5 EXISTS 191 S: * 4 EXPUNGE 192 S: A004 OK Replace completed 194 3.4. Semantics of REPLACE and UID REPLACE 196 The REPLACE and UID REPLACE commands take five arguments: a message 197 identifier, a named mailbox, an optional parenthesized flag list, an 198 optional message date/time string, and a message literal. The 199 message literal will be appended to the named mailbox, and the 200 message specified by the message identifier will be removed from the 201 selected mailbox. These operations will appear to the client as a 202 single action. This has the same effect as the following sequence: 204 1. APPEND 205 2. [UID] STORE +FLAGS.SILENT \DELETED 206 3. UID EXPUNGE 208 In the cited sequence, the quota implications of the APPEND are 209 evaluated within the context of the pending EXPUNGE so that only the 210 net quota consumption is considered. Additionally, the EXPUNGE 211 portion of the sequence only applies to the specified message, not 212 all messages flagged as \Deleted. 214 Although the effect of REPLACE is identical to the steps above, the 215 semantics are not identical; similar to MOVE [RFC6851], the 216 intermediate states do not occur, and the response codes are 217 different. In particular, the response codes for APPEND and EXPUNGE 218 will be returned while those for the STORE operation MUST NOT be 219 generated. 221 When an error occurs while processing REPLACE or UID REPLACE, the 222 server MUST NOT leave the selected mailbox in an inconsistent state; 223 any untagged EXPUNGE response MUST NOT be sent until all actions are 224 successfully completed. 226 While it may be common for the named mailbox argument to match the 227 selected mailbox for the common use case of replacing a draft, the 228 REPLACE extension intentionally does not require the two to be the 229 same. As an example, it's possible to use the REPLACE command to 230 replace a message in the \Drafts special-use mailbox (see [RFC6154]) 231 with a message in the \Sent special-use mailbox following message 232 submission. 234 Because of the similarity of REPLACE to APPEND, extensions that 235 affect APPEND affect REPLACE in the same way. Response codes such as 236 TRYCREATE (see [RFC3501] Section 6.3.11), along with those defined by 237 extensions, are sent as appropriate. See Section 4 for more 238 information about how REPLACE interacts with other IMAP extensions. 240 3.5. IMAP State Diagram Impacts 242 Unlike the APPEND command, which is valid in the authenticated state, 243 the REPLACE and UID REPLACE commands MUST only be valid in the 244 selected state. This difference from APPEND is necessary since 245 REPLACE operates on message sequence numbers. Additionally, the 246 REPLACE extension intentionally follows the convention for UID 247 commands found in [RFC3501] section 6.4.8 in that the UID variant of 248 the command does not support use from the authenticated state. 250 4. Interaction with other extensions 252 This section describes how REPLACE interacts with some other IMAP 253 extensions. 255 4.1. RFC 4314, ACL 257 The ACL rights [RFC4314] required for UID REPLACE are the union of 258 the ACL rights required for UID STORE and UID EXPUNGE in the current 259 mailbox, and APPEND in the target mailbox. 261 4.2. RFC 4469, CATENATE 263 Servers supporting both REPLACE and CATENATE [RFC4469] MUST support 264 the addtional append-data and resp-text-code elements defined the 265 Formal Syntax section of RFC4469 in conjunction with the REPLACE 266 command. When combined with CATENATE, REPLACE can become a quite 267 efficient way for message manipulation. 269 Example: 271 User composes message and attaches photo 272 ---------------------------------------- 273 C: A010 APPEND Drafts (\Seen \Draft) {1201534} 274 S: + Ready for literal data 275 C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST) 276 C: From: Fritz Schmidt 277 C: Message-ID: 278 C: MIME-Version: 1.0 279 C: Content-Type: multipart/mixed; 280 C: boundary="------------030305060306060609050804" 281 C: 282 C: --------------030305060306060609050804 283 C: Content-Type: text/plain; charset=utf-8; format=flowed 284 C: Content-Transfer-Encoding: 7bit 285 C: 286 C: Here is picture from the fireworks 287 C: 288 C: Yours... 289 C: Fritz 290 C: 291 C: --------------030305060306060609050804 292 C: Content-Type: image/jpeg; 293 C: name="Fireworks.jpg" 294 C: Content-Transfer-Encoding: base64 295 C: Content-Disposition: attachment; 296 C: filename="Fireworks.jpg" 297 C: 298 299 C: 300 C: --------------030305060306060609050804-- 301 S: A010 OK [APPENDUID 1 3002] APPEND complete 303 User completes message with To: and Subject: fields 304 --------------------------------------------------- 305 C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71} 306 S: + Ready for literal data 307 C: To: Mitzy 308 C: Subject: My view of the fireworks 309 C: URL "/Drafts/;UID=3002") 310 S: * OK [APPENDUID 1 3003] Replacement Message ready 311 S: * 5 EXISTS 312 S: * 4 EXPUNGE 313 S: A011 OK REPLACE completed 315 4.3. RFC 4315, UIDPLUS 317 Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send 318 APPENDUID in response to a UID REPLACE command. For additional 319 information see section 3 of RFC4315. Servers implementing REPLACE 320 and UIDPLUS are also advised to send the APPENDUID response code in 321 an untagged OK before sending the EXPUNGE or replaced responses. 322 (Sending the APPENDUID in the tagged OK as described in the UIDPLUS 323 specification means that the client first receives an EXPUNGE for a 324 message and afterwards APPENDUID for the new message. It can be 325 unnecessarily difficult to process that sequence usefully.) 327 4.4. RFC 6785, IMAP Events in Sieve 329 REPLACE applies to IMAP events in Sieve [RFC6785] in the same way 330 that APPEND does. Therefore, REPLACE can cause a Sieve script to be 331 invoked with the imap.cause set to "APPEND". Because the 332 intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by 333 REPLACE, no action will be taken that results in a imap.cause of 334 FLAG. 336 4.5. RFC 7162, CONDSTORE/QRESYNC 338 Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] 339 MUST treat the message being replaced as if it were being removed 340 with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of RFC 7162 341 are particularly relevant for this condition. 343 4.6. RFC 8474, OBJECTID 345 Servers implementing both REPLACE and OBJECTID [RFC8474] MUST return 346 different EMAILIDs for both the replaced and replacing messages. The 347 only exception to this is the case outlined in OBJECTID section 5.1 348 when the server detects that both messages' immutable content are 349 identical. 351 4.7. RFC 3502, MULTIAPPEND 353 The REPLACE extension has no interaction with MULTIAPPEND [RFC3502]. 354 This document explicitly does not outline a method for replacing 355 multiple messsages concurrently. 357 5. Formal Syntax 359 The following syntax specification uses the Augmented Backus-Naur 360 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 361 the non-terminals "capability","command-select", "mailbox", and "seq- 362 number". [RFC4466] defines the non-terminal "append-message". 364 Except as noted otherwise, all alphabetic characters are case- 365 insensitive. The use of upper or lower case characters to define 366 token strings is for editorial clarity only. Implementations MUST 367 accept these strings in a case-insensitive fashion. 369 capability =/ "REPLACE" 371 command-select =/ replace 372 replace = "REPLACE" SP seq-number SP mailbox append-message 373 uid =/ replace 375 6. Security Considerations 377 This document is believed to add no security problems beyond those 378 that may already exist with the base IMAP specification. The REPLACE 379 command may actually prevent some potential security problems because 380 it avoids intermediate message states that could possibly be 381 exploited by an attacker. 383 7. IANA Considerations 385 The IANA is requested to add REPLACE to the "IMAP 4 Capabilities" 386 registry, http://www.iana.org/assignments/imap4-capabilities. 388 8. Acknowledgements 390 The author would like to thank the participants of IMAPEXT with 391 particular thanks to Arnt Gulbrandsen, Alexey Melkinov, Chris Newman, 392 and Bron Gondwana for their specific contributions. 394 9. References 396 9.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 404 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 405 . 407 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 408 RFC 4314, DOI 10.17487/RFC4314, December 2005, 409 . 411 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 412 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, 413 December 2005, . 415 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 416 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, 417 . 419 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 420 CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April 421 2006, . 423 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 424 Specifications: ABNF", STD 68, RFC 5234, 425 DOI 10.17487/RFC5234, January 2008, 426 . 428 [RFC6785] Leiba, B., "Support for Internet Message Access Protocol 429 (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, 430 November 2012, . 432 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 433 Changes Resynchronization (CONDSTORE) and Quick Mailbox 434 Resynchronization (QRESYNC)", RFC 7162, 435 DOI 10.17487/RFC7162, May 2014, 436 . 438 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 439 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 440 May 2017, . 442 [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object 443 Identifiers", RFC 8474, DOI 10.17487/RFC8474, September 444 2018, . 446 9.2. Informative References 448 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - 449 MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, 450 March 2003, . 452 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for 453 Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, 454 March 2011, . 456 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message 457 Access Protocol (IMAP) - MOVE Extension", RFC 6851, 458 DOI 10.17487/RFC6851, January 2013, 459 . 461 9.3. URIs 463 [1] https://tools.ietf.org/html/bcp14 465 Author's Address 467 Stuart Brandt 468 Verizon 469 22001 Loudoun County Parkway 470 Ashburn, VA 20147 471 USA 473 Email: stujenerin@aol.com