Network Working Group Arnt Gulbrandsen
Internet-Draft July 2012
Intended Status: Standards Track
The IMAP Move Extension
draft-ietf-imapmove-command-01.txt
Status of this Memo
This Internet-Draft is submitted 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 January 2013.
Gulbrandsen Expires December 2012 [Page 1]
Internet-draft July 2012
Abstract
The MOVE extension provides commands to move 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 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 and side
effects.
3. MOVE and UID MOVE
The UID MOVE command takes two arguments: a set of UIDs and a named
mailbox. The MOVE command takes a set of MSNs and a named mailbox.
Both commands move each message included in the set to the named
mailbox.
The UID MOVE command has the same effect as a sequence of UID COPY,
UID STORE +FLAGS.SILENT \DELETED and UID EXPUNGE, with the added
requirement that 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).
UID MOVE is the same as the three-command sequence in all other
respects, which implies that extensions which affect the three-
command sequence also affect UID MOVE, and that response codes such
as COPYUID, TRYCREATE and so on should be sent as appropriate.
Gulbrandsen Expires December 2012 [Page 2]
Internet-draft July 2012
An example:
C: a UID MOVE 42:69 forble
S: * OK [COPYUID 432432 42:69 1202:1229]
S: * 22 EXPUNGE
S: (more expunges)
S: a OK Done
Note that the server may send EXPUNGEs for other messages as well, if
any happen to have been expunged at the same time.
Implementers will need to read [RFC4315] to understand what UID
EXPUNGE does. Implementing [RFC4315] is not necessary.
Note that moving messages to the current mailbox is well-defined, so
that MOVE is defined for all the cases where the COPY/STORE/EXPUNGE
sequence is.
The MOVE command performs the same actions UID MOVE. Notably, the
server may send EXPUNGE (or VANISHED) messages before the tagged
response, so the client cannot safely send more commands with MSN
arguments while the server is processing MOVE.
4. Interaction with other extensions
This section points out how other IMAP extensions interact with this.
4.1. RFC 2087, QUOTA
The QUOTA extension (defined by [RFC2087]) 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 4314, 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 4315, UIDPLUS
Since UID MOVE is defined by reference to UID COPY, the server has to
send COPYUID for UID MOVE.
Gulbrandsen Expires December 2012 [Page 3]
Internet-draft July 2012
Servers authors who implement UIDPLUS are advised to send the COPYUID
response code in an untagged OK before sending EXPUNGE for moved
messages. (Sending it in the tagged OK, as described in the UIDPLUS
specification, means that clients first receive an EXPUNGE for a
message and afterwards COPYUID for the same message. It can be
unnecessarily difficult to process that usefully.)
4.3. RFC 5162, QRESYNC
The QRESYNC extension defined by [RFC5162] directs the server to send
VANISHED rather than EXPUNGE for the UID EXPUNGE command. Since UID
MOVE is defined by by reference to UID EXPUNGE, UID MOVE is also
affected.
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", "command", "set" and "mailbox".
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-select =/ ["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 "IMAP 4 Capabilities"
registry, http://www.iana.org/assignments/imap4-capabilities.
Gulbrandsen Expires December 2012 [Page 4]
Internet-draft July 2012
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. Witold, Alexey Melnikov, Bron Gondwana, Adrien W. de
Croy, Barry Leiba and others provided valuable comments.
9. 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.
[RFC4315] Crispin, "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, University of Washington,
December 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
10. Informative References
[RFC2087] Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997.
[RFC4315] Melnikov, "IMAP4 Access Control List (ACL) Extension", RFC
4314, December 2005.
[RFC5162] Melnikov, "IMAP4 Extensions for Quick Mailbox
Resynchronization", RFC 5162, Isode Ltd, March 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 December 2012 [Page 5]
Internet-draft July 2012
(RFC Editor: Please delete everything after this point)
RFC Editor: If this document contains no code components when you
receive it, then please remove the sentence which starts with "code
components". Thank you.
Open Issues
Add 3501-like requirements/results paragraphs.
Add text about the desirability of command atomicity.
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
- Changed to Informative, on Barry's suggestion. Or did I ask him?
Whatever.
- Removed the 'reasons to avoid', it was doubleplusungood.
Changes since draft-gulbrandsen-imap-move-02
- Various wording changes from Barry's review.
- Open issue: Delete the \deleted rule?
- Back to PS, informative didn't fly in the IESG
- Turned into a WG document in order to get write access to the IMAP4
capabilities registry
- Mention VANISHED in 5162
- Added bad boilerplate to please idnits. This document contains no
code.
Gulbrandsen Expires December 2012 [Page 6]
Internet-draft July 2012
Changes since -00
- Added MSN-based move. The consensus seems mildly in favour. I think.
We'll see once this is posted.
- Advise sending COPYUID earlier, to help clients. Requiring out of
order processing is unnecessarily nasty.
- Note that moving to the source inbox has to work. I think it does
have to work, but this is a draft, it says so on every page.
Gulbrandsen Expires December 2012 [Page 7]