rfc984.txt

RFC 相关的技术文档

Network Working Group                                     David D. Clark
Request for Comments: 984                                Mark L. Lambert
                                M. I. T. Laboratory for Computer Science
                                                                May 1986

        PCMAIL: A Distributed Mail System for Personal Computers


1. Status of this Document

   This document is a preliminary discussion of the design of a
   personal-computer-based distributed mail system.  It is published for
   discussion and comment, and does not constitute a standard.  As the
   proposal may change, implementation of this document is not advised.
   Distribution of this memo is unlimited.

2. Introduction

   Pcmail is a distributed mail system that provides mail service to an
   arbitrary number of users, each of which owns one or more personal
   computers (PCs).  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, which are
   typically PCs.  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". Since clients are PCs,
   they 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 atomic (that is, they are guaranteed


Clark & Lambert                                                 [Page 1]



RFC 984                                                         May 1986
PCMAIL


   either to succeed completely, or fail completely).  A client can be
   abruptly disconnected from the repository without leaving
   inconsistent or damaged mail states.

   Pcmail is a mail system for PCs.  Its design has therefore been
   heavily influenced by several characteristics unique to PCs. First,
   PCs are relatively inexpensive.  This means that people may own more
   than one PC, perhaps putting one in an office and one at home.
   Second, PCs are portable.  Most PCs can be packed up and moved in the
   back seat of an automobile, and a few are truly portable--about the
   size of a briefcase--and battery-powered.  Finally, PCs are
   resource-poor.  A typical 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).

   Because PCs are relatively inexpensive and people may own more than
   one, Pcmail has been designed to allow users multiple access points
   to their mail state.  Each Pcmail user can have several client PCs,
   each of which can access the user's mail by communicating with the
   repository over a network.  The client PCs all maintain local copies
   of the user's global mail state, and synchronize the local and global
   states using DMSP.

   It is possible, even likely, that many PCs 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 PC 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 as
   "actions".  When next connected to the repository, the actions are
   transmitted, 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 PC as a client.  Mail messages are split into two
   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 always hold a complete set of descriptors, thus




Clark & Lambert                                                 [Page 2]



RFC 984                                                         May 1986
PCMAIL


   providing the user with at least a summary of his mail state.
   Message bodies can be pulled over from the repository as client
   storage becomes available.

   The remainder of this document is broken up into the following
   sections: first, there is a detailed description of the repository
   architecture.  This is followed by a description of DMSP, its
   operations, and motivation for its design.  A third section describes
   client architecture.  Another section describes a typical DMSP
   session between the repository and a client.  The final section
   discusses the current Pcmail implementation.

3. Repository Architecture

   A machine running repository code is typically a medium-to-large size
   computer with a large amount of disk storage.  It must also be a
   permanent network site, since client PCs communicate with the
   repository over a network, and rely on the repository's being
   available 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.  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
      referred to by 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, and a list of "mailbox objects".

      A client object consists of a unique name and a status.  A user


Clark & Lambert                                                 [Page 3]



RFC 984                                                         May 1986
PCMAIL


      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 global state change a list of client objects corresponding
      to those clients which have not recorded the global change
      locally.

      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 Pcmail implementation).  When an inactive client
      does connect to the repository, the repository notifies the client
      that it has been "reset".  The repository resets a client by
      marking all messages in the user's mail state as having changed
      since the client last logged in.  When the client next
      synchronizes with the repository, it will receive a complete copy
      of the repository's global mail state.  A forced 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.

      Messages are stored in mailboxes.  Users can have an arbitrary
      number of mailboxes, which serve both to store and to categorize
      messages.  Since there can be any number of mailboxes, messages
      can be categorized to an arbitrarily fine degree.  A mailbox
      object both names a mailbox and describes its contents. Mailboxes
      are identified by a unique name; their contents are described by
      three numeric values.  The first is the total number of messages
      in the mailbox, the second is the total number of unseen messages
      (messages that have never been seen by the user via any client) in
      the mailbox, and the third is the next available message unique
      identifier (UID).  This information is stored in the mailbox
      object to allow clients to get a summary of a mailbox's contents
      without having to read all the messages within the mailbox.

      Associated with each mailbox are an arbitrary number of message
      objects.  Each message is broken into two parts--a "descriptor",
      which contains a summary of useful information about the message,
      and a "body", which is the message text itself, including NIC
      RFC-822 message header.  Each message is assigned a monotonically
      increasing UID based on the owning mailbox's next available UID.
      Each mailbox has its own set of UIDs which, together with the
      mailbox name and user name, uniquely identify the message within
      the repository.


