MBOX-Line: From dkarp at zimbra.com  Tue Jun 15 11:33:52 2010
To: imap-protocol@u.washington.edu
From: Dan Karp <dkarp@zimbra.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <1276626345.2916.50.camel@kurkku.sapo.corppt.com>
Message-ID: <484642146.4458.1276626832297.JavaMail.root@dogfood.zimbra.com>

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

I think we can stop there.  UID MOVE, like UID FETCH et al, would have
no problems with EXPUNGE or VANISHED notifications.  It's MOVE (and
STORE, etc.) that have the issue addressed in RFC 3501 section 7.4.1.

