Re: [Extra] Implementation questions regarding IMAP REPLACE

[Stuart Brandt <[e-mail]>]

Stephan -

Thanks for the input...comments inline:

On 11/13/2018 6:10 PM, Stephan Bosch wrote:
> 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?

Likely, yes.

>
> 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?

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra
>