rfc934.txt

RFC 相关的技术文档

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

   The rules for forwarding/bursting are described in terms of regular
   expressions.  The first author originally derived simple finite-state
   automata for the rules, but was unable to legibly represent them in
   this memo.  It is suggested that the implementors sketch the automata
   to understand the grammar.

   The conventions used for the grammar are simple.  Each state is
   followed by one or more alternatives, which are separated by the "|"
   character.  Each alternative starts with a character that is received
   as input. (CRLF, although two characters is treated as one character
   herein.)  The last alternative for a state is the character "c",
   which represents any character not specified in the preceeding
   alternatives.  Optionally following the input character is an output
   string enclosed by curly-braces.  Following this is the state that
   the automata enters.  The reader should note that these grammars are
   extremely simple to implement (and, in most cases, can be implemented
   quite efficiently).

   When the forwarding agent encapsulates a message, it should apply the
   following finite-state automaton.  The initial state is S1.

      S1 ::   CRLF {CRLF} S1
            | "-" {"- -"} S2
            | c {c} S2

      S2 ::   CRLF {CRLF} S1
            | c {c} S2

   This simply says that anytime a "-" is found at the beginning of a
   line, a "- " is output prior to outputting the line.










Rose & Stefferud                                                [Page 6]



RFC 934                                                     January 1985
Message Encapsulation


   When the bursting agent decapsulates the text portion of a draft, it
   should apply the following finite-state automaton.  The initial state
   is S1.

      S1 ::   "-" S3
            | CRLF {CRLF} S1
            | c {c} S2

      S2 ::   CRLF {CRLF} S1
            | c {c} S2

      S3 ::   " " S2
            | c S4

      S4 ::   CRLF S5
            | c S4

      S5 ::   CRLF S5
            | c {c} S2

   Although more complicated than the grammar used by the forwarding
   agent to encapsulate a single message, this grammer is still quite
   simple.  Let us make the simplifying assumption that both the initial
   and final text sections of the draft are messages in addition to the
   encapsulated messages.

   To begin, the current message being burst is scanned at state S1. All
   characters are output until the EB is found (state S3).  If "- " is
   found, the automaton enters state S2 and characters from the current
   message are continued to be output.  Finally, a true EB is found
   (state S4).  As the automaton traverses from state S3 to S4, the
   bursting agent should consider the current message ended.  The
   remainder of the EB is discarded (states S4 and S5).  As the
   automaton traverses from state S5 to S2, the bursting agent should
   consider a new message started and output the first character.  In
   state S2, all characters are output until the EB is found.

Blind Carbon Copies

   Many user agents support a blind-carbon-copy facility.  With this
   facility a draft has two types of addressees: visible and blind
   recipients.  The visible recipients are listed as addresses in the
   "To:" and "cc:" fields of the draft, and the blind recipients are
   listed as addresses in the "Bcc:" fields of the draft.  The basis of
   this facility is that copies of the draft which are delivered to the
   recipients list the visible recipients only.



Rose & Stefferud                                                [Page 7]



RFC 934                                                     January 1985
Message Encapsulation


   One method of achieving this is to post a single draft, which lacks
   any "Bcc:" fields, and, during posting, to interact with the MTS in
   such a way that copies are sent to both the visible and blind
   recipients.

   Unfortunately, a key problem with this arrangement is that the blind
   recipients can accidently reply to the draft in such a way that the
   visible recipients are included as addressees in the reply. This is
   socially unacceptable!  To avoid this problem, the message which the
   visible recipients receive must be different than the message which
   the blind recipients receive.

   A second method is to post two drafts.  The first, which goes to the
   visible recipients, is simply the draft without any "Bcc:" fields.
   The second, which goes to the blind recipients, is simply the draft
   with some string prepended to any "To:" and "cc:" field. For example,
   the user agent might prepend "BCC-" to these fields, so that the
   blind recipients get a draft with "BCC-To:" and "Bcc-cc:" fields and
   no "To:" or "cc:" fields. Unfortunately, this is often very confusing
   to the blind recipients.  Although accidental replies are not
   possible, it is often difficult to tell that the draft received is
   the result of a blind-carbon-copy.

   The method which this memo suggests is to post two drafts, a visible
   draft for the visible recipients, and a blind draft for the blind
   recipients.  The visible draft consists of the original draft without
   any "Bcc:" fields.  The blind draft contains the visible message as a
   forwarded message.  The headers for the blind draft contain the
   minimal RFC-822 headers and, if the original draft had a "Subject:"
   field, then this header field is also included.  In addition, the
   user agent might explicitly show that the blind draft is the result
   of a blind-carbon-copy, with a "Bcc" header or prior to the first
   encapsulating boundary in the body.

Message Distribution

   The main purpose of message distribution (often called redistribution
   or resending) is to provide to a secondary recipient, perhaps not
   included among the original addressees, with a "true original" copy
   that can be treated like an original in every respect.

   Such distribution is most often done by discussion group moderators
   who use automated agents to simply repost received messages to a
   distribution list.  The better automatic distribution agents insert a
   new "Return-Path" header field to direct address failure notices to
   the discussion group address list maintainer, rather than to the
   original author.  This form of distribution is encouraged because it


Rose & Stefferud                                                [Page 8]



RFC 934                                                     January 1985
Message Encapsulation


   most simply serves to deliver messages to discussion group recipients
   as processable originals.  It is performed by trusted pseudo-MTS
   agents.

   A second kind of distribution is that done by individuals who wish to
   transfer a processable copy of a received message to another
   recipient. This second form is discouraged in various new standards
   for message transfer.  These include the NBS Standard for Mail
   Interchange [FIPS-98], and the recent CCITT draft MHS (Mail Handling
   Systems) X.400 standards [X.400]. In place of direct reposting of
   received messages as though they are new drafts, the recommendation
   is to forward the received message in the body of a new draft from
   which is can be extracted by its secondary recipient for further
   processing.

   It is in support of this recommendation that this standard for
   encapsulation/decapsulation is proposed.
































Rose & Stefferud                                                [Page 9]



RFC 934                                                     January 1985
Message Encapsulation


References

   [RFC-822]    D.H. Crocker.  "Standard for the Format of ARPA-Internet
                Text Messages", University of Delaware.  (August, 1982)

   [RFC-821]    J.B. Postel.  "Simple Mail Transfer Protocol",
                USC/Information Sciences Institute.  (August, 1982).

   [FIPS-98]    National Bureau of Standards.  "Specification for
                Message Format for Computer Based Message Systems."
                (January, 1983).

   [X.400]      Consultative Committee on International Telephone and
                Telegraph.  "DRAFT Recommendation X.400.  Message
                Handling Systems: System Model-Service Elements."

Authors' Addresses

   Marshall T. Rose

      Department of Computer and Information Sciences
      University of Delaware
      Newark, DE 19716

      [e-mail]

   Einar A. Stefferud

      Network Management Associates, Inc.
      17301 Drey Lane
      Huntington Beach, CA 92647

      [e-mail]
















Rose & Stefferud                                               [Page 10]