rfc1056.txt

RFC 的详细文档！

Network Working Group                                         M. Lambert
Request for Comments: 1056                                           MIT
Obsoletes: RFC-993                                             June 1988

        PCMAIL: A Distributed Mail System for Personal Computers


                           Table of Contents

   1. Status of this Document                                      1
   2. Introduction                                                 2
   3. Repository architecture                                      4
        3.1. Management of user mail state                         5
        3.2. Repository-to-RFC-822 name translation                7
   4. Communication between repository and client: DMSP            8
        4.1. DMSP commands                                         8
        4.2. DMSP responses                                        8
        4.3. DMSP sessions                                        11
        4.4. General operations                                   11
        4.5. User operations                                      12
        4.6. Client operations                                    13
        4.7. Mailbox operations                                   14
        4.8. Address operations                                   15
        4.9. Subscription operations                              15
        4.10. Message operations                                  16
   5. Client Architecture                                         18
        5.1. Multiple clients                                     18
        5.2. Synchronization                                      18
        5.3. Batch operation versus interactive operation         20
        5.4. Message summaries                                    20
   6. Typical interactive-style client-repository interaction     21
   7. A current Pcmail implementation                             25
        7.1. IBM PC client code                                   25
        7.2. UNIX client code                                     26
        7.3. Repository code                                      26
   8. Conclusions                                                 26
   I. DMSP Protocol Specification                                 28
   II. Operations by name                                         37
   III. Responses by number                                       38

1. Status of this Memo

   This RFC is a discussion of the Pcmail workstation based distributed
   mail system.  It is identical to the discussion in RFC-993, save that
   a new, much simpler mail transport protocol is described.  The new
   transport protocol is the result of continued research into ease of
   protocol implementation and use issues.  Distribution of this memo is
   unlimited.



Lambert                                                         [Page 1]

RFC 1056                         PCMAIL                        June 1988


