RFC 934 (rfc934) - Page 2 of 10


Proposed standard for message encapsulation



Alternative Format: Original Text Document





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
      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


Rose & Stefferud