[Imap-protocol] MOVE is a pipeline

[Dan Karp]

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


> Having MOVE issue untagged EXPUNGE responses is a problem, since it

> tempts server implementors to do a non-atomic move. It also makes MOVE

> chatty, and then results in pressure to add MOVE.SILENT or MOVEANDCLOSE.


This is true to some extent, but even so it still makes MOVE slightly
less chatty than COPY/STORE.SILENT/EXPUNGE.  Certainly no more chatty.
And you can probably nip a (misguided) MOVE.SILENT in the bud at this
stage.

Likewise, MOVEANDCLOSE doesn't have a real-world use case, as a move
isn't correlated with the end of a SELECT.  Quite the opposite, in fact.