2. Introduction

   Pcmail is a distributed mail system providing mail service to an
   arbitrary number of users, each of whom owns one or more
   workstations.  Pcmail's motivation is to provide very flexible mail
   service to a wide variety of different workstations, ranging in power
   from small, resource-limited machines like IBM PCs to resource-rich
   (where "resources" are primarily processor speed and disk space)
   machines like Suns or Microvaxes.  It attempts to provide limited
   service to resource-limited workstations while still providing full
   service to resource-rich machines.  It is intended to work well with
   machines only infrequently connected to a network as well as machines
   permanently connected to a network.  It is also designed to offer
   diskless workstations full mail service.

   The system is divided into two halves.  The first consists of a
   single entity called the "repository".  The repository is a storage
   center for incoming mail.  Mail for a Pcmail user can arrive
   externally from the Internet or internally from other repository
   users.  The repository also maintains a stable copy of each user's
   mail state (this will hereafter be referred to as the user's "global
   mail state").  The repository is therefore typically a computer with
   a large amount of disk storage.

   The second half of Pcmail consists of one or more "clients".  Each
   Pcmail user may have an arbitrary number of clients, typically
   single-user workstations.  The clients provide a user with a friendly
   means of accessing the user's global mail state over a network.  In
   order to make the interaction between the repository and a user's
   clients more efficient, each client maintains a local copy of its
   user's global mail state, called the "local mail state".  It is
   assumed that clients, possibly being small personal computers, may
   not always have access to a network (and therefore to the global mail
   state in the repository).  This means that the local and global mail
   states may not be identical all the time, making synchronization
   between local and global mail states necessary.

   Clients communicate with the repository via the Distributed Mail
   System Protocol (DMSP); the specification for this protocol appears
   in appendix A. The repository is therefore a DMSP server in addition
   to a mail end-site and storage facility.  DMSP provides a complete
   set of mail manipulation operations ("send a message", "delete a
   message", "print a message", etc.).  DMSP also provides special
   operations to allow easy synchronization between a user's global mail
   state and his clients' local mail states.  Particular attention has
   been paid to the way in which DMSP operations act on a user's mail
   state.  All DMSP operations are failure-atomic (that is, they are
   guaranteed either to succeed completely, or leave the user's mail



Lambert                                                         [Page 2]

RFC 1056                         PCMAIL                        June 1988


   state unchanged ).  A client can be abruptly disconnected from the
   repository without leaving inconsistent or damaged mail states.

   Pcmail's design has been directed by the characteristics of currently
   available workstations.  Some workstations are fairly portable, and
   can be packed up and moved in the back seat of an automobile.  A few
   are truly portable--about the size of a briefcase--and battery-
   powered.  Some workstations have constant access to a high-speed
   local-area network; pcmail should allow for "on-line" mail delivery
   for these machines while at the same time providing "batch" mail
   delivery for other workstations that are not always connected to a
   network.  Portable and semi-portable workstations tend to be
   resource-poor.  A typical IBM PC has a small amount (typically less
   than one megabyte) of main memory and little in the way of mass
   storage (floppy-disk drives that can access perhaps 360 kilobytes of
   data).  Pcmail must be able to provide machines like this with
   adequate mail service without hampering its performance on more
   resource-rich workstations. Finally, all workstations have some
   common characteristics that Pcmail should take advantage of.  For
   instance, workstations are fairly inexpensive compared to the various
   time-shared systems that most people use for mail service.  This
   means that people may own more than one workstation, perhaps putting
   a Microvax in an office and an IBM PC at home.

   Pcmail's design reflects the differing characteristics of the various
   workstations.  Since one person can own several workstations, Pcmail
   allows users multiple access points to their mail state.  Each Pcmail
   user can have several client workstations, each of which can access
   the user's mail by communicating with the repository over a network.
   The clients all maintain local copies of the user's global mail
   state, and synchronize the local and global states using DMSP.

   It is also possible that some workstations will only infrequently be
   connected to a network (and thus be able to communicate with the
   repository).  The Pcmail design therefore allows two modes of
   communication between repository and client.  "Interactive mode" is
   used when the client is always connected to the network.  Any changes
   to the client's local mail state are immediately also made to the
   repository's global mail state, and any incoming mail is immediately
   transmitted from repository to client.  "Batch mode" is used by
   clients that have infrequent access to the repository.  Users
   manipulate the client's local mail state, queueing the changes
   locally.  When the client is next connected to the repository, the
   changes are executed, and the client's local mail state is
   synchronized with the repository's global mail state.

   Finally, the Pcmail design minimizes the effect of using a resource-
   poor workstation as a client.  Mail messages are split into two



Lambert                                                         [Page 3]

RFC 1056                         PCMAIL                        June 1988


   parts: a "descriptor" and a "body".  The descriptor is a capsule
   message summary whose length (typically about 100 bytes) is
   independent of the actual message length.  The body is the actual
   message text, including an RFC-822 standard message header.  While
   the client may not have enough storage to hold a complete set of
   messages, it can usually hold a complete set of descriptors, thus
   providing the user with at least a summary of his mail state.  For
   clients with extremely limited resources, Pcmail allows the storage
   of partial sets of descriptors.  Although this means the user does
   not have a complete local mail state, he can at least look at
   summaries of some messages.  In the cases where the client cannot
   immediately store message bodies, it can always pull them over from
   the repository as storage becomes available.

   The remainder of this document is broken up into sections discussing
   the following:

      - The repository architecture

      - DMSP, its operations, and motivation for its design

      - The client architecture

      - A typical DMSP session between the repository and a
        client

      - The current Pcmail implementation

      - Appendices describing the DMSP protocol in detail

3. Repository architecture

   A typical machine running repository code has a relatively powerful
   processor and a large amount of disk storage.  It must also be a
   permanent network site, for two reasons.  First, clients communicate
   with the repository over a network, and rely on the repository's
   being available at any time.  Second, people sending mail to
   repository users rely on the repository's being available to receive
   mail at any time.

   The repository must perform several tasks.  First, and most
   importantly, the repository must efficiently manage a potentially
   large number of users and their mail states.  Mail must be reliably
   stored in a manner that makes it easy for multiple clients to access
   the global mail state and synchronize their local mail states with
   the global state.  Since a large category of electronic mail is
   represented by bulletin boards (bboards), the repository should
   efficiently manage bboard mail, using a minimum of storage to store



Lambert                                                         [Page 4]

RFC 1056                         PCMAIL                        June 1988


   bboard messages in a manner that still allows any user subscribing to
   the bboard to read the mail.  Second, the repository must be able to
   communicate efficiently with its clients.  The protocol used to
   communicate between repository and client must be reliable and must
   provide operations that (1) allow typical mail manipulation, and (2)
   support Pcmail's distributed nature by allowing efficient
   synchronization between local and global mail states.  Third, the
   repository must be able to process mail from sources outside the
   repository's own user community (a primary outside source is the
   Internet).  Internet mail will arrive with a NIC RFC-822 standard
   message header; the recipient names in the message must be properly
   translated from the RFC-822 namespace into the repository's
   namespace.

3.1. Management of user mail state

   Pcmail divides the world into a community of users.  Each user is
   associated with a user object.  A user object consists of a unique
   name, a password (which the user's clients use to authenticate
   themselves to the repository before manipulating a global mail
   state), a list of "client objects" describing those clients belonging
   to the user, a list of "subscription objects", and a list of "mailbox
   objects".

   A client object consists of a unique name and a status.  A user has
   one client object for every client he owns; a client cannot
   communicate with the repository unless it has a corresponding client
   object in a user's client list.  Client objects therefore serve as a
   means of identifying valid clients to the repository.  Client objects
   also allow the repository to manage local and global mail state
   synchronization; the repository associates with every client an
   "update list" of message state changes which have occurred since the
   client's last synchronization.

   A client's status is either "active" or "inactive".  The repository
   defines inactive clients as those clients which have not connected to
   the repository within a set time period (one week in the current
   repository implementation).  When a previously-inactive client does
   connect to the repository, the repository notifies the client that it
   has been inactive for some time and should "reset" itself.  Resetting
   a client has the effect of placing every message in every mailbox
   onto the client's update list.  This allows the client to get a fresh
   global mail state from the repository when it next synchronizes (see
   synchronization discussion following).  The reset is performed on the
   assumption that enough global state changes occur in a week that the
   client would spend too much time performing an ordinary local state-
   global state synchronization.