Subject: [Extra] imap4rev2: RFC6851 MOVE

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 08 Nov 2018 06:25:33 -0500

This is one of the open issues from imap4rev2 - which extensions should be part of the mandatory baseline. 
 
In favour - it's quite useful, and has fairly wide server support (including Gmail and Exchange), and at least Thunderbird as a client uses it. 
 
Against - Oracle haven't implemented it. 
 
Arguments for and against in response to this please. 
 
Cheers, 
 Bron. 
 
-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [email-masked]

---

From: Stuart Brandt <[email-masked]>
Date: Thu, 8 Nov 2018 19:55:44 -0500

MOVE is a slam dunk in my view. Its support in clients is much broader 
than just Thunderbird.

- Stu

On 11/8/2018 6:25 AM, Bron Gondwana wrote:
> In favour - it's quite useful, and has fairly wide server support
> (including Gmail and Exchange), and at least Thunderbird as a client
> uses it.
>
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
>

---

From: Brandon Long <[email-masked]>
Date: Fri, 9 Nov 2018 11:06:56 -0800

Agreed, it was pretty trivial to implement for Gmail, though maybe it was
more trivial for us than for servers which keep folders more structurally
separate, ie I can imagine mbox based servers having more trouble making it
atomic, but I don't know how much they already have that problem.

I think for most GUI clients, move is the default action, having to make
two separate calls for that seems unnecessary, even if they can be
pipelined.

Brandon

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 09 Nov 2018 18:09:35 -0500

Honestly it's not 100% atomic in Cyrus, but it's pretty safe and it fails in the "as if it was the copy / store / expunge sequence". 
 
Bron
 
On Sat, 10 Nov 2018, at 06:07, Brandon Long wrote: 
> Agreed, it was pretty trivial to implement for Gmail, though maybe it was more trivial for us than for servers which keep folders more structurally separate, ie I can imagine mbox based servers having more trouble making it atomic, but I don't know how much they already have that problem. 
>  
> I think for most GUI clients, move is the default action, having to make two separate calls for that seems unnecessary, even if they can be pipelined. 
>  
> Brandon 
>  
> On Thu, Nov 8, 2018 at 4:57 PM Stuart Brandt <stujenerin=[email-masked]> wrote:

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 15 Nov 2018 14:52:26 +0100

Move had 10-15 implementations soon after being published as RFC, and 
judging by my inbox, people did not have problems implementing it. And: 
it was regularly requested before that time.

So... what are the 
criteria for inclusion, and how can something like move not pass the 
test?

Arnt

---

From: Michael Slusarz <[email-masked]>
Date: Thu, 15 Nov 2018 09:12:58 -0700 (MST)

> On November 15, 2018 at 6:52 AM Arnt Gulbrandsen <[email-masked]> wrote:
> 

Playing devil's advocate... what were the reason(s) this wasn't part of previous specs?

Was it simply due to the belief that we already have the necessary plumbing to do this (COPY/STORE/EXPUNGE), so MOVE was nothing more than a "shortcut", and shortcuts should be left out lest the base spec get too bloated?

(MOVE atomicity guarantees trump this logic, in my opinion. Seems many others share this view.)

michael

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Nov 2018 16:15:18 +0000

Hi Michael,

> Playing devil's advocate... what were the reason(s) this wasn't part of previous specs?
The short answer is a) Mark disliked MOVE and b) MOVE spec wasn't 
written yet.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 15 Nov 2018 22:41:45 +0100

> Playing devil's advocate... what were the reason(s) this wasn't 

Mark hated the idea. I don't think anyone understood why.

As I recall, there had been nine other substantially similar proposals 
before the one I wrote, most or all from actual implementers. Some weren't 
competently designed and written, but nine is an amazingly large number for 
this kind of thing. There was no lack of demand for MOVE, just Mark's 
resistance.

Arnt

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 15 Nov 2018 13:43:47 -0800

> this kind of thing. There was no lack of demand for MOVE, just Mark's

IIRC, Mark's resistance came from the "its a shortcut" idea that Michael
mentioned.

-Rob

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 15 Nov 2018 23:12:50 +0100

On Thursday 15 November 2018 22:43:47 CET, Rob Siemborski wrote:
> IIRC, Mark's resistance came from the "its a shortcut" idea 
> that Michael mentioned.

One of the people who proposed a MOVE argued that the command wasn't a 
shortcut in case of... at least three formats that were in use at the time. 
MH, djb's format and one more. I don't remember the details. But I do 
remember that Mark ignored that, and that I assumed that the shortcut 
argument was just a superficial rhetorical device, not a deeply held 
conviction.

I found his position very puzzling.

Arnt

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 21 Nov 2018 12:07:09 -0700 (MST)

> On November 8, 2018 at 4:25 AM Bron Gondwana <[email-masked]> wrote: 
> 

Dovecot team in favor of adding to imap4rev2.  Dovecot has support for MOVE already.

michael

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 23 Nov 2018 00:09:47 -0500

> I found his position very puzzling. 
 
My protocol philosophy is that the protocol should describe, as accurately as possible, the user's intention in a way that the server can then decide the best way to implement that intention - which is why I argued for move, because that's what the user is doing! 
 So yeah, I strongly support adding MOVE to the base protocol. Everyone seems to like it.
 
Bron.