MBOX-Line: From dave at cridland.net  Fri Jun 11 01:59:31 2010
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:43 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <201006110854.37969.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
Message-ID: <23852.1276246771.199346@puncture>

On Fri Jun 11 07:54:37 2010, Witold Kr?cicki wrote:
> Hello
> I've wrote a draft of a draft of an IMAP protocol extension  
> providing one
> basic (at least to me) feature that is missing. I've searched  
> (roughly)
> through discussions on this mailing list and haven't seen any  
> mentioning or
> proposal of 'move' functionality.

I'm pretty sure it's come up before.

Depending on your server design, this is either very easy, or else  
very hard - of course, since it's optional, it'd seem likely that  
where it's hard it'd not be supported.

One thing that concerns me is that there is no way to undo this  
operation - traditionally, only EXPUNGE and DELETE have been  
irrevocable actions in IMAP, this adds one more.

The way to combat this is to make it merely mark \Deleted the  
original message - except then this eradicates any benefit to the  
command at all for clients. (Since one could either do MOVE/UID  
EXPUNGE, or else COPY+STORE/UID EXPUNGE).

And there has to be very significant advantage for clients, across a  
wide deployment, for most clients to bother implementing it - right  
now, I don't see 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

