34 lines
1.5 KiB
Plaintext
34 lines
1.5 KiB
Plaintext
MBOX-Line: From tss at iki.fi Tue Jun 15 10:37:23 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: <306561054.4215.1276619210367.JavaMail.root@dogfood.zimbra.com>
|
|
References: <306561054.4215.1276619210367.JavaMail.root@dogfood.zimbra.com>
|
|
Message-ID: <1276623443.2916.36.camel@kurkku.sapo.corppt.com>
|
|
|
|
On Tue, 2010-06-15 at 09:26 -0700, Dan Karp wrote:
|
|
> > > 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.)
|
|
> >
|
|
> > That requires an amendment to RFC 3501 7.4.1.
|
|
>
|
|
> 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).
|
|
|
|
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.
|
|
|
|
|