Proposed standard for message encapsulation
RFC 934

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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                                                [Page 1]



RFC 934                                                     January 1985
Message Encapsulation

   forwarding can be thought of as encapsulating one or more messages
   inside another.  Although this is useful for transfer of past
   correspondence to new recipients, without a decapsulation process
   (which this memo terms "bursting"), the forwarded messages are of
   little use to the recipients because they can not be distributed,
   forwarded, replied-to, or otherwise processed as separate individual
   messages.

      NOTE: RFC-822 mistakenly refers to distribution as forwarding
      (section 4.2).  This memo suggests below, that these two
      activities can and should be the same.

   In the case of an interest group digest, a bursting capability is
   especially useful.  Not only does the ability to burst a digest
   permit a recipient of the digest to reply to an individual digested
   message, but it also allows the recipient to selectively process the
   other messages encapsulated in the digest.  For example, a single
   digest issue usually contains more than one topic.  A subscriber may
   only be interested in a subset of the topics discussed in a
   particular issue.  With a bursting capability, the subscriber can
   burst the digest, scan the headers, and process those messages which
   are of interest.  The others can be ignored, if the user so desires.

   This memo is motivated by three concerns:

      In order to burst a message it is necessary to know how the
      component messages were encapsulated in the draft.  At present
      there is no unambiguous standard for interest group digests.  This
      memo proposes such a standard for the ARPA-Internet.  Although
      interest group digests may appear to conform to a pseudo-standard,
      there is a serious ambiguity in the implementations which produce
      digests.  By proposing this standard, the authors hope to solve
      this problem by specifically addressing the implementation
      ambiguity.

      Next, there is much confusion as to how "blind-carbon-copies"
      should be handled by UAs.  It appears that each agent in the
      ARPA-Internet which supports a "bcc:" facility does so
      differently. Although this memo does not propose a standard for
      the generation of blind-carbon-copies, it introduces a formalism
      which views the "bcc:" facility as a special case of the
      forwarding activity.

      Finally, both forwarding and distribution can be accomplished with