MBOX-Line: From witold.krecicki at firma.o2.pl  Mon Jun 14 03:48:11 2010
To: imap-protocol@u.washington.edu
From: Witold =?utf-8?q?Kr=C4=99cicki?= <witold.krecicki@firma.o2.pl>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <29965.1276510437.099598@puncture>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006120124.53714.witold.krecicki@firma.o2.pl>
	<29965.1276510437.099598@puncture>
Message-ID: <201006141248.11054.witold.krecicki@firma.o2.pl>

On Monday 14 of June 2010 12:13:57 Dave Cridland wrote:
> This is amusing. Your argument appears to be that a sensible, common,
> implementation of a mandatory protocol feature is, somehow,
> undesirable.
> 
> Your overall argument also appears to be that:
> 
> 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.
 
> 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 
 
> 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
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...

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

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

-- 
Witold Kr?cicki

Grupa o2 Sp??ka z o.o., ul. Jutrzenki 177, 02-231 Warszawa,
KRS 0000140518, S?d Rejonowy dla m.st. Warszawy, 
Kapita? zak?adowy 377.298,00 z?., NIP 521-31-11-513

