1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc4466.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,955 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                        A. Melnikov
    1.11 +Request for Comments: 4466                                    Isode Ltd.
    1.12 +Updates: 2088, 2342, 3501, 3502, 3516                           C. Daboo
    1.13 +Category: Standards Track                                     April 2006
    1.14 +
    1.15 +
    1.16 +                   Collected Extensions to IMAP4 ABNF
    1.17 +
    1.18 +Status of This Memo
    1.19 +
    1.20 +   This document specifies an Internet standards track protocol for the
    1.21 +   Internet community, and requests discussion and suggestions for
    1.22 +   improvements.  Please refer to the current edition of the "Internet
    1.23 +   Official Protocol Standards" (STD 1) for the standardization state
    1.24 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.25 +
    1.26 +Copyright Notice
    1.27 +
    1.28 +   Copyright (C) The Internet Society (2006).
    1.29 +
    1.30 +Abstract
    1.31 +
    1.32 +   Over the years, many documents from IMAPEXT and LEMONADE working
    1.33 +   groups, as well as many individual documents, have added syntactic
    1.34 +   extensions to many base IMAP commands described in RFC 3501.  For
    1.35 +   ease of reference, this document collects most of such ABNF changes
    1.36 +   in one place.
    1.37 +
    1.38 +   This document also suggests a set of standard patterns for adding
    1.39 +   options and extensions to several existing IMAP commands defined in
    1.40 +   RFC 3501.  The patterns provide for compatibility between existing
    1.41 +   and future extensions.
    1.42 +
    1.43 +   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
    1.44 +   It also includes part of the errata to RFC 3501.  This document
    1.45 +   doesn't specify any semantic changes to the listed RFCs.
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Melnikov & Daboo            Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
    1.64 +
    1.65 +
    1.66 +Table of Contents
    1.67 +
    1.68 +   1. Introduction ....................................................2
    1.69 +      1.1. Purpose of This Document ...................................2
    1.70 +      1.2. Conventions Used in This Document ..........................3
    1.71 +   2. IMAP ABNF Extensions ............................................3
    1.72 +      2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
    1.73 +      2.2. Extended CREATE Command ....................................4
    1.74 +      2.3. Extended RENAME Command ....................................5
    1.75 +      2.4. Extensions to FETCH and UID FETCH Commands .................6
    1.76 +      2.5. Extensions to STORE and UID STORE Commands .................6
    1.77 +      2.6. Extensions to SEARCH Command ...............................7
    1.78 +           2.6.1. Extended SEARCH Command .............................7
    1.79 +           2.6.2. ESEARCH untagged response ...........................8
    1.80 +      2.7. Extensions to APPEND Command ...............................8
    1.81 +   3. Formal Syntax ...................................................9
    1.82 +   4. Security Considerations ........................................14
    1.83 +   5. Normative References ...........................................15
    1.84 +   6. Acknowledgements ...............................................15
    1.85 +
    1.86 +1.  Introduction
    1.87 +
    1.88 +1.1.  Purpose of This Document
    1.89 +
    1.90 +   This document serves several purposes:
    1.91 +
    1.92 +      1.  rationalize and generalize ABNF for some existing IMAP
    1.93 +          extensions;
    1.94 +      2.  collect the ABNF in one place in order to minimize cross
    1.95 +          references between documents;
    1.96 +      3.  define building blocks for future extensions so that they can
    1.97 +          be used together in a compatible way.
    1.98 +
    1.99 +   It is expected that a future revision of this document will be
   1.100 +   incorporated into a revision of RFC 3501.
   1.101 +
   1.102 +   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
   1.103 +   It also includes part of the errata to RFC 3501.  This document
   1.104 +   doesn't specify any semantic changes to the listed RFCs.
   1.105 +
   1.106 +   The ABNF in section 6 of RFC 2342 got rewritten to conform to the
   1.107 +   ABNF syntax as defined in RFC 4234 and to reference new non-terminals
   1.108 +   from RFC 3501.  It was also restructured to allow for better
   1.109 +   readability.  There were no changes "on the wire".
   1.110 +
   1.111 +   Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH/UID
   1.112 +   FETCH, STORE/UID STORE, SEARCH, and APPEND commands in a consistent
   1.113 +   manner.  Extensions to all the commands but APPEND have the same
   1.114 +
   1.115 +
   1.116 +
   1.117 +Melnikov & Daboo            Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.120 +
   1.121 +
   1.122 +   structure.  Extensibility for the APPEND command was done slightly
   1.123 +   differently in order to preserve backward compatibility with existing
   1.124 +   extensions.
   1.125 +
   1.126 +   Section 2 also defines a new ESEARCH response, whose purpose is to
   1.127 +   define a better version of the SEARCH response defined in RFC 3501.
   1.128 +
   1.129 +   Section 3 defines the collected ABNF that replaces pieces of ABNF in
   1.130 +   the aforementioned RFCs.  The collected ABNF got generalized to allow
   1.131 +   for easier future extensibility.
   1.132 +
   1.133 +1.2.  Conventions Used in This Document
   1.134 +
   1.135 +   In examples, "C:" and "S:" indicate lines sent by the client and
   1.136 +   server, respectively.
   1.137 +
   1.138 +   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   1.139 +   in this document are to be interpreted as defined in "Key words for
   1.140 +   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
   1.141 +
   1.142 +2.  IMAP ABNF Extensions
   1.143 +
   1.144 +   This section is not normative.  It provides some background on the
   1.145 +   intended use of different extensions and it gives some guidance about
   1.146 +   how future extensions should extend the described commands.
   1.147 +
   1.148 +2.1.  Optional Parameters with the SELECT/EXAMINE Commands
   1.149 +
   1.150 +   This document adds the ability to include one or more parameters with
   1.151 +   the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2
   1.152 +   of [IMAP4]) commands, to turn on or off certain standard behaviors,
   1.153 +   or to add new optional behaviors required for a particular extension.
   1.154 +
   1.155 +   There are two possible modes of operation:
   1.156 +
   1.157 +   o  A global state change where a single use of the optional parameter
   1.158 +      will affect the session state from that time on, irrespective of
   1.159 +      subsequent SELECT/EXAMINE commands.
   1.160 +
   1.161 +   o  A per-mailbox state change that will affect the session only for
   1.162 +      the duration of the new selected state.  A subsequent
   1.163 +      SELECT/EXAMINE without the optional parameter will cancel its
   1.164 +      effect for the newly selected mailbox.
   1.165 +
   1.166 +   Optional parameters to the SELECT or EXAMINE commands are added as a
   1.167 +   parenthesized list of attribute/value pairs, and appear after the
   1.168 +   mailbox name in the standard SELECT or EXAMINE command.  The order of
   1.169 +   individual parameters is arbitrary.  A parameter value is optional
   1.170 +
   1.171 +
   1.172 +
   1.173 +Melnikov & Daboo            Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.176 +
   1.177 +
   1.178 +   and may consist of atoms, strings, or lists in a specific order.  If
   1.179 +   the parameter value is present, it always appears in parentheses (*).
   1.180 +   Any parameter not defined by extensions that the server supports must
   1.181 +   be rejected with a BAD response.
   1.182 +
   1.183 +      Example:
   1.184 +
   1.185 +              C: a SELECT INBOX (ANNOTATE)
   1.186 +              S: ...
   1.187 +              S: a OK SELECT complete
   1.188 +
   1.189 +      In the above example, a single parameter is used with the SELECT
   1.190 +      command.
   1.191 +
   1.192 +      Example:
   1.193 +
   1.194 +              C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
   1.195 +                 CONDSTORE)
   1.196 +              S: ...
   1.197 +              S: a OK EXAMINE complete
   1.198 +
   1.199 +      In the above example, three parameters are used with the EXAMINE
   1.200 +      command.  The second parameter consists of two items: an atom
   1.201 +      "RESPONSES" followed by a quoted string.
   1.202 +
   1.203 +      Example:
   1.204 +
   1.205 +              C: a SELECT INBOX (BLURDYBLOOP)
   1.206 +              S: a BAD Unknown parameter in SELECT command
   1.207 +
   1.208 +      In the above example, a parameter not supported by the server is
   1.209 +      used.  This results in the BAD response from the server.
   1.210 +
   1.211 +   (*) - if a parameter has a mandatory value, which can always be
   1.212 +   represented as a number or a sequence-set, the parameter value does
   1.213 +   not need the enclosing ().  See ABNF for more details.
   1.214 +
   1.215 +2.2.  Extended CREATE Command
   1.216 +
   1.217 +   Arguments:  mailbox name
   1.218 +               OPTIONAL list of CREATE parameters
   1.219 +
   1.220 +   Responses:  no specific responses for this command
   1.221 +
   1.222 +   Result:     OK - create completed
   1.223 +               NO - create failure: cannot create mailbox with
   1.224 +                    that name
   1.225 +               BAD - argument(s) invalid
   1.226 +
   1.227 +
   1.228 +
   1.229 +Melnikov & Daboo            Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.232 +
   1.233 +
   1.234 +   This document adds the ability to include one or more parameters with
   1.235 +   the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to turn on or
   1.236 +   off certain standard behaviors, or to add new optional behaviors
   1.237 +   required for a particular extension.  No CREATE parameters are
   1.238 +   defined in this document.
   1.239 +
   1.240 +   Optional parameters to the CREATE command are added as a
   1.241 +   parenthesized list of attribute/value pairs after the mailbox name.
   1.242 +   The order of individual parameters is arbitrary.  A parameter value
   1.243 +   is optional and may consist of atoms, strings, or lists in a specific
   1.244 +   order.  If the parameter value is present, it always appears in
   1.245 +   parentheses (*).  Any parameter not defined by extensions that the
   1.246 +   server supports must be rejected with a BAD response.
   1.247 +
   1.248 +   (*) - if a parameter has a mandatory value, which can always be
   1.249 +   represented as a number or a sequence-set, the parameter value does
   1.250 +   not need the enclosing ().  See ABNF for more details.
   1.251 +
   1.252 +2.3.  Extended RENAME Command
   1.253 +
   1.254 +   Arguments:  existing mailbox name
   1.255 +               new mailbox name
   1.256 +               OPTIONAL list of RENAME parameters
   1.257 +
   1.258 +   Responses:  no specific responses for this command
   1.259 +
   1.260 +   Result:     OK - rename completed
   1.261 +               NO - rename failure: cannot rename mailbox with
   1.262 +                    that name, cannot rename to mailbox with
   1.263 +                    that name, etc.
   1.264 +               BAD - argument(s) invalid
   1.265 +
   1.266 +   This document adds the ability to include one or more parameters with
   1.267 +   the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to turn on or
   1.268 +   off certain standard behaviors, or to add new optional behaviors
   1.269 +   required for a particular extension.  No RENAME parameters are
   1.270 +   defined in this document.
   1.271 +
   1.272 +   Optional parameters to the RENAME command are added as a
   1.273 +   parenthesized list of attribute/value pairs after the new mailbox
   1.274 +   name.  The order of individual parameters is arbitrary.  A parameter
   1.275 +   value is optional and may consist of atoms, strings, or lists in a
   1.276 +   specific order.  If the parameter value is present, it always appears
   1.277 +   in parentheses (*).  Any parameter not defined by extensions that the
   1.278 +   server supports must be rejected with a BAD response.
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Melnikov & Daboo            Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.288 +
   1.289 +
   1.290 +   (*) - if a parameter has a mandatory value, which can always be
   1.291 +   represented as a number or a sequence-set, the parameter value does
   1.292 +   not need the enclosing ().  See ABNF for more details.
   1.293 +
   1.294 +2.4.  Extensions to FETCH and UID FETCH Commands
   1.295 +
   1.296 +   Arguments:  sequence set
   1.297 +               message data item names or macro
   1.298 +               OPTIONAL fetch modifiers
   1.299 +
   1.300 +   Responses:  untagged responses: FETCH
   1.301 +
   1.302 +   Result:     OK - fetch completed
   1.303 +               NO - fetch error: cannot fetch that data
   1.304 +               BAD - command unknown or arguments invalid
   1.305 +
   1.306 +   This document extends the syntax of the FETCH and UID FETCH commands
   1.307 +   (see section 6.4.5 of [IMAP4]) to include optional FETCH modifiers.
   1.308 +   No fetch modifiers are defined in this document.
   1.309 +
   1.310 +   The order of individual modifiers is arbitrary.  Each modifier is an
   1.311 +   attribute/value pair.  A modifier value is optional and may consist
   1.312 +   of atoms and/or strings and/or lists in a specific order.  If the
   1.313 +   modifier value is present, it always appears in parentheses (*).  Any
   1.314 +   modifiers not defined by extensions that the server supports must be
   1.315 +   rejected with a BAD response.
   1.316 +
   1.317 +   (*) - if a modifier has a mandatory value, which can always be
   1.318 +   represented as a number or a sequence-set, the modifier value does
   1.319 +   not need the enclosing ().  See ABNF for more details.
   1.320 +
   1.321 +2.5.  Extensions to STORE and UID STORE Commands
   1.322 +
   1.323 +   Arguments:  message set
   1.324 +               OPTIONAL store modifiers
   1.325 +               message data item name
   1.326 +               value for message data item
   1.327 +
   1.328 +   Responses:  untagged responses: FETCH
   1.329 +
   1.330 +   Result:     OK - store completed
   1.331 +               NO - store error: cannot store that data
   1.332 +               BAD - command unknown or arguments invalid
   1.333 +
   1.334 +   This document extends the syntax of the STORE and UID STORE commands
   1.335 +   (see section 6.4.6 of [IMAP4]) to include optional STORE modifiers.
   1.336 +   No store modifiers are defined in this document.
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Melnikov & Daboo            Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.344 +
   1.345 +
   1.346 +   The order of individual modifiers is arbitrary.  Each modifier is an
   1.347 +   attribute/value pair.  A modifier value is optional and may consist
   1.348 +   of atoms and/or strings and/or lists in a specific order.  If the
   1.349 +   modifier value is present, it always appears in parentheses (*).  Any
   1.350 +   modifiers not defined by extensions that the server supports must be
   1.351 +   rejected with a BAD response.
   1.352 +
   1.353 +   (*) - if a modifier has a mandatory value, which can always be
   1.354 +   represented as a number or a sequence-set, the modifier value does
   1.355 +   not need the enclosing ().  See ABNF for more details.
   1.356 +
   1.357 +2.6.  Extensions to SEARCH Command
   1.358 +
   1.359 +2.6.1.  Extended SEARCH Command
   1.360 +
   1.361 +   Arguments:  OPTIONAL result specifier
   1.362 +               OPTIONAL [CHARSET] specification
   1.363 +               searching criteria (one or more)
   1.364 +
   1.365 +   Responses:  REQUIRED untagged response: SEARCH (*)
   1.366 +
   1.367 +   Result:     OK - search completed
   1.368 +               NO - search error: cannot search that [CHARSET] or
   1.369 +                    criteria
   1.370 +               BAD - command unknown or arguments invalid
   1.371 +
   1.372 +   This section updates definition of the SEARCH command described in
   1.373 +   section 6.4.4 of [IMAP4].
   1.374 +
   1.375 +   The SEARCH command is extended to allow for result options.  This
   1.376 +   document does not define any result options.
   1.377 +
   1.378 +   The order of individual options is arbitrary.  Individual options may
   1.379 +   contain parameters enclosed in parentheses (**).  If an option has
   1.380 +   parameters, they consist of atoms and/or strings and/or lists in a
   1.381 +   specific order.  Any options not defined by extensions that the
   1.382 +   server supports must be rejected with a BAD response.
   1.383 +
   1.384 +   (*) - An extension to the SEARCH command may require another untagged
   1.385 +   response, or no untagged response to be returned.  Section 2.6.2
   1.386 +   defines a new ESEARCH untagged response that replaces the SEARCH
   1.387 +   untagged response.  Note that for a given extended SEARCH command the
   1.388 +   SEARCH and ESEARCH responses SHOULD be mutually exclusive, i.e., only
   1.389 +   one of them should be returned.
   1.390 +
   1.391 +   (**) - if an option has a mandatory parameter, which can always be
   1.392 +   represented as a number or a sequence-set, the option parameter does
   1.393 +   not need the enclosing ().  See ABNF for more details.
   1.394 +
   1.395 +
   1.396 +
   1.397 +Melnikov & Daboo            Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.400 +
   1.401 +
   1.402 +2.6.2.  ESEARCH untagged response
   1.403 +
   1.404 +   Contents:   one or more search-return-data pairs
   1.405 +
   1.406 +   The ESEARCH response SHOULD be sent as a result of an extended SEARCH
   1.407 +   or UID SEARCH command specified in section 2.6.1.
   1.408 +
   1.409 +   The ESEARCH response starts with an optional search correlator.  If
   1.410 +   it is missing, then the response was not caused by a particular IMAP
   1.411 +   command, whereas if it is present, it contains the tag of the command
   1.412 +   that caused the response to be returned.
   1.413 +
   1.414 +   The search correlator is followed by an optional UID indicator.  If
   1.415 +   this indicator is present, all data in the ESEARCH response refers to
   1.416 +   UIDs, otherwise all returned data refers to message numbers.
   1.417 +
   1.418 +   The rest of the ESEARCH response contains one or more search data
   1.419 +   pairs.  Each pair starts with unique return item name, followed by a
   1.420 +   space and the corresponding data.  Search data pairs may be returned
   1.421 +   in any order.  Unless specified otherwise by an extension, any return
   1.422 +   item name SHOULD appear only once in an ESEARCH response.
   1.423 +
   1.424 +   Example:    S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
   1.425 +
   1.426 +   Example:    S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
   1.427 +
   1.428 +   Example:    S: * ESEARCH COUNT 5 ALL 1:17,21
   1.429 +
   1.430 +2.7.  Extensions to APPEND Command
   1.431 +
   1.432 +   The IMAP BINARY extension [BINARY] extends the APPEND command to
   1.433 +   allow a client to append data containing NULs by using the <literal8>
   1.434 +   syntax.  The ABNF was rewritten to allow for easier extensibility by
   1.435 +   IMAP extensions.  This document hasn't specified any semantical
   1.436 +   changes to the [BINARY] extension.
   1.437 +
   1.438 +   In addition, the non-terminal "literal8" defined in [BINARY] got
   1.439 +   extended to allow for non-synchronizing literals if both [BINARY] and
   1.440 +   [LITERAL+] extensions are supported by the server.
   1.441 +
   1.442 +   The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND
   1.443 +   command to allow a client to append multiple messages atomically.
   1.444 +   This document defines a common syntax for the APPEND command that
   1.445 +   takes into consideration syntactic extensions defined by both
   1.446 +   [BINARY] and [MULTIAPPEND] extensions.
   1.447 +
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Melnikov & Daboo            Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.456 +
   1.457 +
   1.458 +3.  Formal Syntax
   1.459 +
   1.460 +   The following syntax specification uses the Augmented Backus-Naur
   1.461 +   Form (ABNF) notation as specified in [ABNF].
   1.462 +
   1.463 +   Non-terminals referenced but not defined below are as defined by
   1.464 +   [IMAP4].
   1.465 +
   1.466 +   Except as noted otherwise, all alphabetic characters are case-
   1.467 +   insensitive.  The use of uppercase or lowercase characters to define
   1.468 +   token strings is for editorial clarity only.  Implementations MUST
   1.469 +   accept these strings in a case-insensitive fashion.
   1.470 +
   1.471 +   append          = "APPEND" SP mailbox 1*append-message
   1.472 +                     ;; only a single append-message may appear
   1.473 +                     ;; if MULTIAPPEND [MULTIAPPEND] capability
   1.474 +                     ;; is not present
   1.475 +
   1.476 +   append-message  = append-opts SP append-data
   1.477 +
   1.478 +   append-ext      = append-ext-name SP append-ext-value
   1.479 +                     ;; This non-terminal define extensions to
   1.480 +                     ;; to message metadata.
   1.481 +
   1.482 +   append-ext-name = tagged-ext-label
   1.483 +
   1.484 +   append-ext-value= tagged-ext-val
   1.485 +                     ;; This non-terminal shows recommended syntax
   1.486 +                     ;; for future extensions.
   1.487 +
   1.488 +
   1.489 +   append-data     = literal / literal8 / append-data-ext
   1.490 +
   1.491 +   append-data-ext = tagged-ext
   1.492 +                     ;; This non-terminal shows recommended syntax
   1.493 +                     ;; for future extensions,
   1.494 +                     ;; i.e., a mandatory label followed
   1.495 +                     ;; by parameters.
   1.496 +
   1.497 +   append-opts     = [SP flag-list] [SP date-time] *(SP append-ext)
   1.498 +                     ;; message metadata
   1.499 +
   1.500 +   charset         = atom / quoted
   1.501 +                     ;; Exact syntax is defined in [CHARSET].
   1.502 +
   1.503 +   create          = "CREATE" SP mailbox
   1.504 +                     [create-params]
   1.505 +                     ;; Use of INBOX gives a NO error.
   1.506 +
   1.507 +
   1.508 +
   1.509 +Melnikov & Daboo            Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.512 +
   1.513 +
   1.514 +   create-params   = SP "(" create-param *( SP create-param) ")"
   1.515 +
   1.516 +   create-param-name = tagged-ext-label
   1.517 +
   1.518 +   create-param      = create-param-name [SP create-param-value]
   1.519 +
   1.520 +   create-param-value= tagged-ext-val
   1.521 +                     ;; This non-terminal shows recommended syntax
   1.522 +                     ;; for future extensions.
   1.523 +
   1.524 +
   1.525 +   esearch-response  = "ESEARCH" [search-correlator] [SP "UID"]
   1.526 +                        *(SP search-return-data)
   1.527 +                      ;; Note that SEARCH and ESEARCH responses
   1.528 +                      ;; SHOULD be mutually exclusive,
   1.529 +                      ;; i.e., only one of the response types
   1.530 +                      ;; should be
   1.531 +                      ;; returned as a result of a command.
   1.532 +
   1.533 +
   1.534 +   examine         = "EXAMINE" SP mailbox [select-params]
   1.535 +                     ;; modifies the original IMAP EXAMINE command
   1.536 +                     ;; to accept optional parameters
   1.537 +
   1.538 +   fetch           = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
   1.539 +                     "FAST" / fetch-att /
   1.540 +                     "(" fetch-att *(SP fetch-att) ")")
   1.541 +                     [fetch-modifiers]
   1.542 +                     ;; modifies the original IMAP4 FETCH command to
   1.543 +                     ;; accept optional modifiers
   1.544 +
   1.545 +   fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
   1.546 +
   1.547 +   fetch-modifier  = fetch-modifier-name [ SP fetch-modif-params ]
   1.548 +
   1.549 +   fetch-modif-params  = tagged-ext-val
   1.550 +                     ;; This non-terminal shows recommended syntax
   1.551 +                     ;; for future extensions.
   1.552 +
   1.553 +   fetch-modifier-name = tagged-ext-label
   1.554 +
   1.555 +   literal8        = "~{" number ["+"] "}" CRLF *OCTET
   1.556 +                      ;; A string that might contain NULs.
   1.557 +                      ;; <number> represents the number of OCTETs
   1.558 +                      ;; in the response string.
   1.559 +                      ;; The "+" is only allowed when both LITERAL+ and
   1.560 +                      ;; BINARY extensions are supported by the server.
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Melnikov & Daboo            Standards Track                    [Page 10]
   1.566 +
   1.567 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.568 +
   1.569 +
   1.570 +   mailbox-data      =/ Namespace-Response /
   1.571 +                        esearch-response
   1.572 +
   1.573 +   Namespace         = nil / "(" 1*Namespace-Descr ")"
   1.574 +
   1.575 +   Namespace-Command = "NAMESPACE"
   1.576 +
   1.577 +   Namespace-Descr   = "(" string SP
   1.578 +                          (DQUOTE QUOTED-CHAR DQUOTE / nil)
   1.579 +                           *(Namespace-Response-Extension) ")"
   1.580 +
   1.581 +   Namespace-Response-Extension = SP string SP
   1.582 +                     "(" string *(SP string) ")"
   1.583 +
   1.584 +   Namespace-Response = "NAMESPACE" SP Namespace
   1.585 +                        SP Namespace SP Namespace
   1.586 +         ;; This response is currently only allowed
   1.587 +         ;; if the IMAP server supports [NAMESPACE].
   1.588 +         ;; The first Namespace is the Personal Namespace(s)
   1.589 +         ;; The second Namespace is the Other Users' Namespace(s)
   1.590 +         ;; The third Namespace is the Shared Namespace(s)
   1.591 +
   1.592 +   rename          = "RENAME" SP mailbox SP mailbox
   1.593 +                     [rename-params]
   1.594 +                     ;; Use of INBOX as a destination gives
   1.595 +                     ;; a NO error, unless rename-params
   1.596 +                     ;; is not empty.
   1.597 +
   1.598 +   rename-params     = SP "(" rename-param *( SP rename-param) ")"
   1.599 +
   1.600 +   rename-param      = rename-param-name [SP rename-param-value]
   1.601 +
   1.602 +   rename-param-name = tagged-ext-label
   1.603 +
   1.604 +   rename-param-value= tagged-ext-val
   1.605 +                     ;; This non-terminal shows recommended syntax
   1.606 +                     ;; for future extensions.
   1.607 +
   1.608 +
   1.609 +   response-data   = "*" SP response-payload CRLF
   1.610 +
   1.611 +   response-payload= resp-cond-state / resp-cond-bye /
   1.612 +                     mailbox-data / message-data / capability-data
   1.613 +
   1.614 +   search          = "SEARCH" [search-return-opts]
   1.615 +                     SP search-program
   1.616 +
   1.617 +   search-correlator  = SP "(" "TAG" SP tag-string ")"
   1.618 +
   1.619 +
   1.620 +
   1.621 +Melnikov & Daboo            Standards Track                    [Page 11]
   1.622 +
   1.623 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.624 +
   1.625 +
   1.626 +   search-program     = ["CHARSET" SP charset SP]
   1.627 +                        search-key *(SP search-key)
   1.628 +                        ;; CHARSET argument to SEARCH MUST be
   1.629 +                        ;; registered with IANA.
   1.630 +
   1.631 +   search-return-data = search-modifier-name SP search-return-value
   1.632 +                        ;; Note that not every SEARCH return option
   1.633 +                        ;; is required to have the corresponding
   1.634 +                        ;; ESEARCH return data.
   1.635 +
   1.636 +   search-return-opts = SP "RETURN" SP "(" [search-return-opt
   1.637 +                        *(SP search-return-opt)] ")"
   1.638 +
   1.639 +   search-return-opt = search-modifier-name [SP search-mod-params]
   1.640 +
   1.641 +   search-return-value = tagged-ext-val
   1.642 +                        ;; Data for the returned search option.
   1.643 +                        ;; A single "nz-number"/"number" value
   1.644 +                        ;; can be returned as an atom (i.e., without
   1.645 +                        ;; quoting).  A sequence-set can be returned
   1.646 +                        ;; as an atom as well.
   1.647 +
   1.648 +   search-modifier-name = tagged-ext-label
   1.649 +
   1.650 +   search-mod-params = tagged-ext-val
   1.651 +                     ;; This non-terminal shows recommended syntax
   1.652 +                     ;; for future extensions.
   1.653 +
   1.654 +
   1.655 +   select          = "SELECT" SP mailbox [select-params]
   1.656 +                     ;; modifies the original IMAP SELECT command to
   1.657 +                     ;; accept optional parameters
   1.658 +
   1.659 +   select-params   = SP "(" select-param *(SP select-param) ")"
   1.660 +
   1.661 +   select-param    = select-param-name [SP select-param-value]
   1.662 +                     ;; a parameter to SELECT may contain one or
   1.663 +                     ;; more atoms and/or strings and/or lists.
   1.664 +
   1.665 +   select-param-name= tagged-ext-label
   1.666 +
   1.667 +   select-param-value= tagged-ext-val
   1.668 +                     ;; This non-terminal shows recommended syntax
   1.669 +                     ;; for future extensions.
   1.670 +
   1.671 +
   1.672 +   status-att-list = status-att-val *(SP status-att-val)
   1.673 +                     ;; Redefines status-att-list from RFC 3501.
   1.674 +
   1.675 +
   1.676 +
   1.677 +Melnikov & Daboo            Standards Track                    [Page 12]
   1.678 +
   1.679 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.680 +
   1.681 +
   1.682 +                     ;; status-att-val is defined in RFC 3501 errata
   1.683 +
   1.684 +   status-att-val  = ("MESSAGES" SP number) /
   1.685 +                     ("RECENT" SP number) /
   1.686 +                     ("UIDNEXT" SP nz-number) /
   1.687 +                     ("UIDVALIDITY" SP nz-number) /
   1.688 +                     ("UNSEEN" SP number)
   1.689 +                     ;; Extensions to the STATUS responses
   1.690 +                     ;; should extend this production.
   1.691 +                     ;; Extensions should use the generic
   1.692 +                     ;; syntax defined by tagged-ext.
   1.693 +
   1.694 +   store           = "STORE" SP sequence-set [store-modifiers]
   1.695 +                     SP store-att-flags
   1.696 +                     ;; extend [IMAP4] STORE command syntax
   1.697 +                     ;; to allow for optional store-modifiers
   1.698 +
   1.699 +   store-modifiers =  SP "(" store-modifier *(SP store-modifier)
   1.700 +                       ")"
   1.701 +
   1.702 +   store-modifier  = store-modifier-name [SP store-modif-params]
   1.703 +
   1.704 +   store-modif-params = tagged-ext-val
   1.705 +                     ;; This non-terminal shows recommended syntax
   1.706 +                     ;; for future extensions.
   1.707 +
   1.708 +   store-modifier-name = tagged-ext-label
   1.709 +
   1.710 +   tag-string         = string
   1.711 +                        ;; tag of the command that caused
   1.712 +                        ;; the ESEARCH response, sent as
   1.713 +                        ;; a string.
   1.714 +
   1.715 +   tagged-ext          = tagged-ext-label SP tagged-ext-val
   1.716 +                          ;; recommended overarching syntax for
   1.717 +                          ;; extensions
   1.718 +
   1.719 +   tagged-ext-label    = tagged-label-fchar *tagged-label-char
   1.720 +                         ;; Is a valid RFC 3501 "atom".
   1.721 +
   1.722 +   tagged-label-fchar  = ALPHA / "-" / "_" / "."
   1.723 +
   1.724 +   tagged-label-char   = tagged-label-fchar / DIGIT / ":"
   1.725 +
   1.726 +
   1.727 +
   1.728 +
   1.729 +
   1.730 +
   1.731 +
   1.732 +
   1.733 +Melnikov & Daboo            Standards Track                    [Page 13]
   1.734 +
   1.735 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.736 +
   1.737 +
   1.738 +   tagged-ext-comp     = astring /
   1.739 +                         tagged-ext-comp *(SP tagged-ext-comp) /
   1.740 +                         "(" tagged-ext-comp ")"
   1.741 +                          ;; Extensions that follow this general
   1.742 +                          ;; syntax should use nstring instead of
   1.743 +                          ;; astring when appropriate in the context
   1.744 +                          ;; of the extension.
   1.745 +                          ;; Note that a message set or a "number"
   1.746 +                          ;; can always be represented as an "atom".
   1.747 +                          ;; An URL should be represented as
   1.748 +                          ;; a "quoted" string.
   1.749 +
   1.750 +   tagged-ext-simple   = sequence-set / number
   1.751 +
   1.752 +   tagged-ext-val      = tagged-ext-simple /
   1.753 +                         "(" [tagged-ext-comp] ")"
   1.754 +
   1.755 +4.  Security Considerations
   1.756 +
   1.757 +   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
   1.758 +   The updated documents must be consulted for security considerations
   1.759 +   for the extensions that they define.
   1.760 +
   1.761 +   As a protocol gets more complex, parser bugs become more common
   1.762 +   including buffer overflow, denial of service, and other common
   1.763 +   security coding errors.  To the extent that this document makes the
   1.764 +   parser more complex, it makes this situation worse.  To the extent
   1.765 +   that this document makes the parser more consistent and thus simpler,
   1.766 +   the situation is improved.  The impact will depend on how many
   1.767 +   deployed IMAP extensions are consistent with this document.
   1.768 +   Implementers are encouraged to take care of these issues when
   1.769 +   extending existing implementations.  Future IMAP extensions should
   1.770 +   strive for consistency and simplicity to the greatest extent
   1.771 +   possible.
   1.772 +
   1.773 +   Extensions to IMAP commands that are permitted in NOT AUTHENTICATED
   1.774 +   state are more sensitive to these security issues due to the larger
   1.775 +   possible attacker community prior to authentication, and the fact
   1.776 +   that some IMAP servers run with elevated privileges in that state.
   1.777 +   This document does not extend any commands permitted in NOT
   1.778 +   AUTHENTICATED state.  Future IMAP extensions to commands permitted in
   1.779 +   NOT AUTHENTICATED state should favor simplicity over consistency or
   1.780 +   extensibility.
   1.781 +
   1.782 +
   1.783 +
   1.784 +
   1.785 +
   1.786 +
   1.787 +
   1.788 +
   1.789 +Melnikov & Daboo            Standards Track                    [Page 14]
   1.790 +
   1.791 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.792 +
   1.793 +
   1.794 +5.  Normative References
   1.795 +
   1.796 +   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
   1.797 +                 Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.798 +
   1.799 +   [IMAP4]       Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
   1.800 +                 VERSION 4rev1", RFC 3501, March 2003.
   1.801 +
   1.802 +   [ABNF]        Crocker, D., Ed., and P. Overell, "Augmented BNF for
   1.803 +                 Syntax Specifications: ABNF", RFC 4234, October 2005.
   1.804 +
   1.805 +   [CHARSET]     Freed, N. and J. Postel, "IANA Charset Registration
   1.806 +                 Procedures", BCP 19, RFC 2978, October 2000.
   1.807 +
   1.808 +   [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
   1.809 +                 MULTIAPPEND Extension", RFC 3502, March 2003.
   1.810 +
   1.811 +   [NAMESPACE]   Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
   1.812 +                 May 1998.
   1.813 +
   1.814 +   [LITERAL+]    Myers, J., "IMAP4 non-synchronizing literals", RFC
   1.815 +                 2088, January 1997.
   1.816 +
   1.817 +   [BINARY]      Nerenberg, L., "IMAP4 Binary Content Extension", RFC
   1.818 +                 3516, April 2003.
   1.819 +
   1.820 +6.  Acknowledgements
   1.821 +
   1.822 +   This documents is based on ideas proposed by Pete Resnick, Mark
   1.823 +   Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon
   1.824 +   Nerenberg.
   1.825 +
   1.826 +   However, all errors and omissions must be attributed to the authors
   1.827 +   of the document.
   1.828 +
   1.829 +   Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman,
   1.830 +   Elwyn Davies, and Barry Leiba for comments and corrections.
   1.831 +
   1.832 +   literal8 syntax was taken from RFC 3516.
   1.833 +
   1.834 +
   1.835 +
   1.836 +
   1.837 +
   1.838 +
   1.839 +
   1.840 +
   1.841 +
   1.842 +
   1.843 +
   1.844 +
   1.845 +Melnikov & Daboo            Standards Track                    [Page 15]
   1.846 +
   1.847 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.848 +
   1.849 +
   1.850 +Authors' Addresses
   1.851 +
   1.852 +   Alexey Melnikov
   1.853 +   Isode Limited
   1.854 +   5 Castle Business Village
   1.855 +   36 Station Road
   1.856 +   Hampton, Middlesex, TW12 2BX
   1.857 +   UK
   1.858 +
   1.859 +   EMail: Alexey.Melnikov@isode.com
   1.860 +
   1.861 +
   1.862 +   Cyrus Daboo
   1.863 +
   1.864 +   EMail: cyrus@daboo.name
   1.865 +
   1.866 +
   1.867 +
   1.868 +
   1.869 +
   1.870 +
   1.871 +
   1.872 +
   1.873 +
   1.874 +
   1.875 +
   1.876 +
   1.877 +
   1.878 +
   1.879 +
   1.880 +
   1.881 +
   1.882 +
   1.883 +
   1.884 +
   1.885 +
   1.886 +
   1.887 +
   1.888 +
   1.889 +
   1.890 +
   1.891 +
   1.892 +
   1.893 +
   1.894 +
   1.895 +
   1.896 +
   1.897 +
   1.898 +
   1.899 +
   1.900 +
   1.901 +Melnikov & Daboo            Standards Track                    [Page 16]
   1.902 +
   1.903 +RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
   1.904 +
   1.905 +
   1.906 +Full Copyright Statement
   1.907 +
   1.908 +   Copyright (C) The Internet Society (2006).
   1.909 +
   1.910 +   This document is subject to the rights, licenses and restrictions
   1.911 +   contained in BCP 78, and except as set forth therein, the authors
   1.912 +   retain all their rights.
   1.913 +
   1.914 +   This document and the information contained herein are provided on an
   1.915 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.916 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   1.917 +   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   1.918 +   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   1.919 +   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.920 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.921 +
   1.922 +Intellectual Property
   1.923 +
   1.924 +   The IETF takes no position regarding the validity or scope of any
   1.925 +   Intellectual Property Rights or other rights that might be claimed to
   1.926 +   pertain to the implementation or use of the technology described in
   1.927 +   this document or the extent to which any license under such rights
   1.928 +   might or might not be available; nor does it represent that it has
   1.929 +   made any independent effort to identify any such rights.  Information
   1.930 +   on the procedures with respect to rights in RFC documents can be
   1.931 +   found in BCP 78 and BCP 79.
   1.932 +
   1.933 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.934 +   assurances of licenses to be made available, or the result of an
   1.935 +   attempt made to obtain a general license or permission for the use of
   1.936 +   such proprietary rights by implementers or users of this
   1.937 +   specification can be obtained from the IETF on-line IPR repository at
   1.938 +   http://www.ietf.org/ipr.
   1.939 +
   1.940 +   The IETF invites any interested party to bring to its attention any
   1.941 +   copyrights, patents or patent applications, or other proprietary
   1.942 +   rights that may cover technology that may be required to implement
   1.943 +   this standard.  Please address the information to the IETF at
   1.944 +   ietf-ipr@ietf.org.
   1.945 +
   1.946 +Acknowledgement
   1.947 +
   1.948 +   Funding for the RFC Editor function is provided by the IETF
   1.949 +   Administrative Support Activity (IASA).
   1.950 +
   1.951 +
   1.952 +
   1.953 +
   1.954 +
   1.955 +
   1.956 +
   1.957 +Melnikov & Daboo            Standards Track                    [Page 17]
   1.958 +