MBOX-Line: From mrc+imap at panda.com  Tue Jun 15 09:20:42 2010
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <DDBD52CE-0DE5-4B9F-9AEF-9EEA1860FD3A@iki.fi>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006150012.43889.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006141528400.662@hsinghsing.panda.com>
	<201006150103.52513.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006141604420.662@hsinghsing.panda.com>
	<4C16C4E8.7010008@aol.com>
	<alpine.OSX.2.00.1006141713260.662@hsinghsing.panda.com>
	<4C17017A.2090305@aol.com>
	<alpine.OSX.2.00.1006142133200.662@hsinghsing.panda.com>
	<DDBD52CE-0DE5-4B9F-9AEF-9EEA1860FD3A@iki.fi>
Message-ID: <alpine.OSX.2.00.1006150908290.662@hsinghsing.panda.com>

On Tue, 15 Jun 2010, Timo Sirainen wrote:
> That would require client to wait for the tagged reply to MOVE to find
> out if it succeeded or not, before it can process any untagged replies.
> a MOVE 1:100 elsewhere
> * MOVED
> * 3 EXPUNGE
> a OK

Ugh, but the only obvious alternative is to amend RFC 3501 7.4.1.  Sigh.

> - Trying to MOVE an expunged message that's still accessible in session
> should fail the MOVE instead of create a copy of it?..

Ugh again.  It's worse.  Consider another session that has the mailbox
open.

Mail stores that just have pointers to the message can do this without
problem.  The operation is just a copy of the pointer, and other sessions
only hold on to the pointer until they reach an expunge-permitted point.

If the mail store doesn't permit ghost pointers, then move makes its
multi-access maibox problems worse....

> - Should describe QRESYNC interaction with HIGHESTMODSEQ updates (and
> maybe VANISHED)

Have fun on this. :p

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

