7Network Working Group A. Melnikov
8Request for Comments: 4466 Isode Ltd.
9Updates: 2088, 2342, 3501, 3502, 3516 C. Daboo
10Category: Standards Track April 2006
13 Collected Extensions to IMAP4 ABNF
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.
25 Copyright (C) The Internet Society (2006).
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
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.
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.
58Melnikov & Daboo Standards Track [Page 1]
60RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
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
851.1. Purpose of This Document
87 This document serves several purposes:
89 1. rationalize and generalize ABNF for some existing IMAP
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.
96 It is expected that a future revision of this document will be
97 incorporated into a revision of RFC 3501.
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.
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".
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
114Melnikov & Daboo Standards Track [Page 2]
116RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
119 structure. Extensibility for the APPEND command was done slightly
120 differently in order to preserve backward compatibility with existing
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.
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.
1301.2. Conventions Used in This Document
132 In examples, "C:" and "S:" indicate lines sent by the client and
133 server, respectively.
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].
1392. IMAP ABNF Extensions
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.
1452.1. Optional Parameters with the SELECT/EXAMINE Commands
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.
152 There are two possible modes of operation:
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.
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.
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
170Melnikov & Daboo Standards Track [Page 3]
172RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
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.
182 C: a SELECT INBOX (ANNOTATE)
184 S: a OK SELECT complete
186 In the above example, a single parameter is used with the SELECT
191 C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
194 S: a OK EXAMINE complete
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.
202 C: a SELECT INBOX (BLURDYBLOOP)
203 S: a BAD Unknown parameter in SELECT command
205 In the above example, a parameter not supported by the server is
206 used. This results in the BAD response from the server.
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.
214 Arguments: mailbox name
215 OPTIONAL list of CREATE parameters
217 Responses: no specific responses for this command
219 Result: OK - create completed
220 NO - create failure: cannot create mailbox with
222 BAD - argument(s) invalid
226Melnikov & Daboo Standards Track [Page 4]
228RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
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.
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.
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.
2492.3. Extended RENAME Command
251 Arguments: existing mailbox name
253 OPTIONAL list of RENAME parameters
255 Responses: no specific responses for this command
257 Result: OK - rename completed
258 NO - rename failure: cannot rename mailbox with
259 that name, cannot rename to mailbox with
261 BAD - argument(s) invalid
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.
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.
282Melnikov & Daboo Standards Track [Page 5]
284RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
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.
2912.4. Extensions to FETCH and UID FETCH Commands
293 Arguments: sequence set
294 message data item names or macro
295 OPTIONAL fetch modifiers
297 Responses: untagged responses: FETCH
299 Result: OK - fetch completed
300 NO - fetch error: cannot fetch that data
301 BAD - command unknown or arguments invalid
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.
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.
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.
3182.5. Extensions to STORE and UID STORE Commands
320 Arguments: message set
321 OPTIONAL store modifiers
322 message data item name
323 value for message data item
325 Responses: untagged responses: FETCH
327 Result: OK - store completed
328 NO - store error: cannot store that data
329 BAD - command unknown or arguments invalid
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.
338Melnikov & Daboo Standards Track [Page 6]
340RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
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.
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.
3562.6.1. Extended SEARCH Command
358 Arguments: OPTIONAL result specifier
359 OPTIONAL [CHARSET] specification
360 searching criteria (one or more)
362 Responses: REQUIRED untagged response: SEARCH (*)
364 Result: OK - search completed
365 NO - search error: cannot search that [CHARSET] or
367 BAD - command unknown or arguments invalid
369 This section updates definition of the SEARCH command described in
370 section 6.4.4 of [IMAP4].
372 The SEARCH command is extended to allow for result options. This
373 document does not define any result options.
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
379 server supports must be rejected with a BAD response.
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.
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.
394Melnikov & Daboo Standards Track [Page 7]
396RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
3992.6.2. ESEARCH untagged response
401 Contents: one or more search-return-data pairs
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.
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.
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.
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.
421 Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
423 Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
425 Example: S: * ESEARCH COUNT 5 ALL 1:17,21
4272.7. Extensions to APPEND Command
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.
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.
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.
450Melnikov & Daboo Standards Track [Page 8]
452RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
457 The following syntax specification uses the Augmented Backus-Naur
458 Form (ABNF) notation as specified in [ABNF].
460 Non-terminals referenced but not defined below are as defined by
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.
468 append = "APPEND" SP mailbox 1*append-message
469 ;; only a single append-message may appear
470 ;; if MULTIAPPEND [MULTIAPPEND] capability
473 append-message = append-opts SP append-data
475 append-ext = append-ext-name SP append-ext-value
476 ;; This non-terminal define extensions to
477 ;; to message metadata.
479 append-ext-name = tagged-ext-label
481 append-ext-value= tagged-ext-val
482 ;; This non-terminal shows recommended syntax
483 ;; for future extensions.
486 append-data = literal / literal8 / append-data-ext
488 append-data-ext = tagged-ext
489 ;; This non-terminal shows recommended syntax
490 ;; for future extensions,
491 ;; i.e., a mandatory label followed
494 append-opts = [SP flag-list] [SP date-time] *(SP append-ext)
497 charset = atom / quoted
498 ;; Exact syntax is defined in [CHARSET].
502 ;; Use of INBOX gives a NO error.
506Melnikov & Daboo Standards Track [Page 9]
508RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
511 create-params = SP "(" create-param *( SP create-param) ")"
513 create-param-name = tagged-ext-label
515 create-param = create-param-name [SP create-param-value]
517 create-param-value= tagged-ext-val
518 ;; This non-terminal shows recommended syntax
519 ;; for future extensions.
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
528 ;; returned as a result of a command.
531 examine = "EXAMINE" SP mailbox [select-params]
532 ;; modifies the original IMAP EXAMINE command
533 ;; to accept optional parameters
537 "(" fetch-att *(SP fetch-att) ")")
539 ;; modifies the original IMAP4 FETCH command to
540 ;; accept optional modifiers
544 fetch-modifier = fetch-modifier-name [ SP fetch-modif-params ]
546 fetch-modif-params = tagged-ext-val
547 ;; This non-terminal shows recommended syntax
548 ;; for future extensions.
550 fetch-modifier-name = tagged-ext-label
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.
562Melnikov & Daboo Standards Track [Page 10]
564RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
567 mailbox-data =/ Namespace-Response /
570 Namespace = nil / "(" 1*Namespace-Descr ")"
572 Namespace-Command = "NAMESPACE"
574 Namespace-Descr = "(" string SP
575 (DQUOTE QUOTED-CHAR DQUOTE / nil)
576 *(Namespace-Response-Extension) ")"
578 Namespace-Response-Extension = SP string SP
579 "(" string *(SP string) ")"
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)
589 rename = "RENAME" SP mailbox SP mailbox
591 ;; Use of INBOX as a destination gives
592 ;; a NO error, unless rename-params
595 rename-params = SP "(" rename-param *( SP rename-param) ")"
597 rename-param = rename-param-name [SP rename-param-value]
599 rename-param-name = tagged-ext-label
601 rename-param-value= tagged-ext-val
602 ;; This non-terminal shows recommended syntax
603 ;; for future extensions.
606 response-data = "*" SP response-payload CRLF
608 response-payload= resp-cond-state / resp-cond-bye /
609 mailbox-data / message-data / capability-data
614 search-correlator = SP "(" "TAG" SP tag-string ")"
618Melnikov & Daboo Standards Track [Page 11]
620RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
623 search-program = ["CHARSET" SP charset SP]
624 search-key *(SP search-key)
625 ;; CHARSET argument to SEARCH MUST be
626 ;; registered with IANA.
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.
633 search-return-opts = SP "RETURN" SP "(" [search-return-opt
634 *(SP search-return-opt)] ")"
636 search-return-opt = search-modifier-name [SP search-mod-params]
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.
645 search-modifier-name = tagged-ext-label
647 search-mod-params = tagged-ext-val
648 ;; This non-terminal shows recommended syntax
649 ;; for future extensions.
653 ;; modifies the original IMAP SELECT command to
654 ;; accept optional parameters
656 select-params = SP "(" select-param *(SP select-param) ")"
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.
662 select-param-name= tagged-ext-label
664 select-param-value= tagged-ext-val
665 ;; This non-terminal shows recommended syntax
666 ;; for future extensions.
669 status-att-list = status-att-val *(SP status-att-val)
670 ;; Redefines status-att-list from RFC 3501.
674Melnikov & Daboo Standards Track [Page 12]
676RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
679 ;; status-att-val is defined in RFC 3501 errata
681 status-att-val = ("MESSAGES" SP number) /
682 ("RECENT" SP number) /
683 ("UIDNEXT" SP nz-number) /
684 ("UIDVALIDITY" SP nz-number) /
686 ;; Extensions to the STATUS responses
687 ;; should extend this production.
688 ;; Extensions should use the generic
689 ;; syntax defined by tagged-ext.
693 ;; extend [IMAP4] STORE command syntax
694 ;; to allow for optional store-modifiers
696 store-modifiers = SP "(" store-modifier *(SP store-modifier)
699 store-modifier = store-modifier-name [SP store-modif-params]
701 store-modif-params = tagged-ext-val
702 ;; This non-terminal shows recommended syntax
703 ;; for future extensions.
705 store-modifier-name = tagged-ext-label
708 ;; tag of the command that caused
709 ;; the ESEARCH response, sent as
712 tagged-ext = tagged-ext-label SP tagged-ext-val
713 ;; recommended overarching syntax for
716 tagged-ext-label = tagged-label-fchar *tagged-label-char
717 ;; Is a valid RFC 3501 "atom".
719 tagged-label-fchar = ALPHA / "-" / "_" / "."
721 tagged-label-char = tagged-label-fchar / DIGIT / ":"
730Melnikov & Daboo Standards Track [Page 13]
732RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
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
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.
747 tagged-ext-simple = sequence-set / number
749 tagged-ext-val = tagged-ext-simple /
750 "(" [tagged-ext-comp] ")"
7524. Security Considerations
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.
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
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
786Melnikov & Daboo Standards Track [Page 14]
788RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
7915. Normative References
793 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
794 Requirement Levels", BCP 14, RFC 2119, March 1997.
796 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
797 VERSION 4rev1", RFC 3501, March 2003.
799 [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
800 Syntax Specifications: ABNF", RFC 4234, October 2005.
802 [CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
803 Procedures", BCP 19, RFC 2978, October 2000.
805 [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
806 MULTIAPPEND Extension", RFC 3502, March 2003.
808 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
811 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC
814 [BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC
819 This documents is based on ideas proposed by Pete Resnick, Mark
820 Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon
823 However, all errors and omissions must be attributed to the authors
826 Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman,
827 Elwyn Davies, and Barry Leiba for comments and corrections.
829 literal8 syntax was taken from RFC 3516.
842Melnikov & Daboo Standards Track [Page 15]
844RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
851 5 Castle Business Village
853 Hampton, Middlesex, TW12 2BX
856 EMail: Alexey.Melnikov@isode.com
861 EMail: cyrus@daboo.name
898Melnikov & Daboo Standards Track [Page 16]
900RFC 4466 Collected Extensions to IMAP4 ABNF April 2006
903Full Copyright Statement
905 Copyright (C) The Internet Society (2006).
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.
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.
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.
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.
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
945 Funding for the RFC Editor function is provided by the IETF
946 Administrative Support Activity (IASA).
954Melnikov & Daboo Standards Track [Page 17]