IMAP REPLACE Extension
AOL43623 Preddy CtAshburnVA20147USAstujenerin@aol.comIMAPREPLACEemail This document defines an IMAP extension which can be used to replace
an existing message in a message store with a new message. Message
replacment is a common operation for clients that automatically
save drafts or notes as a user composes them.
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 .
Formal syntax is defined by .
Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server.
This document defines an IMAP extension to facilitate
replacing an existing message with a new one. This is accomplished by
defining a new REPLACE command and extending the UID command to
allow UID REPLACE.
Using commands from the base IMAP specification, replacement of a message
involves three separate commands issued in serial fashion; APPEND,
STORE, EXPUNGE. Pipelining of these three commands is not
recommended since failure of any individual command should prevent
subsequent commands from being executed lest the original message
version be lost. The REPLACE command is intended to provide an
atomic alternative to the existing non-atomic sequence.
Because of the non-atomic nature of the existing sequence,
interruptions can leave messages in intermediate states which can
be seen and acted upon by other clients. Such interruptions can
also strand older revisions of messages, thereby forcing the user
to manually clean up multiple revisions of the same message in
order to 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 an atomic
encapsulation of STORE + UID EXPUNGE + APPEND. Servers that support
the REPLACE command MUST guarantee atomicity; either the specified
message is completely replaced by the supplied message, or the
specified message is left unmodified and no part of the supplied
message data is stored. Servers supporting REPLACE also MUST NOT
infer any inheritance of content, flags, or annotations from the
message being replaced.
Servers that implement the REPLACE extension will return "REPLACE"
as one of the supported capabilities in the CAPABILITY command
response.
This extends the first form of the UID command (see
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.
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 message specified by the message identifier will
be removed from the selected mailbox. These operations will appear
to the client as a single action. This has the same effect as the
following sequence:
In the cited sequence, the original message is removed first to
avoid possible quota implications of APPENDing new data first.
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 , the
intermediate states produced do not occur, and the response codes
are different. In particular, the response codes for EXPUNGE and
APPEND 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 or
modified state; any untagged EXPUNGE response MUST NOT be sent until
all actions are successfully completed. Additionally, the target
mailbox MUST NOT be modified until all actions are successfully
completed.
Because of the similarity of REPLACE to APPEND, extensions that
affect APPEND affect REPLACE in the same way. Response codes such
TRYCREATE (see Section 6.3.11), as well as those
defined by extensions, are sent as appropriate. See
for more information about how REPLACE interacts with other IMAP
extensions.
Unlike the APPEND command which is valid in the authenticated
state, the REPLACE command MUST only be valid in the selected
state. This difference from APPEND is necessary since REPLACE
operates on message sequence numbers.
This section describes how REPLACE interacts with some other IMAP
extensions.
The ACL rights required for UID REPLACE are the
union of the ACL rights required for UID STORE, UID EXPUNGE, and
APPEND.
Servers supporting both REPLACE and CATENATE MUST support
the addtional append-data and resp-text-code elements defined the
Formal Syntax section of RFC4469 in conjunction with the REPLACE
command.
Servers supporting both REPLACE and UIDPLUS MUST send
APPENDUID in response to a UID REPLACE command. The only
exceptions to this are the ones outlined for APPEND in RFC4315
section 3.
REPLACE applies to IMAP events in Sieve 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 REPLACE, no action will be taken that results in a
imap.cause of FLAG.
Servers implementing both REPLACE and CONDSTORE/QRESYNC 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.
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in .
defines the non-terminals "capability","command-select", "mailbox",
and "seq-number". 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 accept these strings in a case-insensitive
fashion.
This document is believed to add no security problems beyond
those that may already exist with the base IMAP specificaiton.
The IANA is requested to add REPLACE to the
"IMAP 4 Capabilities" registry,
http://www.iana.org/assignments/imap4-capabilities.