rfc753.txt

RFC 相关的技术文档

      reply:  The reply is CANCELED

      arguments:  LIST ( tid )

        tid of transaction to be cancelled

      argument structure:

        LIST ( LIST ( INDEX, INTEGER ))



































Postel                                                         [Page 29]


                                                              March 1979
Internet Message Protocol
Specification



    command:  CANCELED

      type:  4

      function:  reply to CANCEL

      arguments:  LIST ( tid, trail, answer )

        tid:  tid of transaction to be cancelled

        trail:  the stamp of the CANCEL command

        answer:  yes if the command was canceled, no if not.

      argument structure:

        LIST ( LIST ( INDEX, INTEGER ),
               LIST ( INTEGER, ... ),
               BOOLEAN )































[Page 30]                                                         Postel


March 1979                                                              
                                               Internet Message Protocol
                                                           Specification



  To summarize again, a command consists of a LIST of the following
  objects:

    name        element
    ----        -------
    mailbox     PROPLIST
    stamp       LIST ( INTEGER, ... )
    type        INDEX
    operation   TEXT
    arguments   LIST ( --- )
    error       LIST ( INDEX, TEXT )

3.5.  Document

  The actual document follows the command list.  It contains a header
  which usually contains such information as From, To, Date, CC, etc.;
  and the actual body of the message.  The message delivery system does
  not depend on the document.  The following section should be taken as
  a recommendation for common practice, not as a requirement.

  Document Header

    For the same reason that it is impossible to for see the many forms
    that intranet addresses will take, standardizing of document headers
    would also be a mistake. The approach we suggest is to lay the
    groundwork for a set of basic document header functions and provide
    for enough extensibility to allow nets to add whatever header
    features they desire.  Features added in this fashion, however, may
    not be understood by other networks.  It is suggested that subset
    defined here be implemented by all networks.

    This subset is taken from the current ARPANET standard for message
    headers in the text oriented computer message system [6,8].

    The document header will precede the document body portion of the
    message and will consist of a proplist data element.  The document
    header is meant to be used by individual networks to tailor the
    header to suit their individual needs.  As an example, consider the
    ARPA network.  Typically, the receiver's name is taken to be his
    network address.  It often prints in the document header in just
    that form: Frank@SITEX.  Such a salutation is unacceptable in some
    more formal modes of communication.  Some network might choose to
    place into header proplist the name-value pair ("SALUTATION:", "Mr.
    Frank Hacker").  Upon receipt of the message, the document handling
    program would then be able to scan the header proplist looking for
    such a pair and so be able to correctly address the recipient by
    name instead of by network address.  However, other networks or



Postel                                                         [Page 31]


                                                              March 1979
Internet Message Protocol
Specification



    sites within the network may not understand such specific
    information.  Under such a condition it should be ignored.

    The minimum header is a PROPLIST of the following name-value pairs:

      Name     Value
      ----     -----
      DATE     TEXT
      FROM     TEXT

    A normal header is a PROPLIST containing the following name-value
    pairs:

      Name     Value
      ----     -----
      DATE     TEXT
      SENDER   TEXT
      FROM     TEXT
      TO       TEXT
      CC       TEXT
      SUBJECT  TEXT

  Document Body

    The Body of the message is just a sequence of data elements which
    contains the actual document.  Much of the time this will be a
    single TEXT element, but for some applications other data elements
    may be utilized.

    LIST ( --- )




















[Page 32]                                                         Postel


March 1979                                                              
                                               Internet Message Protocol
                                                           Specification



3.6.  Message Structure

  An internet message is composed of three parts.  The first is the tid
  which identifies the transaction; the second is the Command List; and
  the third part is the Document List, which is itself comprised of a
  Document-Header and a Document-Body.

  When shipped between two MPMs, a message will take the form of a LIST:

    Message is:

      LIST ( tid, Command-List, Document-List )

    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.

      Thus, a message-bag is:

        LIST ( Message1, Message2, ... )

  Message Sharing

    When messages are batched for delivery, it may often be the case
    that the same Document will be sent to more than one recipient.
    Since the Document portion can usually be expected to be the major
    parts of the message, much repeated data would be sent if a copy of
    the Mail for each recipient were to be shipped in the message-bag.

    To avoid this redundancy, messages are assembled in the message-bag
    so that actual data appears first and references to it appear later
    in the message-bag.  Since each message has a unique tid, the
    references will indicate the tid of the actual data.  In this sense,
    all references to copied data may be thought of as pointing earlier
    in the message-bag.  The data to be retrieved can be thought of as
    indexed by tid.  Note that the semantics require such references to
    point to data already seen.

    When a portion is Shared, that portion is determined by its position
    within a message, i.e., if the Command list was to be Shared, then
    its position within a Message would contain the tid of the message
    already seen whose Command list was identical to it.  The same is
    true of the Document Header and the Document Body.  Only a complete
    Command, Header, or Body may be Shared, never a partial one.



Postel                                                         [Page 33]


                                                              March 1979
Internet Message Protocol
Specification



    If an encryption scheme is used, that portion of the message which
    is encrypted can not be shared.  This is due to the fact that
    encrypting keys will be specific between two individuals.

  Internal Message Organization

    The tid

      This is the transaction identifier.  It is assigned by the
      originating MPM.

    The Command List

      The command-list is a LIST which contains two elements, content
      and command.

      Content is one item of element type INDEX.  If content=0, the item
      is not shared and the next element of the LIST is the command.  If
      content=1 the item is shared.  In this case, the second element
      will contain the tid of the command to share from.  The tid must
      be of a prior message in the current message-bag.  Other values of
      content may be defined later for different data structures.

      Thus, command-list is:

        LIST ( content, tid )       if content=1

      Or,

        LIST ( content, command )    if content=0

      content is:

        INDEX     which is 0 if there is no sharing
                    and is 1 if sharing occurs

      tid is:

        the tid of the message to be shared from

      command is:

        LIST ( mailbox, stamp, type, operation, arguments, error-list )

    The document-list

      The document portion of an internet message is optional and when
      present is comprised of a LIST containing two elements:


[Page 34]                                                         Postel


March 1979                                                              
                                               Internet Message Protocol
                                                           Specification



        document-list is:

          LIST ( header-list, body-list )

      While either the header-list or the body-list may be shared, both
      elements must appear in the m.

    The document-header

      The header-list will be a List which will always contain two
      elements.  The first element will be content to indicate whether
      or not the header is to be shared.  The second element will either
      be the tid of the header to be copied (if content=1) or it will be
      the document-header (which is a PROPLIST) containing the actual
      header information (if content=0). The tid must point to a
      document-header already seen in the message-bag.

      The header-list is either:

        LIST ( content, tid )                if content=1

      Or,

        LIST ( content, document-header )     if content=0

      document-header is:

        PROPLIST which contains header information

    The document-body

      The body-list will be a LIST of two elements.  The first element
      will again be content, indicating whether or not the body is to be
      shared.  If it is shared, the second element will be tid
      indicating which body to copy.  This tid must be of a message
      already seen in the message-bag.  If content indicates no sharing,
      then the second item is a document-body.

      body-list is:

        LIST ( content, tid )           if content=1

      Or,

        LIST ( content, document-body )  if content=0





Postel                                                         [Page 35]


                                                              March 1979
Internet Message Protocol
Specification



      document-body is:

        LIST ( items comprising the body ... )

  Message Fields

    message := ( tid, command-list, document-list )

    tid := ( tn, ihn )

    command-list := ( content, command )

    command := ( mailbox, stamp, type, operation,
                 arguments, error-list )

    document-list := ( header-list, body-list )

    header-list := ( content, document-header )

    body-list := ( content, document-body )

3.7.  MPM Organization

  Introduction

    The heart of the internet message system is the MPM which is
    responsible for routing and delivering message between the networks.
    Each network must have at least one MPM.  These MPMs are connected
    together, and internet mail is always transferred along channels
    between them.  The system interfaces with the already existent local
    message system.

    Since the local network message system may be very different from
    the internet system, special programs may be necessary to convert
    incoming internet messages to the local format.  Likewise, messages
    outgoing to other networks may be converted to the internet format.

  The MPM

    Messages in the internet mail system are shipped in "bags," each bag
    containing one or more messages.  Each bag is addressed to a
    specific MPM and contains messages for the hosts on that MPM's
    network.

    Each MPM is expected to implement functions which will allow it to
    deliver local messages it receives and to forward non-local ones to
    other MPMs presumably closer to the message's destination.



[Page 36]                                                         Postel


March 1979                                                              
                                               Internet Message Protocol
                                                           Specification



    Loosely, each MPM can be separated into five components:

      1--Acceptor

        Receives incoming Message-Bags, from other MPMs, from UIPs, or
        from conversion programs.

      2--Message-Bag Processor

        Splits a Bag into these three portions:

          a.    Local Host Messages
          b.    Local Net Messages
          c.    Foreign Net Messages

      3--Local Net Delivery

        Delivers local net and local host messages, may call on
        conversion program.

      4--Foreign Net Router

        Creation of new Message-Bags for forwarding to other MPMs,
        determines route.

      5--Foreign Net Shipper

        Activates foreign shipping channels and ships Message-Bag to
        foreign MPMs. Performs data compression while shipping bags.

    All of these components can be thought of as independent.  Of the
    five, the Acceptor, the Local-Net Delivery, and the Message-Bag
    Processor are fully self-contained and communicate with each other
    only through a queue, the Bag-Input Queue.  The function of the
    Acceptor