rfc759.txt

RFC 的详细文档！

                                    
        +------+   +-----+   +-------+                              
        |Telnet|   | FTP |---|Message|            Application Level 
        +------+   +-----+   +-------+                              
              \     /                                               
    +-----+   +-----+                                               
    |Voice|---| NCP |                             Host Level        
    +-----+   +-----+                                               
                 |                                                  
                 |                                                  
                 |                                Gateway Level     
                 |                                                  
                 |                                                  
         +----------------+                                         
         |    ARPA NET    |                       Network Level     
         +----------------+                                         
                                                                    



                         Old ARPANET Protocols

                               Figure 5.

  Note that in the old ARPANET protocols one can't send messages (or
  communicate in any way) to other networks since it has no gateway
  level or internet protocol [5].

  




















Postel                                                         [Page 11]


                                                             August 1980
Internet Message Protocol





















































[Page 12]                                                         Postel


August 1980                                                             
                                               Internet Message Protocol



                       3.  DETAILED SPECIFICATION

The presentation of the information in this section is difficult since
everything depends on everything, and since this is a linear medium it
has to come in some order.  In this attempt, a brief overview of the
message structure is given, the detail of the message is presented in
terms of data objects, the various data objects are defined, and finally
the representation of the data elements is specified.  Several aspects
of the message structure are based on the NSW Transaction Protocol [22],
and similar (but more general) proposals [23,24].

3.1.  Overview of Message Structure

  A message is normally composed of three parts:  the identification,
  the command, and the document.  Each part is in turn composed of data
  objects.

  The identification part is composed of a transaction number assigned
  by the originating MPM and the MPM identifier.

  The command part is composed of an operation type, an operation code,
  the arguments to the operation, error information, the destination
  mailbox, and a trace.  The trace is a list of the MPMs that have
  handled this message.

  The document part is a data structure.  The message delivery system
  does not depend on the contents of the document part.  A standard for
  the document part is defined in reference [25].

  The following sections define the representation of a message as a
  structured object composed of other objects.  Objects in turn are
  represented using a set of basic data elements.

  The basic data elements are defined in section 3.7.  In summary, these
  are exact forms for representing integers, strings, booleans, et
  cetera.  There are also two elements for building data structures:
  list and property list.  Lists are simple lists of elements, including
  lists.  Property lists are lists of pairs of elements, where the first
  element of each pair names the pair.  That is, a property list is a
  list of <name,value> pairs.  In general, when an object is composed of
  multiple instances of a simpler object it is represented as a list of
  the simpler objects.  When an object is composed of a variety of
  simpler objects it is represented as a property list of the simpler
  objects.  In most uses of the property list representation, the
  presence of <name,value> pairs in addition to those specifically
  required is permitted.




Postel                                                         [Page 13]


                                                             August 1980
Internet Message Protocol
Specification



3.2.  Message Structure

  An internet message is composed of two or three parts.  The first is
  the Identification which identifies the transaction; the second is the
  Command; and the optional third part is the Document.

  When shipped between two MPMs, a message will take the form of a
  property list, with the <name,value> pairs in this order.

    MESSAGE is:

      ( Identification, Command [, Document ] )

    It is convenient to batch several messages together, shipping them
    as a unit from one MPM to another.  Such a group of messages is
    called a message-bag.

    A message-bag will be a list of Messages; each Message is of the
    form described above.

      MESSAGE-BAG is:

        ( Message, Message, ... )

  The Identification

    This is the transaction identifier.  It is assigned by the
    originating MPM.  The identification is composed of the MPM
    identifier, and a transaction number unique in that context for this
    message.

  The Command

    The command is composed of a mailbox, an operation code, the
    arguments to that operation, some error information, and a trace of
    the route of this message.  The command is implemented by a property
    list which contains <name,value> pairs, where the names are used to
    identify the associated argument values.

  The Document

    The document portion of an internet message is optional and when
    present is a data structure as defined in [25].






[Page 14]                                                         Postel


August 1980                                                             
                                               Internet Message Protocol
                                                           Specification



3.3.  Identification

  Each message must have a unique identifier while it exists in the
  message delivery system.  This is provided by the combination of the
  unique identifier of the MPM and a unique transaction number chosen
  for the message by this MPM.

    IDENTIFICATION is:

      ( mpm-identifier, transaction-number )

  The mpm-identifier is based on the host address of the computer in
  which the MPM resides.  If there is more than one MPM in a host the
  mpm-identifier must be extended to distinguish between the co-resident
  MPMs.

3.4.  Command

  This section describes the commands MPMs use to communicate between
  themselves.  The commands come in pairs, with each request having a
  corresponding reply.

    COMMAND is:

      ( mailbox, operation, [arguments,]
                                    [error-class, error-string,] trace )

  The mailbox is the "To" specification of the message.  Mailbox is a
  property list of general information, some of which is the essential
  information for delivery, and some of which could be extra information
  which may be helpful for delivery.  Mailbox is different from address
  in that address is a very specific property list without extra
  information.  The mailbox includes a specification of the user,  when
  a command is addressed to the MPM itself (rather than a user it
  serves) the special user name "*MPM*" is specified.

  The operation is the name of the operation or procedure to be
  performed.

  The arguments to the operation vary from operation to operation.

  The error information is composed of a error class code and a
  character string, and indicates what, if any, error occurred.  The
  error information is normally present only in replies, and not present
  in requests.




Postel                                                         [Page 15]


                                                             August 1980
Internet Message Protocol
Specification



  The trace is a list of the MPMs that have handled the message.  Each
  MPM must add its handling-stamp to the list.















































[Page 16]                                                         Postel


August 1980                                                             
                                               Internet Message Protocol
                                                           Specification



  3.4.1.  Command:  DELIVER

    function:  Sends a document to a mailbox.

    reply:  The reply is ACKNOWLEDGE.

    arguments:

      type-of-service:  one or more of the following:

        "REGULAR"  regular delivery
        "FORWARD"  message forwarding
        "GENDEL"   general delivery
        "PRIORITY" priority delivery

  3.4.2.  Command:  ACKNOWLEDGE

    function:  Reply to DELIVER.

    arguments:

      reference:  the identifier of the originating message.

      address:

        The address is the final mailbox the message was delivered to.
        This would be different from the original mailbox if the message
        was forwarded, and is limited to the essential information
        needed for delivery.

      type-of-service:  one of the following:

        "GENDEL"    message was accepted for general delivery
        "REGULAR"   message was accepted for normal delivery
        "PRIORITY"  message was accepted for priority delivery

      error-class:
      error-string:

        If the document was delivered successfully, the error
        information has class 0 and string "ok".  Otherwise, the error
        information has a non-zero class and the string would be one of
        "no such user", "no such host", "no such network", "address
        ambiguous", or a similar response.

      trail:   the trace from the DELIVER command.



Postel                                                         [Page 17]


                                                             August 1980