imapext-2007
view docs/rfc/rfc5161.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line source
7 Network Working Group A. Gulbrandsen, Ed.
8 Request for Comments: 5161 Oryx Mail Systems GmbH
9 Category: Standards Track A. Melnikov, Ed.
10 Isode Limited
11 March 2008
14 The IMAP ENABLE Extension
16 Status of This Memo
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
24 Abstract
26 Most IMAP extensions are used by the client when it wants to and the
27 server supports it. However, a few extensions require the server to
28 know whether a client supports that extension. The ENABLE extension
29 allows an IMAP client to say which extensions it supports.
31 1. Overview
33 Several IMAP extensions allow the server to return unsolicited
34 responses specific to these extensions in certain circumstances.
35 However, servers cannot send those unsolicited responses until they
36 know that the clients support such extensions and thus won't choke on
37 the extension response data.
39 Up until now, extensions have typically stated that a server cannot
40 send the unsolicited responses until after the client has used a
41 command with the extension data (i.e., at that point the server knows
42 the client is aware of the extension). CONDSTORE ([RFC4551]),
43 ANNOTATE ([ANNOTATE]), and some extensions under consideration at the
44 moment use various commands to enable server extensions. For
45 example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE
46 uses a side effect of FETCH.
48 The ENABLE extension provides an explicit indication from the client
49 that it supports particular extensions. This is done using a new
50 ENABLE command.
52 An IMAP server that supports ENABLE advertises this by including the
53 word ENABLE in its capability list.
58 Gulbrandsen & Melnikov Standards Track [Page 1]
60 RFC 5161 The IMAP ENABLE Extension March 2008
63 Most IMAP extensions do not require the client to enable the
64 extension in any way.
66 2. Conventions Used in This Document
68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
70 document are to be interpreted as described in [RFC2119].
72 Formal syntax is defined by [RFC5234] and [RFC3501].
74 Example lines prefaced by "C:" are sent by the client and ones
75 prefaced by "S:" by the server. The five characters [...] means that
76 something has been elided.
78 3. Protocol Changes
80 3.1. The ENABLE Command
82 Arguments: capability names
84 Result: OK: Relevant capabilities enabled
85 BAD: No arguments, or syntax error in an argument
87 The ENABLE command takes a list of capability names, and requests the
88 server to enable the named extensions. Once enabled using ENABLE,
89 each extension remains active until the IMAP connection is closed.
90 For each argument, the server does the following:
92 - If the argument is not an extension known to the server, the server
93 MUST ignore the argument.
95 - If the argument is an extension known to the server, and it is not
96 specifically permitted to be enabled using ENABLE, the server MUST
97 ignore the argument. (Note that knowing about an extension doesn't
98 necessarily imply supporting that extension.)
100 - If the argument is an extension that is supported by the server and
101 that needs to be enabled, the server MUST enable the extension for
102 the duration of the connection. At present, this applies only to
103 CONDSTORE ([RFC4551]). Note that once an extension is enabled,
104 there is no way to disable it.
106 If the ENABLE command is successful, the server MUST send an untagged
107 ENABLED response (see Section 3.2).
114 Gulbrandsen & Melnikov Standards Track [Page 2]
116 RFC 5161 The IMAP ENABLE Extension March 2008
119 Clients SHOULD only include extensions that need to be enabled by the
120 server. At the time of publication, CONDSTORE is the only such
121 extension (i.e., ENABLE CONDSTORE is an additional "CONDSTORE
122 enabling command" as defined in [RFC4551]). Future RFCs may add to
123 this list.
125 The ENABLE command is only valid in the authenticated state (see
126 [RFC3501]), before any mailbox is selected. Clients MUST NOT issue
127 ENABLE once they SELECT/EXAMINE a mailbox; however, server
128 implementations don't have to check that no mailbox is selected or
129 was previously selected during the duration of a connection.
131 The ENABLE command can be issued multiple times in a session. It is
132 additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
133 single command "ENABLE a b c". When multiple ENABLE commands are
134 issued, each corresponding ENABLED response SHOULD only contain
135 extensions enabled by the corresponding ENABLE command.
137 There are no limitations on pipelining ENABLE. For example, it is
138 possible to send ENABLE and then immediately SELECT, or a LOGIN
139 immediately followed by ENABLE.
141 The server MUST NOT change the CAPABILITY list as a result of
142 executing ENABLE; i.e., a CAPABILITY command issued right after an
143 ENABLE command MUST list the same capabilities as a CAPABILITY
144 command issued before the ENABLE command. This is demonstrated in
145 the following example:
147 C: t1 CAPABILITY
148 S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
149 S: t1 OK foo
150 C: t2 ENABLE CONDSTORE X-GOOD-IDEA
151 S: * ENABLED X-GOOD-IDEA
152 S: t2 OK foo
153 C: t3 CAPABILITY
154 S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
155 S: t3 OK foo again
157 In the following example, the client enables CONDSTORE:
159 C: a1 ENABLE CONDSTORE
160 S: * ENABLED CONDSTORE
161 S: a1 OK Conditional Store enabled
170 Gulbrandsen & Melnikov Standards Track [Page 3]
172 RFC 5161 The IMAP ENABLE Extension March 2008
175 3.2. The ENABLED Response
177 Contents: capability listing
179 The ENABLED response occurs as a result of an ENABLE command. The
180 capability listing contains a space-separated listing of capability
181 names that the server supports and that were successfully enabled.
182 The ENABLED response may contain no capabilities, which means that no
183 extensions listed by the client were successfully enabled.
185 3.3. Note to Designers of Extensions That May Use the ENABLE Command
187 Designers of IMAP extensions are discouraged from creating extensions
188 that require ENABLE unless there is no good alternative design.
189 Specifically, extensions that cause potentially incompatible behavior
190 changes to deployed server responses (and thus benefit from ENABLE)
191 have a higher complexity cost than extensions that do not.
193 4. Formal Syntax
195 The following syntax specification uses the Augmented Backus-Naur
196 Form (ABNF) notation as specified in [RFC5234] including the core
197 rules in Appendix B.1. [RFC3501] defines the non-terminals
198 "capability" and "command-any".
200 Except as noted otherwise, all alphabetic characters are
201 case-insensitive. The use of upper or lower case characters to
202 define token strings is for editorial clarity only. Implementations
203 MUST accept these strings in a case-insensitive fashion.
205 capability =/ "ENABLE"
207 command-any =/ "ENABLE" 1*(SP capability)
209 response-data =/ "*" SP enable-data CRLF
211 enable-data = "ENABLED" *(SP capability)
213 5. Security Considerations
215 It is believed that this extension doesn't add any security
216 considerations that are not already present in the base IMAP protocol
217 [RFC3501].
219 6. IANA Considerations
221 The IANA has added ENABLE to the IMAP4 Capabilities Registry.
226 Gulbrandsen & Melnikov Standards Track [Page 4]
228 RFC 5161 The IMAP ENABLE Extension March 2008
231 7. Acknowledgments
233 The editors would like to thank Randy Gellens, Chris Newman, Peter
234 Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus
235 Daboo, Ken Murchison, and Eric Burger for comments and corrections.
236 However, this doesn't necessarily mean that they endorse this
237 extension, agree with all details, or are responsible for errors
238 introduced by the editors.
240 8. Normative References
242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
243 Requirement Levels", BCP 14, RFC 2119, March 1997.
245 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
246 4rev1", RFC 3501, March 2003.
248 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
249 Syntax Specifications: ABNF", STD 68, RFC 5234, January
250 2008.
252 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
253 STORE Operation or Quick Flag Changes Resynchronization",
254 RFC 4551, June 2006.
256 9. Informative References
258 [ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
259 in Progress, August 2006.
282 Gulbrandsen & Melnikov Standards Track [Page 5]
284 RFC 5161 The IMAP ENABLE Extension March 2008
287 Editors' Addresses
289 Arnt Gulbrandsen
290 Oryx Mail Systems GmbH
291 Schweppermannstr. 8
292 D-81671 Muenchen
293 Germany
295 Fax: +49 89 4502 9758
296 EMail: arnt@oryx.com
299 Alexey Melnikov
300 Isode Ltd
301 5 Castle Business Village
302 36 Station Road
303 Hampton, Middlesex TW12 2BX
304 UK
306 EMail: Alexey.Melnikov@isode.com
338 Gulbrandsen & Melnikov Standards Track [Page 6]
340 RFC 5161 The IMAP ENABLE Extension March 2008
343 Full Copyright Statement
345 Copyright (C) The IETF Trust (2008).
347 This document is subject to the rights, licenses and restrictions
348 contained in BCP 78, and except as set forth therein, the authors
349 retain all their rights.
351 This document and the information contained herein are provided on an
352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
359 Intellectual Property
361 The IETF takes no position regarding the validity or scope of any
362 Intellectual Property Rights or other rights that might be claimed to
363 pertain to the implementation or use of the technology described in
364 this document or the extent to which any license under such rights
365 might or might not be available; nor does it represent that it has
366 made any independent effort to identify any such rights. Information
367 on the procedures with respect to rights in RFC documents can be
368 found in BCP 78 and BCP 79.
370 Copies of IPR disclosures made to the IETF Secretariat and any
371 assurances of licenses to be made available, or the result of an
372 attempt made to obtain a general license or permission for the use of
373 such proprietary rights by implementers or users of this
374 specification can be obtained from the IETF on-line IPR repository at
375 http://www.ietf.org/ipr.
377 The IETF invites any interested party to bring to its attention any
378 copyrights, patents or patent applications, or other proprietary
379 rights that may cover technology that may be required to implement
380 this standard. Please address the information to the IETF at
381 ietf-ipr@ietf.org.
394 Gulbrandsen & Melnikov Standards Track [Page 7]