Subject: Re: [imapext] IMAP REPLACE extension

From: Pete Maclean <[email-masked]>
Date: Tue, 05 May 2015 14:35:58 -0400

Stu,

This is a good start indeed but I find a few things to mention.

Is UID REPLACE valid in the authenticated state?  My assumption would 
be that it is but it might be good for the text to make that explicit.

Can REPLACE be used to replace a message in a mailbox other than the 
one the client has selected?  Surely it should not be.  Which perhaps 
suggests that REPLACE should not have a mailbox-name argument.

The penultimate paragraph in section 3.4 strikes me as awkward and unclear.

There is a typo ("replacment") in the first paragraph of the Abstract.

Pete Maclean

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 05 May 2015 21:54:15 +0000

REPLACE wraps APPEND which has a mailbox name as an argument.  Therefore 
REPLACE must also have this argument and that's also why it's an 
authenticated-state command and not a selected-state command.

Adrien

------ Original Message ------
From: "Pete Maclean" <[email-masked]>
To: "Stu Brandt" <[email-masked]>; "[email-masked]'" 
<[email-masked]>
Sent: 6/05/2015 6:35:58 a.m.
Subject: Re: [imapext] IMAP REPLACE extension

>_______________________________________________
>imapext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/imapext

---

From: Stu Brandt <[email-masked]>
Date: Tue, 05 May 2015 18:18:00 -0400

Pete -

Thanks for your response. My comments are inline.

On 5/5/15 2:35 PM, Pete Maclean wrote:
> Is UID REPLACE valid in the authenticated state?  My assumption would be
> that it is but it might be good for the text to make that explicit.

I was hoping that section 3.5 would have covered that. Specifically my 
statement of...

  "Unlike the APPEND command which is valid in the authenticated state,
    the REPLACE command MUST only be valid in the selected state. "

...was intended to answer your question. In my proposal, I'm intending 
to say it's valid ONLY in SELECTED state.  Does that wording cover it 
for you or can you help detail the ambiguity in the wording?

>
> Can REPLACE be used to replace a message in a mailbox other than the one
> the client has selected?  Surely it should not be.  Which perhaps

Yeah, I spent a lot of time going back and forth on this question.
Ultimately where I ended up is that since the problems that REPLACE 
solves (specified in section 2) exist regardless of whether the new 
message ends up in the same mailbox or a different one, I chose not to 
restrict the new message to the selected mailbox.

As an aside, there is at least 1 common use case I can think of where 
I'd want to replace a message in one mailbox with a message in an 
entirely different mailbox; replacing the final version of a message in 
Drafts with a message in Sent following a successful send. Together with 
CATENATE, REPLACE as written could be quite useful in this case.

> The penultimate paragraph in section 3.4 strikes me as awkward and unclear.

It's trying to provide more details around what a server might need to 
do in order to be truly atomic in implementing REPLACE. Things like 
don't fail REPLACE but then show the original message with the /Deleted 
flag. Or don't fail REPLACE *after* you've already sent an untagged 
EXPUNGE. Or don't fail REPLACE but then change MODSEQ and NEXTUID in a 
way that would make the client think it missed some kind of change. Or 
don't fail REPLACE after having sent untagged EXISTS to other clients in 
IDLE. This list goes on, but basically:
1) Don't leave selected mailbox in an altered state if it fails
2) Don't send untagged responses if it fails
3) Don't leave the target mailbox in an altered state if it fails

Does that make sense?

> There is a typo ("replacment") in the first paragraph of the Abstract.

Thank you. It'll be corrected in next version.

---

From: Stu Brandt <[email-masked]>
Date: Tue, 05 May 2015 18:29:42 -0400

Adrien -

I believe message sequence numbers are only valid in the context of a 
Selected mailbox, so REPLACE is not valid in Authenticated state.  I had 
considered doing away with support for sequence numbers and relying on 
IMAP-URL-style specification of the original message in order to avoid 
the need for Selected state, but landed where I did based on:
1) STORE + UID EXPUNGE require Selected state and those are component 
parts of REPLACE
2) being already in Selected state for APPEND is actually a lot more 
common than one would expect

- Stuart

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 05 May 2015 22:31:48 +0000

Ok

do you think many / any people would even want to use this with seq 
numbers, or should it be UID REPLACE only?

I don't have a problem with it being in selected state only.  Was just 
trying to explain the rationale.

I guess it is quite different to an APPEND, since that generates a new 
MSGNO and UID, which is not what happens for REPLACE.

Adrien

------ Original Message ------
From: "Stu Brandt" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Sent: 6/05/2015 10:29:42 a.m.
Subject: Re: [imapext] IMAP REPLACE extension

