The IMAP Move Extension
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|Replaced by||draft-ietf-imapmove-command, draft-ietf-imapmove-command, RFC 6851|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Network Working Group Arnt Gulbrandsen Internet-Draft March 2012 Intended Status: Proposed Standard The IMAP Move Extension draft-gulbrandsen-imap-move-00.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) 2009 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 December 2011. 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 command 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. The five characters [...] means that something has been elided. 2. Overview This document defines an IMAP extension to move messages atomically from one message 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 two 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. If MSN-based move is found to be needed (rather than neat), it can be defined by a future document. 2. 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 3. Interaction with other extensions This section is informational. There are no RFC2119 words in this document; it only points out how other documents interact with this. 3.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. 3.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. 3.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. 4. 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. (This sounds just wrong. COPY requires the same.) 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. Gulbrandsen Expires September 2012 [Page 3] Internet-draft March 2012 Fixme: Either unfuck this entire section or drop it. I would prefer to drop it. 3. 5. 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 6. 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. 7. IANA Considerations The IANA is requested to add MOVE to the list of IMAP extensions, http://www.iana.org/assignments/imap4-capabilities. 8. 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. 9. Normative References [RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. Gulbrandsen Expires September 2012 [Page 4] Internet-draft March 2012 [RFC3501] Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. 10. Author's Address Arnt Gulbrandsen Schweppermannstr. 8 D-81671 Muenchen Germany Fax: +49 89 4502 9758 Email: firstname.lastname@example.org 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 Gulbrandsen Expires September 2012 [Page 6]