rfc1064.txt

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

Crispin                                                        [Page 20]

RFC 1064                         IMAP2                         July 1988


Implementation Discussion

   As of this writing, SUMEX has completed an IMAP2 client for Xerox
   Lisp machines written in hybrid Interlisp/CommonLisp and is beta-
   testing a client for TI Explorers written entirely in CommonLisp.
   SUMEX has also completed a portable IMAP2 client protocol library
   module written in C.  This library, with the addition of a small main
   program (primarily user interface) and a TCP/IP driver, became a
   rudimentary remote system mail-reading program under Unix.  The first
   production use of this library will be as a part of a MacII client
   which is under development.

   As of this writing, SUMEX has completed IMAP2 servers for TOPS-20
   written in DEC-20 assembly language and 4.2/3 BSD Unix written in C.
   The TOPS-20 server is fully compatible with MM-20, the standard
   TOPS-20 mailsystem, and requires no special action or setup on the
   part of the user.  The INBOX under TOPS-20 is the user's MAIL.TXT.
   The TOPS-20 server also supports multiple simultaneous access to the
   same mailbox, including simultaneous access between the IMAP2 server
   and MM-20.  The 4.2/3 BSD Unix server requires that the user use
   mail.txt format which is compatible only with SRI MM-32 or Columbia
   MM-C.  The 4.2/3 BSD Unix server only allows simultaneous read
   access; write access must be exclusive.

   The Xerox Lisp client and DEC-20 server have been in production use
   for over a year; the Unix server was put into production use a few
   months ago.  IMAP2 has been used to access mailboxes at remote sites
   from a local workstation via the Internet.  For example, from the
   Stanford local network the author has read his mailbox at a Milnet
   site.

   This specification does not make any formal definition of size
   restrictions, but the DEC-20 server has the following limitations:

    . length of a mailbox: 7,077,888 characters
    . maximum number of messages: 18,432 messages
    . length of a command line: 10,000 characters
    . length of the local host name: 64 characters
    . length of a "short" argument: 39 characters
    . length of a "long" argument: 491,520 characters
    . maximum amount of data output in a single fetch:
      655,360 characters

   To date, nobody has run up against any of these limitations, many of
   which are substantially larger than most current user mail reading
   programs.

   There are several advantages to the scheme of tags and unsolicited



Crispin                                                        [Page 21]

RFC 1064                         IMAP2                         July 1988


   responses.  First, the infamous synchronization problems of SMTP and
   similar protocols do not happen with tagged commands; a command is
   not considered satisfied until a response with the same tag is seen.
   Tagging allows an arbitrary amount of other responses ("unsolicited"
   data) to be sent by the server with no possibility of the client
   losing synchronization.  Compare this with the problems that FTP or
   SMTP clients have with continuation, partial completion, and
   commentary reply codes.

   Another advantage is that a non-lockstep client implementation is
   possible.  The client could send a command, and entrust the handling
   of the server responses to a different process which would signal the
   client when the tagged response comes in.  Under certain
   circumstances, the client could even have more than one command
   outstanding.

   It was observed that synchronization problems can occur with literals
   if the literal is not recognized as such.  Fortunately, the cases in
   which this can happen are relatively rare; a mechanism (the special
   "+" tag response) was introduced to handle those few cases which
   could happen.  The proper way to address this problem in all cases is
   probably to move towards a record-oriented architecture instead of
   the text stream model provided by TCP.

   Unsolicited data needs some discussion.  Unlike most protocols, in
   which the server merely does the client's bidding, an IMAP2 server
   has a semi-autonomous role.  By means of sending "unsolicited data",
   the server is in effect sending a command to the client -- to update
   and/or extend its (incomplete) model of the mailbox with new
   information from the server.  In this viewpoint, a "fetch" command is
   merely a request to the server to include the desired data in any
   other "unsolicited" data the server may send, and a server
   acknowledgement to the "fetch" is a statement that all the requested
   data has been sent.

   In terms of implementation, the client may have a local cache of data
   from the mailbox.  This cache is incomplete, and at startup is empty.
   A listener processes all unsolicited data, and updates the cache
   based on this data.  If a tagged response arrives, the listener
   unblocks the process which sent the tagged request.

   Perhaps as a result of opening a mailbox, unsolicited data from the
   server arrives.  The first piece of data is the number of messages.
   This is used to size the cache; note that by sending a new "number of
   messages" unsolicited data message the cache would be re-sized (this
   is how newly arrived mail is handled).  If the client attempts to
   access information from the cache, it will encounter empty spots
   which will trigger "fetch" requests.  The request would be sent, some



Crispin                                                        [Page 22]

