draft-ietf-extra-imap-replace-02.txt   draft-ietf-extra-imap-replace-03.txt 
Network Working Group S. Brandt Network Working Group S. Brandt
Internet-Draft Verizon Internet-Draft Verizon
Intended status: Standards Track October 12, 2018 Intended status: Standards Track October 25, 2018
Expires: April 15, 2019 Expires: April 28, 2019
IMAP REPLACE Extension IMAP REPLACE Extension
draft-ietf-extra-imap-replace-02 draft-ietf-extra-imap-replace-03
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 April 15, 2019. This Internet-Draft will expire on April 28, 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 30 skipping to change at page 2, line 30
4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 8 4.5. RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . . 8
4.6. RFC 8474, OBJECTID . . . . . . . . . . . . . . . . . . . 8 4.6. RFC 8474, OBJECTID . . . . . . . . . . . . . . . . . . . 8
4.7. RFC 3502, MULTIAPPEND . . . . . . . . . . . . . . . . . . 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
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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]. 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
prefaced by "S:" by the server. prefaced by "S:" by the server.
2. Overview 2. Overview
This document defines an IMAP [RFC3501] extension to facilitate This document defines an IMAP [RFC3501] extension to facilitate
replacing an existing message with a new one. This is accomplished replacing an existing message with a new one. This is accomplished
skipping to change at page 3, line 24 skipping to change at page 3, line 27
avoid wasteful quota consumption. Additionally, the existing avoid wasteful quota consumption. Additionally, the existing
sequence can fail on APPEND due to an over-quota condition even sequence can fail on APPEND due to an over-quota condition even
though the subsequent STORE/EXPUNGE would free up enough space for though the subsequent STORE/EXPUNGE would free up enough space for
the newly revised message. And finally, server efficiencies may be the newly revised message. And finally, server efficiencies may be
possible with a single logical message replacement operation as possible with a single logical message replacement operation as
compared to the existing APPEND/STORE/EXPUNGE sequence. compared to the existing APPEND/STORE/EXPUNGE sequence.
In its simplest form, the REPLACE command is a single-command In its simplest form, the REPLACE command is a single-command
encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a
message, except that it avoids any of the quota implications or message, except that it avoids any of the quota implications or
intermediate states associated with the 3 command sequence. In intermediate states associated with the 3 command sequence. Server
handling a REPLACE command, a server MUST NOT generate a response developers are encouraged to implement REPLACE as an atomic operation
code for the STORE +flags \DELETED portion of the sequence. to simplify error handling, minimize operational concerns, and reduce
Additionally, servers supporting the REPLACE command MUST NOT infer potential security problems. For systems where this is not possible,
any inheritance of content, flags, or annotations from the message communication with the requesting client must ensure no confusion of
being replaced. Finally, the replaced and replacing messages SHOULD message store state. A server MUST NOT generate a response code for
NOT be present in the mailbox at the same time. 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. REPLACE and UID REPLACE
3.1. Advertising Support for REPLACE 3.1. Advertising Support for REPLACE
Servers that implement the REPLACE extension will return "REPLACE" as Servers that implement the REPLACE extension will return "REPLACE" as
one of the supported capabilities in the CAPABILITY command response. one of the supported capabilities in the CAPABILITY command response.
3.2. REPLACE Command 3.2. REPLACE Command
Arguments: message sequence number Arguments: message sequence number
mailbox name mailbox name
OPTIONAL flag parenthesized list OPTIONAL flag parenthesized list
OPTIONAL date/time string OPTIONAL date/time string
message literal message literal
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - replace completed Result: OK - replace completed
NO - replace error; can't remove specified message NO - replace error; can't remove specified message
skipping to change at page 5, line 27 skipping to change at page 5, line 46
3. UID EXPUNGE 3. UID EXPUNGE
In the cited sequence, the quota implications of the APPEND are In the cited sequence, the quota implications of the APPEND are
evaluated within the context of the pending EXPUNGE so that only the evaluated within the context of the pending EXPUNGE so that only the
net quota consumption is considered. Additionally, the EXPUNGE net quota consumption is considered. Additionally, the EXPUNGE
portion of the sequence only applies to the specified message, not portion of the sequence only applies to the specified message, not
all messages flagged as \Deleted. all messages flagged as \Deleted.
Although the effect of REPLACE is identical to the steps above, the Although the effect of REPLACE is identical to the steps above, the
semantics are not identical; similar to MOVE [RFC6851], 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 different. In particular, the response codes for APPEND and EXPUNGE
will be returned while those for the STORE operation MUST NOT be will be returned while those for the STORE operation MUST NOT be
generated. generated.
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
skipping to change at page 6, line 7 skipping to change at page 6, line 23
submission. 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,
the REPLACE and UID REPLACE commands MUST only be valid in the the REPLACE and UID REPLACE commands MUST only be valid in the
selected state. This difference from APPEND is necessary since 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 4. Interaction with other extensions
This section describes how REPLACE interacts with some other IMAP This section describes how REPLACE interacts with some other IMAP
extensions. extensions.
4.1. RFC 4314, ACL 4.1. RFC 4314, ACL
The ACL rights [RFC4314] required for UID REPLACE are the union of 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 the ACL rights required for UID STORE and UID EXPUNGE in the current
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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
an untagged OK before sending the EXPUNGE or replaced responses. 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 specification means that the client first receives an EXPUNGE for a
message and afterwards APPENDUID for the new message. It can be message and afterwards APPENDUID for the new message. It can be
unnecessarily difficult to process that sequence usefully.) unnecessarily difficult to process that sequence usefully.)
4.4. RFC 6785, IMAP Events in Sieve 4.4. RFC 6785, IMAP Events in Sieve
REPLACE applies to IMAP events in Sieve [RFC6785] in the same way REPLACE applies to IMAP events in Sieve [RFC6785] in the same way
that APPEND does. Therefore, REPLACE can cause a Sieve script to be that APPEND does. Therefore, REPLACE can cause a Sieve script to be
invoked with the imap.cause set to "APPEND". Because the invoked with the imap.cause set to "APPEND". Because the
intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by
skipping to change at page 9, line 14 skipping to change at page 9, line 14
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
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
capability =/ "REPLACE" capability =/ "REPLACE"
command-select =/ replace command-select =/ replace
replace = "REPLACE" SP seq-number SP mailbox append-message replace = "REPLACE" SP seq-number SP mailbox append-message
uid = "UID" SP (copy / fetch/ search / store / move / uid =/ replace
replace)
6. Security Considerations 6. Security Considerations
This document is believed to add no security problems beyond those This document is believed to add no security problems beyond those
that may already exist with the base IMAP specification. The REPLACE that may already exist with the base IMAP specification. The REPLACE
command may actually prevent some potential security problems because command may actually prevent some potential security problems because
it avoids intermediate message states that could possibly be it avoids intermediate message states that could possibly be
exploited by an attacker. exploited by an attacker.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 10, line 32 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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
Identifiers", RFC 8474, DOI 10.17487/RFC8474, September Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
2018, <https://www.rfc-editor.org/info/rfc8474>. 2018, <https://www.rfc-editor.org/info/rfc8474>.
9.2. Informative References 9.2. Informative References
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502, MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502,
March 2003, <https://www.rfc-editor.org/info/rfc3502>. March 2003, <https://www.rfc-editor.org/info/rfc3502>.
[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
March 2011, <https://www.rfc-editor.org/info/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>.
9.3. URIs
[1] https://tools.ietf.org/html/bcp14
Author's Address Author's Address
Stuart Brandt Stuart Brandt
Verizon Verizon
22001 Loudoun County Parkway 22001 Loudoun County Parkway
Ashburn, VA 20147 Ashburn, VA 20147
USA USA
Email: stujenerin@aol.com Email: stujenerin@aol.com
 End of changes. 14 change blocks. 
20 lines changed or deleted 34 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/