MBOX-Line: From dkarp at zimbra.com  Tue Jun 15 10:53:06 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: <1276623443.2916.36.camel@kurkku.sapo.corppt.com>
Message-ID: <1372616189.4386.1276624386644.JavaMail.root@dogfood.zimbra.com>

> > Good form would be to amend it in any case. MOVE would definitely
> > fall into the category of commands for which EXPUNGEs from other
> > sources would cause loss of synchronization, and thus it needs to
> > be added to the list in 7.4.1.
> 
> The problem isn't only EXPUNGEs, but all untagged replies that refer
> to messages (assuming MOVE doesn't send EXPUNGEs/MOVED replies to note
> when the sequences change).

I think you'd have to send EXPUNGEs.  Just for client sanity's sake.

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

