and a text portion.  If the text portion is present, it is
      separated from the header portion by a blank line.

         2.3.1. The Header Portion

         Minimally, there must be two header items in each message being
         forwarded, a "Date:" field and a "From:" field. This differs
         from RFC-822, which requires at least one destination address
         (in a "To:" or "cc:" field) or a possibly empty "Bcc:" field.
         Any addresses occuring in the header items for a message being
         forwarded must be fully qualified.

         2.3.2. The Text Portion

         This memo makes no restrictions on the format of the text
         portion of each encapsulated message.  (Actually, this memo
         does restrict the format of the text portion of each
         encapsulated message, but these restrictions are discussed
         later.)

   Before summarizing the generation/parsing rules for message
   encapsulation, two issues are addressed.





 


RFC 934                                                     January 1985
Message Encapsulation


Compatibility with Existing User Agents

   The above encapsulation protocol is presently used by many user
   agents in the ARPA-Internet, and was specifically designed to
   minimize the amount of changes to existing implementations of
   forwarding agents in the ARPA-Internet.

   However, the protocol is not exactly like the pseudo-standard used by
   those forwarding agents that compose digests.  In particular, the
   post-EB of all messages encapsulated in a digest is preceeded and
   followed by by a blank line.  In addition, the first message
   encapsulated in a digest has a pre-EB that is followed by a blank
   line, but usually isn't preceeded by a blank line (wonderful).

   This memo recommends that implementors of forwarding agents wishing
   to remain compatible with existing bursting agents consider
   surrounding each EB with a blank line.  It should be noted that blank
   lines following a pre-EB for an encapsulated message must be ignored
   by bursting agents.  Further, this memo suggests that blank lines
   preceeding a post-EB also be ignored by bursting agents.

      NOTE: This recommendation is made in the interest of
      backwards-compatibility.  A forwarding agent wishing to strictly
      adhere to this memo, should not generate blank lines surrounding
      EBs.

Character-Stuffing the Encapsulation Boundary

   It should be noted that the protocol is general enough to support
   both general forwarding of messages and the specific case of digests.
   Unfortunately, there is one issue of message encapsulation which
   apparently is not addressed by any forwarding agent (to the authors'
   knowledge) in the ARPA-Internet: what action does the forwarding
   agent take when the encapsulation boundary occurs within a the text
   portion of a message being forwarded?  Without exception, this
   circumstance is ignored by existing forwarding agents.

   To address this issue, this memo proposes the following
   character-stuffing scheme: the encapsulation boundary is defined as a
   line which starts with a dash.  A special case is made for those
   boundaries which start with a dash and are followed by a space
   (decimal code 32, " ").

      During forwarding, if the forwarding agent detects a line in the
      text portion of a message being forwarded which starts with the
      encapsulation boundary, the forwarding agent outputs a dash
      followed by a space prior to outputting the line.



 


RFC 934                                                     January 1985
Message Encapsulation


      During bursting, if the bursting agent detects an encapsulation
      boundary which starts with a dash followed by a space, then the
      bursting agent does not treat the line as an encapsulation
      boundary, and outputs the remainder of the line instead.

   This simple character-stuffing scheme permits recursive forwardings.

Generation/Parsing Rules for Message Encapsulation