--- 1/draft-ietf-extra-imap-replace-02.txt 2018-10-25 09:13:17.431440349 -0700 +++ 2/draft-ietf-extra-imap-replace-03.txt 2018-10-25 09:13:17.459441024 -0700 @@ -1,18 +1,18 @@ Network Working Group S. Brandt Internet-Draft Verizon -Intended status: Standards Track October 12, 2018 -Expires: April 15, 2019 +Intended status: Standards Track October 25, 2018 +Expires: April 28, 2019 IMAP REPLACE Extension - draft-ietf-extra-imap-replace-02 + draft-ietf-extra-imap-replace-03 Abstract This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. Status of This Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 15, 2019. + This Internet-Draft will expire on April 28, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,27 +64,30 @@ 4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 8 4.6. RFC 8474, OBJECTID . . . . . . . . . . . . . . . . . . . 8 4.7. RFC 3502, MULTIAPPEND . . . . . . . . . . . . . . . . . . 8 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 + 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [1] [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. Formal syntax is defined by [RFC5234]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. 2. Overview This document defines an IMAP [RFC3501] extension to facilitate replacing an existing message with a new one. This is accomplished @@ -107,37 +109,38 @@ avoid wasteful quota consumption. Additionally, the existing sequence can fail on APPEND due to an over-quota condition even though the subsequent STORE/EXPUNGE would free up enough space for the newly revised message. And finally, server efficiencies may be possible with a single logical message replacement operation as compared to the existing APPEND/STORE/EXPUNGE sequence. In its simplest form, the REPLACE command is a single-command encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a message, except that it avoids any of the quota implications or - intermediate states associated with the 3 command sequence. In - handling a REPLACE command, a server MUST NOT generate a response - code for the STORE +flags \DELETED portion of the sequence. - Additionally, servers supporting the REPLACE command MUST NOT infer - any inheritance of content, flags, or annotations from the message - being replaced. Finally, the replaced and replacing messages SHOULD - NOT be present in the mailbox at the same time. + intermediate states associated with the 3 command sequence. Server + developers are encouraged to implement REPLACE as an atomic operation + to simplify error handling, minimize operational concerns, and reduce + potential security problems. For systems where this is not possible, + communication with the requesting client must ensure no confusion of + message store state. A server MUST NOT generate a response code for + the STORE +flags \DELETED portion of the sequence. Additionally, + servers supporting the REPLACE command MUST NOT infer any inheritance + of content, flags, or annotations from the message being replaced. 3. REPLACE and UID REPLACE 3.1. Advertising Support for REPLACE Servers that implement the REPLACE extension will return "REPLACE" as one of the supported capabilities in the CAPABILITY command response. 3.2. REPLACE Command - Arguments: message sequence number mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal Responses: no specific responses for this command Result: OK - replace completed NO - replace error; can't remove specified message @@ -203,21 +206,21 @@ 3. UID EXPUNGE In the cited sequence, the quota implications of the APPEND are evaluated within the context of the pending EXPUNGE so that only the net quota consumption is considered. Additionally, the EXPUNGE portion of the sequence only applies to the specified message, not all messages flagged as \Deleted. Although the effect of REPLACE is identical to the steps above, the semantics are not identical; similar to MOVE [RFC6851], the - intermediate states produced do not occur, and the response codes are + intermediate states do not occur, and the response codes are different. In particular, the response codes for APPEND and EXPUNGE will be returned while those for the STORE operation MUST NOT be generated. When an error occurs while processing REPLACE or UID REPLACE, the server MUST NOT leave the selected mailbox in an inconsistent state; any untagged EXPUNGE response MUST NOT be sent until all actions are successfully completed. While it may be common for the named mailbox argument to match the @@ -229,24 +232,27 @@ submission. Because of the similarity of REPLACE to APPEND, extensions that affect APPEND affect REPLACE in the same way. Response codes such as TRYCREATE (see [RFC3501] Section 6.3.11), along with those defined by extensions, are sent as appropriate. See Section 4 for more information about how REPLACE interacts with other IMAP extensions. 3.5. IMAP State Diagram Impacts - Unlike the APPEND command which is valid in the authenticated state, + Unlike the APPEND command, which is valid in the authenticated state, the REPLACE and UID REPLACE commands MUST only be valid in the selected state. This difference from APPEND is necessary since - REPLACE operates on message sequence numbers. + REPLACE operates on message sequence numbers. Additionally, the + REPLACE extension intentionally follows the convention for UID + commands found in [RFC3501] section 6.4.8 in that the UID variant of + the command does not support use from the authenticated state. 4. Interaction with other extensions This section describes how REPLACE interacts with some other IMAP extensions. 4.1. RFC 4314, ACL The ACL rights [RFC4314] required for UID REPLACE are the union of the ACL rights required for UID STORE and UID EXPUNGE in the current @@ -306,21 +312,21 @@ S: * 4 EXPUNGE S: A011 OK REPLACE completed 4.3. RFC 4315, UIDPLUS Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send APPENDUID in response to a UID REPLACE command. For additional information see section 3 of RFC4315. Servers implementing REPLACE and UIDPLUS are also advised to send the APPENDUID response code in an untagged OK before sending the EXPUNGE or replaced responses. - (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS + (Sending the APPENDUID in the tagged OK as described in the UIDPLUS specification means that the client first receives an EXPUNGE for a message and afterwards APPENDUID for the new message. It can be unnecessarily difficult to process that sequence usefully.) 4.4. RFC 6785, IMAP Events in Sieve REPLACE applies to IMAP events in Sieve [RFC6785] in the same way that APPEND does. Therefore, REPLACE can cause a Sieve script to be invoked with the imap.cause set to "APPEND". Because the intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by @@ -357,22 +363,21 @@ Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "REPLACE" command-select =/ replace replace = "REPLACE" SP seq-number SP mailbox append-message - uid = "UID" SP (copy / fetch/ search / store / move / - replace) + uid =/ replace 6. Security Considerations This document is believed to add no security problems beyond those that may already exist with the base IMAP specification. The REPLACE command may actually prevent some potential security problems because it avoids intermediate message states that could possibly be exploited by an attacker. 7. IANA Considerations @@ -423,38 +428,46 @@ [RFC6785] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, November 2012, . [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", RFC 7162, DOI 10.17487/RFC7162, May 2014, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object Identifiers", RFC 8474, DOI 10.17487/RFC8474, September 2018, . 9.2. Informative References [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, March 2003, . [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, March 2011, . [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, . +9.3. URIs + + [1] https://tools.ietf.org/html/bcp14 + Author's Address Stuart Brandt Verizon 22001 Loudoun County Parkway Ashburn, VA 20147 USA Email: stujenerin@aol.com