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
      the same forwarding procedure, if a distributed message can be
      extracted as a separate individually processable message.  With a
      proper bursting agent, it will be difficult to distinguish between



 


RFC 934                                                     January 1985
Message Encapsulation


      a message which has been distributed and a message which has been
      extracted from a forwarded message. This memo argues that there is
      no valuable distinction to be made, between forwarding and
      distribution, and that in the interests of simplicity,
      distribution facilities should not be generally available to the
      ordinary users of a message system.  However, this memo also
      argues that such facilities should be available to certain trusted
      entities within the MTS.

         NOTE: this memo does not propose that the distribution facility
         be abolished.  Rather it argues the case forcefully in the hope
         that other interested parties in the ARPA-Internet will join
         this discussion.

Message Encapsulation

   This memo proposes the following encapsulation protocol: two agents
   act on behalf of the user, a forwarding agent, which composes the
   message draft prior to posting, and a bursting agent which decomposes
   the message after delivery.

   Definitions: a draft forwarding message consists of a header portion
   and a text portion.  If the text portion is present, it is separated
   from the header portion by a blank line.  Inside the text portion a
   certain character string sequence, known as an "encapsulation
   boundary", has special meaning.  Currently (in existing
   digestification agents), an encapsulation boundary (EB) is defined as
   a line in the message which starts with a dash (decimal code 45,
   "-").  Initially, no restriction is placed on the length of the
   encapsulation boundary, or on the characters that follow the dash.

   1. The Header Portion

   This memo makes no restriction on the header portion of the draft,
   although it should conform to the RFC-822 standard.

   2. The Text Portion

   The text of the draft forwarding message consists of three parts: an
   initial text section, the encapsulated messages, and the final text
   section.

      2.1. The Initial Text Section

      All text (if any) up to the first EB comprises the initial text
      section of the draft.  This memo makes no restrictions on the




 


RFC 934                                                     January 1985
Message Encapsulation


      format of the initial text section of the draft.  In the case of a
      digest, this initial text is usually the "table of contents" of
      the digest.

      2.2. The Final Text Section

      All text (if any) after the last EB composes the final text
      section of the draft.  This memo makes no restrictions on the
      format of the final text section of the draft.  In the case of a
      digest, this final text usually contains the sign-off banner for
      the digest (e.g., "End of FOO Digest").

      2.3. Encapsulated Messages

      Each encapsulated message is bounded by two EBs: a pre-EB, which
      occurs before the message; and, a post-EB, which occurs after the
      message.  For two adjacent encapsulated messages, the post-EB of
      the first message is also the pre-EB of the second message.
      Consistent with this, two adjacent EBs with nothing between them
      should be treated as enclosing a null message, and thus two or
      more adjacent EBs are equivalent to one EB.

      Each encapsulated message consists of two parts: a headers portion