rfc1203.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   "(FLAGS INTERNALDATE RFC822.SIZE)".

   The second category is that data which describes the composition and
   delivery information of a message; that is, information such as the
   message sender, recipient lists, message-ID, subject, etc.  This is
   the information which is stored in the message header in RFC 822
   format message and is traditionally called the "envelope".  [Note:
   this should not be confused with the SMTP (RFC 821) envelope, which
   is strictly limited to delivery information.]  IMAP3 defines a
   structured and unambiguous representation for the envelope which is
   particularly nice for Lisp-based parsers.  A client can use the
   envelope for operations such as replying and not worry about RFC 822
   at all.  Envelopes are discussed in more detail below.  The first and
   second category data can be fetched together by using the macro-fetch
   word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE
   RFC822.SIZE ENVELOPE)".

   The third category is that data which is intended for direct human
   viewing.  The present RFC 822 based IMAP3 defines three such items:
   RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
   former appended together in a single text string).  Fetching "RFC822"
   is equivalent to typing the RFC 822 representation of the message as
   stored on the mailbox without any filtering or processing.

   Typically, a client will "FETCH ALL" for some or all of the messages
   in the mailbox for use as a presentation menu, and when the user
    wishes to read a particular message will "FETCH RFC822.TEXT" to get
   the message body.  A more primitive client could, of course, simply
   "FETCH RFC822" a la POP2-type functionality.

   The client can alter certain data by means of a STORE command.  As an
   example, a message is deleted from a mailbox by a STORE command which
   includes the \DELETED flag as one of the flags being set.

   Other client operations include copying a message to another mailbox
   (COPY command), permanently removing deleted messages (EXPUNGE
   command), checking for new messages (CHECK command), and searching
   for messages which match certain criteria (SEARCH command).



Rice                                                           [Page 11]

RFC 1203                         IMAP3                     February 1991


   The client terminates the session with the LOGOUT command.  The
   server returns a "BYE" followed by an "OK".

A Typical Scenario

        Client                          Server
        ------                          ------
                                    {Wait for Connection}
    {Open Connection}        -->
                                <-- * OK IMAP3 Server Ready
                                    {Wait for command}
    A001 SUPPORTED.VERSIONS   -->
                                <-- * SUPPORTED.VERSIONS ((2 0 )
                                        (3 0 EIGHT.BIT.TRANSPARENT
                                             AUTO.SET.SEEN
                                             TAGGED.SOLICITED))
                                    A001 OK Supported Versions returned.
                                    {Wait for command}
    A002 SELECT.VERSION (3 0) -->
                                <-- A002 OK Version 3.0 Selected.
                                    {Wait for command}
    A002 SELECT.FEATURES TAGGED.SOLICITED -->
                                <-- A002 OK Features selected.
                                    {Wait for command}
    A003 LOGIN Fred Secret   -->
                                <-- A003 OK User Fred logged in
                                    {Wait for command}
    A004 SELECT INBOX        -->
                                <-- A004 FLAGS (Meeting Notice \Answered
                                             \Flagged \Deleted \Seen)
                                <-- A004 19 EXISTS
                                <-- A004 2 RECENT
                                <-- A004 OK Select complete
                                    {Wait for command}
    A005 FETCH 1:19 ALL      -->
                                <-- A005 1 Fetch (......)
                                        ...
                                <-- A005 18 Fetch (......)
                                <-- A005 19 Fetch (......)
                                <-- A005 OK Fetch complete
                                    {Wait for command}
    A006 FETCH 8 RFC822.TEXT -->
                                <-- A006 8 Fetch (RFC822.TEXT {893}
                                       ...893 characters of text...
                                <-- )
                                <-- A006 OK Fetch complete
                                    {Wait for command}




Rice                                                           [Page 12]

RFC 1203                         IMAP3                     February 1991


    A007 STORE 8 +Flags \Deleted -->
                                <-- A007 8 Store (Flags (\Deleted
                                               \Seen))
                                <-- A007 OK Store complete
                                    {Wait for command}
    A008 EXPUNGE             -->
                                <-- A008 19 EXISTS
                                <-- A008 8 EXPUNGE
                                <-- A008 18 EXISTS
                                <-- A008 Expunge complete
                                    {Wait for command}
    A009 LOGOUT              -->
                                <-- A009 BYE IMAP3 server quitting
                                <-- A009 OK Logout complete
    {Close Connection}       --><-- {Close connection}
                                    {Go back to start}

   A more complex scenario produced by a pipelining multiprocess client.

        Client                          Server
        ------                          ------
                                    {Wait for Connection}
    {Open session as above}
                                <-- A004 19 EXISTS
                                <-- A004 2 RECENT
                                <-- A004 OK Select complete
                                    {Wait for command}
    A005 SEARCH RECENT       -->
                                <-- A005 SEARCH (18 19) (RECENT)
                                <---A005 OK Search complete
    A006 FETCH 18:19 ALL RFC822.TEXT
    A007 STORE 18:19 +FLAGS (\SEEN)
    A008 FETCH 1:17 ALL      -->
                                <-- A006 18 Fetch (... RFC822.TEXT ...)
    A009 STORE 18 +FLAGS (\DELETED)
                                <-- A006 19 Fetch (... RFC822.TEXT ...)
                                <-- A006 OK Fetch complete
                                <-- A007 18 STORE (Flags (\Seen))
    A010 STORE 19 +FLAGS (\DELETED)
                                <-- A007 19 STORE (Flags (\Seen))
                                <-- A007 OK Store complete
                                <-- A008 1 Fetch (......)
                                       ...
                                <-- A008 16 Fetch (......)
                                <-- A008 17 Fetch (......)
                                <-- A008 OK Fetch complete
                                <-- A009 18 STORE (Flags (\Seen
                                                          \Deleted))



