Internet DRAFT - draft-gulbrandsen-imap-move

draft-gulbrandsen-imap-move









Network Working Group                                   Arnt Gulbrandsen
Internet-Draft                                                March 2012
Intended Status: Proposed Standard


                        The IMAP Move Extension
                   draft-gulbrandsen-imap-move-01.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
   Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft expires in September 2012.











Gulbrandsen              Expires September 2012                 [Page 1]

Internet-draft                                                March 2012


Abstract

   The MOVE extension provides a new command, UID MOVE, which moves one
   or more messages from the selected mailbox to a named mailbox.


1. Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Formal syntax is defined by [RFC5234].

   Example lines prefaced by "C:" are sent by the client and ones
   prefaced by "S:" by the server.


2. Overview

   This document defines an IMAP extension to move messages atomically
   from one mailbox to another. This function (very common in MUA UIs)
   is not provided by stock IMAP, and clients have to use a combination
   of UID STORE, UID COPY and EXPUNGE, and cope with partial failures.

   Only UID MOVE is defined, not MOVE. There are three reasons for this.
   First, MOVE poses some difficult questions with regard to expunges.
   Second, in a survey of user agents that provide move in the user
   interface, all were seen to use UID commands anyway. Third, a server
   implementer reported that MSN-based move would be more difficult than
   UID MOVE.

   If MSN-based move is found to be needed (rather than neat), it can be
   defined by a future document.


3. UID MOVE

   The UID MOVE command takes two arguments: a set of UIDs and a named
   mailbox. It moves each message indicated by UID set to the named
   mailbox.

   The UID MOVE command is the same as a sequence of UID COPY, UID STORE
   +FLAGS \DELETED and UID EXPUNGE, with two added requirements:

   First, each message SHOULD either be moved or unaffected. The server
   SHOULD NOT leave a message in neither or both mailboxes afterwards
   (even if the server returns a tagged NO response).



Gulbrandsen              Expires September 2012                 [Page 2]

Internet-draft                                                March 2012


   Second, the messages MUST NOT have the \Deleted flag set in the
   target mailbox.

   An example:
        C: a UID MOVE 42:69 forble
        @S: a OK [COPYUID 432432 1202:1229] Done


4. Interaction with other extensions

   This section is informational. There are no requirements in this
   section; it only points out how other documents interact with this.


4.1. RFC 2087, QUOTA

   The QUOTA extension may interact with MOVE, on some servers, in the
   sense that a MOVE command may succeed where COPY would cause a quota
   overrun. This may be user-visible, but should not be MUA-visible.


4.2. RFC 2086, ACL

   Since UID MOVE is defined as equivalent to UID STORE, UID COPY and
   UID EXPUNGE, it requires the same ACL rights as the union of those
   three commands.


4.3. RFC 2359, UIDPLUS

   Since UID MOVE is defined by reference to UID COPY, the server may
   send COPYUID for UID MOVE, just as for UID COPY.


5. Reasons to avoid this extension

   Servers may want to avoid implementing this because atomicity
   requires holding one or more locks on several mailboxes at the same
   time. Maildir-based servers, in particular, might have problems
   locking sufficiently if the source and target mailboxes are on
   different file systems.

   Clients may want to avoid implementing this if they already have a
   complex fallback/restart algorithm, and want to have it used, so that
   any problems are easily visible.

   Fixme: Either unfuck this entire section or drop it. I would prefer
   to drop it.



Gulbrandsen              Expires September 2012                 [Page 3]

Internet-draft                                                March 2012


6. Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the
   non-terminals "capability" and "command".

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

       capability   =/ "MOVE"

       command   =/ "UID MOVE" SP set SP mailbox


7. Security Considerations

   This document is believed to add no security problems. It does
   however relieve a problem with the base specification, since client
   authors have to devise and implement complicated algorithms to handle
   partial failures of the STORE/COPY/EXPUNGE trio. Problems with these
   algorithms can lead to mail loss.


8. IANA Considerations

   The IANA is requested to add MOVE to the list of IMAP extensions,
   http://www.iana.org/assignments/imap4-capabilities.


9. Acknowledgements

   An extension like this has been proposed many times, by many people.
   This document is based on several of those, most recently that by
   Witold Krecicki. Witold, Alexey Melnikov, Bron Gondwana, Adrien W. de
   Croy and others provided valuable comments.


10. Normative References

   [RFC2119]  Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, Harvard University, March
              1997.

   [RFC3501]  Crispin, "Internet Message Access Protocol - Version
              4rev1", RFC 3501, University of Washington, June 2003.




Gulbrandsen              Expires September 2012                 [Page 4]

Internet-draft                                                March 2012


   [RFC5234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, January 2008.


11. Author's Address

   Arnt Gulbrandsen
   Schweppermannstr. 8
   D-81671 Muenchen
   Germany

   Fax: +49 89 4502 9758

   Email: arnt@gulbrandsen.priv.no





































Gulbrandsen              Expires September 2012                 [Page 5]

Internet-draft                                                March 2012


          (RFC Editor: Please delete everything after this point)


Open Issues

   Only those noted as "fixme" in the text.


Changes since -00

- Fixed two bad nouns. Mailboxes aren't messages.

- Adrien's server can easily do UID MOVE but not so easily MSN-based
   moves.


Changes since -01


































Gulbrandsen              Expires September 2012                 [Page 6]