>Selected mailbox, so REPLACE is not valid in Authenticated state.  I 
>had considered doing away with support for sequence numbers and relying 
>on IMAP-URL-style specification of the original message in order to 
>avoid the need for Selected state, but landed where I did based on:

---

From: Stu Brandt <[email-masked]>
Date: Tue, 05 May 2015 18:59:31 -0400

Comments inline.

> numbers, or should it be UID REPLACE only?

I'll flip the question back to you...do you think this draft is the 
right place to stop supporting sequence numbers when referring to a 
message in the store?

For a client looking to implement REPLACE, they're likely already in 
Selected mode since their current code needs to do a STORE. Closing the 
door on the use of sequence numbers seemed to be forging an unnecessary 
new path.

So much as I dislike sequence numbers, I did not think this was the 
right vehicle to pursue it.

> MSGNO and UID, which is not what happens for REPLACE.

Sorry, but that's not the case either. Message bodies are immutable 
things, so not changing UID or MSGNO would break the basic client-server 
model where clients fetch body once, store it locally, and never need to 
ask for body ever again.

I was being somewhat literal when I wrote:

"In its simplest form, the REPLACE command is an atomic encapsulation of 
STORE + UID EXPUNGE + APPEND" in section 2.

The examples in section 3 also show APPENDUID responses to cover the 
factthat the new revision is considered its own message with its own UID.

I suppose I should clarify the examples a bit more with untagged EXISTS 
as well per recommendation of 6.3.11 in rfc3501.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 05 May 2015 23:43:40 +0000

------ Original Message ------
From: "Stu Brandt" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>; "[email-masked]'" 
<[email-masked]>
Sent: 6/05/2015 10:59:31 a.m.
Subject: Re: [imapext] IMAP REPLACE extension

>right place to stop supporting sequence numbers when referring to a 
fair enough.

But I think it could be justifiable at some stage to take a position 
that certain extensions are only available using UIDs.  It's optional 
after all.  In fact wasn't MOVE debated around this point, re safety 
thereof?  I guess MOVE is special in that potentially 2 mailboxes are 
involved.

>things, so not changing UID or MSGNO would break the basic 
>client-server model where clients fetch body once, store it locally, 
>and never need to ask for body ever again.
commonly in drafts folder it will actually end up with the same MSGNO 
but I guess there will be an expunge notification in between.

>"In its simplest form, the REPLACE command is an atomic encapsulation 
>of STORE + UID EXPUNGE + APPEND" in section 2.
>

OK.

>as well per recommendation of 6.3.11 in rfc3501.
Sorry I should do more than just glance over the draft before 
commenting.

Cheers

Adrien

---

From: Pete Maclean <[email-masked]>
Date: Tue, 05 May 2015 20:06:44 -0400

I did not feel confident enough to say so in my first message but I 
also thought about suggesting we have UID REPLACE only.  I would 
prefer to see that as a suitable compromise for this extension and 
not as a push to start eliminating sequence numbers.

Pete

At 07:43 PM 5/5/2015, Adrien de Croy wrote:

>that certain extensions are only available using UIDs.  It's 
>optional after all.  In fact wasn't MOVE debated around this point, 
>re safety thereof?  I guess MOVE is special in that potentially 2 
>mailboxes are involved.
>
>>
>>For a client looking to implement REPLACE, they're likely already 
>>in Selected mode since their current code needs to do a STORE. 
>>Closing the door on the use of sequence numbers seemed to be 
>>forging an unnecessary new path.
>>
>>client-server model where clients fetch body once, store it 
>>locally, and never need to ask for body ever again.
>commonly in drafts folder it will actually end up with the same 
>MSGNO but I guess there will be an expunge notification in between.
>
>>
>>"In its simplest form, the REPLACE command is an atomic 
>>encapsulation of STORE + UID EXPUNGE + APPEND" in section 2.
>>
>>The examples in section 3 also show APPENDUID responses to cover 
>>the factthat the new revision is considered its own message with its own UID.
>
>OK.
>
>
>>
>>I suppose I should clarify the examples a bit more with untagged 
>>EXISTS as well per recommendation of 6.3.11 in rfc3501.
>Sorry I should do more than just glance over the draft before commenting.
>
>Cheers
>
>Adrien
>
>
>>
>>>
>>>Adrien
>>>
>

---

From: Chris Newman <[email-masked]>
Date: Mon, 11 May 2015 19:03:46 -0700

I believe the atomic requirement is too stringent and will reduce deployment of
this proposal. A looser requirement can make implementation quite a bit simpler
for some server designs. I'd state the requirement as follows:

The REPLACE command is a combination of APPEND, STORE +flags \DELETED and UID
EXPUNGE for a message. A response code for the STORE \DELETED flag MUST NOT be
generated. The replaced and replacing messages SHOULD NOT be present in the
mailbox at the same time.

