rfc1056.txt

RFC 的详细文档！

   Descriptors provide message information without taking up large
   amounts of storage.  Each descriptor contains a summary of
   information on a message.  This information includes the message UID,
   its length in bytes and lines, its status (contained in the eight
   system-defined and eight user-defined flags), and portions of its



Lambert                                                        [Page 20]

RFC 1056                         PCMAIL                        June 1988


   RFC-822 header (the "from:", "to:", "date:" and "subject:"  fields).
   All of this information can be encoded in a small (around 100 bytes)
   data structure whose length is independent of the size of the message
   it describes.

   Most clients should be able to store a complete list of message
   descriptors with little problem.  This allows a user to get a
   complete picture of his mail state without having all his messages
   present locally.  If a client has extremely limited amounts of disk
   storage, it is also possible to get a subset of the descriptors from
   the repository.  Short messages can reside on the client, along with
   the descriptors, and long messages can either be printed via the DMSP
   print-message operation, or specially pulled over via the fetch-
   message operation.

6. Typical interactive-style client-repository interaction

   The following example describes a typical communication session
   between the repository and a client mail reader.  The client is one
   of three belonging to user "Fred".  Its name is "office-client", and
   since Fred has used the client within the last week, it is marked as
   "active".  Fred has two mailboxes:  "fred" is where all of his
   current mail is stored; "archive" is where messages of lasting
   importance are kept.  The example will run through a simple
   synchronization operation.  Typically, the synchronization will be
   performed by a mail reader as part of a "get new mail" operation.

   First Fred's mail reader connects to the repository and receives the
   following banner:

       200 Pcmail repository version 3.0.0 ready

   In order to access his global mail state, the mail reader must
   authenticate Fred to the repository; this is done via the DMSP login
   operation:

       login fred fred-password office-client 0 0

   This tells the repository that Fred is logging in via "office-
   client", and that "office-client" is identified by an existing client
   object in Fred's mail state.  The first argument to the login
   operation is Fred's repository user name.  The second argument is
   Fred's password.  The third argument is the name of the client
   communicating with the repository.  The fourth argument tells the
   repository not to create "office-client" even if it cannot find its
   client object.  The final argument tells the repository that Fred's
   client is not operating in batch mode but rather in interactive mode.




Lambert                                                        [Page 21]

RFC 1056                         PCMAIL                        June 1988


   Fred's authentication checks out, so the repository logs him in.

       200 command OK

   Now that Fred is logged in, the mail reader performs an initial
   synchronization.  This process starts with the mail reader's asking
   for an up-to-date list of mailboxes:

       list-mailboxes


   The repository replies with:


       230 mailbox list follows:
       fred 2313 10 1
       archive 101 100 0
       .


   This tells the mail reader that there are two mailboxes, "fred" and
   "archive".  "Fred" has 10 messages, one of which is unseen.  The next
   incoming message will be assigned a UID of 2313.  "Archive", on the
   other hand, has 100 messages, none of which are unseen.  The next
   message sent to "archive" will be assigned the UID 101.  There are no
   new mailboxes in the list (if there were, the mail reader would
   create them.  On the other hand, if some mailboxes in the mail
   reader's local list were not in the repository's list, the program
   would assume them deleted by another client and delete them locally
   as well).

   To synchronize, the mail reader need only look at each mailbox's
   contents to see if (1) any new mail has arrived, or (2) if Fred
   changed any messages on one of his other two clients subsequent to
   "office-client"'s last connection to the repository.

   The mail reader asks for any changed descriptors via the "fetch-
   changed-descriptors" operation.  It requests at most ten changed
   descriptors since storage is very limited on Fred's workstation.

       fetch-changed-descriptors fred 10


   The repository responds with:


       250 descriptor list follows:
       expunged



Lambert                                                        [Page 22]

