Subject: Re: [Extra] Last Call: <draft-ietf-extra-imap-replace-01.txt> (IMAP REPLACE Extension) to Proposed Standard

From: Timo Sirainen <[email-masked]>
Date: Tue, 2 Oct 2018 17:17:11 +0300

On 2 Oct 2018, at 16.14, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from the Email mailstore and eXtensions To
> Revise or Amend WG (extra) to consider the following document: - 'IMAP
> REPLACE Extension'
>  <draft-ietf-extra-imap-replace-01.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2018-10-16. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.

1) It should describe issues with command pipelining, which are similar to what exist for MOVE extension. The MOVE extension says about it:

   Both MOVE and UID MOVE can be pipelined with other commands, but care
   has to be taken.  Both commands modify sequence numbers and also
   allow unrelated EXPUNGE responses.  The renumbering of other messages
   in the source mailbox following any EXPUNGE response can be
   surprising and makes it unsafe to pipeline any command that relies on
   message sequence numbers after a MOVE or UID MOVE.  Similarly, MOVE
   cannot be pipelined with a command that might cause message
   renumbering.  See [RFC3501], Section 5.5, for more information about
   ambiguities as well as handling requirements for both clients and
   servers.

Maybe just copy&paste, except MOVE -> REPLACE and it should be fine?

2) In theory all pipelined commands can be processed out-of-order in IMAP, although it's not very common. With UIDPLUS extension it's recommended to send untagged * OK [APPENDUID] reply. If server processed the two UID REPLACEs out-of-order, the untagged replies could be in unexpected order. Maybe just say that the APPENUID replies must be returned in the same order as pipelined REPLACE commands?

3) It says "Finally, the replaced and replacing messages SHOULD NOT be present in the mailbox at the same time." - This is maybe a bit ambiguous when thinking of the following sequence:

 - client A: Opens mailbox and sees a single mail with UID=123
 - client B: REPLACEs UID 123 within the same mailbox where it gets UID 124
 - client A: FETCH 1 BODY[]

I think the FETCH may or may not succeed depending on the server implementation, similar to what happens when the message is EXPUNGEd. But since this is a non-UID FETCH, the old message can't be EXPUNGEd. However, the server may still announce the existence of the new mail. So in this case the client will end up with the mailbox having both messages, UID 123 and 124. Depending on the server implementation it may be possible to FETCH them both. This seems like the logical way to implement the REPLACE extension, but it also sounds like a violation of the "SHOULD NOT".