1
2
3
4
5
6
7Network Working Group A. Melnikov
8Request for Comments: 4466 Isode Ltd.
9Updates: 2088, 2342, 3501, 3502, 3516 C. Daboo
10Category: Standards Track April 2006
11
12
13 Collected Extensions to IMAP4 ABNF
14
15Status 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
23Copyright Notice
24
25 Copyright (C) The Internet Society (2006).
26
27Abstract
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
58Melnikov & Daboo Standards Track [Page 1]
59
60RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
61
62
63Table 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
831. Introduction
84
851.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
114Melnikov & Daboo Standards Track [Page 2]
115
116RFC 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
1301.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
1392. 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
1452.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
170Melnikov & Daboo Standards Track [Page 3]
171
172RFC 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
2122.2. Extended CREATE Command 9051:1951 6154:411 3501:1933 ../imapserver/server.go:2230
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
226Melnikov & Daboo Standards Track [Page 4]
227
228RFC 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
2492.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
282Melnikov & Daboo Standards Track [Page 5]
283
284RFC 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
2912.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
3182.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
338Melnikov & Daboo Standards Track [Page 6]
339
340RFC 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
3542.6. Extensions to SEARCH Command 9051:3716 4731:31 3501:2723 ../imapserver/search.go:19
355
3562.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 9051:3745 ../imapserver/search.go:46
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
394Melnikov & Daboo Standards Track [Page 7]
395
396RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
397
398
3992.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
4272.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
450Melnikov & Daboo Standards Track [Page 8]
451
452RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
453
454
4553. 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 9051:6484 6154:468 3501:4687 ../imapserver/server.go:2232
501 [create-params]
502 ;; Use of INBOX gives a NO error.
503
504
505
506Melnikov & Daboo Standards Track [Page 9]
507
508RFC 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"] 9051:6546 ../imapserver/search.go:212
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" / 9051:6553 3501:4748 7162:2475 ../imapserver/fetch.go:75
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) ")" ../imapserver/fetch.go:84
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
562Melnikov & Daboo Standards Track [Page 10]
563
564RFC 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] 9051:6918 3501:4954 ../imapserver/search.go:21
612 SP search-program
613
614 search-correlator = SP "(" "TAG" SP tag-string ")"
615
616
617
618Melnikov & Daboo Standards Track [Page 11]
619
620RFC 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] 9051:7005 3501:4996 7162:2559 7162:2598 ../imapserver/server.go:1939
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
674Melnikov & Daboo Standards Track [Page 12]
675
676RFC 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] 9051:7076 3501:5052 7162:2471 ../imapserver/server.go:3648
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 5259:1163 9051:7087 ../imapserver/search.go:225
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
730Melnikov & Daboo Standards Track [Page 13]
731
732RFC 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
7524. 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
786Melnikov & Daboo Standards Track [Page 14]
787
788RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
789
790
7915. 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
8176. 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
842Melnikov & Daboo Standards Track [Page 15]
843
844RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
845
846
847Authors' 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
898Melnikov & Daboo Standards Track [Page 16]
899
900RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
901
902
903Full 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
919Intellectual 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
943Acknowledgement
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
954Melnikov & Daboo Standards Track [Page 17]
955
956