draft-ietf-extra-imap-replace-00.txt   draft-ietf-extra-imap-replace-01.txt 
Network Working Group S. Brandt Network Working Group S. Brandt
Internet-Draft Verizon Internet-Draft Verizon
Intended status: Standards Track August 8, 2018 Intended status: Standards Track October 1, 2018
Expires: February 9, 2019 Expires: April 4, 2019
IMAP REPLACE Extension IMAP REPLACE Extension
draft-ietf-extra-imap-replace-00 draft-ietf-extra-imap-replace-01
Abstract Abstract
This document defines an IMAP extension which can be used to replace This document defines an IMAP extension which can be used to replace
an existing message in a message store with a new message. Message an existing message in a message store with a new message. Message
replacement is a common operation for clients that automatically save replacement is a common operation for clients that automatically save
drafts or notes as a user composes them. drafts or notes as a user composes them.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3 3.2. REPLACE Command . . . . . . . . . . . . . . . . . . . . . 3
3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4 3.3. UID REPLACE Command . . . . . . . . . . . . . . . . . . . 4
3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 5 3.4. Semantics of REPLACE and UID REPLACE . . . . . . . . . . 5
3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 6 3.5. IMAP State Diagram Impacts . . . . . . . . . . . . . . . 6
4. Interaction with other extensions . . . . . . . . . . . . . . 6 4. Interaction with other extensions . . . . . . . . . . . . . . 6
4.1. RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . . 6 4.1. RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . . 6
4.2. RFC 4469, CATENATE . . . . . . . . . . . . . . . . . . . 6 4.2. RFC 4469, CATENATE . . . . . . . . . . . . . . . . . . . 6
4.3. RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . . 8 4.3. RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . . 8
4.4. RFC 6785, IMAP Events in Sieve . . . . . . . . . . . . . 8 4.4. RFC 6785, IMAP Events in Sieve . . . . . . . . . . . . . 8
4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 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 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Conventions Used in This Document 1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Formal syntax is defined by [RFC5234]. Formal syntax is defined by [RFC5234].
Example lines prefaced by "C:" are sent by the client and ones Example lines prefaced by "C:" are sent by the client and ones
skipping to change at page 4, line 18 skipping to change at page 4, line 18
C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST) C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org> C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !! C: Subject: happy new year !!
C: To: miss.mitzy@example.org C: To: miss.mitzy@example.org
C: Message-Id: <B238822388-0100000@example.org> C: Message-Id: <B238822388-0100000@example.org>
C: MIME-Version: 1.0 C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C: C:
C: Just saw the best fireworks show. Wish you were here. C: Just saw the best fireworks show. Wish you were here.
C: C:
S: * APPENDUID 1 2000 S: * OK [APPENDUID 1 2000] Replacement Message ready
S: * 5 EXISTS S: * 5 EXISTS
S: * 4 EXPUNGE S: * 4 EXPUNGE
S: A003 OK Replace completed S: A003 OK Replace completed
3.3. UID REPLACE Command 3.3. UID REPLACE Command
This extends the first form of the UID command (see [RFC3501] 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 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 argument. This form of REPLACE uses a UID rather than sequence
number as its first parameter. number as its first parameter.
skipping to change at page 4, line 44 skipping to change at page 4, line 44
C: From: Fritz Schmidt <fritz.ze@example.org> C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !! C: Subject: happy new year !!
C: To: miss.mitzy@example.org C: To: miss.mitzy@example.org
C: Message-Id: <B238822389-0100000@example.org> C: Message-Id: <B238822389-0100000@example.org>
C: MIME-Version: 1.0 C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C: C:
C: Just saw the best fireworks show. Wish you were here. C: Just saw the best fireworks show. Wish you were here.
C: Hopefully next year you can join us. C: Hopefully next year you can join us.
C: C:
S: * APPENDUID 1 2001 S: * OK [APPENDUID 1 2001] Replacement Message ready
S: * 5 EXISTS S: * 5 EXISTS
S: * 4 EXPUNGE S: * 4 EXPUNGE
S: A004 OK Replace completed S: A004 OK Replace completed
3.4. Semantics of REPLACE and UID REPLACE 3.4. Semantics of REPLACE and UID REPLACE
The REPLACE and UID REPLACE commands take five arguments: a message The REPLACE and UID REPLACE commands take five arguments: a message
identifier, a named mailbox, an optional parenthesized flag list, an identifier, a named mailbox, an optional parenthesized flag list, an
optional message date/time string, and a message literal. The optional message date/time string, and a message literal. The
message literal will be appended to the named mailbox, and the message literal will be appended to the named mailbox, and the
skipping to change at page 5, line 41 skipping to change at page 5, line 41
When an error occurs while processing REPLACE or UID REPLACE, the When an error occurs while processing REPLACE or UID REPLACE, the
server MUST NOT leave the selected mailbox in an inconsistent state; server MUST NOT leave the selected mailbox in an inconsistent state;
any untagged EXPUNGE response MUST NOT be sent until all actions are any untagged EXPUNGE response MUST NOT be sent until all actions are
successfully completed. successfully completed.
While it may be common for the named mailbox argument to match the 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 selected mailbox for the common use case of replacing a draft, the
REPLACE extension intentionally does not require the two to be 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 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 replace a message in the \Drafts special-use mailbox (see [RFC6154])
in the \Sent special-use mailbox following message submission. with a message in the \Sent special-use mailbox following message
submission.
Because of the similarity of REPLACE to APPEND, extensions that Because of the similarity of REPLACE to APPEND, extensions that
affect APPEND affect REPLACE in the same way. Response codes such as affect APPEND affect REPLACE in the same way. Response codes such as
TRYCREATE (see [RFC3501] Section 6.3.11), along with those defined by TRYCREATE (see [RFC3501] Section 6.3.11), along with those defined by
extensions, are sent as appropriate. See Section 4 for more extensions, are sent as appropriate. See Section 4 for more
information about how REPLACE interacts with other IMAP extensions. information about how REPLACE interacts with other IMAP extensions.
3.5. IMAP State Diagram Impacts 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,
skipping to change at page 7, line 46 skipping to change at page 7, line 46
C: --------------030305060306060609050804-- C: --------------030305060306060609050804--
S: A010 OK [APPENDUID 1 3002] APPEND complete S: A010 OK [APPENDUID 1 3002] APPEND complete
User completes message with To: and Subject: fields User completes message with To: and Subject: fields
--------------------------------------------------- ---------------------------------------------------
C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71} C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71}
S: + Ready for literal data S: + Ready for literal data
C: To: Mitzy <miss.mitzy@example.org> C: To: Mitzy <miss.mitzy@example.org>
C: Subject: My view of the fireworks C: Subject: My view of the fireworks
C: URL "/Drafts/;UID=3002") C: URL "/Drafts/;UID=3002")
S: * APPENDUID 1 3003 S: * OK [APPENDUID 1 3003] Replacement Message ready
S: * 5 EXISTS S: * 5 EXISTS
S: * 4 EXPUNGE S: * 4 EXPUNGE
S: A011 OK REPLACE completed S: A011 OK REPLACE completed
4.3. RFC 4315, UIDPLUS 4.3. RFC 4315, UIDPLUS
Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send
APPENDUID in response to a UID REPLACE command. For additional APPENDUID in response to a UID REPLACE command. For additional
information see section 3 of RFC4315. Servers implementing REPLACE information see section 3 of RFC4315. Servers implementing REPLACE
and UIDPLUS are also advised to send the APPENDUID response code in and UIDPLUS are also advised to send the APPENDUID response code in
skipping to change at page 8, line 33 skipping to change at page 8, line 33
REPLACE, no action will be taken that results in a imap.cause of REPLACE, no action will be taken that results in a imap.cause of
FLAG. FLAG.
4.5. RFC 7162, CONDSTORE/QRESYNC 4.5. RFC 7162, CONDSTORE/QRESYNC
Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162] Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162]
MUST treat the message being replaced as if it were being removed 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 with a UID EXPUNGE command. Sections 3.2.9 and 3.2.10 of RFC 7162
are particularly relevant for this condition. 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 Servers implementing both REPLACE and OBJECTID [RFC8474] MUST return
EMAILIDs for both the replaced and replacing messages. The only different EMAILIDs for both the replaced and replacing messages. The
exception to this is the case outlined in OBJECTID section 5.1 when only exception to this is the case outlined in OBJECTID section 5.1
the server detects that both messages' immutable content are when the server detects that both messages' immutable content are
identical. 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 5. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines
the non-terminals "capability","command-select", "mailbox", and "seq- the non-terminals "capability","command-select", "mailbox", and "seq-
number". [RFC4466] defines the non-terminal "append-message". number". [RFC4466] defines the non-terminal "append-message".
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
skipping to change at page 10, line 24 skipping to change at page 10, line 32
[RFC6785] Leiba, B., "Support for Internet Message Access Protocol [RFC6785] Leiba, B., "Support for Internet Message Access Protocol
(IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785,
November 2012, <https://www.rfc-editor.org/info/rfc6785>. November 2012, <https://www.rfc-editor.org/info/rfc6785>.
[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
Changes Resynchronization (CONDSTORE) and Quick Mailbox Changes Resynchronization (CONDSTORE) and Quick Mailbox
Resynchronization (QRESYNC)", RFC 7162, Resynchronization (QRESYNC)", RFC 7162,
DOI 10.17487/RFC7162, May 2014, DOI 10.17487/RFC7162, May 2014,
<https://www.rfc-editor.org/info/rfc7162>. <https://www.rfc-editor.org/info/rfc7162>.
[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
2018, <https://www.rfc-editor.org/info/rfc8474>.
9.2. Informative References 9.2. Informative References
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502,
March 2003, <https://www.rfc-editor.org/info/rfc3502>.
[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
March 2011, <https://www.rfc-editor.org/info/rfc6154>.
[RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message
Access Protocol (IMAP) - MOVE Extension", RFC 6851, Access Protocol (IMAP) - MOVE Extension", RFC 6851,
DOI 10.17487/RFC6851, January 2013, DOI 10.17487/RFC6851, January 2013,
<https://www.rfc-editor.org/info/rfc6851>. <https://www.rfc-editor.org/info/rfc6851>.
Author's Address Author's Address
Stuart Brandt Stuart Brandt
Verizon Verizon
22001 Loudoun County Parkway 22001 Loudoun County Parkway
 End of changes. 14 change blocks. 
16 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/