wasm-demo/demo/ermis-f/imap-protocol/cur/1600095210.22807.mbox:2,S

52 lines
1.8 KiB
Plaintext

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.