On 2 Oct 2018, at 16.14, The IESG <iesg-secretary@xxxxxxxx> 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 > ietf@xxxxxxxx mailing lists by 2018-10-16. Exceptionally, comments may be > sent to iesg@xxxxxxxx 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".
