rfc4466.txt

广泛使用的邮件服务器！同时

Network Working Group                                        A. Melnikov
Request for Comments: 4466                                    Isode Ltd.
Updates: 2088, 2342, 3501, 3502, 3516                           C. Daboo
Category: Standards Track                                     April 2006


                   Collected Extensions to IMAP4 ABNF

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Over the years, many documents from IMAPEXT and LEMONADE working
   groups, as well as many individual documents, have added syntactic
   extensions to many base IMAP commands described in RFC 3501.  For
   ease of reference, this document collects most of such ABNF changes
   in one place.

   This document also suggests a set of standard patterns for adding
   options and extensions to several existing IMAP commands defined in
   RFC 3501.  The patterns provide for compatibility between existing
   and future extensions.

   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
   It also includes part of the errata to RFC 3501.  This document
   doesn't specify any semantic changes to the listed RFCs.















Melnikov & Daboo            Standards Track                     [Page 1]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


Table of Contents

   1. Introduction ....................................................2
      1.1. Purpose of This Document ...................................2
      1.2. Conventions Used in This Document ..........................3
   2. IMAP ABNF Extensions ............................................3
      2.1. Optional Parameters with the SELECT/EXAMINE Commands .......3
      2.2. Extended CREATE Command ....................................4
      2.3. Extended RENAME Command ....................................5
      2.4. Extensions to FETCH and UID FETCH Commands .................6
      2.5. Extensions to STORE and UID STORE Commands .................6
      2.6. Extensions to SEARCH Command ...............................7
           2.6.1. Extended SEARCH Command .............................7
           2.6.2. ESEARCH untagged response ...........................8
      2.7. Extensions to APPEND Command ...............................8
   3. Formal Syntax ...................................................9
   4. Security Considerations ........................................14
   5. Normative References ...........................................15
   6. Acknowledgements ...............................................15

1.  Introduction

1.1.  Purpose of This Document

   This document serves several purposes:

      1.  rationalize and generalize ABNF for some existing IMAP
          extensions;
      2.  collect the ABNF in one place in order to minimize cross
          references between documents;
      3.  define building blocks for future extensions so that they can
          be used together in a compatible way.

   It is expected that a future revision of this document will be
   incorporated into a revision of RFC 3501.

   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
   It also includes part of the errata to RFC 3501.  This document
   doesn't specify any semantic changes to the listed RFCs.

   The ABNF in section 6 of RFC 2342 got rewritten to conform to the
   ABNF syntax as defined in RFC 4234 and to reference new non-terminals
   from RFC 3501.  It was also restructured to allow for better
   readability.  There were no changes "on the wire".

   Section 2 extends ABNF for SELECT, EXAMINE, CREATE, RENAME, FETCH/UID
   FETCH, STORE/UID STORE, SEARCH, and APPEND commands in a consistent
   manner.  Extensions to all the commands but APPEND have the same



Melnikov & Daboo            Standards Track                     [Page 2]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


   structure.  Extensibility for the APPEND command was done slightly
   differently in order to preserve backward compatibility with existing
   extensions.

   Section 2 also defines a new ESEARCH response, whose purpose is to
   define a better version of the SEARCH response defined in RFC 3501.

   Section 3 defines the collected ABNF that replaces pieces of ABNF in
   the aforementioned RFCs.  The collected ABNF got generalized to allow
   for easier future extensibility.

1.2.  Conventions Used in This Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [KEYWORDS].

2.  IMAP ABNF Extensions

   This section is not normative.  It provides some background on the
   intended use of different extensions and it gives some guidance about
   how future extensions should extend the described commands.

2.1.  Optional Parameters with the SELECT/EXAMINE Commands

   This document adds the ability to include one or more parameters with
   the IMAP SELECT (section 6.3.1 of [IMAP4]) or EXAMINE (section 6.3.2
   of [IMAP4]) commands, to turn on or off certain standard behaviors,
   or to add new optional behaviors required for a particular extension.

   There are two possible modes of operation:

   o  A global state change where a single use of the optional parameter
      will affect the session state from that time on, irrespective of
      subsequent SELECT/EXAMINE commands.

   o  A per-mailbox state change that will affect the session only for
      the duration of the new selected state.  A subsequent
      SELECT/EXAMINE without the optional parameter will cancel its
      effect for the newly selected mailbox.

   Optional parameters to the SELECT or EXAMINE commands are added as a
   parenthesized list of attribute/value pairs, and appear after the
   mailbox name in the standard SELECT or EXAMINE command.  The order of
   individual parameters is arbitrary.  A parameter value is optional