Clark & Lambert                                                 [Page 4]



RFC 984                                                         May 1986
PCMAIL


      A descriptor holds the following information: the message UID, the
      message size in bytes and lines, four "useful" message header
      fields (the "date:", "to:", "from:", and "subject:" fields), and
      two groups of eight flags each.  The first group of flags is
      system defined.  These flags mark whether the message has never
      been seen, whether it has been deleted, whether it is a forwarded
      message, and whether the message has been expunged. The remaining
      four flags are reserved for future use.  The second group of flags
      is user defined.  The repository never examines these flags
      internally; instead they can be used by application programs
      running on the clients.  Descriptors serve as an efficient means
      for clients to get message information without having to waste
      time retrieving the message from the repository.

   3.2. Repository-to-RFC-822 name translation

      "Address objects" provide the repository with a means for
      translating the RFC-822-style mail addresses in Internet messages
      into repository names.  The repository provides its own namespace
      for message identification.  Any message is uniquely identified by
      the triple (user-name, mailbox-name, message-UID).  Any mailbox is
      uniquely identified by the pair (user-name, mailbox-name).  Thus
      to send a message between two repository users, a user would
      address the message to (user-name, mailbox-name).  The repository
      would deliver the message to the named user and mailbox, and
      assign it a UID based on the requested mailbox's next available
      UID.

      In order to translate between RFC-822-style mail addresses and
      repository names, the repository maintains a list of address
      objects.  Each address object is an association between an
      RFC-822-style address and a (user-name, mailbox-name) pair.  When
      mail arrives from the Internet, the repository can use the address
      object list to translate the recipients into (user-name,
      mailbox-name) pairs and route the message correctly.

4. Communication Between Repository and Client: DMSP

   The Distributed Mail System Protocol (DMSP) is a block-stream
   protocol that defines and manipulates the objects mentioned in the
   previous section.  It has been designed to work with Pcmail's
   single-repository/multiple-client model of the world.  In addition to
   providing typical mail manipulation functions, DMSP provides
   functions that allow easy synchronization of global and local mail
   states.

   DMSP is implemented on top of the Unified Stream Protocol (USP),


Clark & Lambert                                                 [Page 5]



RFC 984                                                         May 1986
PCMAIL


   specified in MIT-LCS Technical Memo 255.  USP provides a reliable
   virtual circuit block-stream connection between two machines.  USP
   defines a basic set of data types ("strings", "integers", "booleans",
   etc.).  Instances of these data types are grouped in an
   application-defined order to form USP blocks.  Each USP block is
   defined by a numeric "block type"; a USP application can thus
   interpret a block's contents based on knowledge of the block's type.
   DMSP consists of a set of operations, each of which is comprised of
   one or more different USP blocks that are sent between repository and
   client.

   A DMSP session proceeds as follows: a client begins the session with
   the repository by opening a USP connection to the repository's
   machine.  The client then authenticates both itself and its user to
   the repository with a "login" operation.  If the authentication is
   successful, the user performs an arbitrary number of DMSP operations
   before ending the session with a "logout" operation (at which time
   the connection is closed by the repository).

   Because DMSP can manipulate a pair of mail states (local and global)
   at once, it is extremely important that all DMSP operations are
   atomic.  Failure of any DMSP operation must leave both states in a
   consistent, known state.  For this reason, a DMSP operation is
   defined to have failed unless an explicit acknowledgement is received
   by the operation initiator.  This acknowledgement can take one of two
   basic forms, based on two broad categories that all DMSP operations
   fall into.  First, an operation can be a request to perform some mail
   state modification, in which case the repository will acknowledge the
   request with either an "ok" or a "failure" (in which case the reason
   for the failure is also returned).  Second, an operation can be a
   request for information, in which case the request is acknowledged by
   the repository's providing the information to the client.  Operations
   such as "delete a message" fall into the first category; operations
   like "send a list of mailboxes" fall into the second category.

   Following are a list of DMSP operations by object type, their block
   types and arguments, and their expected acknowledgement block types.
   Each DMSP block has a different number; the first digit of each block
   type defines the object being manipulated: Operations numbered 5xx
   are general, operations numbered 6xx are user operations, operations
   numbered 7xx are client operations, operations numbered 8xx are
   mailbox and address operations, and operations numbered 11xx are