--- 1/draft-ietf-extra-imap-replace-00.txt 2018-10-01 17:13:09.984565628 -0700 +++ 2/draft-ietf-extra-imap-replace-01.txt 2018-10-01 17:13:10.008566209 -0700 @@ -1,18 +1,18 @@ Network Working Group S. Brandt Internet-Draft Verizon -Intended status: Standards Track August 8, 2018 -Expires: February 9, 2019 +Intended status: Standards Track October 1, 2018 +Expires: April 4, 2019 IMAP REPLACE Extension - draft-ietf-extra-imap-replace-00 + draft-ietf-extra-imap-replace-01 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 February 9, 2019. + This Internet-Draft will expire on April 4, 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 @@ -55,29 +55,30 @@ 3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3 3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4 3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 5 3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 6 4. Interaction with other extensions . . . . . . . . . . . . . . 6 4.1. RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . . 6 4.2. RFC 4469, CATENATE . . . . . . . . . . . . . . . . . . . 6 4.3. RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . . 8 4.4. RFC 6785, IMAP Events in Sieve . . . . . . . . . . . . . 8 4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 8 - 4.6. draft-ietf-extra-imap-objectid, OBJECTID . . . . . . . . 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 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 + 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]. Formal syntax is defined by [RFC5234]. Example lines prefaced by "C:" are sent by the client and ones @@ -148,21 +150,21 @@ C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) C: From: Fritz Schmidt C: Subject: happy new year !! C: To: miss.mitzy@example.org C: Message-Id: C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Just saw the best fireworks show. Wish you were here. C: - S: * APPENDUID 1 2000 + S: * OK [APPENDUID 1 2000] Replacement Message ready S: * 5 EXISTS S: * 4 EXPUNGE S: A003 OK Replace completed 3.3. UID REPLACE Command This extends the first form of the UID command (see [RFC3501] Section 6.4.8) to add the REPLACE command defined above as a valid argument. This form of REPLACE uses a UID rather than sequence number as its first parameter. @@ -174,21 +176,21 @@ C: From: Fritz Schmidt C: Subject: happy new year !! C: To: miss.mitzy@example.org C: Message-Id: C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Just saw the best fireworks show. Wish you were here. C: Hopefully next year you can join us. C: - S: * APPENDUID 1 2001 + S: * OK [APPENDUID 1 2001] Replacement Message ready S: * 5 EXISTS S: * 4 EXPUNGE S: A004 OK Replace completed 3.4. Semantics of REPLACE and UID REPLACE The REPLACE and UID REPLACE commands take five arguments: a message identifier, a named mailbox, an optional parenthesized flag list, an optional message date/time string, and a message literal. The message literal will be appended to the named mailbox, and the @@ -215,22 +217,23 @@ 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 selected mailbox for the common use case of replacing a draft, the REPLACE extension intentionally does not require the two to be the same. As an example, it's possible to use the REPLACE command to - replace a message in the \Drafts special-use mailbox with a message - in the \Sent special-use mailbox following message submission. + replace a message in the \Drafts special-use mailbox (see [RFC6154]) + with a message in the \Sent special-use mailbox following message + 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, @@ -291,21 +294,21 @@ C: --------------030305060306060609050804-- S: A010 OK [APPENDUID 1 3002] APPEND complete User completes message with To: and Subject: fields --------------------------------------------------- C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71} S: + Ready for literal data C: To: Mitzy C: Subject: My view of the fireworks C: URL "/Drafts/;UID=3002") - S: * APPENDUID 1 3003 + S: * OK [APPENDUID 1 3003] Replacement Message ready S: * 5 EXISTS 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 @@ -324,28 +327,34 @@ REPLACE, no action will be taken that results in a imap.cause of FLAG. 4.5. RFC 7162, CONDSTORE/QRESYNC Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] MUST treat the message being replaced as if it were being removed with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of RFC 7162 are particularly relevant for this condition. -4.6. draft-ietf-extra-imap-objectid, OBJECTID +4.6. RFC 8474, OBJECTID - Servers implementing both REPLACE and OBJECTID MUST return different - EMAILIDs for both the replaced and replacing messages. The only - exception to this is the case outlined in OBJECTID section 5.1 when - the server detects that both messages' immutable content are + Servers implementing both REPLACE and OBJECTID [RFC8474] MUST return + different EMAILIDs for both the replaced and replacing messages. The + only exception to this is the case outlined in OBJECTID section 5.1 + when the server detects that both messages' immutable content are identical. +4.7. RFC 3502, MULTIAPPEND + + The REPLACE extension has no interaction with MULTIAPPEND [RFC3502]. + This document explicitly does not outline a method for replacing + multiple messsages concurrently. + 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability","command-select", "mailbox", and "seq- number". [RFC4466] defines the non-terminal "append-message". 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 @@ -411,22 +420,34 @@ [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, . + [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, . Author's Address Stuart Brandt Verizon 22001 Loudoun County Parkway