imap/docs/rfc/rfc4466.txt

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