1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc5161.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,395 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                A. Gulbrandsen, Ed.
    1.11 +Request for Comments: 5161                        Oryx Mail Systems GmbH
    1.12 +Category: Standards Track                               A. Melnikov, Ed.
    1.13 +                                                           Isode Limited
    1.14 +                                                              March 2008
    1.15 +
    1.16 +
    1.17 +                       The IMAP ENABLE Extension
    1.18 +
    1.19 +Status of This Memo
    1.20 +
    1.21 +   This document specifies an Internet standards track protocol for the
    1.22 +   Internet community, and requests discussion and suggestions for
    1.23 +   improvements.  Please refer to the current edition of the "Internet
    1.24 +   Official Protocol Standards" (STD 1) for the standardization state
    1.25 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.26 +
    1.27 +Abstract
    1.28 +
    1.29 +   Most IMAP extensions are used by the client when it wants to and the
    1.30 +   server supports it.  However, a few extensions require the server to
    1.31 +   know whether a client supports that extension.  The ENABLE extension
    1.32 +   allows an IMAP client to say which extensions it supports.
    1.33 +
    1.34 +1.  Overview
    1.35 +
    1.36 +   Several IMAP extensions allow the server to return unsolicited
    1.37 +   responses specific to these extensions in certain circumstances.
    1.38 +   However, servers cannot send those unsolicited responses until they
    1.39 +   know that the clients support such extensions and thus won't choke on
    1.40 +   the extension response data.
    1.41 +
    1.42 +   Up until now, extensions have typically stated that a server cannot
    1.43 +   send the unsolicited responses until after the client has used a
    1.44 +   command with the extension data (i.e., at that point the server knows
    1.45 +   the client is aware of the extension).  CONDSTORE ([RFC4551]),
    1.46 +   ANNOTATE ([ANNOTATE]), and some extensions under consideration at the
    1.47 +   moment use various commands to enable server extensions.  For
    1.48 +   example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE
    1.49 +   uses a side effect of FETCH.
    1.50 +
    1.51 +   The ENABLE extension provides an explicit indication from the client
    1.52 +   that it supports particular extensions.  This is done using a new
    1.53 +   ENABLE command.
    1.54 +
    1.55 +   An IMAP server that supports ENABLE advertises this by including the
    1.56 +   word ENABLE in its capability list.
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Gulbrandsen & Melnikov      Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 5161               The IMAP ENABLE Extension              March 2008
    1.64 +
    1.65 +
    1.66 +   Most IMAP extensions do not require the client to enable the
    1.67 +   extension in any way.
    1.68 +
    1.69 +2.  Conventions Used in This Document
    1.70 +
    1.71 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1.72 +   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    1.73 +   document are to be interpreted as described in [RFC2119].
    1.74 +
    1.75 +   Formal syntax is defined by [RFC5234] and [RFC3501].
    1.76 +
    1.77 +   Example lines prefaced by "C:" are sent by the client and ones
    1.78 +   prefaced by "S:" by the server.  The five characters [...] means that
    1.79 +   something has been elided.
    1.80 +
    1.81 +3.  Protocol Changes
    1.82 +
    1.83 +3.1.  The ENABLE Command
    1.84 +
    1.85 +   Arguments: capability names
    1.86 +
    1.87 +   Result:    OK: Relevant capabilities enabled
    1.88 +              BAD: No arguments, or syntax error in an argument
    1.89 +
    1.90 +   The ENABLE command takes a list of capability names, and requests the
    1.91 +   server to enable the named extensions.  Once enabled using ENABLE,
    1.92 +   each extension remains active until the IMAP connection is closed.
    1.93 +   For each argument, the server does the following:
    1.94 +
    1.95 +   - If the argument is not an extension known to the server, the server
    1.96 +     MUST ignore the argument.
    1.97 +
    1.98 +   - If the argument is an extension known to the server, and it is not
    1.99 +     specifically permitted to be enabled using ENABLE, the server MUST
   1.100 +     ignore the argument.  (Note that knowing about an extension doesn't
   1.101 +     necessarily imply supporting that extension.)
   1.102 +
   1.103 +   - If the argument is an extension that is supported by the server and
   1.104 +     that needs to be enabled, the server MUST enable the extension for
   1.105 +     the duration of the connection.  At present, this applies only to
   1.106 +     CONDSTORE ([RFC4551]).  Note that once an extension is enabled,
   1.107 +     there is no way to disable it.
   1.108 +
   1.109 +   If the ENABLE command is successful, the server MUST send an untagged
   1.110 +   ENABLED response (see Section 3.2).
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Gulbrandsen & Melnikov      Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 5161               The IMAP ENABLE Extension              March 2008
   1.120 +
   1.121 +
   1.122 +   Clients SHOULD only include extensions that need to be enabled by the
   1.123 +   server.  At the time of publication, CONDSTORE is the only such
   1.124 +   extension (i.e., ENABLE CONDSTORE is an additional "CONDSTORE
   1.125 +   enabling command" as defined in [RFC4551]).  Future RFCs may add to
   1.126 +   this list.
   1.127 +
   1.128 +   The ENABLE command is only valid in the authenticated state (see
   1.129 +   [RFC3501]), before any mailbox is selected.  Clients MUST NOT issue
   1.130 +   ENABLE once they SELECT/EXAMINE a mailbox; however, server
   1.131 +   implementations don't have to check that no mailbox is selected or
   1.132 +   was previously selected during the duration of a connection.
   1.133 +
   1.134 +   The ENABLE command can be issued multiple times in a session.  It is
   1.135 +   additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
   1.136 +   single command "ENABLE a b c".  When multiple ENABLE commands are
   1.137 +   issued, each corresponding ENABLED response SHOULD only contain
   1.138 +   extensions enabled by the corresponding ENABLE command.
   1.139 +
   1.140 +   There are no limitations on pipelining ENABLE.  For example, it is
   1.141 +   possible to send ENABLE and then immediately SELECT, or a LOGIN
   1.142 +   immediately followed by ENABLE.
   1.143 +
   1.144 +   The server MUST NOT change the CAPABILITY list as a result of
   1.145 +   executing ENABLE; i.e., a CAPABILITY command issued right after an
   1.146 +   ENABLE command MUST list the same capabilities as a CAPABILITY
   1.147 +   command issued before the ENABLE command.  This is demonstrated in
   1.148 +   the following example:
   1.149 +
   1.150 +      C: t1 CAPABILITY
   1.151 +      S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
   1.152 +      S: t1 OK foo
   1.153 +      C: t2 ENABLE CONDSTORE X-GOOD-IDEA
   1.154 +      S: * ENABLED X-GOOD-IDEA
   1.155 +      S: t2 OK foo
   1.156 +      C: t3 CAPABILITY
   1.157 +      S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
   1.158 +      S: t3 OK foo again
   1.159 +
   1.160 +   In the following example, the client enables CONDSTORE:
   1.161 +
   1.162 +      C: a1 ENABLE CONDSTORE
   1.163 +      S: * ENABLED CONDSTORE
   1.164 +      S: a1 OK Conditional Store enabled
   1.165 +
   1.166 +
   1.167 +
   1.168 +
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Gulbrandsen & Melnikov      Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 5161               The IMAP ENABLE Extension              March 2008
   1.176 +
   1.177 +
   1.178 +3.2.  The ENABLED Response
   1.179 +
   1.180 +   Contents:   capability listing
   1.181 +
   1.182 +   The ENABLED response occurs as a result of an ENABLE command.  The
   1.183 +   capability listing contains a space-separated listing of capability
   1.184 +   names that the server supports and that were successfully enabled.
   1.185 +   The ENABLED response may contain no capabilities, which means that no
   1.186 +   extensions listed by the client were successfully enabled.
   1.187 +
   1.188 +3.3.  Note to Designers of Extensions That May Use the ENABLE Command
   1.189 +
   1.190 +   Designers of IMAP extensions are discouraged from creating extensions
   1.191 +   that require ENABLE unless there is no good alternative design.
   1.192 +   Specifically, extensions that cause potentially incompatible behavior
   1.193 +   changes to deployed server responses (and thus benefit from ENABLE)
   1.194 +   have a higher complexity cost than extensions that do not.
   1.195 +
   1.196 +4.  Formal Syntax
   1.197 +
   1.198 +   The following syntax specification uses the Augmented Backus-Naur
   1.199 +   Form (ABNF) notation as specified in [RFC5234] including the core
   1.200 +   rules in Appendix B.1.  [RFC3501] defines the non-terminals
   1.201 +   "capability" and "command-any".
   1.202 +
   1.203 +   Except as noted otherwise, all alphabetic characters are
   1.204 +   case-insensitive.  The use of upper or lower case characters to
   1.205 +   define token strings is for editorial clarity only.  Implementations
   1.206 +   MUST accept these strings in a case-insensitive fashion.
   1.207 +
   1.208 +      capability    =/ "ENABLE"
   1.209 +
   1.210 +      command-any   =/ "ENABLE" 1*(SP capability)
   1.211 +
   1.212 +      response-data =/ "*" SP enable-data CRLF
   1.213 +
   1.214 +      enable-data   = "ENABLED" *(SP capability)
   1.215 +
   1.216 +5.  Security Considerations
   1.217 +
   1.218 +   It is believed that this extension doesn't add any security
   1.219 +   considerations that are not already present in the base IMAP protocol
   1.220 +   [RFC3501].
   1.221 +
   1.222 +6.  IANA Considerations
   1.223 +
   1.224 +   The IANA has added ENABLE to the IMAP4 Capabilities Registry.
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Gulbrandsen & Melnikov      Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 5161               The IMAP ENABLE Extension              March 2008
   1.232 +
   1.233 +
   1.234 +7.  Acknowledgments
   1.235 +
   1.236 +   The editors would like to thank Randy Gellens, Chris Newman, Peter
   1.237 +   Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus
   1.238 +   Daboo, Ken Murchison, and Eric Burger for comments and corrections.
   1.239 +   However, this doesn't necessarily mean that they endorse this
   1.240 +   extension, agree with all details, or are responsible for errors
   1.241 +   introduced by the editors.
   1.242 +
   1.243 +8.  Normative References
   1.244 +
   1.245 +   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   1.246 +              Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.247 +
   1.248 +   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
   1.249 +              4rev1", RFC 3501, March 2003.
   1.250 +
   1.251 +   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
   1.252 +              Syntax Specifications: ABNF", STD 68, RFC 5234, January
   1.253 +              2008.
   1.254 +
   1.255 +   [RFC4551]  Melnikov, A. and S. Hole, "IMAP Extension for Conditional
   1.256 +              STORE Operation or Quick Flag Changes Resynchronization",
   1.257 +              RFC 4551, June 2006.
   1.258 +
   1.259 +9.  Informative References
   1.260 +
   1.261 +   [ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
   1.262 +              in Progress, August 2006.
   1.263 +
   1.264 +
   1.265 +
   1.266 +
   1.267 +
   1.268 +
   1.269 +
   1.270 +
   1.271 +
   1.272 +
   1.273 +
   1.274 +
   1.275 +
   1.276 +
   1.277 +
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Gulbrandsen & Melnikov      Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 5161               The IMAP ENABLE Extension              March 2008
   1.288 +
   1.289 +
   1.290 +Editors' Addresses
   1.291 +
   1.292 +   Arnt Gulbrandsen
   1.293 +   Oryx Mail Systems GmbH
   1.294 +   Schweppermannstr. 8
   1.295 +   D-81671 Muenchen
   1.296 +   Germany
   1.297 +
   1.298 +   Fax: +49 89 4502 9758
   1.299 +   EMail: arnt@oryx.com
   1.300 +
   1.301 +
   1.302 +   Alexey Melnikov
   1.303 +   Isode Ltd
   1.304 +   5 Castle Business Village
   1.305 +   36 Station Road
   1.306 +   Hampton, Middlesex  TW12 2BX
   1.307 +   UK
   1.308 +
   1.309 +   EMail: Alexey.Melnikov@isode.com
   1.310 +
   1.311 +
   1.312 +
   1.313 +
   1.314 +
   1.315 +
   1.316 +
   1.317 +
   1.318 +
   1.319 +
   1.320 +
   1.321 +
   1.322 +
   1.323 +
   1.324 +
   1.325 +
   1.326 +
   1.327 +
   1.328 +
   1.329 +
   1.330 +
   1.331 +
   1.332 +
   1.333 +
   1.334 +
   1.335 +
   1.336 +
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Gulbrandsen & Melnikov      Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 5161               The IMAP ENABLE Extension              March 2008
   1.344 +
   1.345 +
   1.346 +Full Copyright Statement
   1.347 +
   1.348 +   Copyright (C) The IETF Trust (2008).
   1.349 +
   1.350 +   This document is subject to the rights, licenses and restrictions
   1.351 +   contained in BCP 78, and except as set forth therein, the authors
   1.352 +   retain all their rights.
   1.353 +
   1.354 +   This document and the information contained herein are provided on an
   1.355 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.356 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   1.357 +   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   1.358 +   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   1.359 +   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.360 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.361 +
   1.362 +Intellectual Property
   1.363 +
   1.364 +   The IETF takes no position regarding the validity or scope of any
   1.365 +   Intellectual Property Rights or other rights that might be claimed to
   1.366 +   pertain to the implementation or use of the technology described in
   1.367 +   this document or the extent to which any license under such rights
   1.368 +   might or might not be available; nor does it represent that it has
   1.369 +   made any independent effort to identify any such rights.  Information
   1.370 +   on the procedures with respect to rights in RFC documents can be
   1.371 +   found in BCP 78 and BCP 79.
   1.372 +
   1.373 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.374 +   assurances of licenses to be made available, or the result of an
   1.375 +   attempt made to obtain a general license or permission for the use of
   1.376 +   such proprietary rights by implementers or users of this
   1.377 +   specification can be obtained from the IETF on-line IPR repository at
   1.378 +   http://www.ietf.org/ipr.
   1.379 +
   1.380 +   The IETF invites any interested party to bring to its attention any
   1.381 +   copyrights, patents or patent applications, or other proprietary
   1.382 +   rights that may cover technology that may be required to implement
   1.383 +   this standard.  Please address the information to the IETF at
   1.384 +   ietf-ipr@ietf.org.
   1.385 +
   1.386 +
   1.387 +
   1.388 +
   1.389 +
   1.390 +
   1.391 +
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Gulbrandsen & Melnikov      Standards Track                     [Page 7]
   1.398 +