RFC 1064                         IMAP2                         July 1988


   unsolicited data including the answer to the fetch will flow back,
   and then the "fetch" response will unblock the client.

   People familiar with demand-paged virtual memory operating system
   design will recognize this model as being very similar to page-fault
   handling on a demand-paged system.













































Crispin                                                        [Page 23]

RFC 1064                         IMAP2                         July 1988


Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in RFC 822 with one exception; the
   delimiter used with the "#" construct is a single space (SP) and not
   a comma.

   address         ::= "(" addr_name SP addr_adl SP addr_mailbox SP
                       addr_host ")"

   addr_adl        ::= nil / string

   addr_host       ::= nil / string

   addr_mailbox    ::= nil / string

   addr_name       ::= nil / string

   check           ::= "CHECK"

   copy            ::= "COPY" SP sequence SP mailbox

   data            ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number /
                       "BYE" SP text_line / "OK" SP text_line /
                       "NO" SP text_line / "BAD" SP text_line)

   date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"

   envelope        ::= "(" env_date SP env_subject SP env_from SP
                       env_sender SP env_reply-to SP env_to SP
                       env_cc SP env_bcc SP env_in-reply-to SP
                       env_message-id ")"

   env_bcc         ::= nil / "(" 1*address ")"

   env_cc          ::= nil / "(" 1*address ")"

   env_date        ::= string

   env_from        ::= nil / "(" 1*address ")"

   env_in-reply-to ::= nil / string

   env_message-id  ::= nil / string

   env_reply-to    ::= nil / "(" 1*address ")"

   env_sender      ::= nil / "(" 1*address ")"



Crispin                                                        [Page 24]

RFC 1064                         IMAP2                         July 1988


   env_subject     ::= nil / string

   env_to          ::= nil / "(" 1*address ")"

   expunge         ::= "EXPUNGE"

   fetch           ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
                       fetch_att / "(" 1#fetch_att ")")

   fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
                       "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
                       "RFC822.TEXT"

   flag_list       ::= ATOM / "(" 1#ATOM ")"

   literal         ::= "{" NUMBER "}" CRLF ASCII-STRING

   login           ::= "LOGIN" SP userid SP password

   logout          ::= "LOGOUT"

   mailbox         ::= "INBOX" / string

   msg_copy        ::= "COPY"

   msg_data        ::= (msg_exists / msg_recent / msg_expunge /
                       msg_fetch / msg_copy)

   msg_exists      ::= "EXISTS"

   msg_expunge     ::= "EXPUNGE"

   msg_fetch       ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
                        envelope / "FLAGS" SP "(" 1#(recent_flag
                        flag_list) ")" / "INTERNALDATE" SP date /
                        "RFC822" SP string / "RFC822.HEADER" SP string /
                        "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
                        string) ")"

   msg_recent      ::= "RECENT"

   msg_num         ::= NUMBER

   nil             ::= "NIL"

   noop            ::= "NOOP"

   password        ::= string



Crispin                                                        [Page 25]

RFC 1064                         IMAP2                         July 1988


   recent_flag     ::= "\RECENT"

   ready           ::= "+" SP text_line

   request         ::= tag SP (noop / login / logout / select / check /
                       expunge / copy / fetch / store / search) CRLF

   response        ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF

   search          ::= "SEARCH" SP 1#("ALL" / "ANSWERED" /
                       "BCC" SP string / "BEFORE" SP string /
                       "BODY" SP string / "CC" SP string / "DELETED" /
                       "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
                       "ON" SP string / "RECENT" / "SEEN" /
                       "SINCE" SP string / "TEXT" SP string /
                       "TO" SP string / "UNANSWERED" / "UNDELETED" /
                       "UNFLAGGED" / "UNKEYWORD" / "UNSEEN")

   select          ::= "SELECT" SP mailbox

   sequence        ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
                       sequence)

   store           ::= "STORE" SP sequence SP store_att

   store_att       ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
                       "FLAGS" SP flag_list)

   string          ::= atom / """" 1*character """" / literal

   system_flags    ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
                       "\SEEN"

   tag             ::= atom

   unsolicited     ::= "*" SP (msg_num SP msg_data / data) CRLF

   userid          ::= string

Acknowledgements

   Bill Yeager and Rich Acuff both contributed invaluable suggestions in
   the evolution of IMAP2 from the original IMAP.  The SUMEX IMAP2
   software was written by Mark Crispin (DEC-20 server, Xerox Lisp
   client, C client), Frank Gilmurray (Common Lisp client), Christopher
   Lane (Xerox Lisp client), and Bill Yeager (Unix server).  Any
   mistakes or flaws in this IMAP2 protocol specification are, however,
   strictly my own.



Crispin                                                        [Page 26]