956 lines
33 KiB
Plaintext
956 lines
33 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|