rfc1056.txt

RFC 的详细文档！

Lambert                                                         [Page 5]

RFC 1056                         PCMAIL                        June 1988


   Messages are stored in mailboxes.  Users can have any number of
   mailboxes, which serve both to store and to categorize messages.  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 mailbox's next available
   message unique identifier (UID).  The above 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.

   Some mailboxes are special, in that other users may read the messages
   stored in them.  These mailboxes are called "bulletin board
   mailboxes" or "bboard mailboxes".  The repository uses bboard
   mailboxes to store bboard mail.  Bboard mailboxes differ from
   ordinary mailboxes in the following ways:

      - Their names are unique across the entire repository;
        for instance, only one bboard mailbox named "sf-lovers"
        may exist in the entire repository community.  This
        does not preclude other users from having an ordinary
        mailbox named "sf-lovers".

      - Subscribers to the bboard are granted read-only access
        to the messages in the bboard mailbox.  The bboard
        mailbox's owner (typically the system manager) has
        read/update/delete access to the mailbox.

   A bboard subscriber keeps track of the messages he has looked at via
   a subscription object.  The subscription object contains the name of
   the bboard, its owner (the user who owns the bboard mailbox where all
   the messages are stored), and the UID of the first message not yet
   seen by the subscriber.

   Users gain read-only access to a bboard by creating a subscription to
   it; they lose that access when they delete that subscription.  A list
   of all bboard mailboxes available for subscription can be transmitted
   to the user on demand.

   Associated with each mailbox are any 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 its 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.  A descriptor holds the



Lambert                                                         [Page 6]

RFC 1056                         PCMAIL                        June 1988


   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 sixteen flags.  These flags are
   given identifying numbers 0 through 15.  Eight of these flags have
   well-known definitions and are reserved for the repository's use.
   The eight repository-defined flags mark:

      - (#0) whether the message has been deleted

      - (#1) whether it has been seen

      - (#2) whether it has been forwarded to the user

      - (#3) whether it has been forwarded by the user

      - (#4) whether it has been filed (written to a text file
        outside the repository)

      - (#5) whether it has been printed (locally or remotely)

      - (#6) whether it has been replied to

      - (#7) whether it has been copied to another mailbox



   The remaining eight flags are availble for user use.  Descriptors
   serve as an efficient means for clients to get message information
   without having to waste time retrieving the entire 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).  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.





Lambert                                                         [Page 7]

RFC 1056                         PCMAIL                        June 1988


4. Communication between repository and client: DMSP

   The Distributed Mail System Protocol (DMSP) defines and manipulates
   the objects mentioned in the previous section.  It has been designed
   to work with Pcmail's singlerepository/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 has been completely re-specified in this version of Pcmail.
   Formerly, DMSP was implemented on top of the USP remote-procedure-
   call protocol.  Since this protocol is not fully unofficially
   specified (let alone officially specified) anywhere, implementation
   of USP is difficult for sites wishing to implement Pcmail on
   different systems.  We therefore have decided to completely redesign
   DMSP.  It is now a very simple request/response protocol similar to
   SMTP or NNTP, running directly on a reliable bidirectional byte-
   stream such as TCP.  The TCP contact port for DMSP has been
   designated 158.  Requests and responses consist of ASCII characters;
   on octet-based transmission streams, each character is transmitted
   rightjustified in an octet with the high-order bit cleared to zero.

4.1. DMSP commands

   DMSP operations consist of an operation name, followed by zero or
   more tab or space characters, followed by zero or more arguments,
   each of which is separated from the operation name and other
   arguments by one or more space or tab characters.  All operation
   requests, as well as all responses, must be terminated with a
   carriage-return plus line-feed (CR-LF) pair.  All operation names and
   arguments must be taken from the set of alphanumeric characters plus
   the characters dash ("-"), underscore ("_"), and period (".").

   DMSP operation names are case-insensitive; they may be transmitted in
   any combination of upper and lower case.  DMSP arguments are case-
   insensitive but case-preserving; in other words a mailbox named
   "MarkL" may be referred to by an operation argument "markl", but will
   always be stored, and transmitted in a repository response, as
   "MarkL"; furthermore, any attempt to create a new mailbox "MaRkL"
   will not be permitted.

   Each operation argument may contain no more than 64 characters.  No
   single request or response line may contain more than 512 characters,
   including all white space and the terminating CR-LF.

4.2. DMSP responses

   A DMSP operation always results in a response, which may be followed



Lambert                                                         [Page 8]

RFC 1056                         PCMAIL                        June 1988


   in turn by a list, consisting of zero or more lines of CR-LF-
   terminated text terminated by a single period (".") plus a CR-LF.  A
   response is always prefaced by a three-digit reply code; possible
   text following the response code can be in any format.  The response
   code is sufficient to determine whether the operation succeeded or
   failed, or whether more text is forthcoming following the response
   line.  Any text following the response code is for information only,
   and need not follow any particular format.

   The first digit indicates whether the operation succeeded or failed,
   and if it succeeded whether or not more text should be presented to
   the repository.  Definitions of the first digit are similar to those
   of NNTP:

   1XX             Informative message


   2XX             Operation completed successfully


   3XX             Operation completed successfully, present
                   remainder of text and terminate with a single
                   period plus CR-LF pair.


   4XX             Operation was performed and failed for some
                   reason.


   5XX             Operation could not be performed because of a
                   protocol syntax error of some sort.


   The second digit indicates the type of object referred to by the
   response.


   X0X             Miscellaneous


   X1X             User operation


   X2X             Client operation


   X3X             Mailbox operation




Lambert                                                         [Page 9]

RFC 1056                         PCMAIL                        June 1988


   X4X             Subscription operation


   X5X             Message operation


   X6X             Address operation


   In an error response, the final digit can describe the type of error
   that occurred.  Otherwise, it simply gives a response a unique
   number.  Numbers 0 through 3 are significant in 4XX-class (error)
   responses only.  Numbers 0-9 in all other responses serve only to
   differentiate responses dealing with the same type of object under
   different circumstances.

   4X0             Operation failed because object exists


   4X1             Operation failed because object does not exist


   4X2             Operation failed because of an internal error


   4X3             Operation failed because of an argument syntax
                   error


   Each operation generates one of a set of responses, detailed in the
   protocol specification appendix.

   List termination is determined solely by a well-known character
   sequence (CR-LF, period, CR-LF).  Since application data could well
   accidentally contain this termination sequence, the transmitting
   protocol module must modify application data so it contains no
   termination sequences.  The receiving module must similarly undo the
   modification before presenting the data to the application at the
   receiving end.

   The transmitting module modifies application data as follows:  If a
   line of application data begins with a period, that period is
   duplicated.  Since the termination sequence is a single period,
   accidental termination has now been prevented.

   The receiving protocol checks incoming all incoming data lines for a