Melnikov & Daboo            Standards Track                     [Page 3]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


   and may consist of atoms, strings, or lists in a specific order.  If
   the parameter value is present, it always appears in parentheses (*).
   Any parameter not defined by extensions that the server supports must
   be rejected with a BAD response.

      Example:

              C: a SELECT INBOX (ANNOTATE)
              S: ...
              S: a OK SELECT complete

      In the above example, a single parameter is used with the SELECT
      command.

      Example:

              C: a EXAMINE INBOX (ANNOTATE RESPONSES ("UID Responses")
                 CONDSTORE)
              S: ...
              S: a OK EXAMINE complete

      In the above example, three parameters are used with the EXAMINE
      command.  The second parameter consists of two items: an atom
      "RESPONSES" followed by a quoted string.

      Example:

              C: a SELECT INBOX (BLURDYBLOOP)
              S: a BAD Unknown parameter in SELECT command

      In the above example, a parameter not supported by the server is
      used.  This results in the BAD response from the server.

   (*) - if a parameter has a mandatory value, which can always be
   represented as a number or a sequence-set, the parameter value does
   not need the enclosing ().  See ABNF for more details.

2.2.  Extended CREATE Command

   Arguments:  mailbox name
               OPTIONAL list of CREATE parameters

   Responses:  no specific responses for this command

   Result:     OK - create completed
               NO - create failure: cannot create mailbox with
                    that name
               BAD - argument(s) invalid



Melnikov & Daboo            Standards Track                     [Page 4]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


   This document adds the ability to include one or more parameters with
   the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to turn on or
   off certain standard behaviors, or to add new optional behaviors
   required for a particular extension.  No CREATE parameters are
   defined in this document.

   Optional parameters to the CREATE command are added as a
   parenthesized list of attribute/value pairs after the mailbox name.
   The order of individual parameters is arbitrary.  A parameter value
   is optional and may consist of atoms, strings, or lists in a specific
   order.  If the parameter value is present, it always appears in
   parentheses (*).  Any parameter not defined by extensions that the
   server supports must be rejected with a BAD response.

   (*) - if a parameter has a mandatory value, which can always be
   represented as a number or a sequence-set, the parameter value does
   not need the enclosing ().  See ABNF for more details.

2.3.  Extended RENAME Command

   Arguments:  existing mailbox name
               new mailbox name
               OPTIONAL list of RENAME parameters

   Responses:  no specific responses for this command

   Result:     OK - rename completed
               NO - rename failure: cannot rename mailbox with
                    that name, cannot rename to mailbox with
                    that name, etc.
               BAD - argument(s) invalid

   This document adds the ability to include one or more parameters with
   the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to turn on or
   off certain standard behaviors, or to add new optional behaviors
   required for a particular extension.  No RENAME parameters are
   defined in this document.

   Optional parameters to the RENAME command are added as a
   parenthesized list of attribute/value pairs after the new mailbox
   name.  The order of individual parameters is arbitrary.  A parameter
   value is optional and may consist of atoms, strings, or lists in a
   specific order.  If the parameter value is present, it always appears
   in parentheses (*).  Any parameter not defined by extensions that the
   server supports must be rejected with a BAD response.






Melnikov & Daboo            Standards Track                     [Page 5]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


   (*) - if a parameter has a mandatory value, which can always be
   represented as a number or a sequence-set, the parameter value does
   not need the enclosing ().  See ABNF for more details.

2.4.  Extensions to FETCH and UID FETCH Commands

   Arguments:  sequence set
               message data item names or macro
               OPTIONAL fetch modifiers

   Responses:  untagged responses: FETCH

   Result:     OK - fetch completed
               NO - fetch error: cannot fetch that data
               BAD - command unknown or arguments invalid

   This document extends the syntax of the FETCH and UID FETCH commands
   (see section 6.4.5 of [IMAP4]) to include optional FETCH modifiers.
   No fetch modifiers are defined in this document.

   The order of individual modifiers is arbitrary.  Each modifier is an
   attribute/value pair.  A modifier value is optional and may consist
   of atoms and/or strings and/or lists in a specific order.  If the
   modifier value is present, it always appears in parentheses (*).  Any
   modifiers not defined by extensions that the server supports must be
   rejected with a BAD response.

   (*) - if a modifier has a mandatory value, which can always be
   represented as a number or a sequence-set, the modifier value does
   not need the enclosing ().  See ABNF for more details.

2.5.  Extensions to STORE and UID STORE Commands