imapext-2007

annotate docs/rfc/rfc4466.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group A. Melnikov
yuuji@0 8 Request for Comments: 4466 Isode Ltd.
yuuji@0 9 Updates: 2088, 2342, 3501, 3502, 3516 C. Daboo
yuuji@0 10 Category: Standards Track April 2006
yuuji@0 11
yuuji@0 12
yuuji@0 13 Collected Extensions to IMAP4 ABNF
yuuji@0 14
yuuji@0 15 Status of This Memo
yuuji@0 16
yuuji@0 17 This document specifies an Internet standards track protocol for the
yuuji@0 18 Internet community, and requests discussion and suggestions for
yuuji@0 19 improvements. Please refer to the current edition of the "Internet
yuuji@0 20 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 21 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 22
yuuji@0 23 Copyright Notice
yuuji@0 24
yuuji@0 25 Copyright (C) The Internet Society (2006).
yuuji@0 26
yuuji@0 27 Abstract
yuuji@0 28
yuuji@0 29 Over the years, many documents from IMAPEXT and LEMONADE working
yuuji@0 30 groups, as well as many individual documents, have added syntactic
yuuji@0 31 extensions to many base IMAP commands described in RFC 3501. For
yuuji@0 32 ease of reference, this document collects most of such ABNF changes
yuuji@0 33 in one place.
yuuji@0 34
yuuji@0 35 This document also suggests a set of standard patterns for adding
yuuji@0 36 options and extensions to several existing IMAP commands defined in
yuuji@0 37 RFC 3501. The patterns provide for compatibility between existing
yuuji@0 38 and future extensions.
yuuji@0 39
yuuji@0 40 This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
yuuji@0 41 It also includes part of the errata to RFC 3501. This document
yuuji@0 42 doesn't specify any semantic changes to the listed RFCs.
yuuji@0 43
yuuji@0 44
yuuji@0 45
yuuji@0 46
yuuji@0 47
yuuji@0 48
yuuji@0 49
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Melnikov & Daboo Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 61
yuuji@0 62
yuuji@0 63 Table of Contents
yuuji@0 64
yuuji@0 65 1. Introduction ....................................................2
yuuji@0 66 1.1. Purpose of This Document ...................................2
yuuji@0 67 1.2. Conventions Used in This Document ..........................3
yuuji@0 68 2. IMAP ABNF Extensions ............................................3
yuuji@0 69 2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
yuuji@0 70 2.2. Extended CREATE Command ....................................4
yuuji@0 71 2.3. Extended RENAME Command ....................................5
yuuji@0 72 2.4. Extensions to FETCH and UID FETCH Commands .................6
yuuji@0 73 2.5. Extensions to STORE and UID STORE Commands .................6
yuuji@0 74 2.6. Extensions to SEARCH Command ...............................7
yuuji@0 75 2.6.1. Extended SEARCH Command .............................7
yuuji@0 76 2.6.2. ESEARCH untagged response ...........................8
yuuji@0 77 2.7. Extensions to APPEND Command ...............................8
yuuji@0 78 3. Formal Syntax ...................................................9
yuuji@0 79 4. Security Considerations ........................................14
yuuji@0 80 5. Normative References ...........................................15
yuuji@0 81 6. Acknowledgements ...............................................15
yuuji@0 82
yuuji@0 83 1. Introduction
yuuji@0 84
yuuji@0 85 1.1. Purpose of This Document
yuuji@0 86
yuuji@0 87 This document serves several purposes:
yuuji@0 88
yuuji@0 89 1. rationalize and generalize ABNF for some existing IMAP
yuuji@0 90 extensions;
yuuji@0 91 2. collect the ABNF in one place in order to minimize cross
yuuji@0 92 references between documents;
yuuji@0 93 3. define building blocks for future extensions so that they can
yuuji@0 94 be used together in a compatible way.
yuuji@0 95
yuuji@0 96 It is expected that a future revision of this document will be
yuuji@0 97 incorporated into a revision of RFC 3501.
yuuji@0 98
yuuji@0 99 This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
yuuji@0 100 It also includes part of the errata to RFC 3501. This document
yuuji@0 101 doesn't specify any semantic changes to the listed RFCs.
yuuji@0 102
yuuji@0 103 The ABNF in section 6 of RFC 2342 got rewritten to conform to the
yuuji@0 104 ABNF syntax as defined in RFC 4234 and to reference new non-terminals
yuuji@0 105 from RFC 3501. It was also restructured to allow for better
yuuji@0 106 readability. There were no changes "on the wire".
yuuji@0 107
yuuji@0 108 Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH/UID
yuuji@0 109 FETCH, STORE/UID STORE, SEARCH, and APPEND commands in a consistent
yuuji@0 110 manner. Extensions to all the commands but APPEND have the same
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Melnikov & Daboo Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 117
yuuji@0 118
yuuji@0 119 structure. Extensibility for the APPEND command was done slightly
yuuji@0 120 differently in order to preserve backward compatibility with existing
yuuji@0 121 extensions.
yuuji@0 122
yuuji@0 123 Section 2 also defines a new ESEARCH response, whose purpose is to
yuuji@0 124 define a better version of the SEARCH response defined in RFC 3501.
yuuji@0 125
yuuji@0 126 Section 3 defines the collected ABNF that replaces pieces of ABNF in
yuuji@0 127 the aforementioned RFCs. The collected ABNF got generalized to allow
yuuji@0 128 for easier future extensibility.
yuuji@0 129
yuuji@0 130 1.2. Conventions Used in This Document
yuuji@0 131
yuuji@0 132 In examples, "C:" and "S:" indicate lines sent by the client and
yuuji@0 133 server, respectively.
yuuji@0 134
yuuji@0 135 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
yuuji@0 136 in this document are to be interpreted as defined in "Key words for
yuuji@0 137 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
yuuji@0 138
yuuji@0 139 2. IMAP ABNF Extensions
yuuji@0 140
yuuji@0 141 This section is not normative. It provides some background on the
yuuji@0 142 intended use of different extensions and it gives some guidance about
yuuji@0 143 how future extensions should extend the described commands.
yuuji@0 144
yuuji@0 145 2.1. Optional Parameters with the SELECT/EXAMINE Commands
yuuji@0 146
yuuji@0 147 This document adds the ability to include one or more parameters with
yuuji@0 148 the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2
yuuji@0 149 of [IMAP4]) commands, to turn on or off certain standard behaviors,
yuuji@0 150 or to add new optional behaviors required for a particular extension.
yuuji@0 151
yuuji@0 152 There are two possible modes of operation:
yuuji@0 153
yuuji@0 154 o A global state change where a single use of the optional parameter
yuuji@0 155 will affect the session state from that time on, irrespective of
yuuji@0 156 subsequent SELECT/EXAMINE commands.
yuuji@0 157
yuuji@0 158 o A per-mailbox state change that will affect the session only for
yuuji@0 159 the duration of the new selected state. A subsequent
yuuji@0 160 SELECT/EXAMINE without the optional parameter will cancel its
yuuji@0 161 effect for the newly selected mailbox.
yuuji@0 162
yuuji@0 163 Optional parameters to the SELECT or EXAMINE commands are added as a
yuuji@0 164 parenthesized list of attribute/value pairs, and appear after the
yuuji@0 165 mailbox name in the standard SELECT or EXAMINE command. The order of
yuuji@0 166 individual parameters is arbitrary. A parameter value is optional
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Melnikov & Daboo Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 173
yuuji@0 174
yuuji@0 175 and may consist of atoms, strings, or lists in a specific order. If
yuuji@0 176 the parameter value is present, it always appears in parentheses (*).
yuuji@0 177 Any parameter not defined by extensions that the server supports must
yuuji@0 178 be rejected with a BAD response.
yuuji@0 179
yuuji@0 180 Example:
yuuji@0 181
yuuji@0 182 C: a SELECT INBOX (ANNOTATE)
yuuji@0 183 S: ...
yuuji@0 184 S: a OK SELECT complete
yuuji@0 185
yuuji@0 186 In the above example, a single parameter is used with the SELECT
yuuji@0 187 command.
yuuji@0 188
yuuji@0 189 Example:
yuuji@0 190
yuuji@0 191 C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
yuuji@0 192 CONDSTORE)
yuuji@0 193 S: ...
yuuji@0 194 S: a OK EXAMINE complete
yuuji@0 195
yuuji@0 196 In the above example, three parameters are used with the EXAMINE
yuuji@0 197 command. The second parameter consists of two items: an atom
yuuji@0 198 "RESPONSES" followed by a quoted string.
yuuji@0 199
yuuji@0 200 Example:
yuuji@0 201
yuuji@0 202 C: a SELECT INBOX (BLURDYBLOOP)
yuuji@0 203 S: a BAD Unknown parameter in SELECT command
yuuji@0 204
yuuji@0 205 In the above example, a parameter not supported by the server is
yuuji@0 206 used. This results in the BAD response from the server.
yuuji@0 207
yuuji@0 208 (*) - if a parameter has a mandatory value, which can always be
yuuji@0 209 represented as a number or a sequence-set, the parameter value does
yuuji@0 210 not need the enclosing (). See ABNF for more details.
yuuji@0 211
yuuji@0 212 2.2. Extended CREATE Command
yuuji@0 213
yuuji@0 214 Arguments: mailbox name
yuuji@0 215 OPTIONAL list of CREATE parameters
yuuji@0 216
yuuji@0 217 Responses: no specific responses for this command
yuuji@0 218
yuuji@0 219 Result: OK - create completed
yuuji@0 220 NO - create failure: cannot create mailbox with
yuuji@0 221 that name
yuuji@0 222 BAD - argument(s) invalid
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Melnikov & Daboo Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 229
yuuji@0 230
yuuji@0 231 This document adds the ability to include one or more parameters with
yuuji@0 232 the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to turn on or
yuuji@0 233 off certain standard behaviors, or to add new optional behaviors
yuuji@0 234 required for a particular extension. No CREATE parameters are
yuuji@0 235 defined in this document.
yuuji@0 236
yuuji@0 237 Optional parameters to the CREATE command are added as a
yuuji@0 238 parenthesized list of attribute/value pairs after the mailbox name.
yuuji@0 239 The order of individual parameters is arbitrary. A parameter value
yuuji@0 240 is optional and may consist of atoms, strings, or lists in a specific
yuuji@0 241 order. If the parameter value is present, it always appears in
yuuji@0 242 parentheses (*). Any parameter not defined by extensions that the
yuuji@0 243 server supports must be rejected with a BAD response.
yuuji@0 244
yuuji@0 245 (*) - if a parameter has a mandatory value, which can always be
yuuji@0 246 represented as a number or a sequence-set, the parameter value does
yuuji@0 247 not need the enclosing (). See ABNF for more details.
yuuji@0 248
yuuji@0 249 2.3. Extended RENAME Command
yuuji@0 250
yuuji@0 251 Arguments: existing mailbox name
yuuji@0 252 new mailbox name
yuuji@0 253 OPTIONAL list of RENAME parameters
yuuji@0 254
yuuji@0 255 Responses: no specific responses for this command
yuuji@0 256
yuuji@0 257 Result: OK - rename completed
yuuji@0 258 NO - rename failure: cannot rename mailbox with
yuuji@0 259 that name, cannot rename to mailbox with
yuuji@0 260 that name, etc.
yuuji@0 261 BAD - argument(s) invalid
yuuji@0 262
yuuji@0 263 This document adds the ability to include one or more parameters with
yuuji@0 264 the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to turn on or
yuuji@0 265 off certain standard behaviors, or to add new optional behaviors
yuuji@0 266 required for a particular extension. No RENAME parameters are
yuuji@0 267 defined in this document.
yuuji@0 268
yuuji@0 269 Optional parameters to the RENAME command are added as a
yuuji@0 270 parenthesized list of attribute/value pairs after the new mailbox
yuuji@0 271 name. The order of individual parameters is arbitrary. A parameter
yuuji@0 272 value is optional and may consist of atoms, strings, or lists in a
yuuji@0 273 specific order. If the parameter value is present, it always appears
yuuji@0 274 in parentheses (*). Any parameter not defined by extensions that the
yuuji@0 275 server supports must be rejected with a BAD response.
yuuji@0 276
yuuji@0 277
yuuji@0 278
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Melnikov & Daboo Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 285
yuuji@0 286
yuuji@0 287 (*) - if a parameter has a mandatory value, which can always be
yuuji@0 288 represented as a number or a sequence-set, the parameter value does
yuuji@0 289 not need the enclosing (). See ABNF for more details.
yuuji@0 290
yuuji@0 291 2.4. Extensions to FETCH and UID FETCH Commands
yuuji@0 292
yuuji@0 293 Arguments: sequence set
yuuji@0 294 message data item names or macro
yuuji@0 295 OPTIONAL fetch modifiers
yuuji@0 296
yuuji@0 297 Responses: untagged responses: FETCH
yuuji@0 298
yuuji@0 299 Result: OK - fetch completed
yuuji@0 300 NO - fetch error: cannot fetch that data
yuuji@0 301 BAD - command unknown or arguments invalid
yuuji@0 302
yuuji@0 303 This document extends the syntax of the FETCH and UID FETCH commands
yuuji@0 304 (see section 6.4.5 of [IMAP4]) to include optional FETCH modifiers.
yuuji@0 305 No fetch modifiers are defined in this document.
yuuji@0 306
yuuji@0 307 The order of individual modifiers is arbitrary. Each modifier is an
yuuji@0 308 attribute/value pair. A modifier value is optional and may consist
yuuji@0 309 of atoms and/or strings and/or lists in a specific order. If the
yuuji@0 310 modifier value is present, it always appears in parentheses (*). Any
yuuji@0 311 modifiers not defined by extensions that the server supports must be
yuuji@0 312 rejected with a BAD response.
yuuji@0 313
yuuji@0 314 (*) - if a modifier has a mandatory value, which can always be
yuuji@0 315 represented as a number or a sequence-set, the modifier value does
yuuji@0 316 not need the enclosing (). See ABNF for more details.
yuuji@0 317
yuuji@0 318 2.5. Extensions to STORE and UID STORE Commands
yuuji@0 319
yuuji@0 320 Arguments: message set
yuuji@0 321 OPTIONAL store modifiers
yuuji@0 322 message data item name
yuuji@0 323 value for message data item
yuuji@0 324
yuuji@0 325 Responses: untagged responses: FETCH
yuuji@0 326
yuuji@0 327 Result: OK - store completed
yuuji@0 328 NO - store error: cannot store that data
yuuji@0 329 BAD - command unknown or arguments invalid
yuuji@0 330
yuuji@0 331 This document extends the syntax of the STORE and UID STORE commands
yuuji@0 332 (see section 6.4.6 of [IMAP4]) to include optional STORE modifiers.
yuuji@0 333 No store modifiers are defined in this document.
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Melnikov & Daboo Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 341
yuuji@0 342
yuuji@0 343 The order of individual modifiers is arbitrary. Each modifier is an
yuuji@0 344 attribute/value pair. A modifier value is optional and may consist
yuuji@0 345 of atoms and/or strings and/or lists in a specific order. If the
yuuji@0 346 modifier value is present, it always appears in parentheses (*). Any
yuuji@0 347 modifiers not defined by extensions that the server supports must be
yuuji@0 348 rejected with a BAD response.
yuuji@0 349
yuuji@0 350 (*) - if a modifier has a mandatory value, which can always be
yuuji@0 351 represented as a number or a sequence-set, the modifier value does
yuuji@0 352 not need the enclosing (). See ABNF for more details.
yuuji@0 353
yuuji@0 354 2.6. Extensions to SEARCH Command
yuuji@0 355
yuuji@0 356 2.6.1. Extended SEARCH Command
yuuji@0 357
yuuji@0 358 Arguments: OPTIONAL result specifier
yuuji@0 359 OPTIONAL [CHARSET] specification
yuuji@0 360 searching criteria (one or more)
yuuji@0 361
yuuji@0 362 Responses: REQUIRED untagged response: SEARCH (*)
yuuji@0 363
yuuji@0 364 Result: OK - search completed
yuuji@0 365 NO - search error: cannot search that [CHARSET] or
yuuji@0 366 criteria
yuuji@0 367 BAD - command unknown or arguments invalid
yuuji@0 368
yuuji@0 369 This section updates definition of the SEARCH command described in
yuuji@0 370 section 6.4.4 of [IMAP4].
yuuji@0 371
yuuji@0 372 The SEARCH command is extended to allow for result options. This
yuuji@0 373 document does not define any result options.
yuuji@0 374
yuuji@0 375 The order of individual options is arbitrary. Individual options may
yuuji@0 376 contain parameters enclosed in parentheses (**). If an option has
yuuji@0 377 parameters, they consist of atoms and/or strings and/or lists in a
yuuji@0 378 specific order. Any options not defined by extensions that the
yuuji@0 379 server supports must be rejected with a BAD response.
yuuji@0 380
yuuji@0 381 (*) - An extension to the SEARCH command may require another untagged
yuuji@0 382 response, or no untagged response to be returned. Section 2.6.2
yuuji@0 383 defines a new ESEARCH untagged response that replaces the SEARCH
yuuji@0 384 untagged response. Note that for a given extended SEARCH command the
yuuji@0 385 SEARCH and ESEARCH responses SHOULD be mutually exclusive, i.e., only
yuuji@0 386 one of them should be returned.
yuuji@0 387
yuuji@0 388 (**) - if an option has a mandatory parameter, which can always be
yuuji@0 389 represented as a number or a sequence-set, the option parameter does
yuuji@0 390 not need the enclosing (). See ABNF for more details.
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Melnikov & Daboo Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 397
yuuji@0 398
yuuji@0 399 2.6.2. ESEARCH untagged response
yuuji@0 400
yuuji@0 401 Contents: one or more search-return-data pairs
yuuji@0 402
yuuji@0 403 The ESEARCH response SHOULD be sent as a result of an extended SEARCH
yuuji@0 404 or UID SEARCH command specified in section 2.6.1.
yuuji@0 405
yuuji@0 406 The ESEARCH response starts with an optional search correlator. If
yuuji@0 407 it is missing, then the response was not caused by a particular IMAP
yuuji@0 408 command, whereas if it is present, it contains the tag of the command
yuuji@0 409 that caused the response to be returned.
yuuji@0 410
yuuji@0 411 The search correlator is followed by an optional UID indicator. If
yuuji@0 412 this indicator is present, all data in the ESEARCH response refers to
yuuji@0 413 UIDs, otherwise all returned data refers to message numbers.
yuuji@0 414
yuuji@0 415 The rest of the ESEARCH response contains one or more search data
yuuji@0 416 pairs. Each pair starts with unique return item name, followed by a
yuuji@0 417 space and the corresponding data. Search data pairs may be returned
yuuji@0 418 in any order. Unless specified otherwise by an extension, any return
yuuji@0 419 item name SHOULD appear only once in an ESEARCH response.
yuuji@0 420
yuuji@0 421 Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
yuuji@0 422
yuuji@0 423 Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
yuuji@0 424
yuuji@0 425 Example: S: * ESEARCH COUNT 5 ALL 1:17,21
yuuji@0 426
yuuji@0 427 2.7. Extensions to APPEND Command
yuuji@0 428
yuuji@0 429 The IMAP BINARY extension [BINARY] extends the APPEND command to
yuuji@0 430 allow a client to append data containing NULs by using the <literal8>
yuuji@0 431 syntax. The ABNF was rewritten to allow for easier extensibility by
yuuji@0 432 IMAP extensions. This document hasn't specified any semantical
yuuji@0 433 changes to the [BINARY] extension.
yuuji@0 434
yuuji@0 435 In addition, the non-terminal "literal8" defined in [BINARY] got
yuuji@0 436 extended to allow for non-synchronizing literals if both [BINARY] and
yuuji@0 437 [LITERAL+] extensions are supported by the server.
yuuji@0 438
yuuji@0 439 The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND
yuuji@0 440 command to allow a client to append multiple messages atomically.
yuuji@0 441 This document defines a common syntax for the APPEND command that
yuuji@0 442 takes into consideration syntactic extensions defined by both
yuuji@0 443 [BINARY] and [MULTIAPPEND] extensions.
yuuji@0 444
yuuji@0 445
yuuji@0 446
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Melnikov & Daboo Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 453
yuuji@0 454
yuuji@0 455 3. Formal Syntax
yuuji@0 456
yuuji@0 457 The following syntax specification uses the Augmented Backus-Naur
yuuji@0 458 Form (ABNF) notation as specified in [ABNF].
yuuji@0 459
yuuji@0 460 Non-terminals referenced but not defined below are as defined by
yuuji@0 461 [IMAP4].
yuuji@0 462
yuuji@0 463 Except as noted otherwise, all alphabetic characters are case-
yuuji@0 464 insensitive. The use of uppercase or lowercase characters to define
yuuji@0 465 token strings is for editorial clarity only. Implementations MUST
yuuji@0 466 accept these strings in a case-insensitive fashion.
yuuji@0 467
yuuji@0 468 append = "APPEND" SP mailbox 1*append-message
yuuji@0 469 ;; only a single append-message may appear
yuuji@0 470 ;; if MULTIAPPEND [MULTIAPPEND] capability
yuuji@0 471 ;; is not present
yuuji@0 472
yuuji@0 473 append-message = append-opts SP append-data
yuuji@0 474
yuuji@0 475 append-ext = append-ext-name SP append-ext-value
yuuji@0 476 ;; This non-terminal define extensions to
yuuji@0 477 ;; to message metadata.
yuuji@0 478
yuuji@0 479 append-ext-name = tagged-ext-label
yuuji@0 480
yuuji@0 481 append-ext-value= tagged-ext-val
yuuji@0 482 ;; This non-terminal shows recommended syntax
yuuji@0 483 ;; for future extensions.
yuuji@0 484
yuuji@0 485
yuuji@0 486 append-data = literal / literal8 / append-data-ext
yuuji@0 487
yuuji@0 488 append-data-ext = tagged-ext
yuuji@0 489 ;; This non-terminal shows recommended syntax
yuuji@0 490 ;; for future extensions,
yuuji@0 491 ;; i.e., a mandatory label followed
yuuji@0 492 ;; by parameters.
yuuji@0 493
yuuji@0 494 append-opts = [SP flag-list] [SP date-time] *(SP append-ext)
yuuji@0 495 ;; message metadata
yuuji@0 496
yuuji@0 497 charset = atom / quoted
yuuji@0 498 ;; Exact syntax is defined in [CHARSET].
yuuji@0 499
yuuji@0 500 create = "CREATE" SP mailbox
yuuji@0 501 [create-params]
yuuji@0 502 ;; Use of INBOX gives a NO error.
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Melnikov & Daboo Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 509
yuuji@0 510
yuuji@0 511 create-params = SP "(" create-param *( SP create-param) ")"
yuuji@0 512
yuuji@0 513 create-param-name = tagged-ext-label
yuuji@0 514
yuuji@0 515 create-param = create-param-name [SP create-param-value]
yuuji@0 516
yuuji@0 517 create-param-value= tagged-ext-val
yuuji@0 518 ;; This non-terminal shows recommended syntax
yuuji@0 519 ;; for future extensions.
yuuji@0 520
yuuji@0 521
yuuji@0 522 esearch-response = "ESEARCH" [search-correlator] [SP "UID"]
yuuji@0 523 *(SP search-return-data)
yuuji@0 524 ;; Note that SEARCH and ESEARCH responses
yuuji@0 525 ;; SHOULD be mutually exclusive,
yuuji@0 526 ;; i.e., only one of the response types
yuuji@0 527 ;; should be
yuuji@0 528 ;; returned as a result of a command.
yuuji@0 529
yuuji@0 530
yuuji@0 531 examine = "EXAMINE" SP mailbox [select-params]
yuuji@0 532 ;; modifies the original IMAP EXAMINE command
yuuji@0 533 ;; to accept optional parameters
yuuji@0 534
yuuji@0 535 fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
yuuji@0 536 "FAST" / fetch-att /
yuuji@0 537 "(" fetch-att *(SP fetch-att) ")")
yuuji@0 538 [fetch-modifiers]
yuuji@0 539 ;; modifies the original IMAP4 FETCH command to
yuuji@0 540 ;; accept optional modifiers
yuuji@0 541
yuuji@0 542 fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"
yuuji@0 543
yuuji@0 544 fetch-modifier = fetch-modifier-name [ SP fetch-modif-params ]
yuuji@0 545
yuuji@0 546 fetch-modif-params = tagged-ext-val
yuuji@0 547 ;; This non-terminal shows recommended syntax
yuuji@0 548 ;; for future extensions.
yuuji@0 549
yuuji@0 550 fetch-modifier-name = tagged-ext-label
yuuji@0 551
yuuji@0 552 literal8 = "~{" number ["+"] "}" CRLF *OCTET
yuuji@0 553 ;; A string that might contain NULs.
yuuji@0 554 ;; <number> represents the number of OCTETs
yuuji@0 555 ;; in the response string.
yuuji@0 556 ;; The "+" is only allowed when both LITERAL+ and
yuuji@0 557 ;; BINARY extensions are supported by the server.
yuuji@0 558
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Melnikov & Daboo Standards Track [Page 10]
yuuji@0 563
yuuji@0 564 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 565
yuuji@0 566
yuuji@0 567 mailbox-data =/ Namespace-Response /
yuuji@0 568 esearch-response
yuuji@0 569
yuuji@0 570 Namespace = nil / "(" 1*Namespace-Descr ")"
yuuji@0 571
yuuji@0 572 Namespace-Command = "NAMESPACE"
yuuji@0 573
yuuji@0 574 Namespace-Descr = "(" string SP
yuuji@0 575 (DQUOTE QUOTED-CHAR DQUOTE / nil)
yuuji@0 576 *(Namespace-Response-Extension) ")"
yuuji@0 577
yuuji@0 578 Namespace-Response-Extension = SP string SP
yuuji@0 579 "(" string *(SP string) ")"
yuuji@0 580
yuuji@0 581 Namespace-Response = "NAMESPACE" SP Namespace
yuuji@0 582 SP Namespace SP Namespace
yuuji@0 583 ;; This response is currently only allowed
yuuji@0 584 ;; if the IMAP server supports [NAMESPACE].
yuuji@0 585 ;; The first Namespace is the Personal Namespace(s)
yuuji@0 586 ;; The second Namespace is the Other Users' Namespace(s)
yuuji@0 587 ;; The third Namespace is the Shared Namespace(s)
yuuji@0 588
yuuji@0 589 rename = "RENAME" SP mailbox SP mailbox
yuuji@0 590 [rename-params]
yuuji@0 591 ;; Use of INBOX as a destination gives
yuuji@0 592 ;; a NO error, unless rename-params
yuuji@0 593 ;; is not empty.
yuuji@0 594
yuuji@0 595 rename-params = SP "(" rename-param *( SP rename-param) ")"
yuuji@0 596
yuuji@0 597 rename-param = rename-param-name [SP rename-param-value]
yuuji@0 598
yuuji@0 599 rename-param-name = tagged-ext-label
yuuji@0 600
yuuji@0 601 rename-param-value= tagged-ext-val
yuuji@0 602 ;; This non-terminal shows recommended syntax
yuuji@0 603 ;; for future extensions.
yuuji@0 604
yuuji@0 605
yuuji@0 606 response-data = "*" SP response-payload CRLF
yuuji@0 607
yuuji@0 608 response-payload= resp-cond-state / resp-cond-bye /
yuuji@0 609 mailbox-data / message-data / capability-data
yuuji@0 610
yuuji@0 611 search = "SEARCH" [search-return-opts]
yuuji@0 612 SP search-program
yuuji@0 613
yuuji@0 614 search-correlator = SP "(" "TAG" SP tag-string ")"
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Melnikov & Daboo Standards Track [Page 11]
yuuji@0 619
yuuji@0 620 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 621
yuuji@0 622
yuuji@0 623 search-program = ["CHARSET" SP charset SP]
yuuji@0 624 search-key *(SP search-key)
yuuji@0 625 ;; CHARSET argument to SEARCH MUST be
yuuji@0 626 ;; registered with IANA.
yuuji@0 627
yuuji@0 628 search-return-data = search-modifier-name SP search-return-value
yuuji@0 629 ;; Note that not every SEARCH return option
yuuji@0 630 ;; is required to have the corresponding
yuuji@0 631 ;; ESEARCH return data.
yuuji@0 632
yuuji@0 633 search-return-opts = SP "RETURN" SP "(" [search-return-opt
yuuji@0 634 *(SP search-return-opt)] ")"
yuuji@0 635
yuuji@0 636 search-return-opt = search-modifier-name [SP search-mod-params]
yuuji@0 637
yuuji@0 638 search-return-value = tagged-ext-val
yuuji@0 639 ;; Data for the returned search option.
yuuji@0 640 ;; A single "nz-number"/"number" value
yuuji@0 641 ;; can be returned as an atom (i.e., without
yuuji@0 642 ;; quoting). A sequence-set can be returned
yuuji@0 643 ;; as an atom as well.
yuuji@0 644
yuuji@0 645 search-modifier-name = tagged-ext-label
yuuji@0 646
yuuji@0 647 search-mod-params = tagged-ext-val
yuuji@0 648 ;; This non-terminal shows recommended syntax
yuuji@0 649 ;; for future extensions.
yuuji@0 650
yuuji@0 651
yuuji@0 652 select = "SELECT" SP mailbox [select-params]
yuuji@0 653 ;; modifies the original IMAP SELECT command to
yuuji@0 654 ;; accept optional parameters
yuuji@0 655
yuuji@0 656 select-params = SP "(" select-param *(SP select-param) ")"
yuuji@0 657
yuuji@0 658 select-param = select-param-name [SP select-param-value]
yuuji@0 659 ;; a parameter to SELECT may contain one or
yuuji@0 660 ;; more atoms and/or strings and/or lists.
yuuji@0 661
yuuji@0 662 select-param-name= tagged-ext-label
yuuji@0 663
yuuji@0 664 select-param-value= tagged-ext-val
yuuji@0 665 ;; This non-terminal shows recommended syntax
yuuji@0 666 ;; for future extensions.
yuuji@0 667
yuuji@0 668
yuuji@0 669 status-att-list = status-att-val *(SP status-att-val)
yuuji@0 670 ;; Redefines status-att-list from RFC 3501.
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Melnikov & Daboo Standards Track [Page 12]
yuuji@0 675
yuuji@0 676 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 677
yuuji@0 678
yuuji@0 679 ;; status-att-val is defined in RFC 3501 errata
yuuji@0 680
yuuji@0 681 status-att-val = ("MESSAGES" SP number) /
yuuji@0 682 ("RECENT" SP number) /
yuuji@0 683 ("UIDNEXT" SP nz-number) /
yuuji@0 684 ("UIDVALIDITY" SP nz-number) /
yuuji@0 685 ("UNSEEN" SP number)
yuuji@0 686 ;; Extensions to the STATUS responses
yuuji@0 687 ;; should extend this production.
yuuji@0 688 ;; Extensions should use the generic
yuuji@0 689 ;; syntax defined by tagged-ext.
yuuji@0 690
yuuji@0 691 store = "STORE" SP sequence-set [store-modifiers]
yuuji@0 692 SP store-att-flags
yuuji@0 693 ;; extend [IMAP4] STORE command syntax
yuuji@0 694 ;; to allow for optional store-modifiers
yuuji@0 695
yuuji@0 696 store-modifiers = SP "(" store-modifier *(SP store-modifier)
yuuji@0 697 ")"
yuuji@0 698
yuuji@0 699 store-modifier = store-modifier-name [SP store-modif-params]
yuuji@0 700
yuuji@0 701 store-modif-params = tagged-ext-val
yuuji@0 702 ;; This non-terminal shows recommended syntax
yuuji@0 703 ;; for future extensions.
yuuji@0 704
yuuji@0 705 store-modifier-name = tagged-ext-label
yuuji@0 706
yuuji@0 707 tag-string = string
yuuji@0 708 ;; tag of the command that caused
yuuji@0 709 ;; the ESEARCH response, sent as
yuuji@0 710 ;; a string.
yuuji@0 711
yuuji@0 712 tagged-ext = tagged-ext-label SP tagged-ext-val
yuuji@0 713 ;; recommended overarching syntax for
yuuji@0 714 ;; extensions
yuuji@0 715
yuuji@0 716 tagged-ext-label = tagged-label-fchar *tagged-label-char
yuuji@0 717 ;; Is a valid RFC 3501 "atom".
yuuji@0 718
yuuji@0 719 tagged-label-fchar = ALPHA / "-" / "_" / "."
yuuji@0 720
yuuji@0 721 tagged-label-char = tagged-label-fchar / DIGIT / ":"
yuuji@0 722
yuuji@0 723
yuuji@0 724
yuuji@0 725
yuuji@0 726
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Melnikov & Daboo Standards Track [Page 13]
yuuji@0 731
yuuji@0 732 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 733
yuuji@0 734
yuuji@0 735 tagged-ext-comp = astring /
yuuji@0 736 tagged-ext-comp *(SP tagged-ext-comp) /
yuuji@0 737 "(" tagged-ext-comp ")"
yuuji@0 738 ;; Extensions that follow this general
yuuji@0 739 ;; syntax should use nstring instead of
yuuji@0 740 ;; astring when appropriate in the context
yuuji@0 741 ;; of the extension.
yuuji@0 742 ;; Note that a message set or a "number"
yuuji@0 743 ;; can always be represented as an "atom".
yuuji@0 744 ;; An URL should be represented as
yuuji@0 745 ;; a "quoted" string.
yuuji@0 746
yuuji@0 747 tagged-ext-simple = sequence-set / number
yuuji@0 748
yuuji@0 749 tagged-ext-val = tagged-ext-simple /
yuuji@0 750 "(" [tagged-ext-comp] ")"
yuuji@0 751
yuuji@0 752 4. Security Considerations
yuuji@0 753
yuuji@0 754 This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
yuuji@0 755 The updated documents must be consulted for security considerations
yuuji@0 756 for the extensions that they define.
yuuji@0 757
yuuji@0 758 As a protocol gets more complex, parser bugs become more common
yuuji@0 759 including buffer overflow, denial of service, and other common
yuuji@0 760 security coding errors. To the extent that this document makes the
yuuji@0 761 parser more complex, it makes this situation worse. To the extent
yuuji@0 762 that this document makes the parser more consistent and thus simpler,
yuuji@0 763 the situation is improved. The impact will depend on how many
yuuji@0 764 deployed IMAP extensions are consistent with this document.
yuuji@0 765 Implementers are encouraged to take care of these issues when
yuuji@0 766 extending existing implementations. Future IMAP extensions should
yuuji@0 767 strive for consistency and simplicity to the greatest extent
yuuji@0 768 possible.
yuuji@0 769
yuuji@0 770 Extensions to IMAP commands that are permitted in NOT AUTHENTICATED
yuuji@0 771 state are more sensitive to these security issues due to the larger
yuuji@0 772 possible attacker community prior to authentication, and the fact
yuuji@0 773 that some IMAP servers run with elevated privileges in that state.
yuuji@0 774 This document does not extend any commands permitted in NOT
yuuji@0 775 AUTHENTICATED state. Future IMAP extensions to commands permitted in
yuuji@0 776 NOT AUTHENTICATED state should favor simplicity over consistency or
yuuji@0 777 extensibility.
yuuji@0 778
yuuji@0 779
yuuji@0 780
yuuji@0 781
yuuji@0 782
yuuji@0 783
yuuji@0 784
yuuji@0 785
yuuji@0 786 Melnikov & Daboo Standards Track [Page 14]
yuuji@0 787
yuuji@0 788 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 789
yuuji@0 790
yuuji@0 791 5. Normative References
yuuji@0 792
yuuji@0 793 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 794 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 795
yuuji@0 796 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
yuuji@0 797 VERSION 4rev1", RFC 3501, March 2003.
yuuji@0 798
yuuji@0 799 [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
yuuji@0 800 Syntax Specifications: ABNF", RFC 4234, October 2005.
yuuji@0 801
yuuji@0 802 [CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
yuuji@0 803 Procedures", BCP 19, RFC 2978, October 2000.
yuuji@0 804
yuuji@0 805 [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
yuuji@0 806 MULTIAPPEND Extension", RFC 3502, March 2003.
yuuji@0 807
yuuji@0 808 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
yuuji@0 809 May 1998.
yuuji@0 810
yuuji@0 811 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC
yuuji@0 812 2088, January 1997.
yuuji@0 813
yuuji@0 814 [BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC
yuuji@0 815 3516, April 2003.
yuuji@0 816
yuuji@0 817 6. Acknowledgements
yuuji@0 818
yuuji@0 819 This documents is based on ideas proposed by Pete Resnick, Mark
yuuji@0 820 Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon
yuuji@0 821 Nerenberg.
yuuji@0 822
yuuji@0 823 However, all errors and omissions must be attributed to the authors
yuuji@0 824 of the document.
yuuji@0 825
yuuji@0 826 Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman,
yuuji@0 827 Elwyn Davies, and Barry Leiba for comments and corrections.
yuuji@0 828
yuuji@0 829 literal8 syntax was taken from RFC 3516.
yuuji@0 830
yuuji@0 831
yuuji@0 832
yuuji@0 833
yuuji@0 834
yuuji@0 835
yuuji@0 836
yuuji@0 837
yuuji@0 838
yuuji@0 839
yuuji@0 840
yuuji@0 841
yuuji@0 842 Melnikov & Daboo Standards Track [Page 15]
yuuji@0 843
yuuji@0 844 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 845
yuuji@0 846
yuuji@0 847 Authors' Addresses
yuuji@0 848
yuuji@0 849 Alexey Melnikov
yuuji@0 850 Isode Limited
yuuji@0 851 5 Castle Business Village
yuuji@0 852 36 Station Road
yuuji@0 853 Hampton, Middlesex, TW12 2BX
yuuji@0 854 UK
yuuji@0 855
yuuji@0 856 EMail: Alexey.Melnikov@isode.com
yuuji@0 857
yuuji@0 858
yuuji@0 859 Cyrus Daboo
yuuji@0 860
yuuji@0 861 EMail: cyrus@daboo.name
yuuji@0 862
yuuji@0 863
yuuji@0 864
yuuji@0 865
yuuji@0 866
yuuji@0 867
yuuji@0 868
yuuji@0 869
yuuji@0 870
yuuji@0 871
yuuji@0 872
yuuji@0 873
yuuji@0 874
yuuji@0 875
yuuji@0 876
yuuji@0 877
yuuji@0 878
yuuji@0 879
yuuji@0 880
yuuji@0 881
yuuji@0 882
yuuji@0 883
yuuji@0 884
yuuji@0 885
yuuji@0 886
yuuji@0 887
yuuji@0 888
yuuji@0 889
yuuji@0 890
yuuji@0 891
yuuji@0 892
yuuji@0 893
yuuji@0 894
yuuji@0 895
yuuji@0 896
yuuji@0 897
yuuji@0 898 Melnikov & Daboo Standards Track [Page 16]
yuuji@0 899
yuuji@0 900 RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
yuuji@0 901
yuuji@0 902
yuuji@0 903 Full Copyright Statement
yuuji@0 904
yuuji@0 905 Copyright (C) The Internet Society (2006).
yuuji@0 906
yuuji@0 907 This document is subject to the rights, licenses and restrictions
yuuji@0 908 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 909 retain all their rights.
yuuji@0 910
yuuji@0 911 This document and the information contained herein are provided on an
yuuji@0 912 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 913 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
yuuji@0 914 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
yuuji@0 915 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
yuuji@0 916 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 917 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 918
yuuji@0 919 Intellectual Property
yuuji@0 920
yuuji@0 921 The IETF takes no position regarding the validity or scope of any
yuuji@0 922 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 923 pertain to the implementation or use of the technology described in
yuuji@0 924 this document or the extent to which any license under such rights
yuuji@0 925 might or might not be available; nor does it represent that it has
yuuji@0 926 made any independent effort to identify any such rights. Information
yuuji@0 927 on the procedures with respect to rights in RFC documents can be
yuuji@0 928 found in BCP 78 and BCP 79.
yuuji@0 929
yuuji@0 930 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 931 assurances of licenses to be made available, or the result of an
yuuji@0 932 attempt made to obtain a general license or permission for the use of
yuuji@0 933 such proprietary rights by implementers or users of this
yuuji@0 934 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 935 http://www.ietf.org/ipr.
yuuji@0 936
yuuji@0 937 The IETF invites any interested party to bring to its attention any
yuuji@0 938 copyrights, patents or patent applications, or other proprietary
yuuji@0 939 rights that may cover technology that may be required to implement
yuuji@0 940 this standard. Please address the information to the IETF at
yuuji@0 941 ietf-ipr@ietf.org.
yuuji@0 942
yuuji@0 943 Acknowledgement
yuuji@0 944
yuuji@0 945 Funding for the RFC Editor function is provided by the IETF
yuuji@0 946 Administrative Support Activity (IASA).
yuuji@0 947
yuuji@0 948
yuuji@0 949
yuuji@0 950
yuuji@0 951
yuuji@0 952
yuuji@0 953
yuuji@0 954 Melnikov & Daboo Standards Track [Page 17]
yuuji@0 955

UW-IMAP'd extensions by yuuji