Subject: [Extra] Implementation questions regarding IMAP REPLACE

From: Stephan Bosch <[email-masked]>
Date: Wed, 14 Nov 2018 00:10:55 +0100

Hi,

I've been evaluating a bit what effort an implementation of IMAP REPLACE 
would require at our end. I got two remarks/questions now:

1) The MOVE capability has some overlap with this one and that document 
states the following:

    The server may send EXPUNGE (or VANISHED) responses before the tagged
    response, so the client cannot safely send more commands with message
    sequence number arguments while the server is processing MOVE or UID
    MOVE.

    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 <https://tools.ietf.org/html/rfc3501#section-5.5>, for more information about
    ambiguities as well as handling requirements for both clients and
    servers.

I'd say similar considerations apply to REPLACE, don't they?

2) What happens when the replaced message does not exist at all (no such 
seqnum/UID). Will the whole command fail or will it assume that the 
replaced message is already expunged and continue as a normal APPEND?

Regards,

Stephan.

---

From: Stuart Brandt <[email-masked]>
Date: Tue, 13 Nov 2018 22:14:12 -0500

Stephan -

Thanks for the input...comments inline:

> I'd say similar considerations apply to REPLACE, don't they?

Likely, yes.

> replaced message is already expunged and continue as a normal APPEND?

The intention is that it would fail and fail quickly -- prior to upload 
of the replacing data. Continuing with the Append can be problematic in 
a multi-client/session scenario and can lead to re-introduction of a 
Draft that was already sent or creation of a draft that appears newer 
than the one that replaced the referenced message. Additionally, it's 
important that a client actually *know* when it's not in sync with the 
present mail store, something that's downright dangerous when dealing 
with sequence numbers.

>
> Regards,
>
> Stephan.
>
>
>
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
>