idnits 2.17.1 draft-brandt-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 (April 29, 2015) is 3284 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 193, 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 April 29, 2015 5 Expires: October 31, 2015 7 IMAP REPLACE Extension 8 draft-brandt-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 replacment 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 October 31, 2015. 34 Copyright Notice 36 Copyright (c) 2015 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 . . . . . . . . . . . . . . 5 60 4.1. RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. RFC 4469, CATENATE . . . . . . . . . . . . . . . . . . . 6 62 4.3. RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . . 6 63 4.4. RFC 6785, IMAP Events in Sieve . . . . . . . . . . . . . 6 64 4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 6 65 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 Using commands from the base IMAP specification, replacement of a 93 message involves three separate commands issued in serial fashion; 94 APPEND, STORE, EXPUNGE. Pipelining of these three commands is not 95 recommended since failure of any individual command should prevent 96 subsequent commands from being executed lest the original message 97 version be lost. The REPLACE command is intended to provide an 98 atomic alternative to the existing non-atomic sequence. 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 an atomic encapsulation 113 of STORE + UID EXPUNGE + APPEND. Servers that support the REPLACE 114 command MUST guarantee atomicity; either the specified message is 115 completely replaced by the supplied message, or the specified message 116 is left unmodified and no part of the supplied message data is 117 stored. Servers supporting REPLACE also MUST NOT infer any 118 inheritance of content, flags, or annotations from the message being 119 replaced. 121 3. REPLACE and UID REPLACE 123 3.1. Advertising Support for REPLACE 125 Servers that implement the REPLACE extension will return "REPLACE" as 126 one of the supported capabilities in the CAPABILITY command response. 128 3.2. REPLACE Command 130 Arguments: message sequence number 131 mailbox name 132 OPTIONAL flag parenthesized list 133 OPTIONAL date/time string 134 message literal 136 Responses: no specific responses for this command 138 Result: OK - replace completed 139 NO - replace error; can't remove specified message 140 or can't add new message content 141 BAD - command unknown or arguments invalid 143 Example: 144 C: A003 REPLACE 4 Drafts (\Seen \Draft) {312} 145 S: + Ready for literal data 146 C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) 147 C: From: Fritz Schmidt 148 C: Subject: happy new year !! 149 C: To: miss.mitzy@example.org 150 C: Message-Id: 151 C: MIME-Version: 1.0 152 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 153 C: 154 C: Just saw the best fireworks show. Wish you were here. 155 C: 156 S: * 4 EXPUNGE 157 S: A003 OK [APPENDUID 1 2000] Replace completed 159 3.3. UID REPLACE Command 161 This extends the first form of the UID command (see [RFC3501] 162 Section 6.4.8) to add the REPLACE command defined above as a valid 163 argument. This form of REPLACE uses a UID rather than sequence 164 number as its first parameter. 166 Example: 167 C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350} 168 S: + Ready for literal data 169 C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST) 170 C: From: Fritz Schmidt 171 C: Subject: happy new year !! 172 C: To: miss.mitzy@example.org 173 C: Message-Id: 174 C: MIME-Version: 1.0 175 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 176 C: 177 C: Just saw the best fireworks show. Wish you were here. 178 C: Hopefully next year you can join us. 179 C: 180 S: * 4 EXPUNGE 181 S: A004 OK [APPENDUID 1 2001] Replace completed 183 3.4. Semantics of REPLACE and UID REPLACE 185 The REPLACE and UID REPLACE commands take five arguments: a message 186 identifier, a named mailbox, an optional parenthesized flag list, an 187 optional message date/time string, and a message literal. The 188 message literal will be appended to the named mailbox, and the 189 message specified by the message identifier will be removed from the 190 selected mailbox. These operations will appear to the client as a 191 single action. This has the same effect as the following sequence: 193 1. [UID] STORE +FLAGS.SILENT \DELETED 194 2. UID EXPUNGE 195 3. APPEND 197 In the cited sequence, the original message is removed first to avoid 198 possible quota implications of APPENDing new data first. 199 Additionally, the EXPUNGE portion of the sequence only applies to the 200 specified message, not all messages flagged as \Deleted. 202 Although the effect of REPLACE is identical to the steps above, the 203 semantics are not identical; similar to MOVE [RFC6851], the 204 intermediate states produced do not occur, and the response codes are 205 different. In particular, the response codes for EXPUNGE and APPEND 206 will be returned while those for the STORE operation MUST NOT be 207 generated. 209 When an error occurs while processing REPLACE or UID REPLACE, the 210 server MUST NOT leave the selected mailbox in an inconsistent or 211 modified state; any untagged EXPUNGE response MUST NOT be sent until 212 all actions are successfully completed. Additionally, the target 213 mailbox MUST NOT be modified until all actions are successfully 214 completed. 216 Because of the similarity of REPLACE to APPEND, extensions that 217 affect APPEND affect REPLACE in the same way. Response codes such 218 TRYCREATE (see [RFC3501] Section 6.3.11), as well as those defined by 219 extensions, are sent as appropriate. See Section 4 for more 220 information about how REPLACE interacts with other IMAP extensions. 222 3.5. IMAP State Diagram Impacts 224 Unlike the APPEND command which is valid in the authenticated state, 225 the REPLACE command MUST only be valid in the selected state. This 226 difference from APPEND is necessary since REPLACE operates on message 227 sequence numbers. 229 4. Interaction with other extensions 231 This section describes how REPLACE interacts with some other IMAP 232 extensions. 234 4.1. RFC 4314, ACL 236 The ACL rights [RFC4314] required for UID REPLACE are the union of 237 the ACL rights required for UID STORE, UID EXPUNGE, and APPEND. 239 4.2. RFC 4469, CATENATE 241 Servers supporting both REPLACE and CATENATE [RFC4469] MUST support 242 the addtional append-data and resp-text-code elements defined the 243 Formal Syntax section of RFC4469 in conjunction with the REPLACE 244 command. 246 4.3. RFC 4315, UIDPLUS 248 Servers supporting both REPLACE and UIDPLUS [RFC4315] MUST send 249 APPENDUID in response to a UID REPLACE command. The only exceptions 250 to this are the ones outlined for APPEND in RFC4315 section 3. 252 4.4. RFC 6785, IMAP Events in Sieve 254 REPLACE applies to IMAP events in Sieve [RFC6785] in the same way 255 that APPEND does. Therefore, REPLACE can cause a Sieve script to be 256 invoked with the imap.cause set to "APPEND". Because the 257 intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by 258 REPLACE, no action will be taken that results in a imap.cause of 259 FLAG. 261 4.5. RFC 7162, CONDSTORE/QRESYNC 263 Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] 264 MUST treat the message being replaced as if it were being removed 265 with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of RFC 7162 266 are particularly relevant for this condition. 268 5. Formal Syntax 270 The following syntax specification uses the Augmented Backus-Naur 271 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 272 the non-terminals "capability","command-select", "mailbox", and "seq- 273 number". [RFC4466] defines the non-terminal "append-message". 275 Except as noted otherwise, all alphabetic characters are case- 276 insensitive. The use of upper or lower case characters to define 277 token strings is for editorial clarity only. Implementations MUST 278 accept these strings in a case-insensitive fashion. 280 capability =/ "REPLACE" 282 command-select =/ replace 283 replace = "REPLACE" SP seq-number SP mailbox append-message 284 uid = "UID" SP (copy / fetch/ search / store / move / 285 replace) 287 6. Security Considerations 289 This document is believed to add no security problems beyond those 290 that may already exist with the base IMAP specificaiton. 292 7. IANA Considerations 294 The IANA is requested to add REPLACE to the "IMAP 4 Capabilities" 295 registry, http://www.iana.org/assignments/imap4-capabilities. 297 8. Acknowledgements 299 9. References 301 9.1. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 307 4rev1", RFC 3501, March 2003. 309 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 310 RFC 4314, December 2005. 312 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 313 UIDPLUS extension", RFC 4315, December 2005. 315 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 316 ABNF", RFC 4466, April 2006. 318 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 319 CATENATE Extension", RFC 4469, April 2006. 321 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 322 Specifications: ABNF", STD 68, RFC 5234, January 2008. 324 [RFC6785] Leiba, B., "Support for Internet Message Access Protocol 325 (IMAP) Events in Sieve", RFC 6785, November 2012. 327 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag 328 Changes Resynchronization (CONDSTORE) and Quick Mailbox 329 Resynchronization (QRESYNC)", RFC 7162, May 2014. 331 9.2. Informative References 333 [RFC6851] Gulbrandsen, A. and N. Freed, "Internet Message Access 334 Protocol (IMAP) - MOVE Extension", RFC 6851, January 2013. 336 Author's Address 338 Stuart Brandt 339 AOL 340 43623 Preddy Ct 341 Ashburn, VA 20147 342 USA 344 Email: stujenerin@aol.com