rfc984.txt

RFC 相关的技术文档

      mailbox and address object lists with the repository's global
      version and make any appropriate changes.  The majority of
      possible changes to a user's mail state are in the form of changed
      descriptors.  Since most users will have a large number of
      messages, and message states will change relatively often, special
      attention needs to be paid to message synchronization.

      An existing descriptor can be changed in one of two ways: first,
      one of its sixteen flags values can be changed (this encompasses
      reading an unseen message, deleting a message, and expunging a
      message).  The second way to change a descriptor is via the
      arrival of incoming mail or the copying of a message from one
      mailbox to another.  Both result in a new message being added to a
      mailbox.

      In both the above cases, synchronization is required between the
      repository and every client that has not previously noted a
      change.  To keep track of which clients have noticed a global mail
      state change and changed their local states accordingly, each
      descriptor has associated with it a (potentially empty) "update
      list" of client objects.  The list identifies those clients which
      have not yet recorded a change to that descriptor's state.



Clark & Lambert                                                [Page 18]



RFC 984                                                         May 1986
PCMAIL


      When a client connects to the repository, it executes a DMSP
      "get-changed-descriptors" operation.  This causes the repository
      to return a list of all descriptor objects that have the
      requesting client on their update list.  As the client receives
      the changed descriptors, it can store them locally, thus updating
      the local mail state.  After a changed descriptor has been
      recorded, the client uses the DMSP "reset-descriptors" operation
      to remove itself from the descriptor's update list.  That
      descriptor will now not be sent to the client unless (1) it is
      explicitly requested, or (2) it changes again.

      In this manner, a client can run through its user's mailboxes,
      getting all changed descriptors, incorporating them into the local
      mail state, and marking the change as recorded.

   5.3. Batch operation versus interactive operation

      Because of the portable nature of most PCs, they may not always be
      connected to the repository.  Since each client maintains a local
      mail state, Pcmail users can manipulate the local state while not
      connected to the repository.  This is known as "batch" operation,
      since all changes are recorded by the client and made to the
      repository's global state in a batch, when the client next
      connects to the repository.  Interactive operation occurs when a
      client is always connected to the repository.  In interactive
      mode, changes made to the local mail state are immediately
      propagated to the global state via DMSP operations.

      In batch mode, interaction between client and repository takes the
      following form:  the client connects to the repository and sends
      over all the changes made by the user to the local mail state.
      The repository changes its global mail state accordingly. When all
      changes have been processed, the client begins synchronization, to
      incorporate newly-arrived mail, as well as mail state changes by
      other clients, into the local state.

      In interactive mode, since local changes are immediately
      propagated to the repository, the first part of batch-type
      operation is eliminated.  The synchronization process also
      changes; interactive clients can periodically poll the repository
      for a list of changes, synchronizing a small amount at a time.








Clark & Lambert                                                [Page 19]



