rfc1730.txt

RFC 的详细文档！

   recorded copy rather than sending a command to the server to request
   the data.  In the case of certain server data, recording the data is
   mandatory.

   This topic is discussed in greater detail in the Server Responses
   section.































Crispin                                                         [Page 3]

RFC 1730                         IMAP4                     December 1994


3.      State and Flow Diagram

   An IMAP4 server is in one of four states.  Most commands are valid in
   only certain states.  It is a protocol error for the client to
   attempt a command while the command is in an inappropriate state.  In
   this case, a server will respond with a BAD or NO (depending upon
   server implementation) command completion result.


3.1.    Non-Authenticated State

   In non-authenticated state, the user must supply authentication
   credentials before most commands will be permitted.  This state is
   entered when a connection starts unless the connection has been
   pre-authenticated.


3.2.    Authenticated State

   In authenticated state, the user is authenticated and must select a
   mailbox to access before commands that affect messages will be
   permitted.  This state is entered when a pre-authenticated connection
   starts, when acceptable authentication credentials have been
   provided, or after an error in selecting a mailbox.


3.3.    Selected State

   In selected state, a mailbox has been selected to access.  This state
   is entered when a mailbox has been successfully selected.


3.4.    Logout State

   In logout state, the session is being terminated, and the server will
   close the connection.  This state can be entered as a result of a
   client request or by unilateral server decision.














Crispin                                                         [Page 4]

RFC 1730                         IMAP4                     December 1994


            +--------------------------------------+
            |initial connection and server greeting|
            +--------------------------------------+
                      || (1)       || (2)        || (3)
                      VV           ||            ||
            +-----------------+    ||            ||
            |non-authenticated|    ||            ||
            +-----------------+    ||            ||
             || (7)   || (4)       ||            ||
             ||       VV           VV            ||
             ||     +----------------+           ||
             ||     | authenticated  |<=++       ||
             ||     +----------------+  ||       ||
             ||       || (7)   || (5)   || (6)   ||
             ||       ||       VV       ||       ||
             ||       ||    +--------+  ||       ||
             ||       ||    |selected|==++       ||
             ||       ||    +--------+           ||
             ||       ||       || (7)            ||
             VV       VV       VV                VV
            +--------------------------------------+
            |     logout and close connection      |
            +--------------------------------------+

         (1) connection without pre-authentication (OK greeting)
         (2) pre-authenticated connection (PREAUTH greeting)
         (3) rejected connection (BYE greeting)
         (4) successful LOGIN or AUTHENTICATE command
         (5) successful SELECT or EXAMINE command
         (6) CLOSE command, or failed SELECT or EXAMINE command
         (7) LOGOUT command, server shutdown, or connection closed




















Crispin                                                         [Page 5]

RFC 1730                         IMAP4                     December 1994


4.      Data Formats

   IMAP4 uses textual commands and responses.  Data in IMAP4 can be in
   one of several forms: atom, number, string, parenthesized list, or
   NIL.


4.1.    Atom

   An atom consists of one or more non-special characters.


4.2.    Number

   A number consists of one or more digit characters, and represents a
   numeric value.