RFC 1056                         PCMAIL                        June 1988


       2101
       expunged
       2104
       descriptor
       2107 1100011100000010 1400 30
       [e-mail] (Foo Jones)
       [e-mail]
       Wed, 9 Dec 87 10:43:52 EST
       A typical subject line
       descriptor
       2312 0000000000000000 12232 320
       [e-mail]
       [e-mail]
       Thu, 17 Dec 87 18:24:09 PST
       Another typical subject line
       .

   If a descriptor changed because it was expunged, it is transmitted as
   two lines: the word "expunged" on one line, followed by the message
   UID on the next line.  If one of its flags changed state, or it is a
   new message, it is transmitted as six lines: the word "descriptor" on
   one line, followed by a line containing the message UID, flags, and
   length in bytes and lines, followed by the to, from, date, and
   subject fields, each on one line.  The flags are transmitted as a
   single string of ones and zeroes, a one if the flag is on and a zero
   if the flag is off.  All 16 flags are always transmitted.  Flag
   zero's state is the first character in the flag string; flag
   fifteen's is the last character in the flag string.

   The first two descriptors in the list have been expunged, presumably
   by Fred's expunging his mailbox on another client.  The mail reader
   removes messages 2101 and 2104 from its local copy of mailbox "fred".
   The next descriptor in the list is one which Fred marked for deletion
   on another client yesterday.  The mail reader marks the local version
   of the message as deleted.  The last descriptor in the list is a new
   one.  The mail reader adds the descriptor to its local list.  Since
   all changes to mailbox "fred" have now been recorded locally, the
   update list can be reset:

       reset-descriptors fred 1 2312


   The repository responds with:


       200 command OK

   indicating that it has removed from "office-client"'s update list all



Lambert                                                        [Page 23]

RFC 1056                         PCMAIL                        June 1988


   messages in mailbox "fred" with UIDs between 1 and 2312 inclusive (in
   this case just two messages).  "Fred" has now been synchronized.  The
   mail reader now turns to Fred's "archive" mailbox and asks for the
   first ten changed descriptors.

       fetch-changed-descriptors archive 10


   The repository responds with:


       250 descriptor list follows:
       .

   The zero-length list tells the mail reader that no descriptors have
   been changed in "archive" since its last synchronization.  No new
   synchronization needs to be performed.

   Fred's mail reader is now ready to pull over the new message.  The
   message is 320 lines long; there might not be sufficient storage on
   "office-client" to hold the new message.  The mail reader tries
   anyway:

       fetch-message fred 2312


   The repository begins transmitting the message:


       251 message follows:
       UID: 2312
       From: [e-mail]
       To: [e-mail]
       Date: Thu, 17 Dec 87 18:24:09 PST
       Subject: Another typical subject line

       Fred,

       ...

   Halfway through the message transmission, Fred's workstation runs out
   of disk space.  Because all DMSP operations are defined to be
   failure-atomic, the portion of the message already transmitted is
   destroyed locally and the operation fails.  The mail reader informs
   Fred that the message cannot be pulled over because of a lack of disk
   space.  The synchronization process is now finished and Fred can
   start reading his mail.  The new message that was too big to fit on
   "office-client" will be marked "off line"; Fred can use the mail



Lambert                                                        [Page 24]

RFC 1056                         PCMAIL                        June 1988


   reader to either remote-print it or delete and expunge other messages
   until he has enough space to store the new message.

   Since Fred is running in interactive mode, changes he makes to any
   messages will immediately be transmitted into DMSP operations and
   sent to the repository.  Depending on the mail reader implementation,
   Fred will either have to execute a "synchronize" command periodically
   or the client will synchronize for him automatically every so often.

7. A current Pcmail implementation

   The following section briefly describes a current Pcmail system that
   services a small community of users.  The Pcmail repository runs
   under UNIX on a DEC Microvax-II connected to the Internet.  The
   clients run on IBM PCs, XTs, and ATs, as well as Sun workstations,
   Microvaxes, and VAX-750s.

7.1. IBM PC client code

   Client code for the IBM machines operates only in batch mode.  Users
   make local state changes in a mail reader; the changes are queued
   until the user runs a network client program.  The program connects
   to the repository, performs the queued changes, and synchronizes
   local and global mail states.  The network client program then
   disconnects from the repository.

   The IBM PC client code has gone through several revisions since the
   first Pcmail RFC was published.  What was once a fairly primitive and
   cumbersome system has evolved into a system that makes excellent use
   of the PC's limited resources and provides a fairly powerful, easy-
   to-use mail reader.

   Users access and modify their local mail state via a mail reader
   written in the Epsilon text editor's EEL extension language.  Users
   are given a variety of commands to operate on individual messages and
   mailboxes, as well as to compose outgoing mail.

   Synchronization and the processing of queued changes is performed by