idnits 2.17.1 draft-melnikov-imap-ext-abnf-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 774. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-melnikov-imap-ext-abnf', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-melnikov-imap-ext-abnf', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-melnikov-imap-ext-abnf', but the file name used is 'draft-melnikov-imap-ext-abnf-08' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 851 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to directly say this. It does mention RFC3501 though, so this could be OK. -- The draft header indicates that this document updates RFC3502, but the abstract doesn't seem to directly say this. It does mention RFC3502 though, so this could be OK. -- The draft header indicates that this document updates RFC2088, but the abstract doesn't seem to directly say this. It does mention RFC2088 though, so this could be OK. -- The draft header indicates that this document updates RFC2342, but the abstract doesn't seem to directly say this. It does mention RFC2342 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2088, updated by this document, for RFC5378 checks: 1996-07-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2006) is 6674 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2342' is mentioned on line 509, but not defined == Unused Reference: 'NAMESPACE' is defined on line 697, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) Summary: 6 errors (**), 1 flaw (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft A. Melnikov 2 Document: draft-melnikov-imap-ext-abnf Isode Ltd. 3 Expires: July 2006 Cyrus Daboo 4 Updates: RFC 3501, RFC 2342, RFC 2088, RFC 3502 and RFC 3516 5 January 2006 7 Collected extensions to IMAP4 ABNF 8 draft-melnikov-imap-ext-abnf-08 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 A revised version of this draft document will be submitted to the 34 RFC editor as a Standard Track RFC for the Internet Community. 35 Discussion and suggestions for improvement are requested, and 36 should be sent to ietf-imapext@imc.org and/or lemonade@ietf.org. 37 Distribution of this memo is unlimited. 39 Abstract 41 Over years many documents from IMAPEXT and LEMONADE working groups, 42 as well as many individual documents have added syntactic 43 extensions to many base IMAP commands described in RFC 3501. For 44 ease of reference this document collects most of such ABNF changes 45 in one place. 47 This document also suggest a set of standard patterns for adding 48 options and extensions to several existing IMAP commands defined in 49 RFC 3501. The patterns provide for compatibility between existing 50 and future extensions. 52 This document updates ABNF in RFC 3501, RFC 2342, RFC 2088, RFC 53 3502 and RFC 3516. It also includes part of the errata to RFC 3501. 54 This document doesn't specify any semantic changes to the listed 55 RFCs. 57 Table of Contents 59 1. Introduction and Conventions Used 3 60 1.1 Purpose of this document 3 61 1.2 Conventions Used in this document 4 62 2. IMAP ABNF extensions 4 63 2.1 Optional parameters with the SELECT/EXAMINE commands 4 64 2.2 Extended CREATE command 5 65 2.3 Extended RENAME command 6 66 2.4 Extensions to FETCH and UID FETCH Commands 6 67 2.5 Extensions to STORE and UID STORE Commands 7 68 2.6 Extensions to SEARCH Command 8 69 2.7 Extensions to APPEND Command 9 70 3. Formal Syntax 9 71 4. Security Considerations 14 72 5. IANA Considerations 15 73 6. References 15 74 6.1 Normative References 15 75 7. Acknowledgments 16 76 8. Authors' Addresses 16 77 9. Full Copyright Statement 16 78 10. Intellectual Property 17 79 11. Appendix A. Editorial. 17 80 11.1 Change Log 18 82 1. Introduction and Conventions Used 84 1.1 Purpose of this document 86 This document serves several purposes: 87 1. rationalize and generalize ABNF for some existing IMAP 88 extensions; 89 2. collect the ABNF in one place in order to minimize cross 90 references between documents; 91 3. define building blocks for future extensions so that they can 92 be used together in a compatible way. 94 It is expected that a future revision of this document gets 95 incorporated into a revision of RFC 3501. 97 This document updates ABNF in RFC 2342, 3501, RFC 2088, RFC 3502 98 and RFC 3516. It also includes part of the errata to RFC 3501. This 99 document doesn't specify any semantic changes to the listed RFCs. 101 The ABNF in section 6 of RFC 2342 got rewritten to conform to the 102 ABNF syntax as defined in RFC 4234 and to reference new non- 103 terminals from RFC 3501. It was also restructured to allow for 104 better readability. There were no changes "on the wire". 106 Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH 107 /UID FETCH, STORE/UID STORE, SEARCH and APPEND commands in a 108 consistent manner. Extensions to all the commands but APPEND have 109 the same structure. Extensibility for the APPEND command was done 110 slightly differently in order to preserve backward compatibility 111 with existing extensions. 112 Section 2 also defines a new ESEARCH response which purpose is to 113 define a better version of the SEARCH response defined in RFC 3501. 115 Section 3 defines the collected ABNF that replaces pieces of ABNF 116 in the aforementioned RFCs. The collected ABNF got generalized to 117 allow for easier future extensibility. 119 1.2 Conventions Used in this document 121 In examples, "C:" and "S:" indicate lines sent by the client and 122 server respectively. 124 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 125 in this document are to be interpreted as defined in "Key words for 126 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 128 2. IMAP ABNF extensions 130 This section is not normative. It provides some background on the 131 intended use of different extensions and it gives some guidance 132 about how future extensions should extend the described commands. 134 2.1 Optional parameters with the SELECT/EXAMINE commands 136 This documents adds the ability to include one or more parameters 137 with the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 138 6.3.2 of [IMAP4]) commands, to turn on or off certain standard 139 behaviours, or to add new optional behaviours required for a 140 particular extension. 142 There are two possible modes of operation: 144 o A global state change where a single use of the optional 145 parameter will affect the session state from that time on, 146 irrespective of subsequent SELECT/EXAMINE commands. 148 o A per-mailbox state change that will affect the session only for 149 the duration of the new selected state. A subsequent SELECT/ 150 EXAMINE without the optional parameter will cancel its effect 151 for the newly selected mailbox. 153 Optional parameters to the SELECT or EXAMINE commands are added as 154 a parenthesised list of attribute/value pairs, and appear after the 155 mailbox name in the standard SELECT or EXAMINE command. The order 156 of individual parameters is arbitrary. A parameter value is 157 optional and may consist of atoms, strings or lists in a specific 158 order. If the parameter value is present, it always appears in 159 parentheses (*). Any parameter not defined by extensions that the 160 server supports must be rejected with a BAD response. 162 Example: 164 C: a SELECT INBOX (ANNOTATE) 165 S: ... 166 S: a OK SELECT complete 168 In the above example, a single parameter is used with the SELECT 169 command. 171 Example: 173 C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses") 174 CONDSTORE) 175 S: ... 176 S: a OK EXAMINE complete 178 In the above example, three parameters are used with the EXAMINE 179 command. The second parameter consists of two items: an atom 180 "RESPONSES" followed by a quoted string. 182 Example: 184 C: a SELECT INBOX (BLURDYBLOOP) 185 S: a BAD Unknown parameter in SELECT command 187 In the above example, a parameter not supported by the server is 188 used. This results in the BAD response from the 189 server. 191 (*) - if a parameter has a mandatory value, which can always be 192 represented as a number or a sequence-set, the parameter value does 193 not need the enclosing (). See ABNF for more details. 195 2.2 Extended CREATE command 197 Arguments: mailbox name 198 OPTIONAL list of CREATE parameters 200 Responses: no specific responses for this command 202 Result: OK - create completed 203 NO - create failure: can not create mailbox with 204 that name 205 BAD - argument(s) invalid 207 This documents adds the ability to include one or more parameters 208 with the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to 209 turn on or off certain standard behaviour, or to add new optional 210 behaviours required for a particular extension. No CREATE 211 parameters are defined in this document. 213 Optional parameters to the CREATE command are added as a 214 parenthesised list of attribute/value pairs after the mailbox name. 215 The order of individual parameters is arbitrary. A parameter value 216 is optional and may consist of atoms, strings or lists in a 217 specific order. If the parameter value is present, it always 218 appears in parentheses (*). Any parameter not defined by extensions 219 that the server supports must be rejected with a BAD response. 221 (*) - if a parameter has a mandatory value, which can always be 222 represented as a number or a sequence-set, the parameter value does 223 not need the enclosing (). See ABNF for more details. 225 2.3 Extended RENAME command 227 Arguments: existing mailbox name 228 new mailbox name 229 OPTIONAL list of RENAME parameters 231 Responses: no specific responses for this command 233 Result: OK - rename completed 234 NO - rename failure: can not rename mailbox with 235 that name, can not rename to mailbox with 236 that name, etc. 237 BAD - argument(s) invalid 239 This documents adds the ability to include one or more parameters 240 with the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to 241 turn on or off certain standard behaviour, or to add new optional 242 behaviours required for a particular extension. No RENAME 243 parameters are defined in this document. 245 Optional parameters to the RENAME command are added as a 246 parenthesised list of attribute/value pairs after the new mailbox 247 name. The order of individual parameters is arbitrary. A parameter 248 value is optional and may consist of atoms, strings or lists in a 249 specific order. If the parameter value is present, it always 250 appears in parentheses (*). Any parameter not defined by extensions 251 that the server supports must be rejected with a BAD response. 253 (*) - if a parameter has a mandatory value, which can always be 254 represented as a number or a sequence-set, the parameter value does 255 not need the enclosing (). See ABNF for more details. 257 2.4 Extensions to FETCH and UID FETCH Commands 259 Arguments: sequence set 260 message data item names or macro 261 OPTIONAL fetch modifiers 263 Responses: untagged responses: FETCH 265 Result: OK - fetch completed 266 NO - fetch error: can not fetch that data 267 BAD - command unknown or arguments invalid 269 This document extends the syntax of the FETCH and UID FETCH 270 commands (see section 6.4.5 of [IMAP4]) to include optional FETCH 271 modifiers. No fetch modifiers are defined in this document. 273 The order of individual modifiers is arbitrary. Each modified is 274 an attribute/value pair. A modifier value is optional and may 275 consist of atoms and/or strings and/or lists in a specific order. 276 If the modifier value is present, it always appears in parentheses 277 (*). Any modifiers not defined by extensions that the server 278 supports must be rejected with a BAD response. 280 (*) - if a modifier has a mandatory value, which can always be 281 represented as a number or a sequence-set, the modifier value does 282 not need the enclosing (). See ABNF for more details. 284 2.5 Extensions to STORE and UID STORE Commands 286 Arguments: message set 287 OPTIONAL store modifiers 288 message data item name 289 value for message data item 291 Responses: untagged responses: FETCH 293 Result: OK - store completed 294 NO - store error: can not store that data 295 BAD - command unknown or arguments invalid 297 This document extends the syntax of the STORE and UID STORE 298 commands (see section 6.4.6 of [IMAP4]) to include optional STORE 299 modifiers. No store modifiers are defined in this document. 301 The order of individual modifiers is arbitrary. Each modified is 302 an attribute/value pair. A modifier value is optional and may 303 consist of atoms and/or strings and/or lists in a specific order. 304 If the modifier value is present, it always appears in parentheses 305 (*). Any modifiers not defined by extensions that the server 306 supports must be rejected with a BAD response. 308 (*) - if a modifier has a mandatory value, which can always be 309 represented as a number or a sequence-set, the modifier value does 310 not need the enclosing (). See ABNF for more details. 312 2.6 Extensions to SEARCH Command 314 2.6.1 Extended SEARCH command 316 Arguments: OPTIONAL result specifier 317 OPTIONAL [CHARSET] specification 318 searching criteria (one or more) 320 Responses: REQUIRED untagged response: SEARCH (*) 322 Result: OK - search completed 323 NO - search error: can not search that [CHARSET] or 324 criteria 325 BAD - command unknown or arguments invalid 327 This section updates definition of the SEARCH command described in 328 section 6.4.4 of [IMAP4]. 330 The SEARCH command is extended to allow for result options. This 331 document does not define any result options. 333 The order of individual options is arbitrary. Individual options 334 may contain parameters enclosed in parentheses (**). If an option 335 has parameters, they consist of atoms and/or strings and/or lists 336 in a specific order. Any options not defined by extensions that the 337 server supports must be rejected with a BAD response. 339 (*) - An extension to the SEARCH command may require another 340 untagged response, or no untagged response to be returned. Section 341 2.6.2 defines a new ESEARCH untagged response, that replaces the 342 SEARCH untagged response. Note that for a given extended SEARCH 343 command the SEARCH and ESEARCH responses SHOULD be mutually 344 exclusive, i.e. only one of them should be returned. 346 (**) - if an option has a mandatory parameter, which can always be 347 represented as a number or a sequence-set, the option parameter 348 does not need the enclosing (). See ABNF for more details. 350 2.6.2 ESEARCH untagged response 352 Contents: one or more search-return-data pairs 354 The ESEARCH response SHOULD be sent as a result of an extended 355 SEARCH or UID SEARCH command specified in section 2.6.1. 357 The ESEARCH response starts with an optional search correlator. If 358 it is missing then the response was not caused by a particular IMAP 359 command, whereas if it is present it contains the tag of the 360 command that caused the response to be returned. 362 The search correlator is followed by an optional UID indicator. If 363 this indicator is present, all data in the ESEARCH response refers 364 to UIDs, otherwise all returned data refers to message numbers. 366 The rest of the ESEARCH response contains one or more search data 367 pairs. Each pair starts with unique return item name, followed by a 368 space and the corresponding data. Search data pairs may be returned 369 in any order. Unless specified otherwise by an extension, any 370 return item name SHOULD appear only once in an ESEARCH response. 372 Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28 374 Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28 376 Example: S: * ESEARCH COUNT 5 ALL 1:17,21 378 2.7 Extensions to APPEND Command 380 The IMAP BINARY extension [BINARY] extends the APPEND command to 381 allow a client to append data 382 containing NULs by using the syntax. The ABNF was 383 rewritten to allow for easier extensibility by IMAP extensions. 384 This document hasn't specified any semantical changes to the 385 [BINARY] extension. 387 In addition, the non-terminal "literal8" defined in [BINARY] got 388 extended to allow for non-syncronizing literals if both [BINARY] 389 and [LITERAL+] extensions are supported by the server. 391 The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND 392 command to allow a client to append multiple messages atomically. 393 This document defines a common syntax for the APPEND command that 394 takes into considerations syntactic extensions defined by both 395 [BINARY] and [MULTIAPPEND] extensions. 397 3. Formal Syntax 399 The following syntax specification uses the Augmented Backus-Naur 400 Form (ABNF) notation as specified in [ABNF]. 402 Non-terminals referenced but not defined below are as defined by 403 [IMAP4]. 405 Except as noted otherwise, all alphabetic characters are case- 406 insensitive. The use of upper or lower case characters to define 407 token strings is for editorial clarity only. Implementations MUST 408 accept these strings in a case-insensitive fashion. 410 append = "APPEND" SP mailbox 1*append-message 411 ;; only a single append-message may appear 412 ;; if MULTIAPPEND [MULTIAPPEND] capability 413 ;; is not present 415 append-message = append-opts SP append-data 417 append-ext = append-ext-name SP append-ext-value 418 ;; This non-terminal define extensions to 419 ;; to message metadata. 421 append-ext-name = tagged-ext-label 423 append-ext-value= tagged-ext-val 424 ;; This non-terminal shows recommended syntax 425 ;; for future extensions. 427 append-data = literal / literal8 / append-data-ext 429 append-data-ext = tagged-ext 430 ;; This non-terminal shows recommended syntax 431 ;; for future extensions, 432 ;; i.e. a mandatory label followed 433 ;; by parameters. 435 append-opts = [SP flag-list] [SP date-time] *(SP append-ext) 436 ;; message metadata 438 charset = atom / quoted 439 ;; Exact syntax is defined in [CHARSET]. 441 create = "CREATE" SP mailbox 442 [create-params] 443 ;; Use of INBOX gives a NO error. 445 create-params = SP "(" create-param *( SP create-param) ")" 447 create-param-name = tagged-ext-label 449 create-param = create-param-name [SP create-param-value] 451 create-param-value= tagged-ext-val 452 ;; This non-terminal shows recommended syntax 453 ;; for future extensions. 455 esearch-response = "ESEARCH" [search-correlator] [SP "UID"] 456 *(SP search-return-data) 457 ;; Note that SEARCH and ESEARCH responses 458 ;; SHOULD be mutually exclusive, 459 ;; i.e. only one of the response types 460 ;; should be 461 ;; returned as a result of a command. 463 examine = "EXAMINE" SP mailbox [select-params] 464 ;; modifies the original IMAP EXAMINE command 465 ;; to accept optional parameters 467 fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / 468 "FAST" / fetch-att / 469 "(" fetch-att *(SP fetch-att) ")") 470 [fetch-modifiers] 471 ;; modifies the original IMAP4 FETCH command to 472 ;; accept optional modifiers 474 fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")" 476 fetch-modifier = fetch-modifier-name [ SP fetch-modif-params ] 478 fetch-modif-params = tagged-ext-val 479 ;; This non-terminal shows recommended syntax 480 ;; for future extensions. 482 fetch-modifier-name = tagged-ext-label 484 literal8 = "~{" number ["+"] "}" CRLF *OCTET 485 ;; A string that might contain NULs. 486 ;; represents the number of OCTETs 487 ;; in the response string. 488 ;; The "+" is only allowed when both LITERAL+ 489 ;; and BINARY extensions are supported 490 ;; by the server. 492 mailbox-data =/ Namespace-Response / 493 esearch-response 495 Namespace = nil / "(" 1*Namespace-Descr ")" 497 Namespace-Command = "NAMESPACE" 499 Namespace-Descr = "(" string SP 500 (DQUOTE QUOTED-CHAR DQUOTE / nil) 501 *(Namespace-Response-Extension) ")" 503 Namespace-Response-Extension = SP string SP 504 "(" string *(SP string) ")" 506 Namespace-Response = "NAMESPACE" SP Namespace 507 SP Namespace SP Namespace 508 ;; This response is currently only allowed 509 ;; if the IMAP server supports [RFC 2342]. 510 ;; The first Namespace is the Personal Namespace(s) 511 ;; The second Namespace is the Other Users' Namespace(s) 512 ;; The third Namespace is the Shared Namespace(s) 514 rename = "RENAME" SP mailbox SP mailbox 515 [rename-params] 516 ;; Use of INBOX as a destination gives 517 ;; a NO error, unless rename-params 518 ;; is not empty. 520 rename-params = SP "(" rename-param *( SP rename-param) ")" 522 rename-param = rename-param-name [SP rename-param-value] 524 rename-param-name = tagged-ext-label 526 rename-param-value= tagged-ext-val 527 ;; This non-terminal shows recommended syntax 528 ;; for future extensions. 530 response-data = "*" SP response-payload CRLF 532 response-payload= resp-cond-state / resp-cond-bye / 533 mailbox-data / message-data / capability-data 535 search = "SEARCH" [search-return-opts] 536 search-program 538 search-correlator = SP "(" "TAG" SP tag-string ")" 540 search-program = [SP "CHARSET" SP charset] 1*(SP search-key) 541 ;; CHARSET argument to SEARCH MUST be 542 ;; registered with IANA. 544 search-return-data = search-modifier-name SP search-return-value 545 ;; Note that not every SEARCH return option 546 ;; is required to have the corresponding 547 ;; ESEARCH return data. 549 search-return-opts = SP "RETURN" SP "(" [search-return-opt 550 *(SP search-return-opt)] ")" 552 search-return-opt = search-modifier-name [SP search-mod-params] 554 search-return-value = tagged-ext-val 555 ;; Data for the returned search option. 556 ;; A single "nz-number"/"number" value 557 ;; can be returned as an atom (i.e. without 558 ;; quoting). A sequence-set can be returned 559 ;; as an atom as well. 561 search-modifier-name = tagged-ext-label 563 search-mod-params = tagged-ext-val 564 ;; This non-terminal shows recommended syntax 565 ;; for future extensions. 567 select = "SELECT" SP mailbox [select-params] 568 ;; modifies the original IMAP SELECT command to 569 ;; accept optional parameters 571 select-params = SP "(" select-param *(SP select-param) ")" 573 select-param = select-param-name [SP select-param-value] 574 ;; a parameter to SELECT may contain one or 575 ;; more atoms and/or strings and/or lists. 577 select-param-name= tagged-ext-label 579 select-param-value= tagged-ext-val 580 ;; This non-terminal shows recommended syntax 581 ;; for future extensions. 583 status-att-list = status-att-val *(SP status-att-val) 584 ;; Redefines status-att-list from RFC 3501. 585 ;; status-att-val is defined in RFC 3501 errata 587 status-att-val = ("MESSAGES" SP number) / 588 ("RECENT" SP number) / 589 ("UIDNEXT" SP nz-number) / 590 ("UIDVALIDITY" SP nz-number) / 591 ("UNSEEN" SP number) 592 ;; Extensions to the STATUS responses 593 ;; should extend this production. 594 ;; Extensions should use the generic 595 ;; syntax defined by tagged-ext. 597 store = "STORE" SP sequence-set [store-modifiers] 598 SP store-att-flags 599 ;; extend [IMAP4] STORE command syntax 600 ;; to allow for optional store-modifiers 602 store-modifiers = SP "(" store-modifier *(SP store-modifier) 603 ")" 605 store-modifier = store-modifier-name [SP store-modif-params] 607 store-modif-params = tagged-ext-val 608 ;; This non-terminal shows recommended syntax 609 ;; for future extensions. 611 store-modifier-name = tagged-ext-label 613 tag-string = string 614 ;; tag of the command that caused 615 ;; the ESEARCH response, sent as 616 ;; a string. 618 tagged-ext = tagged-ext-label SP tagged-ext-val 619 ;; recommended overarching syntax for 620 ;; extensions 622 tagged-ext-label = tagged-label-fchar *tagged-label-char 623 ;; Is a valid RFC 3501 "atom". 625 tagged-label-fchar = ALPHA / "-" / "_" / "." 627 tagged-label-char = tagged-label-fchar / DIGIT / ":" 629 tagged-ext-comp = astring / 630 tagged-ext-comp *(SP tagged-ext-comp) / 631 "(" tagged-ext-comp ")" 632 ;; Extensions that follow this general 633 ;; syntax should use nstring instead of 634 ;; astring when appropriate in the context 635 ;; of the extension. 636 ;; Note that a message set or a "number" 637 ;; can always be represented as an "atom". 638 ;; An URL should be represented as 639 ;; a "quoted" string. 641 tagged-ext-simple = sequence-set / number 643 tagged-ext-val = tagged-ext-simple / 644 "(" [tagged-ext-comp] ")" 646 4. Security Considerations 648 This document updates ABNF in RFC 3501, RFC 2342, RFC 2088, RFC 649 3502 and RFC 3516. The updated documents must be consulted for 650 security considerations for the extensions that they define. 652 As a protocol gets more complex, parser bugs become more common 653 including buffer overflow, denial of service and other common 654 security coding errors. To the extent this document makes the 655 parser more complex, it makes this situation worse. To this extent 656 this document makes the parser more consistent and thus simpler, 657 the situation is improved. The impact will depend on how many 658 deployed IMAP extensions are consistent with this document. 659 Implementers are encouraged to take care of these issues when 660 extending existing implementations. Future IMAP extensions should 661 strive for consistency and simplicity to the greatest extent 662 possible. 664 Extensions to IMAP commands that are permitted in NOT AUTHENTICATED 665 state are more sensitive to these security issues due to the larger 666 possible attacker community prior to authentication, and the fact 667 that some IMAP servers run with elevated privileges in that state. 668 This document does not extend any commands permitted in NOT 669 AUTHENTICATED state. Future IMAP extensions to commands permitted 670 in NOT AUTHENTICATED state should favor simplicity over consistency 671 or extensibility. 673 5. IANA Considerations 675 This document doesn't define any new IMAP extension, so no action 676 from IANA is required. 678 6. References 680 6.1 Normative References 682 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", RFC 2119, March 1997. 685 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 686 4rev1", RFC 3501, University of Washington, March 2003. 688 [ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for Syntax 689 Specifications: ABNF", RFC 4234, October 2005. 691 [CHARSET] Freed, N. and J. Postel, "IANA Character Set Registration 692 Procedures", RFC 2978, October 2000. 694 [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol 695 (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003. 697 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 698 May 1998. 700 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 701 January 1997. 703 [BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 704 April 2003 706 7. Acknowledgments 708 This documents is based on ideas proposed by Pete Resnick, Mark 709 Crispin, Ken Murchison, Philip Guenther, Randall Gellens and Lyndon 710 Nerenberg. 712 However all errors and omissions must be attributed to the authors 713 of the document. 715 Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris 716 Newman, Elwyn Davies and Barry Leiba for comments and corrections. 718 literal8 syntax was taken from RFC 3516. 720 8. Authors' Addresses 722 Alexey Melnikov 723 Isode Limited 724 5 Castle Business Village 725 36 Station Road 726 Hampton, Middlesex, TW12 2BX 727 UK 729 Email: Alexey.Melnikov@isode.com 731 Cyrus Daboo 733 EMail: cyrus@daboo.name 735 9. Full Copyright Statement 737 Copyright (C) The Internet Society (2006). 739 This document is subject to the rights, licenses and restrictions 740 contained in BCP 78, and except as set forth therein, the authors 741 retain all their rights. 743 This document and the information contained herein are provided on 744 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 745 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 746 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 747 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 748 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 749 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 750 PARTICULAR PURPOSE. 752 10. Intellectual Property 754 The IETF takes no position regarding the validity or scope of any 755 Intellectual Property Rights or other rights that might be claimed 756 to pertain to the implementation or use of the technology described 757 in this document or the extent to which any license under such 758 rights might or might not be available; nor does it represent that 759 it has made any independent effort to identify any such rights. 760 Information on the procedures with respect to rights in RFC 761 documents can be found in BCP 78 and BCP 79. 763 Copies of IPR disclosures made to the IETF Secretariat and any 764 assurances of licenses to be made available, or the result of an 765 attempt made to obtain a general license or permission for the use 766 of such proprietary rights by implementers or users of this 767 specification can be obtained from the IETF on-line IPR repository 768 at http://www.ietf.org/ipr. 770 The IETF invites any interested party to bring to its attention any 771 copyrights, patents or patent applications, or other proprietary 772 rights that may cover technology that may be required to implement 773 this standard. Please address the information to the IETF at ietf- 774 ipr@ietf.org. 776 Acknowledgement 778 Funding for the RFC Editor function is currently provided by the 779 Internet Society. 781 11. Appendix A. Editorial. 783 11.1 Change Log 785 00 Initial Revision. 786 01 Added Cyrus as co-author. Added BINARY literals. Added section 787 about APPEND. Clarified that the order of all 788 parameters/modifiers is arbitrary. Unrecognized SELECT/EXAMINE 789 parameter should cause the BAD, not the NO response. 790 02 Updated boilerplate. Extended SEARCH modifiers to be consistent 791 with STORE modifiers. Rewrote FETCH modifier syntax for 792 consistency. 793 03 Updated as per comments from Philip (ABNF suggestions, in 794 particular addition of response-data; normative language). 795 Incorporated RFC 3501 ABNF errata from Mark. Added extensions to 796 CREATE and RENAME commands. Updated ABNF to use consistent 797 grammer for all extension elements (this changed ABNF for 798 SELECT/EXAMINE and FETCH). 799 04 Added ESEARCH response. Added search-program from IMAP URL. 800 Removed the partition parameter from CREATE/RENAME. Added 801 NAMESPACE command/response. 802 05 Added non-synchronizing literals (RFC 2088). Clarified generic 803 syntax for STATUS responses. 804 06 Updated reference to ABNF. Made CREATE/RENAME/SELECT parameter 805 values optional (for consistency with other parameters and to 806 make examples valid), but if a value is present, it must be in 807 (), unless it is a number or a sequence. Updated description of 808 CREATE/RENAME/SELECT parameters to match ABNF. Disallow a single 809 astring parameter with not parentheses. Defined append-ext to be 810 "atom SP value". Added a missing reference to RFC 3516. Added 811 missing leading space in the search-return-opts non-terminal. 812 Rewrote ABNF for STORE and FETCH options for consistency with 813 others. Added Security Considerations, courtesy of Chris Newman. 814 Added new non-terminal for charset (from Mark Crispin's RFC 3501 815 errata). Describe exact syntax for future extensions (as per 816 IETF LC comment from Mark Crispin).