doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc4466.txt b/doc/rfc/rfc4466.txt
new file mode 100644
index 0000000..dfde168
--- /dev/null
+++ b/doc/rfc/rfc4466.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                        A. Melnikov
+Request for Comments: 4466                                    Isode Ltd.
+Updates: 2088, 2342, 3501, 3502, 3516                           C. Daboo
+Category: Standards Track                                     April 2006
+
+
+                   Collected Extensions to IMAP4 ABNF
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Over the years, many documents from IMAPEXT and LEMONADE working
+   groups, as well as many individual documents, have added syntactic
+   extensions to many base IMAP commands described in RFC 3501.  For
+   ease of reference, this document collects most of such ABNF changes
+   in one place.
+
+   This document also suggests a set of standard patterns for adding
+   options and extensions to several existing IMAP commands defined in
+   RFC 3501.  The patterns provide for compatibility between existing
+   and future extensions.
+
+   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
+   It also includes part of the errata to RFC 3501.  This document
+   doesn't specify any semantic changes to the listed RFCs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 1]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Purpose of This Document ...................................2
+      1.2. Conventions Used in This Document ..........................3
+   2. IMAP ABNF Extensions ............................................3
+      2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
+      2.2. Extended CREATE Command ....................................4
+      2.3. Extended RENAME Command ....................................5
+      2.4. Extensions to FETCH and UID FETCH Commands .................6
+      2.5. Extensions to STORE and UID STORE Commands .................6
+      2.6. Extensions to SEARCH Command ...............................7
+           2.6.1. Extended SEARCH Command .............................7
+           2.6.2. ESEARCH untagged response ...........................8
+      2.7. Extensions to APPEND Command ...............................8
+   3. Formal Syntax ...................................................9
+   4. Security Considerations ........................................14
+   5. Normative References ...........................................15
+   6. Acknowledgements ...............................................15
+
+1.  Introduction
+
+1.1.  Purpose of This Document
+
+   This document serves several purposes:
+
+      1.  rationalize and generalize ABNF for some existing IMAP
+          extensions;
+      2.  collect the ABNF in one place in order to minimize cross
+          references between documents;
+      3.  define building blocks for future extensions so that they can
+          be used together in a compatible way.
+
+   It is expected that a future revision of this document will be
+   incorporated into a revision of RFC 3501.
+
+   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
+   It also includes part of the errata to RFC 3501.  This document
+   doesn't specify any semantic changes to the listed RFCs.
+
+   The ABNF in section 6 of RFC 2342 got rewritten to conform to the
+   ABNF syntax as defined in RFC 4234 and to reference new non-terminals
+   from RFC 3501.  It was also restructured to allow for better
+   readability.  There were no changes "on the wire".
+
+   Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH/UID
+   FETCH, STORE/UID STORE, SEARCH, and APPEND commands in a consistent
+   manner.  Extensions to all the commands but APPEND have the same
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 2]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   structure.  Extensibility for the APPEND command was done slightly
+   differently in order to preserve backward compatibility with existing
+   extensions.
+
+   Section 2 also defines a new ESEARCH response, whose purpose is to
+   define a better version of the SEARCH response defined in RFC 3501.
+
+   Section 3 defines the collected ABNF that replaces pieces of ABNF in
+   the aforementioned RFCs.  The collected ABNF got generalized to allow
+   for easier future extensibility.
+
+1.2.  Conventions Used in This Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server, respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+2.  IMAP ABNF Extensions
+
+   This section is not normative.  It provides some background on the
+   intended use of different extensions and it gives some guidance about
+   how future extensions should extend the described commands.
+
+2.1.  Optional Parameters with the SELECT/EXAMINE Commands
+
+   This document adds the ability to include one or more parameters with
+   the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2
+   of [IMAP4]) commands, to turn on or off certain standard behaviors,
+   or to add new optional behaviors required for a particular extension.
+
+   There are two possible modes of operation:
+
+   o  A global state change where a single use of the optional parameter
+      will affect the session state from that time on, irrespective of
+      subsequent SELECT/EXAMINE commands.
+
+   o  A per-mailbox state change that will affect the session only for
+      the duration of the new selected state.  A subsequent
+      SELECT/EXAMINE without the optional parameter will cancel its
+      effect for the newly selected mailbox.
+
+   Optional parameters to the SELECT or EXAMINE commands are added as a
+   parenthesized list of attribute/value pairs, and appear after the
+   mailbox name in the standard SELECT or EXAMINE command.  The order of
+   individual parameters is arbitrary.  A parameter value is optional
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 3]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   and may consist of atoms, strings, or lists in a specific order.  If
+   the parameter value is present, it always appears in parentheses (*).
+   Any parameter not defined by extensions that the server supports must
+   be rejected with a BAD response.
+
+      Example:
+
+              C: a SELECT INBOX (ANNOTATE)
+              S: ...
+              S: a OK SELECT complete
+
+      In the above example, a single parameter is used with the SELECT
+      command.
+
+      Example:
+
+              C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
+                 CONDSTORE)
+              S: ...
+              S: a OK EXAMINE complete
+
+      In the above example, three parameters are used with the EXAMINE
+      command.  The second parameter consists of two items: an atom
+      "RESPONSES" followed by a quoted string.
+
+      Example:
+
+              C: a SELECT INBOX (BLURDYBLOOP)
+              S: a BAD Unknown parameter in SELECT command
+
+      In the above example, a parameter not supported by the server is
+      used.  This results in the BAD response from the server.
+
+   (*) - if a parameter has a mandatory value, which can always be
+   represented as a number or a sequence-set, the parameter value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.2.  Extended CREATE Command
+
+   Arguments:  mailbox name
+               OPTIONAL list of CREATE parameters
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - create completed
+               NO - create failure: cannot create mailbox with
+                    that name
+               BAD - argument(s) invalid
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 4]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   This document adds the ability to include one or more parameters with
+   the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to turn on or
+   off certain standard behaviors, or to add new optional behaviors
+   required for a particular extension.  No CREATE parameters are
+   defined in this document.
+
+   Optional parameters to the CREATE command are added as a
+   parenthesized list of attribute/value pairs after the mailbox name.
+   The order of individual parameters is arbitrary.  A parameter value
+   is optional and may consist of atoms, strings, or lists in a specific
+   order.  If the parameter value is present, it always appears in
+   parentheses (*).  Any parameter not defined by extensions that the
+   server supports must be rejected with a BAD response.
+
+   (*) - if a parameter has a mandatory value, which can always be
+   represented as a number or a sequence-set, the parameter value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.3.  Extended RENAME Command
+
+   Arguments:  existing mailbox name
+               new mailbox name
+               OPTIONAL list of RENAME parameters
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - rename completed
+               NO - rename failure: cannot rename mailbox with
+                    that name, cannot rename to mailbox with
+                    that name, etc.
+               BAD - argument(s) invalid
+
+   This document adds the ability to include one or more parameters with
+   the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to turn on or
+   off certain standard behaviors, or to add new optional behaviors
+   required for a particular extension.  No RENAME parameters are
+   defined in this document.
+
+   Optional parameters to the RENAME command are added as a
+   parenthesized list of attribute/value pairs after the new mailbox
+   name.  The order of individual parameters is arbitrary.  A parameter
+   value is optional and may consist of atoms, strings, or lists in a
+   specific order.  If the parameter value is present, it always appears
+   in parentheses (*).  Any parameter not defined by extensions that the
+   server supports must be rejected with a BAD response.
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 5]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   (*) - if a parameter has a mandatory value, which can always be
+   represented as a number or a sequence-set, the parameter value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.4.  Extensions to FETCH and UID FETCH Commands
+
+   Arguments:  sequence set
+               message data item names or macro
+               OPTIONAL fetch modifiers
+
+   Responses:  untagged responses: FETCH
+
+   Result:     OK - fetch completed
+               NO - fetch error: cannot fetch that data
+               BAD - command unknown or arguments invalid
+
+   This document extends the syntax of the FETCH and UID FETCH commands
+   (see section 6.4.5 of [IMAP4]) to include optional FETCH modifiers.
+   No fetch modifiers are defined in this document.
+
+   The order of individual modifiers is arbitrary.  Each modifier is an
+   attribute/value pair.  A modifier value is optional and may consist
+   of atoms and/or strings and/or lists in a specific order.  If the
+   modifier value is present, it always appears in parentheses (*).  Any
+   modifiers not defined by extensions that the server supports must be
+   rejected with a BAD response.
+
+   (*) - if a modifier has a mandatory value, which can always be
+   represented as a number or a sequence-set, the modifier value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.5.  Extensions to STORE and UID STORE Commands
+
+   Arguments:  message set
+               OPTIONAL store modifiers
+               message data item name
+               value for message data item
+
+   Responses:  untagged responses: FETCH
+
+   Result:     OK - store completed
+               NO - store error: cannot store that data
+               BAD - command unknown or arguments invalid
+
+   This document extends the syntax of the STORE and UID STORE commands
+   (see section 6.4.6 of [IMAP4]) to include optional STORE modifiers.
+   No store modifiers are defined in this document.
+
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 6]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   The order of individual modifiers is arbitrary.  Each modifier is an
+   attribute/value pair.  A modifier value is optional and may consist
+   of atoms and/or strings and/or lists in a specific order.  If the
+   modifier value is present, it always appears in parentheses (*).  Any
+   modifiers not defined by extensions that the server supports must be
+   rejected with a BAD response.
+
+   (*) - if a modifier has a mandatory value, which can always be
+   represented as a number or a sequence-set, the modifier value does
+   not need the enclosing ().  See ABNF for more details.
+
+2.6.  Extensions to SEARCH Command
+
+2.6.1.  Extended SEARCH Command
+
+   Arguments:  OPTIONAL result specifier
+               OPTIONAL [CHARSET] specification
+               searching criteria (one or more)
+
+   Responses:  REQUIRED untagged response: SEARCH (*)
+
+   Result:     OK - search completed
+               NO - search error: cannot search that [CHARSET] or
+                    criteria
+               BAD - command unknown or arguments invalid
+
+   This section updates definition of the SEARCH command described in
+   section 6.4.4 of [IMAP4].
+
+   The SEARCH command is extended to allow for result options.  This
+   document does not define any result options.
+
+   The order of individual options is arbitrary.  Individual options may
+   contain parameters enclosed in parentheses (**).  If an option has
+   parameters, they consist of atoms and/or strings and/or lists in a
+   specific order.  Any options not defined by extensions that the
+   server supports must be rejected with a BAD response.
+
+   (*) - An extension to the SEARCH command may require another untagged
+   response, or no untagged response to be returned.  Section 2.6.2
+   defines a new ESEARCH untagged response that replaces the SEARCH
+   untagged response.  Note that for a given extended SEARCH command the
+   SEARCH and ESEARCH responses SHOULD be mutually exclusive, i.e., only
+   one of them should be returned.
+
+   (**) - if an option has a mandatory parameter, which can always be
+   represented as a number or a sequence-set, the option parameter does
+   not need the enclosing ().  See ABNF for more details.
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 7]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+2.6.2.  ESEARCH untagged response
+
+   Contents:   one or more search-return-data pairs
+
+   The ESEARCH response SHOULD be sent as a result of an extended SEARCH
+   or UID SEARCH command specified in section 2.6.1.
+
+   The ESEARCH response starts with an optional search correlator.  If
+   it is missing, then the response was not caused by a particular IMAP
+   command, whereas if it is present, it contains the tag of the command
+   that caused the response to be returned.
+
+   The search correlator is followed by an optional UID indicator.  If
+   this indicator is present, all data in the ESEARCH response refers to
+   UIDs, otherwise all returned data refers to message numbers.
+
+   The rest of the ESEARCH response contains one or more search data
+   pairs.  Each pair starts with unique return item name, followed by a
+   space and the corresponding data.  Search data pairs may be returned
+   in any order.  Unless specified otherwise by an extension, any return
+   item name SHOULD appear only once in an ESEARCH response.
+
+   Example:    S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
+
+   Example:    S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
+
+   Example:    S: * ESEARCH COUNT 5 ALL 1:17,21
+
+2.7.  Extensions to APPEND Command
+
+   The IMAP BINARY extension [BINARY] extends the APPEND command to
+   allow a client to append data containing NULs by using the <literal8>
+   syntax.  The ABNF was rewritten to allow for easier extensibility by
+   IMAP extensions.  This document hasn't specified any semantical
+   changes to the [BINARY] extension.
+
+   In addition, the non-terminal "literal8" defined in [BINARY] got
+   extended to allow for non-synchronizing literals if both [BINARY] and
+   [LITERAL+] extensions are supported by the server.
+
+   The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND
+   command to allow a client to append multiple messages atomically.
+   This document defines a common syntax for the APPEND command that
+   takes into consideration syntactic extensions defined by both
+   [BINARY] and [MULTIAPPEND] extensions.
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 8]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+3.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) notation as specified in [ABNF].
+
+   Non-terminals referenced but not defined below are as defined by
+   [IMAP4].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of uppercase or lowercase characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   append          = "APPEND" SP mailbox 1*append-message
+                     ;; only a single append-message may appear
+                     ;; if MULTIAPPEND [MULTIAPPEND] capability
+                     ;; is not present
+
+   append-message  = append-opts SP append-data
+
+   append-ext      = append-ext-name SP append-ext-value
+                     ;; This non-terminal define extensions to
+                     ;; to message metadata.
+
+   append-ext-name = tagged-ext-label
+
+   append-ext-value= tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   append-data     = literal / literal8 / append-data-ext
+
+   append-data-ext = tagged-ext
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions,
+                     ;; i.e., a mandatory label followed
+                     ;; by parameters.
+
+   append-opts     = [SP flag-list] [SP date-time] *(SP append-ext)
+                     ;; message metadata
+
+   charset         = atom / quoted
+                     ;; Exact syntax is defined in [CHARSET].
+
+   create          = "CREATE" SP mailbox
+                     [create-params]
+                     ;; Use of INBOX gives a NO error.
+
+
+
+Melnikov & Daboo            Standards Track                     [Page 9]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   create-params   = SP "(" create-param *( SP create-param) ")"
+
+   create-param-name = tagged-ext-label
+
+   create-param      = create-param-name [SP create-param-value]
+
+   create-param-value= tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   esearch-response  = "ESEARCH" [search-correlator] [SP "UID"]
+                        *(SP search-return-data)
+                      ;; Note that SEARCH and ESEARCH responses
+                      ;; SHOULD be mutually exclusive,
+                      ;; i.e., only one of the response types
+                      ;; should be
+                      ;; returned as a result of a command.
+
+
+   examine         = "EXAMINE" SP mailbox [select-params]
+                     ;; modifies the original IMAP EXAMINE command
+                     ;; to accept optional parameters
+
+   fetch           = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
+                     "FAST" / fetch-att /
+                     "(" fetch-att *(SP fetch-att) ")")
+                     [fetch-modifiers]
+                     ;; modifies the original IMAP4 FETCH command to
+                     ;; accept optional modifiers
+
+   fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
+
+   fetch-modifier  = fetch-modifier-name [ SP fetch-modif-params ]
+
+   fetch-modif-params  = tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+   fetch-modifier-name = tagged-ext-label
+
+   literal8        = "~{" number ["+"] "}" CRLF *OCTET
+                      ;; A string that might contain NULs.
+                      ;; <number> represents the number of OCTETs
+                      ;; in the response string.
+                      ;; The "+" is only allowed when both LITERAL+ and
+                      ;; BINARY extensions are supported by the server.
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 10]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   mailbox-data      =/ Namespace-Response /
+                        esearch-response
+
+   Namespace         = nil / "(" 1*Namespace-Descr ")"
+
+   Namespace-Command = "NAMESPACE"
+
+   Namespace-Descr   = "(" string SP
+                          (DQUOTE QUOTED-CHAR DQUOTE / nil)
+                           *(Namespace-Response-Extension) ")"
+
+   Namespace-Response-Extension = SP string SP
+                     "(" string *(SP string) ")"
+
+   Namespace-Response = "NAMESPACE" SP Namespace
+                        SP Namespace SP Namespace
+         ;; This response is currently only allowed
+         ;; if the IMAP server supports [NAMESPACE].
+         ;; The first Namespace is the Personal Namespace(s)
+         ;; The second Namespace is the Other Users' Namespace(s)
+         ;; The third Namespace is the Shared Namespace(s)
+
+   rename          = "RENAME" SP mailbox SP mailbox
+                     [rename-params]
+                     ;; Use of INBOX as a destination gives
+                     ;; a NO error, unless rename-params
+                     ;; is not empty.
+
+   rename-params     = SP "(" rename-param *( SP rename-param) ")"
+
+   rename-param      = rename-param-name [SP rename-param-value]
+
+   rename-param-name = tagged-ext-label
+
+   rename-param-value= tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   response-data   = "*" SP response-payload CRLF
+
+   response-payload= resp-cond-state / resp-cond-bye /
+                     mailbox-data / message-data / capability-data
+
+   search          = "SEARCH" [search-return-opts]
+                     SP search-program
+
+   search-correlator  = SP "(" "TAG" SP tag-string ")"
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 11]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   search-program     = ["CHARSET" SP charset SP]
+                        search-key *(SP search-key)
+                        ;; CHARSET argument to SEARCH MUST be
+                        ;; registered with IANA.
+
+   search-return-data = search-modifier-name SP search-return-value
+                        ;; Note that not every SEARCH return option
+                        ;; is required to have the corresponding
+                        ;; ESEARCH return data.
+
+   search-return-opts = SP "RETURN" SP "(" [search-return-opt
+                        *(SP search-return-opt)] ")"
+
+   search-return-opt = search-modifier-name [SP search-mod-params]
+
+   search-return-value = tagged-ext-val
+                        ;; Data for the returned search option.
+                        ;; A single "nz-number"/"number" value
+                        ;; can be returned as an atom (i.e., without
+                        ;; quoting).  A sequence-set can be returned
+                        ;; as an atom as well.
+
+   search-modifier-name = tagged-ext-label
+
+   search-mod-params = tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   select          = "SELECT" SP mailbox [select-params]
+                     ;; modifies the original IMAP SELECT command to
+                     ;; accept optional parameters
+
+   select-params   = SP "(" select-param *(SP select-param) ")"
+
+   select-param    = select-param-name [SP select-param-value]
+                     ;; a parameter to SELECT may contain one or
+                     ;; more atoms and/or strings and/or lists.
+
+   select-param-name= tagged-ext-label
+
+   select-param-value= tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+
+   status-att-list = status-att-val *(SP status-att-val)
+                     ;; Redefines status-att-list from RFC 3501.
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 12]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+                     ;; status-att-val is defined in RFC 3501 errata
+
+   status-att-val  = ("MESSAGES" SP number) /
+                     ("RECENT" SP number) /
+                     ("UIDNEXT" SP nz-number) /
+                     ("UIDVALIDITY" SP nz-number) /
+                     ("UNSEEN" SP number)
+                     ;; Extensions to the STATUS responses
+                     ;; should extend this production.
+                     ;; Extensions should use the generic
+                     ;; syntax defined by tagged-ext.
+
+   store           = "STORE" SP sequence-set [store-modifiers]
+                     SP store-att-flags
+                     ;; extend [IMAP4] STORE command syntax
+                     ;; to allow for optional store-modifiers
+
+   store-modifiers =  SP "(" store-modifier *(SP store-modifier)
+                       ")"
+
+   store-modifier  = store-modifier-name [SP store-modif-params]
+
+   store-modif-params = tagged-ext-val
+                     ;; This non-terminal shows recommended syntax
+                     ;; for future extensions.
+
+   store-modifier-name = tagged-ext-label
+
+   tag-string         = string
+                        ;; tag of the command that caused
+                        ;; the ESEARCH response, sent as
+                        ;; a string.
+
+   tagged-ext          = tagged-ext-label SP tagged-ext-val
+                          ;; recommended overarching syntax for
+                          ;; extensions
+
+   tagged-ext-label    = tagged-label-fchar *tagged-label-char
+                         ;; Is a valid RFC 3501 "atom".
+
+   tagged-label-fchar  = ALPHA / "-" / "_" / "."
+
+   tagged-label-char   = tagged-label-fchar / DIGIT / ":"
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 13]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+   tagged-ext-comp     = astring /
+                         tagged-ext-comp *(SP tagged-ext-comp) /
+                         "(" tagged-ext-comp ")"
+                          ;; Extensions that follow this general
+                          ;; syntax should use nstring instead of
+                          ;; astring when appropriate in the context
+                          ;; of the extension.
+                          ;; Note that a message set or a "number"
+                          ;; can always be represented as an "atom".
+                          ;; An URL should be represented as
+                          ;; a "quoted" string.
+
+   tagged-ext-simple   = sequence-set / number
+
+   tagged-ext-val      = tagged-ext-simple /
+                         "(" [tagged-ext-comp] ")"
+
+4.  Security Considerations
+
+   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
+   The updated documents must be consulted for security considerations
+   for the extensions that they define.
+
+   As a protocol gets more complex, parser bugs become more common
+   including buffer overflow, denial of service, and other common
+   security coding errors.  To the extent that this document makes the
+   parser more complex, it makes this situation worse.  To the extent
+   that this document makes the parser more consistent and thus simpler,
+   the situation is improved.  The impact will depend on how many
+   deployed IMAP extensions are consistent with this document.
+   Implementers are encouraged to take care of these issues when
+   extending existing implementations.  Future IMAP extensions should
+   strive for consistency and simplicity to the greatest extent
+   possible.
+
+   Extensions to IMAP commands that are permitted in NOT AUTHENTICATED
+   state are more sensitive to these security issues due to the larger
+   possible attacker community prior to authentication, and the fact
+   that some IMAP servers run with elevated privileges in that state.
+   This document does not extend any commands permitted in NOT
+   AUTHENTICATED state.  Future IMAP extensions to commands permitted in
+   NOT AUTHENTICATED state should favor simplicity over consistency or
+   extensibility.
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 14]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+5.  Normative References
+
+   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IMAP4]       Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                 VERSION 4rev1", RFC 3501, March 2003.
+
+   [ABNF]        Crocker, D., Ed., and P. Overell, "Augmented BNF for
+                 Syntax Specifications: ABNF", RFC 4234, October 2005.
+
+   [CHARSET]     Freed, N. and J. Postel, "IANA Charset Registration
+                 Procedures", BCP 19, RFC 2978, October 2000.
+
+   [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
+                 MULTIAPPEND Extension", RFC 3502, March 2003.
+
+   [NAMESPACE]   Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
+                 May 1998.
+
+   [LITERAL+]    Myers, J., "IMAP4 non-synchronizing literals", RFC
+                 2088, January 1997.
+
+   [BINARY]      Nerenberg, L., "IMAP4 Binary Content Extension", RFC
+                 3516, April 2003.
+
+6.  Acknowledgements
+
+   This documents is based on ideas proposed by Pete Resnick, Mark
+   Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon
+   Nerenberg.
+
+   However, all errors and omissions must be attributed to the authors
+   of the document.
+
+   Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman,
+   Elwyn Davies, and Barry Leiba for comments and corrections.
+
+   literal8 syntax was taken from RFC 3516.
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 15]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+Authors' Addresses
+
+   Alexey Melnikov
+   Isode Limited
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex, TW12 2BX
+   UK
+
+   EMail: Alexey.Melnikov@isode.com
+
+
+   Cyrus Daboo
+
+   EMail: cyrus@daboo.name
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 16]
+
+RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Melnikov & Daboo            Standards Track                    [Page 17]
+