rfc993.txt

RFC 相关的技术文档

   replicated, scalable version of the repository designed to support a
   very large community of users with high availability.  This reposito-
   ry also uses DMSP and has successfully communicated with clients that
   use the current repository implementation.  DMSP therefore seems to
   be usable over several flavors of repository design.

   The IBM PC clients are unfortunately very limited in the way of
   resources, making local mail state manipulation difficult at times.
   Synchronization is also relatively time consuming due to the low per-
   formance of the PCs.  The "batch-mode" that the PCs use tends to be
   good for those PCs that spend a large percentage of their time un-
   plugged and away from a network.  It is somewhat inconvenient for
   those PCs that are always connected to a network and could make good
   use of an "interactive-mode" state manipulation.



Clark & Lambert                                                [Page 20]

RFC 993                                                    December 1986


   The UNIX-based clients are far easier to use than their PC counter-
   parts.  Synchronization is much faster, and there is far more func-
   tionality in the user interface (having an interface that runs within
   GNU-EMACS helps a lot in this respect).  Most of those people using
   the Pcmail system use the UNIX-based client code.


                                 APPENDIX


A. DMSP Protocol Specification

   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 mail-
   box operations, operations numbered 9xx are address operations,
   operations numbered 10xx are bboard operations, and operations num-
   bered 11xx are message operations.

   Failure blocks contain two fields, a "code" and a "why".  The "code"
   is an unsigned number placing the error in one of several broad
   categories (listed below).  The "why" is a text string, possibly ex-
   plaining the error in greater detail.

        Error codes:

        - 1: network error while reading or writing data

        - 2: internal repository error.  This can be due to lack
             of memory, a fatal bug, lack of disk space, etc.

        - 3: requested object already exists.  For example, you
             tried to create a mailbox that already exists

        - 4: requested object not found.  For example, you tried
             to delete a message or a mailbox that doesn't exist.

        - 5: protocol error.  Typically DMSP protocol version
             skew.

        - 6: block argument error.  For example, a "set-message-flag"
             operation was attempted on a bboard by someone
             other than the bboard's owner.

        - 7: data read error.  The repository was unable to read
             the mail state information requested.





Clark & Lambert                                                [Page 21]

RFC 993                                                    December 1986


        - 8: data write error.  The repository was unable to
             write out changed mail state information, perhaps
             because the disk was full.

        - 9: operating system error:  Should be reserved for
             things like fork or pipe call errors.

        - 10: unexpected or unknown block type received.  For
              example, you sent a "delete-mailbox" block and received
              a "mailbox-list" block in response.

   Blocks marked "=>" flow from client to repository; blocks marked "<="
   flow from repository to client.  If more than one block can be sent,
   the choices are delimited by "or" ("|") characters.

   For clarity, each block type is put in a human-understandable form.
   The block number is followed by an operation name; this name is never
   transmitted as part of a USP block.  Block arguments are identified
   by name and type, and enclosed in square brackets.  "Record" data
   types are described by a list of "field-name:field-type" pairs con-
   tained in square brackets.  "Choice" data types are described by a
   list of "tag-name:tag-type" pairs contained in square brackets.  USP
   data types are defined as follows (the definitions are brief; refer
   to the USP specification for more detailed descriptions):

A.1. Primitive data types

   string (S): a series of bytes, null-byte padded to even length and
   preceded by a 16-bit length specifier.  Strings are sent in "net-
   ascii" format (newline sequence is carriage return followed by
   linefeed, single carriage returns to be followed by a null byte).

        - cardinal (C): a 16-bit unsigned number.

        - long-cardinal (LC): a 32-bit unsigned number.

        - integer (I): a 16-bit signed number.

        - long-integer (LI): a 32-bit signed number.

        - boolean (B): a 16-bit number with either a 1 or a 0 in the
          16th bit.

A.2. Compound data types

        - sequence (SEQ): A list of data items, all the same type and
          preceded by a 16-bit sequence length specifier.







Clark & Lambert                                                [Page 22]

RFC 993                                                    December 1986


        - array (AR): A fixed-length list of data items, all the same
          type.  A particular array's length is fixed by the application.

        - record (REC): A list of data items of any type.  A
          particular record's format is fixed by the application.

        - choice (CH): One of a list of possible data types.  The data
          type contained in the choice is identified by a 16-bit numeric
          tag.  The application interprets the data item based on the tag
          value.


A.3. DMSP Abstract Data Types

     Following are data types defined and used only by DMSP:

     - client: a record with the following format:
       REC[name:S, status:C] Status is either 1 (active) or 0
       (inactive)

     - mailbox: a record with the following format:
       REC[name:S, next-uid:LC, #msgs:C, #new-msgs:C]

     - bboard: a record with the following format:
       REC[name:S, first-unread-message-UID:LC
       number-of-unseen-messages:C highest-UID:LC]

     - descriptor: a record with the following format:

     - REC[UID:LC, flags:SEQ[B], from, to, date, subject:S,
       #bytes:LC, #lines:LC]

     - desc-choice: a choice with the following format:
       CH[expunged-message-UID:LC, desc:descriptor] Descriptor
       tag number is 1.  Expunged-message tag number is 0.

A.4. General operations

     => 502 (send-version) [version:C]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]


     => 503 (send-message) [message:SEQ[S]]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]








Clark & Lambert                                                [Page 23]

RFC 993                                                    December 1986


A.5. User operations

     => 600 (login) [name:S, password:S, client:S,
                     create-client-object?:B
                     batch-mode?:B]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S] |
        705 (force-client-reset) []


     => 601 (logout) []
     <= 500 (ok) []


     => 602 (set-password) [old:S, new:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]

A.6. Client operations

     => 701 (list-clients) []
     <= 700 (client-list) [client-list:SEQ[client]]


     => 702 (create-client) [client:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]

     => 703 (delete-client) [client:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]


     => 704 (reset-client) [client:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]

A.7. Mailbox operations

     => 801 (list-mailboxes) []
     <= 800 (mailbox-list) [mailbox-list:SEQ[mailbox]]


     => 802 (create-mailbox) [mailbox:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]


     => 803 (delete-mailbox) [mailbox:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]



Clark & Lambert                                                [Page 24]

RFC 993                                                    December 1986


     => 804 (reset-mailbox) [mailbox:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]


     => 805 (expunge-mailbox) [mailbox:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S

A.8. Address operations

     => 901 (list-addresses) [mailbox:S]
     <= 501 (failure) [code:C, why:S] |
        900 (address-list) [address-list:SEQ[S]]


     => 902 (create-address) [mailbox:S, address:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]


     => 903 (delete-address) [mailbox:S, address:S]
     <= 500 (ok) [] |
        501 (failure) [code:C, why:S]

A.9. Bboard operations

     => 1001 (list-bboa