rfc993.txt

RFC 相关的技术文档

   name, mailbox-name) pair.






Clark & Lambert                                                [Page 10]

RFC 993                                                    December 1986


4.6. Bboard operations

   DMSP provides seven bulletin board operations.  The first, "list-
   bboards", gives the user a list of the bboards he is currently sub-
   scribing to.  The list contains an entry for each bboard that the
   user subscribes to.  Each entry contains the following information:

      - The bulletin board's name

      - The UID of the first message the subscriber has not yet
        seen

      - The highest message UID in the bulletin board

      - The number of messages the subscriber has not yet seen

   "List-all-bboards" gives the user a list of all bboards he can sub-
   scribe to.

   "Create-bboard" allows a user to create a bboard mailbox.  The name
   given must be unique across the entire repository user community.
   Once the bboard mailbox has been created, other users may subscribe
   to the bboard, using bboard objects to keep track of which messages
   they have read on which bboards.

   "Delete-bboard" allows a bboard's owner to delete a bboard mailbox.
   Subscribers who attempt to read from a bboard mailbox after it has
   been deleted are told that the bboard no longer exists.

   DMSP also provides operations to subscribe to, and unsubscribe from,
   any bboard.  "Subscribe-bboard" adds a bboard object to the users
   bboard object list; "unsubscribe-bboard" removes a bboard object from
   the list.  Note that this does not delete the bboard mailbox (obvi-
   ously only the bboard's owner can do that).  It merely removes the
   user from the list of the bboard's subscribers.

   DMSP allows for the user to tell the repository which messages in a
   bboard he has seen.  Every bboard object contains the UID of the
   first message the user has not yet seen; the "set-first-unread-
   message-UID" operation updates that number, insuring that the user
   sees a given bboard message only once.

4.7. Message operations

   The most commonly-manipulated Pcmail objects are messages; DMSP
   therefore provides special message operations to allow efficient syn-
   chronization, as well as a set of operations to perform standard
   message-manipulation functions.  In the following paragraphs, the
   terms "message" and "descriptor" will be used interchangeably.

   A user may request a series of descriptors with the "get-descriptors"



Clark & Lambert                                                [Page 11]

RFC 993                                                    December 1986


   operation.  The series is identified by a pair of message UIDs,
   representing the lower and upper bounds of the list.  Since UIDs are
   defined to be monotonically increasing numbers, a pair of UIDs is
   sufficient to completely identify the series of descriptors.  If the
   lower bound UID does not exist, the repository starts the series with
   the first message with UID greater than the lower bound.  Similarly,
   if the upper bound does not exist, the repository ends the series
   with the last message with UID less than the upper bound.  If certain
   UIDs within the series no longer exist, the repository (obviously)
   does not send them.  The repository returns the descriptors in a se-
   quence of "choices".  Elements of the sequence can either be descrip-
   tors, in which case the choice is tagged as a descriptor, or they can
   be notification that the requested message has been expunged subse-
   quent to the client's last connection to the repository.  A descrip-
   tor choice is a record containing the message's UID, flags, to, from,
   date, and subject fields, length in bytes, and length in lines.  An
   expunged choice contains only the expunged message's UID.

   The "get-changed-descriptors" operation is intended for use during
   state synchronization.  Whenever a descriptor changes state (is
   deleted, for example), the repository notes those clients which have
   not yet recorded the change locally.  Get-changed-descriptors has the
   repository send to the client a given number of descriptors which
   have changed since the client's last synchronization.  The list sent
   begins with the earliest-changed descriptor.  Note that the list of
   descriptors is only guaranteed to be monotonically increasing for a
   given call to "get-changed-descriptors"; messages with lower UIDs may
   be changed by other clients in between calls to "get-changed-
   descriptors".

   Once the changed descriptors have been looked at, a user will want to
   inform the repository that the current client has recorded the change
   locally.  The "reset-changed-descriptors" causes the repository to
   mark as "seen by current client" a given series of descriptors.  The
   series is identified by a low UID and a high UID.  UIDs within the
   series that no longer exist are not reset.

   Message bodies are transmitted from repository to user with the
   "get-message-text" operation.  The separation of "get-descriptors"
   and "get-message-text" operations allows clients with small amounts
   of disk storage to obtain a small message summary (via "get-
   descriptors" or "get-changed-descriptors") without having to pull
   over the entire message.

   Frequently, a message may be too large for some clients to store lo-
   cally.  Users can still look at the message contents via the "print-
   message" operation.  This operation has the repository send a copy of
   the message to a named printer.  The printer name need only have
   meaning to the particular repository implementation; DMSP transmits
   the name only as a means of identification.




Clark & Lambert                                                [Page 12]

RFC 993                                                    December 1986


   Copying of one message into another mailbox is accomplished via the
   "copy-message" operation.  A descriptor list of length one, contain-
   ing a descriptor for the copied message is returned if the copy
   operation is successful.  This descriptor is required because the
   copied message acquires a UID different from the original message.
   The client cannot be expected to know which UID has been assigned the
   copy, hence the repository's sending a descriptor containing the UID.

5. Client Architecture

   Clients can be any of a number of different workstations; Pcmail's
   architecture must therefore take into account the range of charac-
   teristics of these workstations.  First, most workstations are much
   more affordable than the large computers currently used for mail ser-
   vice.  It is therefore possible that a user may well have more than
   one.  Second, some workstations are portable and they are not expect-
   ed to be constantly tied into a network.  Finally, many of the small-
   er workstations resource-poor, so they are not expected to be able to
   store a significant amount of state information locally.  The follow-
   ing subsections describe the particular parts of Pcmail's client ar-
   chitecture that address these different characteristics.

5.1. Multiple clients

   The fact that Pcmail users may own more than one workstation forms
   the rationalization for the multiple client model that Pcmail uses.
   A Pcmail user may have one client at home, another at an office, and
   maybe even a third portable client.  Each client maintains a separate
   copy of the user's mail state, hence Pcmail's distributed nature.
   The notion of separate clients allows Pcmail users to access mail
   state from several different locations.  Pcmail places no restric-
   tions on a user's ability to communicate with the repository from
   several clients at the same time.  Instead, the decision to allow
   several clients concurrent access to a user's mail state is made by
   the repository implementation.

5.2. Synchronization

   Some workstations tend to be small and fairly portable; the likeli-
   hood of their always being connected to a network is relatively
   small.  This is another reason for each client's maintaining a local
   copy of a user's mail state.  The user can then manipulate the local
   mail state while not connected to the network (and the repository).
   This immediately brings up the problem of synchronization between lo-
   cal and global mail states.  The repository is continually in a posi-
   tion to receive global mail state updates, either in the form of in-
   coming mail, or in the form of changes from other clients.  A client
   that is not always connected to the net cannot immediately receive
   the global changes.  In addition, the client's user can make his own
   changes on the local mail state.




Clark & Lambert                                                [Page 13]

RFC 993                                                    December 1986


   Pcmail's architecture allows fast synchronization between client lo-
   cal mail states and the repository's global mail state.  Each client
   is identified in the repository by a client object attached to the
   user.  This object forms the basis for synchronization between local
   and global mail states.  Some of the less common state changes in-
   clude the adding and deleting of user mailboxes and the adding and
   deleting of address objects.  Synchronization of these changes is
   performed via DMSP list operations, which allow clients to compare
   their local versions of 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 re-
   pository 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 mailbox has associ-
   ated with it a list of active clients.  Each client has a (potential-
   ly empty) "update list" of messages which have changed since that
   client last read them.

   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 on that client's 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 the message from its 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, get-
   ting 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 some workstations, they may not al-
   ways be connected to a network (and able to communicate with the re-
   pository).  Since each client maintains a local mail state, Pcmail
   users can manipulate the local state while not connected to the repo-
   sitory.  This is known as "batch" operation, since all changes are



Clark & Lambert                                                [Page 14]

RFC 993                                                    December 1986


   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 also
   immediately made 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 repo-
   sitory changes its global mail state accordingly.  When all changes
   have been processed, the client begins synchronization, to incor-
   porate 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 elim-
   inated.  The synchronization process also changes; although one syn-
   chronization is required when the client first opens a connection to
   the repository, subsequent synchronizations can be performed either
   at the user's request or automatically every so often by the client.

5.4. Message summaries

   Smaller workstations may have little in the way of disk storage.
   Clients running on these workstations 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 pic-
   ture 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 informa-
   tion 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.

   Most clients should be able to store a complete list of message
   descriptors with little problem.  This allows a user to get a com-
   plete picture of his mail state without having all his messages