rfc984.txt

RFC 相关的技术文档

      The "add-mailbox" has the repository create a new mailbox and
      attach it to the user's list of mailboxes.  An address object
      binding the (user-name, mailbox-name) pair to an RFC-822-style
      address is automatically created and placed in the repository's
      list of address objects.  This allows mail coming from the
      Internet to be correctly routed to the new mailbox.

         => 802 (add-mailbox) [mailbox:str]

         <= 500 (ok) [] |
            501 (failure) [why:str]

      "Remove-mailbox" removes a mailbox from the user's list of
      mailboxes.  All messages within the mailbox are also deleted and


Clark & Lambert                                                [Page 12]



RFC 984                                                         May 1986
PCMAIL


      permanently removed from the system.  Any address objects binding
      the mailbox name to RFC-822-style mailbox addresses are also
      removed from the system.

         => 803 (remove-mailbox) [mailbox:str]

         <= 500 (ok) [] |
            501 (failure) [why:str]

      DMSP also has an "expunge-mailbox" operation.  Any message can be
      deleted and "undeleted" at will.  Deletions are made permanent by
      performing an expunge-mailbox operation.  The expunge operation
      causes the repository to look through a named mailbox, removing
      from the system any messages marked "deleted".

         => 808 expunge-mailbox[mailbox:str]

         <= 500 (ok) [] |
            501 (failure) [why:str]

      Finally, "reset-mailbox" causes the repository to mark all the
      messages in a named mailbox as having changed since the current
      client last logged in.  When the client next synchronizes with the
      repository, it will receive a complete copy of the named mailbox's
      mail state.  This operation is merely a more specific version of
      the reset-client operation (which allows the client to pull over a
      complete copy of the user's global mail state).  Its primary use
      is for mailboxes whose contents have accidentally been destroyed
      locally.

         => 809 (reset-mailbox) [mailbox:str]

         <= 500 (ok) [] |
            501 (failure) [why:str]

   4.5. Address operations

      DMSP provides three operations that allow users to manipulate
      address objects.  First, the "list-address" operation returns a
      list of address objects associated with a particular (user-name,
      mailbox-name) pair.

         => 804 (list-addresses) [mailbox:str]

         <= 501 (failure) [why:str] |
            805 (address-list) [address-list:SEQ[str]]



Clark & Lambert                                                [Page 13]



RFC 984                                                         May 1986
PCMAIL


      The "add-address" operation adds a new address object that
      associates a (user-name, mailbox-name) pair with a given
      RFC-822-style mailbox address.

         => 806 (add-address) [mailbox:str,
                               RFC-822-mail-address:str]

         <= 500 (ok) [] |
            501 (failure) [why:str]

      Finally, the "remove-address" operation destroys the address
      object binding the given RFC-822-style mail address and the given
      (user-name, mailbox-name) pair.

         => 807 (remove-address) [mailbox:str,
                                  RFC-822-mail-address:str]

         <= 500 (ok) [] |
            501 (failure) [why:str]

   4.6. 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.  In the following
      paragraphs, the terms "message" and "descriptor" will be used
      interchangeably.

      A client can request a particular message's flag values with the
      "get-descriptor-flags" operation.  The repository sends over an
      array of boolean values, eight of which are system defined, and
      eight of which are user defined and ignored by the repository.

         => 1100 (get-descriptor-flags) [mailbox:str,
                                         uid:Lcard]

         <= 1101 (descriptor-flags) [flags:SEQ[bool]] |
            501 (failure) [why:str]

      A user may request a series of descriptors with the
      "get-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.  The repository returns a sequence of
      "choices".  Elements of the sequence can either be descriptors, in


Clark & Lambert                                                [Page 14]



RFC 984                                                         May 1986
PCMAIL


      which case the choice is tagged as a descriptor, or they can be
      notification that the requested message has been expunged
      subsequent to the client's last connection to the repository.

         => 1102 (get-descriptors) [mailbox:str,
                                    low-UID:Lcard,
                                    high-UID:Lcard]

         <= 501 (failure) [why:str] |
            1103 (descriptor-list) [descriptor-list:SEQ[ CH[
                                    expunged[uid:Lcard]
                                    descriptor[REC[UID:Lcard,
                                                   flags:SEQ[bool],
                                                   from-field:str,
                                                   to-field:str,
                                                   date-field:str,
                                                   subject-field:str,
                                                   num-bytes:Lcard,
                                                   num-lines:Lcard]
                                                ]]]]

      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.

         => 1105 (get-changed-descriptors) [mailbox:str,
                                            max-to-send:card]

         <= 501 (failure) why:str] |
            1103 (descriptor-list) [descriptor-list:SEQ[
                  CH[
                    expunged[uid:Lcard]
                    descriptor[REC[UID:Lcard,
                                   flags:SEQ[bool],
                                   from-field:str,
                                   to-field:str,
                                   date-field:str,
                                   subject-field:str,
                                   num-bytes:Lcard,
                                   num-lines:Lcard]
                                ]]]]



Clark & Lambert                                                [Page 15]



RFC 984                                                         May 1986
PCMAIL


      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 number of
      changed descriptors, starting with the changed descriptor with
      lowest UID.

         => 1106 (reset-changed-descriptors) [
                  mailbox:str,
                  number-to-reset:card]

         <= 500 (ok) [] |
            501 (failure) [why:str]

      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.

         => 1107 (get-message-text)[mailbox:str,
                                    uid:Lcard]

         <= 501 (failure) [why:str] |
            1110 (message) [message:SEQ[str]]

      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.

         => 1108 (print-message) [mailbox:str,
                                  uid:Lcard,
                                  printer-name:str]

         <= 500 (ok) [] |
            501 (failure) [why:str]

      The user can set and clear any of the 16 descriptor flags with the
      "set-flag" operation.  The desired flag is set or cleared
      according to the operation arguments.





Clark & Lambert                                                [Page 16]



RFC 984                                                         May 1986
PCMAIL


         => 1109 (set-flag) [mailbox:str,
                             uid:Lcard,
                             flag-number:card,
                             flag-setting:bool]

         <= 500 (ok) [] |
            501 (failure) [why:str]

      Copying of one message into another mailbox is accomplished via
      the "copy-message" operation.

         => 1111 (copy-message) [source-mailbox:str,
                                 target-mailbox:str,
                                 source-uid:Lcard]

         <= 500 (ok) [] |
            501 (failure) [why:str]

5. Client Architecture

   Clients are typically PCs; Pcmail's architecture must therefore take
   into account several characteristics common to PCs.  First, PCs are
   cheap, therefore a user may well have more than one.  Second, they
   are portable, therefore they are not expected to be constantly tied
   into a network.  Finally, they are 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
   three characteristics.

   5.1. Multiple clients

      The fact that Pcmail users may own more than one PC forms the
      rationalization for the multiple client model that Pcmail uses.  A
      Pcmail user may have a PC client at home, a PC at an office, and
      maybe even a third portable PC.  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.










Clark & Lambert                                                [Page 17]



RFC 984                                                         May 1986
PCMAIL


   5.2. Synchronization

      Since PCs are fairly portable, the likelihood of a PC's being
      always 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 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 permits efficient 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