RFC IMAP
Sommaire How to Read This Document Protocol Overview State and Flow Diagram Data Formats Operational Considerations Client Commands Server Responses Sample IMAP4 connection Formal Syntax Author's Note Security Considerations Author's Address References

RFC du protocole IMAP : How to Read This Document

1. How to Read This Document

1.1. Organization of This Document

   This document is written from the point of view of the implementor of
   an IMAP4rev1 client or server.  Beyond the protocol overview in
   section 2, it is not optimized for someone trying to understand the
   operation of the protocol.  The material in sections 3 through 5
   provides the general context and definitions with which IMAP4rev1
   operates.

   Sections 6, 7, and 9 describe the IMAP commands, responses, and
   syntax, respectively.  The relationships among these are such that it
   is almost impossible to understand any of them separately.  In
   particular, do not attempt to deduce command syntax from the command
   section alone; instead refer to the Formal Syntax section.

1.2. Conventions Used in This Document

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

   The following terms are used in this document to signify the
   requirements of this specification.

   1) MUST, or the adjective REQUIRED, means that the definition is
      an absolute requirement of the specification.

   2) MUST NOT that the definition is an absolute prohibition of the
      specification.

   3) SHOULD means that there may exist valid reasons in particular
      circumstances to ignore a particular item, but the full
      implications MUST be understood and carefully weighed before
      choosing a different course.

   4) SHOULD NOT means that there may exist valid reasons in
      particular circumstances when the particular behavior is
      acceptable or even useful, but the full implications SHOULD be
      understood and the case carefully weighed before implementing
      any behavior described with this label.

   5) MAY, or the adjective OPTIONAL, means that an item is truly
      optional.  One vendor may choose to include the item because a
      particular marketplace requires it or because the vendor feels
      that it enhances the product while another vendor may omit the
      same item.  An implementation which does not include a
      particular option MUST be prepared to interoperate with another
      implementation which does include the option.

      "Can" is used instead of "may" when referring to a possible
      circumstance or situation, as opposed to an optional facility of
      the protocol.

      "User" is used to refer to a human user, whereas "client" refers
      to the software being run by the user.

      "Connection" refers to the entire sequence of client/server
      interaction from the initial establishment of the network
      connection until its termination.  "Session" refers to the
      sequence of client/server interaction from the time that a mailbox
      is selected (SELECT or EXAMINE command) until the time that
      selection ends (SELECT or EXAMINE of another mailbox, CLOSE
      command, or connection termination).

       Characters are 7-bit US-ASCII unless otherwise specified.  Other
       character sets are indicated using a "CHARSET", as described in
       [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
       additional semantics in addition to defining character set; refer
       to these documents for more detail.
Annonces