MBOX-Line: From tss at iki.fi  Tue Jun 15 11:25:45 2010
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <1372616189.4386.1276624386644.JavaMail.root@dogfood.zimbra.com>
References: <1372616189.4386.1276624386644.JavaMail.root@dogfood.zimbra.com>
Message-ID: <1276626345.2916.50.camel@kurkku.sapo.corppt.com>

On Tue, 2010-06-15 at 10:53 -0700, Dan Karp wrote:

> > Oh, now I started also thinking about NOTIFY+QRESYNC combination where
> > you can tell it to send VANISHED replies at any time. If MOVE is
> > sending EXPUNGE/VANISHED replies and if client cares about which ones
> > of those were from MOVE, it couldn't really know since a VANISHED reply
> > might have been sent to client just before the server received MOVE
> > command.
> 
> Would it be unreasonable to state that the only untagged EXPUNGE
> responses from a MOVE command may be those directly resulting from
> the MOVE? (UID MOVE, like UID FETCH, would have no such constraints.)

But that's what I was trying to explain above that it doesn't
necessarily work when enough extensions are being used:

1. Client 1 enables QRESYNC, so it gets VANISHED (uidset) replies
instead of EXPUNGEs.

2. Client 1 enables NOTIFY extension and tells server that it can handle
any untagged replies at any time (basically enables IDLE without the
IDLE command being running).

3. Client 2 EXPUNGEs UID 123.

4. Client 1 sends UID MOVE 1 command.

5. Server sends VANISHED update to client 1.

6. Server starts processing UID MOVE command.

The result looks like:

C: a UID MOVE 1 elsewhere
S: * VANISHED 123
S: * VANISHED 1
S: a OK [UIDMOVE 1] Moved

I don't know if that's a big problem, but "EXPUNGEs can't be sent during
MOVE" is incompatible with QRESYNC+NOTIFY.


