MBOX-Line: From dave at cridland.net  Wed Jun 16 05:22:10 2010
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <11418747.5765.1276690309071.JavaMail.root@dogfood.zimbra.com>
References: <11418747.5765.1276690309071.JavaMail.root@dogfood.zimbra.com>
Message-ID: <15361.1276690930.129601@puncture>

On Wed Jun 16 13:11:49 2010, Dan Karp wrote:
> > C: t MOVE 1:10
> > S: * EXPUNGE 1
> > S: * EXPUNGE 2
> > S: * EXPUNGE 3
> > // ...
> > S: t OK Moved, and grooved.
> >
> > As long as clients expect there to be potentially more, or fewer,
> > expunges, then there's no loss of synchronization, as far as I can
> > tell, even if expunged fail for the MOVE itself, yet occur as a
> > result of unrelated actions.
> 
> It's the same issue addressed by RFC 3501 section 7.4.1:
> 
>       An EXPUNGE response MUST NOT be sent when no command is in
>       progress, nor while responding to a FETCH, STORE, or SEARCH
>       command.  This rule is necessary to prevent a loss of
>       synchronization of message sequence numbers between client and
>       server.  A command is not "in progress" until the complete  
> command
>       has been received; in particular, a command is not "in  
> progress"
>       during the negotiation of command continuation.
> 
> MOVE falls into the same category as FETCH, STORE, and SEARCH.

You think?

I think it falls into the same category as EXPUNGE - both commands  
are specifically designed to remove messages from the mailbox.

The MSNs specifed as the argument to MOVE need to be dereferenced, in  
effect, prior to any EXPUNGE occuring, as with UID SEARCH's errata  
note (?5.5), but that's really it.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