Rice                                                           [Page 13]

RFC 1203                         IMAP3                     February 1991


                                <-- A009 OK Store complete
                                <-- A010 19 STORE (Flags (\Seen
                                                          \Deleted))
                                <-- A010 OK Store complete
                                    {Wait for command}
                                <-- * EXISTS 23
                                <-- * RECENT 4
                                <-- * SEARCH (20 21 22 23) (RECENT)
   A011 FETCH 20:23 ALL RFC822.TEXT

Conventions

   The following terms are used in a meta-sense in the syntax
   specification below:

      An ASCII-STRING is a sequence of arbitrary ASCII characters.

      An ATOM is a sequence of ASCII characters delimited by SP or CRLF.

      A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
      or "\".

      A CRLF is an ASCII carriage-return character followed immediately
      by an ASCII linefeed character.

      A NUMBER is a sequence of the ASCII characters which represent
      decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
      ":".

      A SP is the ASCII space character.

      A TEXT_LINE is a human-readable sequence of ASCII characters up to
      but not including a terminating CRLF.

   One of the most common fields in the IMAP3 protocol is a STRING,
   which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside
   double-quotes), or a LITERAL.  A literal consists of an open brace
   ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII-
   STRING of n characters, where n is the value of the number inside the
   brace. In general, a string should be represented as an ATOM or
   QUOTED-STRING if at all possible.  The semantics for QUOTED-STRING or
   LITERAL are checked before those for ATOM; therefore an ATOM used in
   a STRING may only contain CHARACTERs.  Literals are most often sent
   from the server to the client; in the rare case of a client to server
   literal there is a special consideration (see the "+ text" response
   below).

   Another important field is the SEQUENCE, which identifies a set of



Rice                                                           [Page 14]

RFC 1203                         IMAP3                     February 1991


   messages by consecutive numbers from 1 to n where n is the number of
   messages in the mailbox.  A sequence may consist of a single number,
   a pair of numbers delimited by colon indicating all numbers between
   those two numbers, or a list of single numbers and/or number pairs.
   For example, the sequence 2,4:7,9,12:15 is equivalent to
   2,4,5,6,7,9,12,13,14,15 and identifies all of those messages.

Definitions of Commands and Responses

   Summary of Commands and Responses

Commands:
       tag NOOP
       tag LOGIN user password
       tag LOGOUT
       tag SELECT mailbox
       tag CHECK
       tag EXPUNGE
       tag COPY sequence mailbox
       tag FETCH sequence data
       tag STORE sequence data value
       tag SEARCH criteria
       tag BBOARD bboard
       tag FIND (BBOARDS / MAILBOXES) pattern
       tag READONLY
       tag READWRITE
       tag SELECT.VERSION (major_version minor_version)
       tag SELECT.FEATURES features
       tag SUPPORTED.VERSIONS
       tag FLAGS
       tag SET.FLAGS

Responses (can be either solicited or unsolicited):
       */tag FLAGS flag_list
       */tag SEARCH (numbers) (criteria)
       */tag EXISTS
       */tag RECENT
       */tag EXPUNGE
       */tag STORE data
       */tag FETCH data
       */tag BBOARD bboard_name
       */tag MAILBOX non_inbox_mailbox_name
       */tag SUPPORTED.VERSIONS version_data
       */tag READONLY
       */tag READWRITE
       */tag OK text
       */tag NO text
       */tag BAD text



Rice                                                           [Page 15]

RFC 1203                         IMAP3                     February 1991


       */tag BYE text

Responses (can only be solicited):
       tag COPY message_number

Responses (can only be unsolicited):
       + text

Commands

   tag NOOP

      The NOOP command returns an OK to the client.  By itself, it does
      nothing, but certain things may happen as side effects.  For
      example, server implementations which implicitly check the mailbox
      for new mail may do so as a result of this command.  The primary
      use of this command is to for the client to see if the server is
      still alive (and notify the server that the client is still alive,