rfc1056.txt

RFC 的详细文档！

   line, terminated by a period plus CR-LF.  "Createsubscription" adds a
   subscription to the user's list of subscriptions; it takes as an
   argument the name of the bboard to subscribe to.  "Delete-
   subscription" removes a subscription from the list, and takes as an



Lambert                                                        [Page 15]

RFC 1056                         PCMAIL                        June 1988


   argument the name of the subscription to remove.  Note that this does
   not delete the associated bboard mailbox (obviously only the bboard's
   owner can do that).  It merely removes the user from the list of the
   bboard's subscribers.  Finally DMSP allows the user to tell the
   repository which messages in a bboard he has seen.  Every
   subscription object contains the UID of the first message the user
   has not yet seen; the "reset-subscription" operation updates that
   number, insuring that the user sees a given bboard message only once.
   Reset-subscription takes as arguments the name of the subscription
   and the new UID value.

4.10. Message operations

   The most commonly-manipulated Pcmail objects are messages; DMSP
   therefore provides special message operations to allow efficient
   synchronization, as well as a set of operations to perform standard
   message-manipulation functions.

   A user may request a series of descriptors with the "fetch-
   descriptors" 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 list with the following format:

   If a descriptor has been expunged, the repository transmits two
   consecutive lines of information: the word "expunged" on one line,
   followed by the message UID on the next line.  "Expunged"
   notifications are only transmitted in response to a "fetch-changed-
   descriptors" command; they are an indication to the client that
   someone else has expunged the mailbox and that the client should
   remove the local copy of the expunged message.

   If a descriptor has not been expunged, it is presented as six
   consecutive lines of information: the word "descriptor" on the first
   line, followed by a second line containing the message UID, flag
   states (see examples following), message length in bytes, and message
   length in lines, followed by four lines containing in order the
   message "from:" field, "to:" field, "date:" field, and "subject:"
   field.  The entire list of descriptors is terminated by a period plus
   CR-LF; individual descriptors are not specially terminated since the
   first line ("expunged" or "descriptor") of a list entry determines



Lambert                                                        [Page 16]

RFC 1056                         PCMAIL                        June 1988


   the exact length of the entry (two lines or six lines).

   The "fetch-changed-descriptors" operation is intended for use during
   state synchronization.  Whenever a descriptor changes state (one of
   its flags is cleared, for example), the repository notes those
   clients which have not yet recorded the change locally.  Fetch-
   changed-descriptors has the repository send to the client a maximum
   of the first N descriptors which have changed since the client's last
   synchronization, where N is a number sent by the client.  The list
   sent begins with the descriptor with lowest UID.  Note that the list
   of descriptors is only guaranteed to be monotonically increasing for
   a given call to "fetch-changed-descriptors"; messages with lower UIDs
   may be changed by other clients in between calls to "fetch-
   changeddescriptors".  "Fetch-changed-descriptors" takes two
   arguments:  the name of the mailbox to search, and the maximum number
   of descriptors for the repository to return.

   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-descriptors" command causes the repository to
   mark as "recorded 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 ignored.  Arguments are: mailbox
   name, low UID in range, and high UID in range.

   Whole messages are transmitted from repository to user with the
   "fetch-message" operation.  The separation of "fetchdescriptors" and
   "fetch-message" operations allows clients with small amounts of disk
   storage to obtain a small message summary (via "fetch-descriptors" or
   "fetch-changed-descriptors") without having to pull over the entire
   message.  Arguments are mailbox name, followed by message UID.

   Frequently, a message may be too large for some clients to store
   locally.  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.  Arguments are:
   mailbox name, followed by message UID, followed by printer
   identification.

   Copying of one message into another mailbox is accomplished via the
   "copy-message" operation.  A descriptor list of length one,
   containing 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



Lambert                                                        [Page 17]

RFC 1056                         PCMAIL                        June 1988


   containing the UID.  Arguments to copy-message are:  source mailbox
   name, target mailbox name, and source message UID.

   Each message has associated with it sixteen flags, as described
   earlier.  These flags can be set and cleared using the "set-message-
   flag" operation.  The first eight flags have special meaning to the
   repository as described above; the remaining eight are for user use.
   Set-message-flag takes four arguments: mailbox name, message UID,
   flag number (0 through 15), and desired flag state (0 or 1).

5. Client Architecture

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

5.1. Multiple clients

   The fact that Pcmail users may own more than one workstation forms
   the rationale 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
   restrictions 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
   likelihood 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
   local and global mail states.  The repository is continually in a
   position to receive global mail state updates, either in the form of



Lambert                                                        [Page 18]

RFC 1056                         PCMAIL                        June 1988


   incoming 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.

   Pcmail's architecture allows fast synchronization between client
   local 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
   include 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 three ways:  first,
   one of its sixteen flag values can be changed (this encompasses the
   user's reading an unseen message, deleting a message, printing a
   message, etc).  Second, a descriptor can be created, either by the
   delivery of a new message or by the copying of a message from one
   mailbox to another.  Finally, a descriptor can be destroyed, via an
   "expunge-mailbox" operation.

   In the above cases, synchronization is required between the
   repository and every client that has not previously noted the change.
   To keep track of which clients have noticed a global mail state
   change and changed their local states accordingly, each mailbox has
   associated with it a list of active clients.  Each client has a
   (potentially empty) "update list" of messages which have changed
   since that client last synchronized.

   When a client connects to the repository, it executes a DMSP "fetch-
   changed-descriptors" operation.  This causes the repository to return
   a list of all descriptors on that client's update list.  When the
   client receives the changed descriptors, it may do one of two things:
   if the descriptor is marked "expunged", it can remove the
   corresponding message from the local mailbox.  If the descriptor is
   not expunged, the client can store the descriptor, thus updating the
   local mail state.  After a changed descriptor has been recorded, the
   client uses the DMSP "reset-descriptors" operation to remove
   descriptors from its update list.  Those descriptors will now not be
   sent to the client unless (1) it is explicitly requested via a
   "fetch-descriptors" operation, or (2) it changes again.



Lambert                                                        [Page 19]

RFC 1056                         PCMAIL                        June 1988


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

5.3. Batch operation versus interactive operation

   Because of the portable nature of some workstations, they may not
   always be connected to a network (and able to communicate with 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 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
   repository changes its global mail state accordingly.  When all
   changes have been processed, the client begins synchronization; this
   incorporates 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; although one
   synchronization 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
   picture of their mail state without having all their messages
   present.