idnits 2.17.1 draft-krecicki-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 11, 2010) is 5066 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 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Krecicki 3 Internet-Draft Webstorage 4 Intended status: Standards Track June 11, 2010 5 Expires: December 13, 2010 7 Internet Message Access Protocol (IMAP) - MOVE extension 8 draft-krecicki-imap-move-01.txt 10 Abstract 12 The MOVE extension of the Internet Message Access Protocol [IMAP4] 13 provides a feature intended to reduce the amount of time and 14 resources used by usual complicated methods of moving messages 15 between mailboxes by providing the capability of directly moving 16 messages. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 13, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Conventions Used in this Document 52 In examples, "C:" and "S:" indicate lines sent by the client and 53 server respectively. 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 57 be interpreted as described in [KEYWORDS]. 59 2. Introduction and Overview 61 Most of IMAP clients are moving messages between mailboxes by use of 62 sequence of COPY, STORE +FLAGS (\Deleted) and EXPUNGE commands. 63 This, though functionally equivalent to moving messages, is a lot 64 more complicated on the server side than simple move. When moving 65 large amounts of messages this can create unnecessary loads and 66 delays on server side. It also prohibits user from moving a message 67 which is larger than the remnant of his quota 69 The MOVE extension allows simple single-command moving of messages 70 between mailboxes without creating additional unnecessary server-side 71 loads and without requiring user consideration about his quota limits 72 when simply moving message and not changing the overall amount of 73 data stored in his account. MOVE command can be implemented as an 74 atomic operation which is impossible with three-commands sequence 75 currently used. 77 The MOVE extension is present in any IMAP server implementation which 78 returns "MOVE" as one of the supported capabilities to the CAPABILITY 79 command. 81 The MOVE extension defines one additional command which MUST be 82 supported by server that returns supports MOVE extension. 84 3. Additional commands 86 The following command definition is an extension to [IMAP4] section 87 6.4. 89 3.1. MOVE command 90 Arguments: sequence set 91 mailbox name 93 Data: untagged responses: EXPUNGE 95 Result: OK - move completed 96 NO - move error: can't move those messages or to that 97 mailbox 98 BAD - command unknown or arguments invalid 100 The MOVE command moves messages from the currently selected mailbox 101 to the end of the specified mailbox. Messages that are moved are 102 expunged from selected mailbox. Any messages that are not included 103 in the sequence set or do not exists are unaffected. All flags 104 (including \Deleted) and message internal date are persistent through 105 move. 107 If the server does not support the MOVE capability, the client should 108 fall back to using the regular COPY, STORE, EXPUNGE sequence. 110 Additionally if MOVE command can be directly preceeded by UID 111 command, the sequence set argument is then treated as unique 112 identifiers sequence instead of message sequence numbers as defined 113 in [IMAP4] paragraph 6.4.8. 115 Command EXPUNGE untagged responses reports that the specified message 116 sequence number has been permanently removed from selected mailbox 117 (and moved to specified mailbox) as defined in [IMAP4] paragraph 118 7.4.1. 120 The MOVE command SHOULD be atomic and server SHOULD keep both 121 mailboxes in consistent state at all times, at no time SHOULD the 122 moved messages be visible by any concurrent session in both source 123 and destination mailboxes or in none of these mailboxes. The server 124 MUST assure that after succesful operation all the moved messages are 125 in the destination mailbox and no moved messages are in the source 126 mailbox. The server SHOULD assure that after unsuccesful operation 127 no messages are moved to the destination folder and all messages 128 remain in source folder. In case of unsuccesful operation the server 129 MUST assure that no messages that were being moved are expunged from 130 source mailbox without being moved to destination mailbox. 132 Example: C: A003 MOVE 3000:3002 Trash 133 S: * 3002 EXPUNGE 134 S: * 3001 EXPUNGE 135 S: * 3000 EXPUNGE 136 S: A003 OK MOVE completed 137 C: A004 UID MOVE 4000:* Trash 138 S: * 3010 EXPUNGE 139 S: * 3009 EXPUNGE 140 S: * 3008 EXPUNGE 141 S: A004 OK MOVE completed 143 4. Response Codes 145 If the server supports both the UIDPLUS and MOVE extensions it SHOULD 146 return COPYUID response code as a part of tagged OK response to a 147 MOVE command, as defined in [UIDPLUS] paragraph 4.3. 149 5. Formal Syntax 151 Formal syntax is defined using ABNF [ABNF], extending the ABNF rules 152 defined in [IMAP4]. The IMAP4 ABNF should be imported first before 153 attempting to validate these rules. 155 capability =/ "MOVE" 157 command-select =/ move 159 move = "MOVE" SP sequence-set SP mailbox 161 uid =/ "UID" SP move 163 6. IANA Considerations 165 This document constitutes registration of the MOVE capability in the 166 imap4-capabilities. 168 7. References 170 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 171 Specifications: ABNF", RFC 2234, November 1997. 173 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 174 4rev1", RFC 3501, March 2003. 176 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 177 UIDPLUS extension", RFC 4315, December 2005. 179 [KEYWORDS] 180 Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, March 1997. 183 Author's Address 185 Witold Krecicki 186 Webstorage sp. z o.o. 187 Jutrzenki 177 188 Warszawa 02-231 189 Poland 191 Email: witold.krecicki@firma.o2.pl