1 ../imapserver/server.go:135
2
3
4
5
6
7Network Working Group A. Gulbrandsen, Ed.
8Request for Comments: 5161 Oryx Mail Systems GmbH
9Category: Standards Track A. Melnikov, Ed.
10 Isode Limited
11 March 2008
12
13
14 The IMAP ENABLE Extension
15
16Status of This Memo
17
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.
23
24Abstract
25
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.
30
311. Overview
32
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.
38
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.
47
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.
51
52 An IMAP server that supports ENABLE advertises this by including the
53 word ENABLE in its capability list.
54
55
56
57
58Gulbrandsen & Melnikov Standards Track [Page 1]
59
60RFC 5161 The IMAP ENABLE Extension March 2008
61
62
63 Most IMAP extensions do not require the client to enable the
64 extension in any way.
65
662. Conventions Used in This Document
67
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].
71
72 Formal syntax is defined by [RFC5234] and [RFC3501].
73
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.
77
783. Protocol Changes
79
803.1. The ENABLE Command 9051:1652 ../imapserver/server.go:1856
81
82 Arguments: capability names
83
84 Result: OK: Relevant capabilities enabled
85 BAD: No arguments, or syntax error in an argument
86
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:
91
92 - If the argument is not an extension known to the server, the server
93 MUST ignore the argument.
94
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.)
99
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.
105
106 If the ENABLE command is successful, the server MUST send an untagged
107 ENABLED response (see Section 3.2).
108
109
110
111
112
113
114Gulbrandsen & Melnikov Standards Track [Page 2]
115
116RFC 5161 The IMAP ENABLE Extension March 2008
117
118
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.
124
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.
130
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.
136
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.
140
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:
146
147 C: t1 CAPABILITY 9051:1728 ../imapserver/server.go:1857
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
156
157 In the following example, the client enables CONDSTORE:
158
159 C: a1 ENABLE CONDSTORE
160 S: * ENABLED CONDSTORE
161 S: a1 OK Conditional Store enabled
162
163
164
165
166
167
168
169
170Gulbrandsen & Melnikov Standards Track [Page 3]
171
172RFC 5161 The IMAP ENABLE Extension March 2008
173
174
1753.2. The ENABLED Response
176
177 Contents: capability listing
178
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.
184
1853.3. Note to Designers of Extensions That May Use the ENABLE Command
186
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.
192
1934. Formal Syntax
194
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".
199
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.
204
205 capability =/ "ENABLE"
206
207 command-any =/ "ENABLE" 1*(SP capability) 9051:6518 ../imapserver/server.go:1859
208
209 response-data =/ "*" SP enable-data CRLF
210
211 enable-data = "ENABLED" *(SP capability) 9051:6520 ../imapserver/server.go:1891
212
2135. Security Considerations
214
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].
218
2196. IANA Considerations
220
221 The IANA has added ENABLE to the IMAP4 Capabilities Registry.
222
223
224
225
226Gulbrandsen & Melnikov Standards Track [Page 4]
227
228RFC 5161 The IMAP ENABLE Extension March 2008
229
230
2317. Acknowledgments
232
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.
239
2408. Normative References
241
242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
243 Requirement Levels", BCP 14, RFC 2119, March 1997.
244
245 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
246 4rev1", RFC 3501, March 2003.
247
248 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
249 Syntax Specifications: ABNF", STD 68, RFC 5234, January
250 2008.
251
252 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
253 STORE Operation or Quick Flag Changes Resynchronization",
254 RFC 4551, June 2006.
255
2569. Informative References
257
258 [ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
259 in Progress, August 2006.
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Gulbrandsen & Melnikov Standards Track [Page 5]
283
284RFC 5161 The IMAP ENABLE Extension March 2008
285
286
287Editors' Addresses
288
289 Arnt Gulbrandsen
290 Oryx Mail Systems GmbH
291 Schweppermannstr. 8
292 D-81671 Muenchen
293 Germany
294
295 Fax: +49 89 4502 9758
296 EMail: arnt@oryx.com
297
298
299 Alexey Melnikov
300 Isode Ltd
301 5 Castle Business Village
302 36 Station Road
303 Hampton, Middlesex TW12 2BX
304 UK
305
306 EMail: Alexey.Melnikov@isode.com
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338Gulbrandsen & Melnikov Standards Track [Page 6]
339
340RFC 5161 The IMAP ENABLE Extension March 2008
341
342
343Full Copyright Statement
344
345 Copyright (C) The IETF Trust (2008).
346
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.
350
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.
358
359Intellectual Property
360
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.
369
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.
376
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.
382
383
384
385
386
387
388
389
390
391
392
393
394Gulbrandsen & Melnikov Standards Track [Page 7]
395
396