MBOX-Line: From dave at cridland.net  Mon Jun 14 05:07:08 2010
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <201006141248.11054.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006120124.53714.witold.krecicki@firma.o2.pl>
	<29965.1276510437.099598@puncture>
	<201006141248.11054.witold.krecicki@firma.o2.pl>
Message-ID: <29965.1276517228.230869@puncture>

On Mon Jun 14 11:48:11 2010, Witold Kr?cicki wrote:
> On Monday 14 of June 2010 12:13:57 Dave Cridland wrote:
> > a) MOVE is simpler for client authors. However, client authors  
> would
> > still have to move messages without this extension, hence have to
> > provide multiple codepaths to achieve the same - really quite  
> simple
> > - facility.
> That's their choice, it's an EXTENSION hence they don't HAVE to use  
> MOVE
> functionality.
> Yet MOVE enables user to move messages even if they're at their  
> quota limits,
> which is currently impossible with enforced quota limits.
> 
> 
I'm trying to make what I think is quite an important point, so let  
me try and rephrase so you see where I'm coming from.

If a client implements MOVE, it *still* has to implement a  
move-analogue by COPY/EXPUNGE, in order to remain functional.

If it's implementing COPY/EXPUNGE anyway, there is merit in *not*  
implementing MOVE, as there are then fewer codepaths - whether this  
outweighs any advantage in implementing anyway depends on deployment  
levels and perceived gain to the client developer.

So, like most things, this is a trade-off, and I'm not convinced it's  
worthwhile given the small gains for client developers.

> > b) MOVE may be simpler for server authors. However, server authors
> > who cannot implement COPY are themselves at a disadvantage.
> MOVE is a basic command, and the fact that it wasn't included in  
> original
> specification with arguments that 'it cannot be atomic' it's just  
> dumb. The
> fact that specification author can't make it atomic in his own  
> server code is
> not an argument to me

You're getting very close to calling Mark dumb. I don't agree, but  
even if this were the case, this wouldn't invalidate Mark's arguments  
- which are *not* that his own implementation makes it difficult to  
implement, but that the majority of extent implementations make it  
difficult to implement with "IMAP-like" semantics.

> > c) It doesn't matter if MOVE is non-atomic, or introduces a new
> > irreversable removal of data from a mailbox. This sends shivers  
> up my
> > spine. This is surely not an extension critical enough to break  
> IMAP
> > semantics, is it?
> It does matter if MOVE is non-atomic. Move as any other command in  
> IMAP should
> be atomic. The fact that you and Crispin have problem with making  
> it atomic in
> Your servers is, well, your problem - you don't have to use it

Erm, my server? You're making some assumptions, there.


> About removal: read the draft (version 01) carefully. The possible  
> outcomes of
> MOVE command are:
> 1. MOVE is succesful, server sends untagged EXPUNGE responses and  
> then tagged
> OK,  mails are removed from a mailbox but they're still there - in  
> another
> mailbox. Client knows everything about internal state of currently  
> selected
> mailbox.
> 
> 2. (case of 'emulation' by copy+expunge, or more internally by  
> link+delete)
> MOVE command is unsuccesful, messages are duplicated in both  
> mailboxes, no
> EXPUNGE responses are sent, client knows everything about internal  
> state of
> currently selected mailbox (nothing has changed)
> 
> 3. MOVE command is totally unsuccesful, no messages are moved, no  
> EXPUNGE
> responses are sent, client knows...
> 
> 
Yes, I know you're attempting to cover all the issues, here, I just  
happen to be of the opinion that there are a lot of corner cases, and  
many of these you seem to be blissfully unaware of - for instance:

I note that in the case of success, you refer to messages in the  
UIDPLUS response code after they've already been expunged. A  
conformant client might struggle with that a bit, since it's already  
dropped the messages locally.

Perhaps this needs to say that COPYUID is sent as an untagged OK  
prior to any EXPUNGE being sent referring to any message in the set.

I'd imagine that for some implementations, this would lead to a  
sequence of COPYUID/EXPUNGE pairs, which is unfortunate, when it  
could have been a single COPYUID/VANISHED.

Also, the specification needs to ensure that it clearly marks the  
MOVE command as one that causes ambiguity as described in ?5.5 of  
RFC 3501 - in fact, the ambiguity is quite complex, here, because  
there are multiple failure cases.

Finally, your case 2 and 3 are perceived as identical by a client  
according to your draft. I'd suggest that an OK is made equivalent to  
a COPY's OK, and that the removal of source messages is indicated  
solely by the untagged EXPUNGEs - thought this would also be covered  
by my first comment.

And these are just the issues I've spotted now. I don't know how I  
can make this clearer - this is a very complex extension to design  
such that it'll work safely in all implementations.


> > d) If MOVE turns out to be hard in an existing, conformant
> > implementation, then the implementation is somehow broken.
> No, it means that this implementation wasn't written with MOVE in  
> mind from
> the beginning. Hence it's an -optional- -feature-, not an  
> obligation. And it's
> a feature that is already being implemented.
> 
> 
Right, fine, but your argument was that it's perfectly acceptable for  
a server to have broken or slow COPY.


> > Yes, I agree it's a good idea, too. But the barriers to it are  
> just
> > far, far too large to be worthwhile overcoming, given the scope of
> > the extension. An extension like this you really want to be
> > implementable *everywhere*, and this just doesn't feel right.
> "This extension is so great it should be EVERYWHERE, but I'll have  
> to spend
> lots of hours implementing it in my server, so it shouldn't be used  
> anywhere"
> - is that it? Can't you see the hypocrisy in that?

No, that's not what I said at all.

Let me spell this out for you:

a) The extension is, in principle, a good idea.

b) However, it's the kind of fundamental semantic that needs to be  
defined such that it is implementable in all existing implementations.

c) Ideally, this would result in a MOVE command (or facility of some  
form) which would become part of the de-facto core.

d) I don't do any work on M-Box, Isode's IMAP server, currently - I  
work on our XMPP server instead. If I did, I believe I could  
implement a MOVE command quite readily, conformant to your -01 draft.

e) I do, however, work on my own IMAP client, still. This client has  
facilities for moving messages, and is specifically designed to work  
on very large mailboxes over low-bandwidth, high-latency, links. I'm  
not dashing out to implement a MOVE command there, and I wouldn't  
unless it were extremely common on servers - otherwise it seems a  
very small gain for additional codepaths.

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

