idnits 2.17.1 draft-ietf-imapmove-command-05.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 (November 29, 2012) is 4159 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) == Missing Reference: 'UID' is mentioned on line 122, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4551 (Obsoleted by RFC 7162) ** Obsolete normative reference: RFC 5162 (Obsoleted by RFC 7162) -- Obsolete informational reference (is this intentional?): RFC 2087 (Obsoleted by RFC 9208) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Gulbrandsen 3 Internet-Draft 4 Intended status: Standards Track N. Freed 5 Expires: June 2, 2013 Oracle 6 November 29, 2012 8 Internet Message Access Protocol (IMAP) - MOVE Extension 9 draft-ietf-imapmove-command-05 11 Abstract 13 This document defines an IMAP extension consisting of two new 14 commands, MOVE and UID MOVE, that are used to move messages from one 15 mailbox to another. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 2, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 This document defines an IMAP [RFC3501] extension to facilitate 52 moving messages from one mailbox to another. This is accomplished by 53 defining a new MOVE command and extending the UID command to allow 54 UID MOVE. 56 A move function is not provided in the base IMAP specification, so 57 clients have instead had to use a combination of the COPY, STORE, and 58 EXPUNGE commands to perform this very common operation. 60 Implementors have long pointed out some shortcomings with this 61 approach. Because the moving of a message is not an atomic process, 62 interruptions can leave messages in intermediate states. Because 63 multiple clients can be accessing the mailboxes at the same time, 64 clients can see messages in intermediate states even without 65 interruptions. If the source mailbox contains other messages that 66 are flagged for deletion, the third step can have the side effect of 67 expunging more than just the set of moved messages. And servers with 68 certain types of back-end message stores might have efficient ways of 69 moving messages, which don't involve actual copying of data. Such 70 efficiencies are often not available to the COPY/STORE/EXPUNGE 71 process. 73 The MOVE extension is present in any IMAP4 implementation which 74 returns "MOVE" as one of the supported capabilities to the CAPABILITY 75 command. 77 2. Conventions Used in This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 Formal syntax is specified using ABNF [RFC5234]. 85 Example lines prefaced by "C:" are sent by the client and ones 86 prefaced by "S:" by the server. 88 3. MOVE and UID MOVE 89 3.1. MOVE Command 91 Arguments: sequence set 92 mailbox name 94 Responses: no specific responses for this command 96 Result: OK - move completed 98 NO - move error: can't move those messages or to that name 100 BAD - command unknown or arguments invalid 102 3.2. UID MOVE Command 104 This extends the first form of the UID command (see [RFC3501], 105 Section 6.4.8) to add the MOVE command, defined above, as a valid 106 argument. 108 3.3. Semantics of MOVE and UID MOVE 110 The MOVE command takes two arguments: a message set (sequence numbers 111 for MOVE, UIDs for UID MOVE) and a named mailbox. Each message 112 included in the set is moved, rather than copied, from the selected 113 (source) mailbox to the named (target) mailbox. 115 This means that a new message is created in the target mailbox, with 116 a new UID, the original message is removed from the source mailbox, 117 and it appears to the client as a single action. This has the same 118 effect for each message as this sequence: 120 1. [UID] COPY 122 2. [UID] STORE +FLAGS.SILENT \DELETED 124 3. UID EXPUNGE 126 Although the effect of the MOVE is the same as the preceding steps, 127 the semantics are not identical: The intermediate states produced by 128 those steps do not occur, and the response codes are different. In 129 particular, though the COPY and EXPUNGE response codes will be 130 returned, response codes for a STORE MUST NOT be generated and the 131 \DELETED flag MUST NOT be set for any message. 133 Because a MOVE applies to a set of messages, it might fail partway 134 through the set. Regardless of whether the command is successful in 135 moving the entire set, each individual message SHOULD either be moved 136 or unaffected. The server MUST leave each message in a state where 137 it is in at least one of the source or target mailboxes (no message 138 can be lost or orphaned). The server SHOULD NOT leave any message in 139 both mailboxes (it would be bad for a partial failure to result in a 140 bunch of duplicate messages). This is true even if the server 141 returns a tagged NO response to the command. 143 Because of the similarity of MOVE to COPY, extensions that affect 144 COPY affect MOVE in the same way. Response codes such TRYCREATE (see 145 [RFC3501] Section 6.4.7), as well as those defined by extensions, are 146 sent as appropriate. See Section 4 for more information about how 147 MOVE interacts with other IMAP extensions. 149 An example: 151 C: a UID MOVE 42:69 forble 152 S: * OK [COPYUID 432432 42:69 1202:1229] 153 S: * 22 EXPUNGE 154 S: (more expunges) 155 S: a OK Done 157 Note that the server may send unrelated EXPUNGE responses as well, if 158 any happen to have been expunged at the same time; this is normal 159 IMAP operation. 161 Implementers will need to read [RFC4315] to understand what UID 162 EXPUNGE does, though full implementation of [RFC4315] is not 163 necessary. 165 Note that moving a message to the currently selected mailbox (that 166 is, where the source and target mailboxes are the same) is allowed 167 when copying the message to the currently selected mailbox is 168 allowed. 170 The server may send EXPUNGE (or VANISHED) responses before the tagged 171 response, so the client cannot safely send more commands with message 172 sequence number arguments while the server is processing MOVE. The 173 UID MOVE command does not have this limitation. 175 Both MOVE and UID MOVE can be pipelined with other commands, but care 176 has to be taken. Both commands modify sequence numbers and also 177 allow unrelated EXPUNGE responses. The renumbering of other messages 178 in the source mailbox following any EXPUNGE response can be 179 surprising, and makes it unsafe to pipeline any command that relies 180 on message sequence numbers after a MOVE or UID MOVE. Similarly, 181 MOVE cannot be pipelined with a command that might cause message 182 renumbering. See [RFC3501], Section 5.5, for more information about 183 ambiguities as well as handling requirements for both clients and 184 servers. 186 4. Interaction with other extensions 188 This section describes how MOVE interacts with some other IMAP 189 extensions. 191 4.1. RFC 2087, QUOTA 193 The QUOTA extension (defined by [RFC2087]) may interact with MOVE, on 194 some servers, in the sense that a MOVE command may succeed where COPY 195 would cause a quota overrun. 197 4.2. RFC 4314, ACL 199 The ACL rights [RFC4314] required for UID MOVE are the union of the 200 ACL rights required for UID STORE, UID COPY and UID EXPUNGE. 202 4.3. RFC 4315, UIDPLUS 204 Servers supporting UIDPLUS [RFC4315] MUST send COPYUID in response to 205 a UID MOVE command. 207 Servers implementing UIDPLUS are also advised to send the COPYUID 208 response code in an untagged OK before sending EXPUNGE or moved 209 responses. (Sending COPYUID in the tagged OK, as described in the 210 UIDPLUS specification, means that clients first receive an EXPUNGE 211 for a message and afterwards COPYUID for the same message. It can be 212 unnecessarily difficult to process that sequence usefully.) 214 4.4. RFC 5162, QRESYNC 216 The QRESYNC extension [RFC5162] states that the server SHOULD send 217 VANISHED rather than EXPUNGE in response to the UID EXPUNGE command. 218 The same requirement applies to MOVE, and a QRESYNC-enabled client 219 needs to handle both VANISHED and EXPUNGE responses to a UID MOVE 220 command. 222 If the server is capable of storing modification sequences for the 223 selected mailbox, it MUST increment the per-mailbox mod-sequence if 224 at least one message was permanently moved due to the execution of 225 the MOVE/UID MOVE command. For each permanently removed message, the 226 server MUST remember the incremented mod-sequence and corresponding 227 UID. If at least one message was moved, the server MUST send the 228 updated per-mailbox modification sequence using the HIGHESTMODSEQ 229 response code (defined in [RFC4551]) in the tagged or untagged OK 230 response. 232 When a message is moved to a target mailbox, if the server is capable 233 of storing modification sequences for the mailbox, the server MUST 234 generate a new modification sequence that is higher than the highest 235 modification sequence of all messages in the mailbox and assign it to 236 the moved message. 238 4.5. IMAP Events in Sieve 240 MOVE applies to IMAP events in Sieve [RFC6785] in the same way as 241 COPY does. Therefore, MOVE can cause a Sieve script to be invoked 242 with the imap.cause set to "COPY". Because MOVE does not cause flags 243 to be changed, a MOVE command will not result in a script invocation 244 with the imap.cause set to "FLAG". 246 5. Formal Syntax 248 The following syntax specification uses the Augmented Backus-Naur 249 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 250 the non-terminals "capability", "command-select", "sequence-set" and 251 "mailbox". 253 Except as noted otherwise, all alphabetic characters are case- 254 insensitive. The use of upper or lower case characters to define 255 token strings is for editorial clarity only. Implementations MUST 256 accept these strings in a case-insensitive fashion. 258 capability =/ "MOVE" 260 command-select =/ move 261 move = "MOVE" SP sequence-set SP mailbox 262 uid = "UID" SP (copy / fetch / search / store / move) 264 6. Security Considerations 266 MOVE does not introduce any new capabilities to IMAP, and this limits 267 the security impact. However, the transactional semantics of MOVE 268 may interact with specific implementations in ways that could have 269 unexpected consequences. For example, moving messages between 270 mailboxes under the quota root may require temporary suspension of 271 quota checking. 273 An additional area of concern is interaction with antispam, 274 antivirus, and other security scanning and auditing mechanisms. 275 Different mailboxes may have different security policies which could 276 interact with MOVE in complex ways. Scanning with updated rules may 277 also be required when messages are moved even when the underlying 278 policy has not changed. 280 MOVE does relieve a problem with the base specification, since client 281 authors currently have to devise and implement complicated algorithms 282 to handle partial failures of the STORE/COPY/EXPUNGE trio. 283 Incomplete or improper implementation of these algorithms can lead to 284 mail loss. 286 7. IANA Considerations 288 The IANA is requested to add MOVE to the "IMAP 4 Capabilities" 289 registry, http://www.iana.org/assignments/imap4-capabilities. 291 8. Acknowledgments 293 An extension like this has been proposed many times, by many people. 294 This document is based on several of those, most recently that by 295 Witold Krecicki. Witold, Benoit Claise, Adrien W. de Croy, Stephen 296 Farrell, Bron Gondwana, Dan Karp, Christian Ketterer, Murray 297 Kucherawy, Jan Kundrat, Barry Leiba, Alexey Melnikov, Kathleen 298 Moriarty, Zoltan Ordogh, Pete Resnick, Timo Sirainen, Michael 299 Slusarz, and others provided valuable comments. 301 9. References 303 9.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 309 4rev1", RFC 3501, March 2003. 311 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 312 RFC 4314, December 2005. 314 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - 315 UIDPLUS extension", RFC 4315, December 2005. 317 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional 318 STORE Operation or Quick Flag Changes Resynchronization", 319 RFC 4551, June 2006. 321 [RFC5162] Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 322 Extensions for Quick Mailbox Resynchronization", RFC 5162, 323 March 2008. 325 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 326 Specifications: ABNF", STD 68, RFC 5234, January 2008. 328 9.2. Informative References 330 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 331 January 1997. 333 [RFC6785] Leiba, B., "Support for Internet Message Access Protocol 334 (IMAP) Events in Sieve", RFC 6785, November 2012. 336 Appendix A. Change History 338 RFC Editor: Please delete this section from the final RFC. 340 A.1. Changes since -00 342 1. Fixed two bad nouns. Mailboxes aren't messages. 344 2. Adrien's server can easily do UID MOVE but not so easily MSN- 345 based moves. 347 A.2. Changes since -01 349 1. Changed to Informative, on Barry's suggestion. Or did I ask him? 350 Whatever. 352 2. Removed the 'reasons to avoid', it was doubleplusungood. 354 A.3. Changes since draft-gulbrandsen-imap-move-02 356 1. Various wording changes from Barry's review. 358 2. Open issue: Delete the \deleted rule? 360 3. Back to PS, informative didn't fly in the IESG 362 4. Turned into a WG document in order to get write access to the 363 IMAP4 capabilities registry 365 5. Mention VANISHED in 5162 367 6. Added bad boilerplate to please idnits. This document contains 368 no code. 370 A.4. Changes since -00 372 1. Added MSN-based move. The consensus seems mildly in favor. I 373 think. We'll see once this is posted. 375 2. Advise sending COPYUID earlier, to help clients. Requiring out 376 of order processing is unnecessarily nasty. 378 3. Note that moving to the source inbox has to work. I think it 379 does have to work, but this is a draft, it says so on every page. 381 A.5. Changes since -01 383 1. (Issue tracker #1) Changed command-select ABNF to conform with 384 the conventions used in RFC 3501. 386 2. (Issue tracker #2) Banned overlapped pipelined MOVE and UID 387 MOVE. 389 3. (Issue tracker #3) Added section about interaction with IMAP 390 Sieve. 392 4. (Issue tracker #4) Revised security considerations. 394 5. (Issue tracker #5) Removed text that characterized MOVE as the 395 same as COPY/STORE/EXPUNGE. 397 6. (Issue tracker #6) RFC 4314 is now a normative reference. 399 7. (Issue tracker #7) Major rewrite of the command description text 400 as a result of AD review. 402 8. (Issue tracker #8) Revised abstract. 404 9. (Issue tracker #9) Added text saying partial failures are 405 allowed. 407 10. (Issue tracker #10) Some additional tweaks to the security 408 considerations section were made. 410 11. The abstract and introduction were out of whack as a result of 411 other changes, so some revisions were made to bring them back 412 into sync. 414 A.6. Changes since -02 416 1. Corrected various typos, clarified several paragraphs discussing 417 MOVE semantics. 419 2. Added the usual text about the extension only being available 420 when it is reported by the CAPABILITIES command. 422 3. Revised the text about QRESYNC to make clear what the 423 requirements are. 425 4. Removed a suggestion about MUA/user behavior from the discussion 426 of the QUOTA extension. 428 5. Updated the main and running title to conform to other IMAP RFCs. 430 A.7. Changes since -03 432 1. Corrected another bad noun. Responses aren't messages. 434 2. More minor editorial changes. 436 3. The text on command pipelining has been completely rewritten. 438 4. Added text stating that the effects of setting the \Deleted flag 439 aren't visible. 441 A.8. Changes since -04 443 1. Added some additional requirements text for QRESYNC. 445 2. Took some text from the charter and added it to the introduction 446 in order to clarify why this extension is useful. 448 Authors' Addresses 450 Arnt Gulbrandsen 451 Schweppermannstr. 8 452 D-81671 Muenchen 453 Germany 455 Fax: +49 89 4502 9758 456 Email: arnt@gulbrandsen.priv.no 457 Ned Freed (editor) 458 Oracle 459 800 Royal Oaks 460 Monrovia, CA 91016-6347 461 USA 463 Email: ned+ietf@mrochek.com