The IMAP ENABLE Extension
RFC 5161
Document | Type |
RFC - Proposed Standard
(March 2008; No errata)
Was draft-gulbrandsen-imap-enable (individual in app area)
|
|
---|---|---|---|
Authors | Alexey Melnikov , Arnt Gulbrandsen | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5161 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Chris Newman | ||
Send notices to | (None) |
Network Working Group A. Gulbrandsen, Ed. Request for Comments: 5161 Oryx Mail Systems GmbH Category: Standards Track A. Melnikov, Ed. Isode Limited March 2008 The IMAP ENABLE 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. Abstract Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. 1. Overview Several IMAP extensions allow the server to return unsolicited responses specific to these extensions in certain circumstances. However, servers cannot send those unsolicited responses until they know that the clients support such extensions and thus won't choke on the extension response data. Up until now, extensions have typically stated that a server cannot send the unsolicited responses until after the client has used a command with the extension data (i.e., at that point the server knows the client is aware of the extension). CONDSTORE ([RFC4551]), ANNOTATE ([ANNOTATE]), and some extensions under consideration at the moment use various commands to enable server extensions. For example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE uses a side effect of FETCH. The ENABLE extension provides an explicit indication from the client that it supports particular extensions. This is done using a new ENABLE command. An IMAP server that supports ENABLE advertises this by including the word ENABLE in its capability list. Gulbrandsen & Melnikov Standards Track [Page 1] RFC 5161 The IMAP ENABLE Extension March 2008 Most IMAP extensions do not require the client to enable the extension in any way. 2. 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] and [RFC3501]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. The five characters [...] means that something has been elided. 3. Protocol Changes 3.1. The ENABLE Command Arguments: capability names Result: OK: Relevant capabilities enabled BAD: No arguments, or syntax error in an argument The ENABLE command takes a list of capability names, and requests the server to enable the named extensions. Once enabled using ENABLE, each extension remains active until the IMAP connection is closed. For each argument, the server does the following: - If the argument is not an extension known to the server, the server MUST ignore the argument. - If the argument is an extension known to the server, and it is not specifically permitted to be enabled using ENABLE, the server MUST ignore the argument. (Note that knowing about an extension doesn't necessarily imply supporting that extension.) - If the argument is an extension that is supported by the server and that needs to be enabled, the server MUST enable the extension for the duration of the connection. At present, this applies only to CONDSTORE ([RFC4551]). Note that once an extension is enabled, there is no way to disable it. If the ENABLE command is successful, the server MUST send an untagged ENABLED response (see Section 3.2). Gulbrandsen & Melnikov Standards Track [Page 2] RFC 5161 The IMAP ENABLE Extension March 2008 Clients SHOULD only include extensions that need to be enabled by the server. At the time of publication, CONDSTORE is the only such extension (i.e., ENABLE CONDSTORE is an additional "CONDSTORE enabling command" as defined in [RFC4551]). Future RFCs may add to this list. The ENABLE command is only valid in the authenticated state (see [RFC3501]), before any mailbox is selected. Clients MUST NOT issue ENABLE once they SELECT/EXAMINE a mailbox; however, server implementations don't have to check that no mailbox is selected or was previously selected during the duration of a connection. The ENABLE command can be issued multiple times in a session. It isShow full document text