idnits 2.17.1 draft-gulbrandsen-imap-move-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2012) is 4417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Arnt Gulbrandsen 3 Internet-Draft March 2012 4 Intended Status: Proposed Standard 6 The IMAP Move Extension 7 draft-gulbrandsen-imap-move-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Copyright (c) 2012 IETF Trust and the persons identified as the 15 document authors. All rights reserved. 17 This document is subject to BCP 78 and the IETF Trust's Legal 18 Provisions Relating to IETF Documents 19 (http://trustee.ietf.org/license-info) in effect on the date of 20 publication of this document. Please review these documents 21 carefully, as they describe your rights and restrictions with respect 22 to this document. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 36 Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft expires in September 2012. 41 Abstract 43 The MOVE extension provides a new command, UID MOVE, which moves one 44 or more messages from the selected mailbox to a named mailbox. 46 1. Conventions Used in This Document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in [RFC2119]. 52 Formal syntax is defined by [RFC5234]. 54 Example lines prefaced by "C:" are sent by the client and ones 55 prefaced by "S:" by the server. 57 2. Overview 59 This document defines an IMAP extension to move messages atomically 60 from one mailbox to another. This function (very common in MUA UIs) 61 is not provided by stock IMAP, and clients have to use a combination 62 of UID STORE, UID COPY and EXPUNGE, and cope with partial failures. 64 Only UID MOVE is defined, not MOVE. There are three reasons for this. 65 First, MOVE poses some difficult questions with regard to expunges. 66 Second, in a survey of user agents that provide move in the user 67 interface, all were seen to use UID commands anyway. Third, a server 68 implementer reported that MSN-based move would be more difficult than 69 UID MOVE. 71 If MSN-based move is found to be needed (rather than neat), it can be 72 defined by a future document. 74 3. UID MOVE 76 The UID MOVE command takes two arguments: a set of UIDs and a named 77 mailbox. It moves each message indicated by UID set to the named 78 mailbox. 80 The UID MOVE command is the same as a sequence of UID COPY, UID STORE 81 +FLAGS \DELETED and UID EXPUNGE, with two added requirements: 83 First, each message SHOULD either be moved or unaffected. The server 84 SHOULD NOT leave a message in neither or both mailboxes afterwards 85 (even if the server returns a tagged NO response). 87 Second, the messages MUST NOT have the \Deleted flag set in the 88 target mailbox. 90 An example: 91 C: a UID MOVE 42:69 forble 92 @S: a OK [COPYUID 432432 1202:1229] Done 94 4. Interaction with other extensions 96 This section is informational. There are no requirements in this 97 section; it only points out how other documents interact with this. 99 4.1. RFC 2087, QUOTA 101 The QUOTA extension may interact with MOVE, on some servers, in the 102 sense that a MOVE command may succeed where COPY would cause a quota 103 overrun. This may be user-visible, but should not be MUA-visible. 105 4.2. RFC 2086, ACL 107 Since UID MOVE is defined as equivalent to UID STORE, UID COPY and 108 UID EXPUNGE, it requires the same ACL rights as the union of those 109 three commands. 111 4.3. RFC 2359, UIDPLUS 113 Since UID MOVE is defined by reference to UID COPY, the server may 114 send COPYUID for UID MOVE, just as for UID COPY. 116 5. Reasons to avoid this extension 118 Servers may want to avoid implementing this because atomicity 119 requires holding one or more locks on several mailboxes at the same 120 time. Maildir-based servers, in particular, might have problems 121 locking sufficiently if the source and target mailboxes are on 122 different file systems. 124 Clients may want to avoid implementing this if they already have a 125 complex fallback/restart algorithm, and want to have it used, so that 126 any problems are easily visible. 128 Fixme: Either unfuck this entire section or drop it. I would prefer 129 to drop it. 131 6. Formal Syntax 133 The following syntax specification uses the Augmented Backus-Naur 134 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the 135 non-terminals "capability" and "command". 137 Except as noted otherwise, all alphabetic characters are case- 138 insensitive. The use of upper or lower case characters to define 139 token strings is for editorial clarity only. Implementations MUST 140 accept these strings in a case-insensitive fashion. 142 capability =/ "MOVE" 144 command =/ "UID MOVE" SP set SP mailbox 146 7. Security Considerations 148 This document is believed to add no security problems. It does 149 however relieve a problem with the base specification, since client 150 authors have to devise and implement complicated algorithms to handle 151 partial failures of the STORE/COPY/EXPUNGE trio. Problems with these 152 algorithms can lead to mail loss. 154 8. IANA Considerations 156 The IANA is requested to add MOVE to the list of IMAP extensions, 157 http://www.iana.org/assignments/imap4-capabilities. 159 9. Acknowledgements 161 An extension like this has been proposed many times, by many people. 162 This document is based on several of those, most recently that by 163 Witold Krecicki. Witold, Alexey Melnikov, Bron Gondwana, Adrien W. de 164 Croy and others provided valuable comments. 166 10. Normative References 168 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 169 Requirement Levels", RFC 2119, Harvard University, March 170 1997. 172 [RFC3501] Crispin, "Internet Message Access Protocol - Version 173 4rev1", RFC 3501, University of Washington, June 2003. 175 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 176 Specifications: ABNF", RFC 5234, January 2008. 178 11. Author's Address 180 Arnt Gulbrandsen 181 Schweppermannstr. 8 182 D-81671 Muenchen 183 Germany 185 Fax: +49 89 4502 9758 187 Email: arnt@gulbrandsen.priv.no 188 (RFC Editor: Please delete everything after this point) 190 Open Issues 192 Only those noted as "fixme" in the text. 194 Changes since -00 196 - Fixed two bad nouns. Mailboxes aren't messages. 198 - Adrien's server can easily do UID MOVE but not so easily MSN-based 199 moves. 201 Changes since -01