4.3.    String

   A string is in one of two forms: literal and quoted string.  The
   literal form is the general form of string.  The quoted string form
   is an alternative that avoids the overhead of processing a literal at
   the cost of restrictions of what may be in a quoted string.

   A literal is a sequence of zero or more octets (including CR and LF),
   prefix-quoted with an octet count in the form of an open brace ("{"),
   the number of octets, close brace ("}"), and CRLF.  In the case of
   literals transmitted from server to client, the CRLF is immediately
   followed by the octet data.  In the case of literals transmitted from
   client to server, the client must wait to receive a command
   continuation request (described later in this document) before
   sending the octet data (and the remainder of the command).

   A quoted string is a sequence of zero or more 7-bit characters,
   excluding CR and LF, with double quote (<">) characters at each end.

   The empty string is respresented as either "" (a quoted string with
   zero characters between double quotes) or as {0} followed by CRLF (a
   literal with an octet count of 0).

        Note: Even if the octet count is 0, a client transmitting a
        literal must wait to receive a command continuation
        request.







Crispin                                                         [Page 6]

RFC 1730                         IMAP4                     December 1994


4.3.1.  8-bit and Binary Strings

   8-bit textual and binary mail is supported through the use of
   [MIME-1] encoding.  IMAP4 implementations MAY transmit 8-bit or
   multi-octet characters in literals, but should do so only when the
   character set is identified.

   Although a BINARY body encoding is defined, unencoded binary strings
   are not permitted.  A "binary string" is any string with NUL
   characters.  Implementations MUST encode binary data into a textual
   form such as BASE64 before transmitting the data.  A string with an
   excessive amount of CTL characters may also be considered to be
   binary, although this is not required.


4.4.    Parenthesized List

   Data structures are represented as a "parenthesized list"; a sequence
   of data items, delimited by space, and bounded at each end by
   parentheses.  A parenthesized list may itself contain other
   parenthesized lists, using multiple levels of parentheses to indicate
   nesting.

   The empty list is represented as () -- a parenthesized list with no
   members.


4.5.    NIL

   The special atom "NIL" represents the non-existence of a particular
   data item that is represented as a string or parenthesized list, as
   distinct from the empty string "" or the empty parenthesized list ().



















Crispin                                                         [Page 7]

RFC 1730                         IMAP4                     December 1994


5.      Operational Considerations

5.1.    Mailbox Naming

   The interpretation of mailbox names is implementation-dependent.
   However, the mailbox name INBOX is a special name reserved to mean
   "the primary mailbox for this user on this server".  If it is desired
   to export hierarchical mailbox names, mailbox names must be
   left-to-right hierarchical using a single character to separate
   levels of hierarchy.  The same hierarchy separator character is used
   for all levels of hierarchy within a single name.

5.2.    Mailbox Size and Message Status Updates

   At any time, a server can send data that the client did not request.
   Sometimes, such behavior is required.  For example, agents other than
   the server may add messages to the mailbox (e.g. new mail delivery),
   change the flags of message in the mailbox (e.g. simultaneous access
   to the same mailbox by multiple agents), or even remove messages from
   the mailbox.  A server MUST send mailbox size updates automatically
   if a mailbox size change is observed during the processing of a
   command.  A server SHOULD send message flag updates automatically,
   without requiring the client to request such updates explicitly.
   Special rules exist for server notification of a client about the
   removal of messages to prevent synchronization errors; see the
   description of the EXPUNGE response for more details.

   Regardless of what implementation decisions a client may take on
   remembering data from the server, a client implementation MUST record
   mailbox size updates.  It MUST NOT assume that any command after
   initial mailbox selection will return the size of the mailbox.


5.3.    Response when no Command in Progress

   Server implementations are permitted to send an untagged response
   (except for EXPUNGE) while there is no command in progress.  Server
   implementations that send such responses MUST deal with flow control
   considerations.  Specifically, they must either (1) verify that the
   size of the data does not exceed the underlying transport's available
   window size, or (2) use non-blocking writes.










Crispin                                                         [Page 8]

RFC 1730                         IMAP4                     December 1994


5.4.    Autologout Timer

   If a server has an inactivity autologout timer, that timer MUST be of
   at least 30 minutes' duration.  The receipt of ANY command from the
   client during that interval should suffice to reset the autologout
   timer.


5.5.    Multiple Commands in Progress

   The client is not required to wait for the completion result response
   of a command before sending another command, subject to flow control
   constraints on the underlying data stream.  Similarly, a server is
   not required to process a command to completion before beginning
   processing of the next command, unless an ambiguity would result
   because of a command that would affect the results of other commands.
   If there is such an ambiguity, the server executes commands to
   completion in the order given by the client.