Internet Message Access Protocol (IMAP) - UIDPLUS extension
RFC 4315
Document | Type |
RFC - Proposed Standard
(December 2005; No errata)
Obsoletes RFC 2359
Was draft-crispin-imap-rfc2359bis (individual in app area)
|
|
---|---|---|---|
Author | Mark Crispin | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4315 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Scott Hollenbeck | ||
Send notices to | (None) |
Network Working Group M. Crispin Request for Comments: 4315 December 2005 Obsoletes: 2359 Category: Standards Track Internet Message Access Protocol (IMAP) - UIDPLUS extension Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. 1. Introduction and Overview The UIDPLUS extension is present in any IMAP server implementation that returns "UIDPLUS" as one of the supported capabilities to the CAPABILITY command. The UIDPLUS extension defines an additional command. In addition, this document recommends new status response codes in IMAP that SHOULD be returned by all server implementations, regardless of whether or not the UIDPLUS extension is implemented. The added facilities of the features in UIDPLUS are optimizations; clients can provide equivalent functionality, albeit less efficiently, by using facilities in the base protocol. 1.1. Conventions Used in This Document In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. Crispin Standards Track [Page 1] RFC 4315 IMAP - UIDPLUS Extension December 2005 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. A "UID set" is similar to the [IMAP] sequence set; however, the "*" value for a sequence number is not permitted. 2. Additional Commands The following command definition is an extension to [IMAP] section 6.4. 2.1. UID EXPUNGE Command Arguments: sequence set Data: untagged responses: EXPUNGE Result: OK - expunge completed NO - expunge failure (e.g., permission denied) BAD - command unknown or arguments invalid The UID EXPUNGE command permanently removes all messages that both have the \Deleted flag set and have a UID that is included in the specified sequence set from the currently selected mailbox. If a message either does not have the \Deleted flag set or has a UID that is not included in the specified sequence set, it is not affected. This command is particularly useful for disconnected use clients. By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the server, the client can ensure that it does not inadvertantly remove any messages that have been marked as \Deleted by other clients between the time that the client was last connected and the time the client resynchronizes. If the server does not support the UIDPLUS capability, the client should fall back to using the STORE command to temporarily remove the \Deleted flag from messages it does not want to remove, then issuing the EXPUNGE command. Finally, the client should use the STORE command to restore the \Deleted flag on the messages in which it was temporarily removed. Alternatively, the client may fall back to using just the EXPUNGE command, risking the unintended removal of some messages. Crispin Standards Track [Page 2] RFC 4315 IMAP - UIDPLUS Extension December 2005 Example: C: A003 UID EXPUNGE 3000:3002 S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: A003 OK UID EXPUNGE completed 3. Additional Response Codes The following response codes are extensions to the response codes defined in [IMAP] section 7.1. With limited exceptions, discussed below, server implementations that advertise the UIDPLUS extension SHOULD return these response codes. In the case of a mailbox that has permissions set so that the client can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the server SHOULD NOT send an APPENDUID or COPYUID response code as it would disclose information about the mailbox. In the case of a mailbox that has UIDNOTSTICKY status (as defined below), the server MAY omit the APPENDUID or COPYUID response code as it is not meaningful. If the server does not return the APPENDUID or COPYUID responseShow full document text