idnits 2.17.1 draft-gulbrandsen-imap-enable-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 16, 2007) is 5975 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2177' is defined on line 253, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4551 (Obsoleted by RFC 7162) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Arnt Gulbrandsen 3 Internet-Draft Oryx Mail Systems GmbH 4 Intended Status: Proposed Standard Alexey Melnikov 5 Isode Limited 6 December 16, 2007 8 The IMAP ENABLE Extension 9 draft-gulbrandsen-imap-enable-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 30 Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft expires in February 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Most IMAP extensions are used by the client when it wants to and the 42 server supports it. However, a few extensions require the server to 43 know whether a client supports that extension. The ENABLE extension 44 allows an IMAP client to say which extensions it supports. 46 Internet-draft December 2007 48 1. Conventions Used in This Document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in [RFC2119]. 54 Formal syntax is defined by [RFC4234] as modified by [RFC3501]. 56 Example lines prefaced by "C:" are sent by the client and ones 57 prefaced by "S:" by the server. The five characters [...] means that 58 something has been elided. 60 2. Overview 62 Several IMAP extensions allow the server to return unsolicited 63 responses specific to these extensions in certain circumstances. 64 However, servers cannot send those unsolicited responses until they 65 know that the clients support such extensions and thus won't choke 66 on the extension response data. 68 Up until now extensions have typically stated that a server cannot 69 send the unsolicited responses until after the client has used a 70 command with the extension data (i.e. at that point the server knows 71 the client is aware of the extension). CONSTORE ([RFC4551]), 72 ANNOTATE ([ANNOTATE]) and some extensions under consideration at the 73 moment use various commands to enable server extensions. For example 74 CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE uses a side 75 effect of FETCH. 77 The ENABLE extension provides an explicit indication from the client 78 that it supports particular extensions. This is done using a new 79 ENABLE command. 81 An IMAP server which supports ENABLE advertises this by including 82 the word ENABLE in its capability list. 84 Most IMAP extensions do not require the client to enable the 85 extension in any way. 87 3. Protocol changes 88 3.1 The ENABLE Command 90 Arguments: capability names 92 Result: OK: Relevant capabilities enabled 93 BAD: No arguments, or syntax error in an argument 95 Internet-draft December 2007 97 The ENABLE command takes a list of capability names, and requests 98 the server to enable the named extensions. Once enabled using 99 ENABLE, each extension remains active until the IMAP connection is 100 closed. For each argument, the server does the following: 102 - If the argument is not an extension known to the server, the 103 server MUST ignore the argument. 105 - If the argument is an extension known to the server, and it is not 106 specifically permitted to be enabled using ENABLE, the server MUST 107 ignore the argument. (Note that knowing about an extension doesn't 108 necessarily imply supporting that extension.) 110 - If the argument is an extension is supported by the server and 111 which needs to be enabled, the server MUST enable the extension 112 for the duration of the connection. At present this applies only 113 to CONDSTORE ([RFC4551]). Note that once an extension is enabled, 114 there is no way to disable it. 116 If the ENABLE command is successful, the server MUST send an 117 untagged ENABLED response (see Section 3.2). 119 Clients SHOULD only include extensions that need to be enabled by 120 the server. At the time this RFC is published CONDSTORE is the only 121 such extension (ie. ENABLE CONDSTORE is an additional "Condstore 122 enabling command" as defined in [RFC4551]). Future RFCs may add to 123 this list. [Note to the RFC Editor: If the IMAP ANNOTATE document 124 has been published already, ANNOTATE should be mentioned as well as 125 CONDSTORE.] 127 The ENABLE command is only valid in Authenticated state (see 128 [RFC3501]), before any mailbox is selected. Clients MUST NOT issue 129 ENABLE once they SELECT/EXAMINE a mailbox, however server 130 implementations don't have to check that no mailbox is selected or 131 was previously selected during the duration of a connection. 133 The ENABLE command can be issued multiple times in a session. It is 134 additive, i.e. "ENABLE a b", followed by "ENABLE c" is the same as a 135 single command "ENABLE a b c". When multiple ENABLE commands are 136 issued, each corresponding ENABLED response SHOULD only contain 137 extensions enabled by the corresponding ENABLE command. 139 There are no limitations on pipelining ENABLE. For example, it is 140 possible to send ENABLE and then immediately SELECT, or a LOGIN 141 immediately followed by ENABLE. 143 The server MUST NOT change the CAPABILITY list as a result of 144 executing ENABLE, i.e. a CAPABILITY command issued right after an 146 Internet-draft December 2007 148 ENABLE command MUST list the same capabilities as a CAPABILITY 149 command issued before the ENABLE command. The following example 150 demonstrates that: 152 C: t1 CAPABILITY 153 S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA 154 S: t1 OK foo 155 C: t2 ENABLE CONDSTORE X-GOOD-IDEA 156 S: * ENABLED X-GOOD-IDEA 157 S: t2 OK foo 158 C: t3 CAPABILITY 159 S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA 160 S: t3 OK foo again 162 In the following example, the client enables CONDSTORE: 164 C: a1 ENABLE CONDSTORE 165 S: * ENABLED CONDSTORE 166 S: a1 OK Conditional Store enabled 168 3.2 The ENABLED Response 170 Contents: capability listing 172 The ENABLED response occurs as a result of an ENABLE command. The 173 capability listing contains a space-separated listing of capability 174 names that the server supports and that were successfully enabled. 175 The ENABLED response may contain no capabilities, which means that 176 no extensions listed by the client were successfully enabled. 178 3.3 Note to designers of extensions that may use the ENABLE command 180 Designers of IMAP extensions are discouraged from creating 181 extensions that require ENABLE unless there is no good alternative 182 design. Specifically, extensions that cause potentially 183 incompatible behavior changes to deployed server responses (and thus 184 benefit from ENABLE) have a higher complexity cost than extensions 185 that do not. 187 4. Formal Syntax 189 The following syntax specification uses the Augmented Backus-Naur 190 Form (ABNF) notation as specified in [RFC4234] including the core 191 rules in Appendix B.1. [RFC3501] defines the non-terminals 192 "capability" and "command-any". 194 Internet-draft December 2007 196 Except as noted otherwise, all alphabetic characters are case- 197 insensitive. The use of upper or lower case characters to define 198 token strings is for editorial clarity only. Implementations MUST 199 accept these strings in a case-insensitive fashion. 201 capability =/ "ENABLE" 203 command-any =/ "ENABLE" 1*(SP capability) 205 response-data =/ "*" SP enable-data CRLF 207 enable-data = "ENABLED" *(SP capability) 209 5. Security considerations 211 It is believed that this extension doesn't add any new security 212 considerations that are not already present in the base IMAP 213 protocol [RFC3501]. 215 6. IANA considerations 217 The IANA is requested to add ENABLE to the IMAP4 Capabilities 218 Registry. [[Note to RFC-editor: please remove the following before 219 publication: This registration should take place at the following 220 location: http://www.iana.org/assignments/imap4-capabilities]] 222 7. Acknowledgements 224 Editors would like to thank Randy Gellens, Chris Newman, Peter 225 Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus 226 Daboo, Ken Murchison and Eric Burger for comments and corrections. 227 However this doesn't necessarily mean that they endorse this 228 extension, agree with all details or responsible for errors 229 introduced by editors. 231 8. Normative References 233 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 234 Requirement Levels", RFC 2119, Harvard University, March 235 1997. 237 [RFC3501] Crispin, "Internet Message Access Protocol - Version 239 Internet-draft December 2007 241 4rev1", RFC 3501, University of Washington, June 2003. 243 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 244 Specifications: ABNF", RFC 4234, Brandenburg 245 Internetworking, Demon Internet Ltd, October 2005. 247 [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE 248 Operation or Quick Flag Changes Resynchronization", RFC 249 4551, Isode Ltd., June 2006. 251 8. Informative References 253 [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. 255 [ANNOTATE] Daboo, Gellens, "IMAP ANNOTATE Extension", draft-ietf- 256 imapext-annotate, August 2006. 258 10. Author's Address 260 Arnt Gulbrandsen 261 Oryx Mail Systems GmbH 262 Schweppermannstr. 8 263 D-81671 Muenchen 264 Germany 266 Fax: +49 89 4502 9758 268 Email: arnt@oryx.com 270 Alexey Melnikov 271 Isode Ltd 272 5 Castle Business Village 273 36 Station Road 274 Hampton, Middlesex TW12 2BX 275 UK 277 Email: Alexey.Melnikov@isode.com 279 Internet-draft December 2007 281 Intellectual Property Statement 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed to 285 pertain to the implementation or use of the technology described in 286 this document or the extent to which any license under such rights 287 might or might not be available; nor does it represent that it has 288 made any independent effort to identify any such rights. Information 289 on the procedures with respect to rights in RFC documents can be found 290 in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use of 295 such proprietary rights by implementers or users of this specification 296 can be obtained from the IETF on-line IPR repository at 297 http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at 303 ietf-ipr@ietf.org. 305 Full Copyright Statement 307 Copyright (C) The IETF Trust (2007). This document is subject to 308 the rights, licenses and restrictions contained in BCP 78, and 309 except as set forth therein, the authors retain all their rights. 311 This document and the information contained herein are provided on 312 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 313 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 314 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 315 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 316 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 317 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 318 FOR A PARTICULAR PURPOSE. 320 Acknowledgment 322 Funding for the RFC Editor function is currently provided by the 323 Internet Society. 325 Internet-draft December 2007 327 (RFC Editor: Please delete everything after this point) 329 Changes since -00 331 - The IANA asked me to specify the IANA registry exactly 333 - Say "clients should only use ENABLE when it's really necessary" 335 - Better abstract 337 - Wording. 339 - Refer to RFCs by number, not by topic. 341 - Boilerplate updates - IETF Trust and so on. 343 Changes since -01 345 - Specify that ENABLE ID is BAD, not ignorable. 347 - Explicitly allow maximum pipelining. 349 - Security implications. 351 Changes since -02 353 - Nits 355 - Unique tags in examples 357 - Note specifically that a server can reply BAD to ENABLE ID, even 358 if it doesn't support ID. All it needs is to know that ID cannot 359 be ENABLEd. 361 Changes since -03 363 - Added ENABLED response as per discussion on the mailing list 365 - Changed ENABLE to never return BAD 367 - Only allow ENABLE in the authenticated state as per consensus in 368 Vancouver 370 - Clarified [lack of] interaction with the CAPABILITY response 372 Internet-draft December 2007 374 - Clarified that the ENABLE command is additive 376 - Added more examples 378 Changes since -04 380 - Added rationale for the ENABLE extension 382 - Fixed several inconsistencies caused by restring ENABLE to 383 authentication state only.