RFC 984                                                         May 1986
PCMAIL


   5.4. Message summaries

      Since PCs are assumed to have little in the way of disk storage, a
      given client may never have enough room for a complete local copy
      of a user's global mail state.  This means that Pcmail's client
      architecture must allow user's to obtain a clear picture of their
      mail state without having all their messages present.

      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 (encoded in the
      eight system-defined and eight user-defined flags), and portions
      of its RFC-822 header (the "to:", "from:", "subject:" and "date:"
      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.

      Any client 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.  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-text operation.

6. Typical Client-Repository Interaction

   The following example describes a typical communication session
   between the repository and a client.  The client is one of three
   belonging to user "Fred".  Its name is "office-client", and since
   Fred uses the client regularly to access his mail, the client is
   marked as "active".  Fred has two mailboxes: "main" 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 followed by a series of typical mail state
   manipulations.  Typically, the synchronization will be performed by
   an application program that connects to the repository, logs in,
   synchronizes, and logs out.

   For the example, all DMSP operations will be shown in a user-readable
   format.  In reality, the operations would be sent as a stream of USP
   blocks consisting of a block-type number followed by a stream of
   bytes representing the block's arguments. Both the block name and its
   number are included for convenience.




Clark & Lambert                                                [Page 20]



RFC 984                                                         May 1986
PCMAIL


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

      600 (login) ["fred", "ajyr63ywg", "office-client",
                   FALSE, FALSE]

   This tells the repository that Fred is logging in via
   "office-client", and that "office-client" is identified by an
   existing client object attached to Fred's user object.  The second
   login block argument in an encrypted version of Fred's password.  The
   final argument tells the repository that Fred's client is not
   operating in batch mode but rather in interactive mode.

   Fred's authentication checks out, so the repository logs him in,
   acknowledging the login request with an OK block.

   Now that Fred is logged in, he wants to bring
   "office-client"'s local mail state up to date.  To do this, the
   client program asks for an up-to-date list of mailboxes:

      800 (list-mailboxes) []

   The repository replies with:

      801 (mailbox-list) [["main", 10, 1, 253],
                          ["archive", 100, 0, 101]]

   This tells the client that there are two mailboxes, "main" and
   "archive".  "Main" has 10 messages, one of which is unseen. The next
   incoming message will be assigned a UID of 253. "Archive", on the
   other hand, has 100 message, 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 client program would
   create them.  On the other hand, if some mailboxes in the client'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 client 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 client asks for any changed descriptors via the
   "get-changed-descriptors" operation.  It requests at most ten changed
   descriptors since storage is very tight on "office-client".


Clark & Lambert                                                [Page 21]



RFC 984                                                         May 1986
PCMAIL


      1105 (get-changed-descriptors) ["main", 10]

   The repository responds with:

      1103 (descriptor-list) [[descriptor[
                               6,
                               [T T F F F F F F F F F F F F F F],
                               "Fred@borax",
                               "Joe@fab",
                               "Wed, 23 Jan 86 11:11 EST",
                               "tomorrow's meeting",
                               621,
                               10]]
                              [descriptor[
                               10,
                               [F T F F F F F F F F F F F F F F],
                               "Fred",
                               "Freds-secretary",
                               "Fri, 25 Jan 86 11:11 EST",
                               "Monthly progress report",
                               13211,
                               350]]
                           ]

   The first descriptor in the list is one which Fred deleted on another
   client yesterday.  "Office-client" marks the local version of the
   message as deleted.  The second descriptor in the list is a new one.
   "Office-client" adds the descriptor to its local list.  Since both
   changes have now been recorded locally, the descriptors can be reset:

      1106 (reset-descriptors) ["main", 2]

   The repository clears each descriptor's update vector bit
   corresponding to "office-client"'s client object.  "Main" has now
   been synchronized.  The client now turns to Fred's "archive" mailbox
   and asks for the first ten changed descriptors.

      1105 (get-changed-descriptors) ["archive", 10]

   The repository responds with

      1103 (descriptor-list) []

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



Clark & Lambert                                                [Page 22]



RFC 984                                                         May 1986
PCMAIL


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

      1107 (fetch-message-text) ["main", 10]

   The repository begins transmitting the message:

      1110 (message) ["From: Fred's-secretary",
                      "To: Fred",
                      "Subject: Monthly progress report",
                      "Date: Fri, 25 Jan 86 11:11 EST",
                      "",
                      "Dear Fred,",
                      "Here is this month's progress report",
                      ...
                      ]

   Halfway through the message transmission, "office-client" runs out of
   disk space.  Because all DMSP operations are defined to be atomic,
   the portion of the message already transmitted is destroyed locally
   and the operation fails.  "Office-client" informs Fred that the
   message cannot be pulled over because of a lack of disk space.  The
   synchronization process is now finished and Fred's client logs out.

      601 (logout) []

   The repository does any housecleaning it needs to do, acknowledges
   the logout request, and closes the USP connection.

7. A Current Pcmail Implementation

   The following section briefly describes a current implementation of
   Pcmail that services a small community of users.  The Pcmail
   repository runs under UNIX on a DEC VAX-750 connected to the
   Internet.  The clients are IBM PCs, XTs, and ATs.  The network
   software that communicates with the repository allows only
   "batch-mode" operation.  Users make local state changes, which are
   queued until the client connects to the repository.  At that time,
   the changes are performed and the local and global states
   synchronized.  The client then disconnects from the repository.

   Users access and modify their local mail state via a user interface
   program.  The program uses windows and a full-screen mode of
   operation.  Users are given a rich variety of commands to operate on



Clark & Lambert                                                [Page 23]



RFC 984                                                         May 1986
PCMAIL


   individual messages as well as mailboxes.  The interface allows use
   of any text editor to compose messages, and adds features of its own
   to make RFC-822-style header composition easier.

   Synchronization and the processing of queued changes is performed by
   a separate program, which the user runs whenever he wishes.  The
   program takes any actions queued while operating the user interface,
   and converts them into DMSP operations.  All queued changes are made
   before any synchronization is performed.

   The limitation of client operation to batch mode was made for the
   following reasons: first, the implementation is slanted toward use of
   portable computers as clients.  These computers are rarely connected
   to the network, making interactive mode unnecessary.  Those clients
   that are constantly connected to the network run slightly less