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