The difference with this phrasing relative to the stricter "atomic" phrasing is
this does not require the server to eliminate the window where both draft
messages are present in the mailbox. For certain server designs, eliminating
that window can be either difficult to implement or significantly more
expensive.

The unnecessary "atomic" requirement deters deployment of multiappend extension
as well. Slightly looser language is better for deployment. The MOVE command is
a good example of language with appropriately loose requirements.

		- Chris

--On April 29, 2015 9:45:11 -0400 Stu Brandt <[email-masked]> wrote:
> As promised, here's a draft of a REPLACE extension.
> 
> Since the most obvious question is going to be "Why REPLACE and not an option
> on APPEND?",  I'll answer it straight away...
> 
> First, APPEND is valid in the authenticated state. REPLACE requires the
> selected state. I chose not to generate a mixed state scenario for APPEND.
> Secondly, REPLACE is similar to MOVE in that it avoids a number of issues
> that come with a serialized non-atomic sequence attempting to perform a
> single operation. MOVE is not an option on COPY, so I chose to follow the
> same precedent.
> 
> Here's the writeup.
> 
> ------------------------------------------------------------------------
> 
> Network Working Group                                          S. Brandt
> Internet-Draft                                                       AOL
> Intended status: Standards Track                          April 29, 2015
> Expires: October 31, 2015
> 
>                           IMAP REPLACE Extension
>                        draft-brandt-imap-replace-00
> 
> 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
>     replacment is a common operation for clients that automatically save
>     drafts or notes as a user composes them.
> 
> Status of This Memo
> 
>     This Internet-Draft is submitted in full conformance with the
>     provisions of BCP 78 and BCP 79.
> 
>     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 http://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 October 31, 2015.
> 
> Copyright Notice
> 
>     Copyright (c) 2015 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
>     (http://trustee.ietf.org/license-info) in effect on the date of
>     publication of this document.  Please review these documents
>     carefully, as they describe your rights and restrictions with respect
>     to this document.  Code Components extracted from this document must
>     include Simplified BSD License text as described in Section 4.e of
>     the Trust Legal Provisions and are provided without warranty as
>     described in the Simplified BSD License.
> 
> Brandt                  Expires October 31, 2015                [Page 1]
> Internet-Draft           IMAP REPLACE Extension               April 2015
> 
> Table of Contents
> 
>     1.  Conventions Used in This Document . . . . . . . . . . . . . .   2
>     2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
>     3.  REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . .   3
>       3.1.  Advertising Support for REPLACE . . . . . . . . . . . . .   3
>       3.2.  REPLACE Command . . . . . . . . . . . . . . . . . . . . .   3
>       3.3.  UID REPLACE Command . . . . . . . . . . . . . . . . . . .   4
>       3.4.  Semantics of REPLACE and UID REPLACE  . . . . . . . . . .   4
>       3.5.  IMAP State Diagram Impacts  . . . . . . . . . . . . . . .   5
>     4.  Interaction with other extensions . . . . . . . . . . . . . .   5
>       4.1.  RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . .   6
>       4.2.  RFC 4469, CATENATE  . . . . . . . . . . . . . . . . . . .   6
>       4.3.  RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . .   6
>       4.4.  RFC 6785, IMAP Events in Sieve  . . . . . . . . . . . . .   6
>       4.5.  RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . .   6
>     5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   6
>     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
>     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
>     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
>     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
>       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
>       9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
>     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8
> 
> 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
>     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
>     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
> 
> Brandt                  Expires October 31, 2015                [Page 2]
> Internet-Draft           IMAP REPLACE Extension               April 2015
> 
>     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.
> 
> 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
>                      or can't add new message content
>                 BAD - command unknown or arguments invalid
> 
> Brandt                  Expires October 31, 2015                [Page 3]
> Internet-Draft           IMAP REPLACE Extension               April 2015
> 
>     Example:
>       C: A003 REPLACE 4 Drafts (\Seen \Draft) {312}
>       S: + Ready for literal data
>       C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
>       C: From: Fritz Schmidt <[email-masked]>
>       C: Subject: happy new year !!
>       C: To: [email-masked]
>       C: Message-Id: <[email-masked]>
>       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: * 4 EXPUNGE
>       S: A003 OK [APPENDUID 1 2000] 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.
> 
>     Example:
>       C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350}
>       S: + Ready for literal data
>       C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST)
>       C: From: Fritz Schmidt <[email-masked]>
>       C: Subject: happy new year !!
>       C: To: [email-masked]
>       C: Message-Id: <[email-masked]>
>       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: * 4 EXPUNGE
>       S: A004 OK [APPENDUID 1 2001] 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
>     message specified by the message identifier will be removed from the
> 
> Brandt                  Expires October 31, 2015                [Page 4]
> Internet-Draft           IMAP REPLACE Extension               April 2015
> 
>     selected mailbox.  These operations will appear to the client as a
>     single action.  This has the same effect as the following sequence:
> 
>        1. [UID] STORE +FLAGS.SILENT \DELETED
>        2. UID EXPUNGE
>        3. APPEND
> 
>     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 [RFC6851], 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 [RFC3501] Section 6.3.11), as well as 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,
>     the REPLACE command MUST only be valid in the selected state.  This
>     difference from APPEND is necessary since REPLACE operates on message
>     sequence numbers.
> 
> 4.  Interaction with other extensions
> 
>     This section describes how REPLACE interacts with some other IMAP
>     extensions.
> 
> Brandt                  Expires October 31, 2015                [Page 5]
> Internet-Draft           IMAP REPLACE Extension               April 2015
> 
> 4.1.  RFC 4314, ACL
> 
>     The ACL rights [RFC4314] required for UID REPLACE are the union of
>     the ACL rights required for UID STORE, UID EXPUNGE, and APPEND.
> 
> 4.2.  RFC 4469, CATENATE
> 
>     Servers supporting both REPLACE and CATENATE [RFC4469] MUST support
>     the addtional append-data and resp-text-code elements defined the
>     Formal Syntax section of RFC4469 in conjunction with the REPLACE
>     command.
> 
> 4.3.  RFC 4315, UIDPLUS
> 
>     Servers supporting both REPLACE and UIDPLUS [RFC4315] 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.
> 
> 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
>     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.
> 
> 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
>     accept these strings in a case-insensitive fashion.
> 
> Brandt                  Expires October 31, 2015                [Page 6]
> Internet-Draft           IMAP REPLACE Extension               April 2015
> 
>     capability     =/ "REPLACE"
> 
>     command-select =/ replace
>     replace        = "REPLACE" SP seq-number SP mailbox append-message
>     uid            = "UID" SP (copy / fetch/ search / store / move /
>                                replace)
> 
> 6.  Security Considerations
> 
>     This document is believed to add no security problems beyond those
>     that may already exist with the base IMAP specificaiton.
> 
> 7.  IANA Considerations
> 
>     The IANA is requested to add REPLACE to the "IMAP 4 Capabilities"
>     registry, http://www.iana.org/assignments/imap4-capabilities.
> 
> 8.  Acknowledgements
> 
> 9.  References
> 
> 9.1.  Normative References
> 
>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>                Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
>     [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
>                4rev1", RFC 3501, March 2003.
> 
>     [RFC4314]  Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
>                RFC 4314, December 2005.
> 
>     [RFC4315]  Crispin, M., "Internet Message Access Protocol (IMAP) -
>                UIDPLUS extension", RFC 4315, December 2005.
> 
>     [RFC4466]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
>                ABNF", RFC 4466, April 2006.
> 
>     [RFC4469]  Resnick, P., "Internet Message Access Protocol (IMAP)
>                CATENATE Extension", RFC 4469, April 2006.
> 
>     [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
>                Specifications: ABNF", STD 68, RFC 5234, January 2008.
> 
>     [RFC6785]  Leiba, B., "Support for Internet Message Access Protocol
>                (IMAP) Events in Sieve", RFC 6785, November 2012.
> 
> Brandt                  Expires October 31, 2015                [Page 7]
> Internet-Draft           IMAP REPLACE Extension               April 2015
> 
>     [RFC7162]  Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
>                Changes Resynchronization (CONDSTORE) and Quick Mailbox
>                Resynchronization (QRESYNC)", RFC 7162, May 2014.
> 
> 9.2.  Informative References
> 
>     [RFC6851]  Gulbrandsen, A. and N. Freed, "Internet Message Access
>                Protocol (IMAP) - MOVE Extension", RFC 6851, January 2013.
> 
> Author's Address
> 
>     Stuart Brandt
>     AOL
>     43623 Preddy Ct
>     Ashburn, VA  20147
>     USA
> 
>     Email: [email-masked]
> 
> Brandt                  Expires October 31, 2015                [Page 8]
>

---

From: Stu Brandt <[email-masked]>
Date: Tue, 12 May 2015 21:44:51 -0400

Chris -

Thanks for your feedback. The atomic requirement is intended to provide 
a guarantee to clients that use of REPLACE should simplify possible 
message states as compared to the existing 3 command sequence. I was 
really hoping to avoid a case where failure of REPLACE would require a 
client to retry by using 2 of the 3 underlying commands.

I certainly understand how it may be burdensome to some server 
implementations, though, so I'm hoping to hear from a few more server 
implementers before making a decision on whether to relax the atomicity 
requirement.

Thanks again...

- Stuart

> a good example of language with appropriately loose requirements.

[snip]