RFC 934 (rfc934) - Page 1 of 10

Proposed standard for message encapsulation

Alternative Format: Original Text Document
Next >
Network Working Group                        Marshall T. Rose (Delaware)
Request for Comments: 934                       Einar A. Stefferud (NMA)
                                                            January 1985

              Proposed Standard for Message Encapsulation


STATUS OF THIS MEMO

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

Introduction, Scope, and Motivation

   The services that a user agent (UA) can offer are varied.  Although
   all outgoing mail may be thought of as going through a single posting
   slot to connect to the message transport system (MTS), it is possible
   to consider a message draft being posted as described by one of the
   following four types of postings:

      Originate - a new message is composed from scratch, which, to the
      knowledge of the UA, is unrelated to any message previously
      handled by the user.

      Reply - a message is composed as a reply to a message previously
      received by the user.  In most circumstances, the UA aids the user
      in composing the reply by constructing the header portion of the
      message draft, using components extracted from the received
      message headers.

      Forward - one more more messages previously received by the user
      are formatted by the UA as a part of the body portion of the
      draft.  In this sense, a "digest" for an interest group may be
      considered as forwarding.  Similarly, an argument may be made that
      "blind-carbon-copies" should also be handled in this fashion.

      Distribute - a message previously received by the user is
      re-posted to the MTS.  The draft being re-posted is identical to
      the original message with the exception that certain "ReSent-XXX"
      headers are appended to the headers portion of the draft, and the
      "Return-Path" header is reset to reference the re-sender's
      address.  (See [RFC-821] for a discussion of the Return-Path
      header.)

   Most user agents support the first two of these activities, many
   support the first three, and a few support all four.

   This memo concerns itself only with the third type, which is message
   forwarding.  (For a brief treatment of the semantics of message
   components with respect to replies, see [RFC-822].) In many ways,


Rose & Stefferud
Next >