home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / r / rfc934.zip / RFC934.TXT < prev   
Text File  |  1987-04-19  |  22KB  |  571 lines

  1.  
  2.  
  3. Network Working Group                        Marshall T. Rose (Delaware)
  4. Request for Comments: 934                       Einar A. Stefferud (NMA)
  5.                                                             January 1985
  6.  
  7.               Proposed Standard for Message Encapsulation
  8.  
  9.  
  10. STATUS OF THIS MEMO
  11.  
  12.    This RFC suggests a proposed protocol for the ARPA-Internet
  13.    community, and requests discussion and suggestions for improvements.
  14.    Distribution of this memo is unlimited.
  15.  
  16. Introduction, Scope, and Motivation
  17.  
  18.    The services that a user agent (UA) can offer are varied.  Although
  19.    all outgoing mail may be thought of as going through a single posting
  20.    slot to connect to the message transport system (MTS), it is possible
  21.    to consider a message draft being posted as described by one of the
  22.    following four types of postings:
  23.  
  24.       Originate - a new message is composed from scratch, which, to the
  25.       knowledge of the UA, is unrelated to any message previously
  26.       handled by the user.
  27.  
  28.       Reply - a message is composed as a reply to a message previously
  29.       received by the user.  In most circumstances, the UA aids the user
  30.       in composing the reply by constructing the header portion of the
  31.       message draft, using components extracted from the received
  32.       message headers.
  33.  
  34.       Forward - one more more messages previously received by the user
  35.       are formatted by the UA as a part of the body portion of the
  36.       draft.  In this sense, a "digest" for an interest group may be
  37.       considered as forwarding.  Similarly, an argument may be made that
  38.       "blind-carbon-copies" should also be handled in this fashion.
  39.  
  40.       Distribute - a message previously received by the user is
  41.       re-posted to the MTS.  The draft being re-posted is identical to
  42.       the original message with the exception that certain "ReSent-XXX"
  43.       headers are appended to the headers portion of the draft, and the
  44.       "Return-Path" header is reset to reference the re-sender's
  45.       address.  (See [RFC-821] for a discussion of the Return-Path
  46.       header.)
  47.  
  48.    Most user agents support the first two of these activities, many
  49.    support the first three, and a few support all four.
  50.  
  51.    This memo concerns itself only with the third type, which is message
  52.    forwarding.  (For a brief treatment of the semantics of message
  53.    components with respect to replies, see [RFC-822].) In many ways,
  54.  
  55.  
  56. Rose & Stefferud                                                [Page 1]
  57.  
  58.  
  59.  
  60. RFC 934                                                     January 1985
  61. Message Encapsulation
  62.  
  63.  
  64.    forwarding can be thought of as encapsulating one or more messages
  65.    inside another.  Although this is useful for transfer of past
  66.    correspondence to new recipients, without a decapsulation process
  67.    (which this memo terms "bursting"), the forwarded messages are of
  68.    little use to the recipients because they can not be distributed,
  69.    forwarded, replied-to, or otherwise processed as separate individual
  70.    messages.
  71.  
  72.       NOTE: RFC-822 mistakenly refers to distribution as forwarding
  73.       (section 4.2).  This memo suggests below, that these two
  74.       activities can and should be the same.
  75.  
  76.    In the case of an interest group digest, a bursting capability is
  77.    especially useful.  Not only does the ability to burst a digest
  78.    permit a recipient of the digest to reply to an individual digested
  79.    message, but it also allows the recipient to selectively process the
  80.    other messages encapsulated in the digest.  For example, a single
  81.    digest issue usually contains more than one topic.  A subscriber may
  82.    only be interested in a subset of the topics discussed in a
  83.    particular issue.  With a bursting capability, the subscriber can
  84.    burst the digest, scan the headers, and process those messages which
  85.    are of interest.  The others can be ignored, if the user so desires.
  86.  
  87.    This memo is motivated by three concerns:
  88.  
  89.       In order to burst a message it is necessary to know how the
  90.       component messages were encapsulated in the draft.  At present
  91.       there is no unambiguous standard for interest group digests.  This
  92.       memo proposes such a standard for the ARPA-Internet.  Although
  93.       interest group digests may appear to conform to a pseudo-standard,
  94.       there is a serious ambiguity in the implementations which produce
  95.       digests.  By proposing this standard, the authors hope to solve
  96.       this problem by specifically addressing the implementation
  97.       ambiguity.
  98.  
  99.       Next, there is much confusion as to how "blind-carbon-copies"
  100.       should be handled by UAs.  It appears that each agent in the
  101.       ARPA-Internet which supports a "bcc:" facility does so
  102.       differently. Although this memo does not propose a standard for
  103.       the generation of blind-carbon-copies, it introduces a formalism
  104.       which views the "bcc:" facility as a special case of the
  105.       forwarding activity.
  106.  
  107.       Finally, both forwarding and distribution can be accomplished with
  108.       the same forwarding procedure, if a distributed message can be
  109.       extracted as a separate individually processable message.  With a
  110.       proper bursting agent, it will be difficult to distinguish between
  111.  
  112.  
  113. Rose & Stefferud                                                [Page 2]
  114.  
  115.  
  116.  
  117. RFC 934                                                     January 1985
  118. Message Encapsulation
  119.  
  120.  
  121.       a message which has been distributed and a message which has been
  122.       extracted from a forwarded message. This memo argues that there is
  123.       no valuable distinction to be made, between forwarding and
  124.       distribution, and that in the interests of simplicity,
  125.       distribution facilities should not be generally available to the
  126.       ordinary users of a message system.  However, this memo also
  127.       argues that such facilities should be available to certain trusted
  128.       entities within the MTS.
  129.  
  130.          NOTE: this memo does not propose that the distribution facility
  131.          be abolished.  Rather it argues the case forcefully in the hope
  132.          that other interested parties in the ARPA-Internet will join
  133.          this discussion.
  134.  
  135. Message Encapsulation
  136.  
  137.    This memo proposes the following encapsulation protocol: two agents
  138.    act on behalf of the user, a forwarding agent, which composes the
  139.    message draft prior to posting, and a bursting agent which decomposes
  140.    the message after delivery.
  141.  
  142.    Definitions: a draft forwarding message consists of a header portion
  143.    and a text portion.  If the text portion is present, it is separated
  144.    from the header portion by a blank line.  Inside the text portion a
  145.    certain character string sequence, known as an "encapsulation
  146.    boundary", has special meaning.  Currently (in existing
  147.    digestification agents), an encapsulation boundary (EB) is defined as
  148.    a line in the message which starts with a dash (decimal code 45,
  149.    "-").  Initially, no restriction is placed on the length of the
  150.    encapsulation boundary, or on the characters that follow the dash.
  151.  
  152.    1. The Header Portion
  153.  
  154.    This memo makes no restriction on the header portion of the draft,
  155.    although it should conform to the RFC-822 standard.
  156.  
  157.    2. The Text Portion
  158.  
  159.    The text of the draft forwarding message consists of three parts: an
  160.    initial text section, the encapsulated messages, and the final text
  161.    section.
  162.  
  163.       2.1. The Initial Text Section
  164.  
  165.       All text (if any) up to the first EB comprises the initial text
  166.       section of the draft.  This memo makes no restrictions on the
  167.  
  168.  
  169.  
  170. Rose & Stefferud                                                [Page 3]
  171.  
  172.  
  173.  
  174. RFC 934                                                     January 1985
  175. Message Encapsulation
  176.  
  177.  
  178.       format of the initial text section of the draft.  In the case of a
  179.       digest, this initial text is usually the "table of contents" of
  180.       the digest.
  181.  
  182.       2.2. The Final Text Section
  183.  
  184.       All text (if any) after the last EB composes the final text
  185.       section of the draft.  This memo makes no restrictions on the
  186.       format of the final text section of the draft.  In the case of a
  187.       digest, this final text usually contains the sign-off banner for
  188.       the digest (e.g., "End of FOO Digest").
  189.  
  190.       2.3. Encapsulated Messages
  191.  
  192.       Each encapsulated message is bounded by two EBs: a pre-EB, which
  193.       occurs before the message; and, a post-EB, which occurs after the
  194.       message.  For two adjacent encapsulated messages, the post-EB of
  195.       the first message is also the pre-EB of the second message.
  196.       Consistent with this, two adjacent EBs with nothing between them
  197.       should be treated as enclosing a null message, and thus two or
  198.       more adjacent EBs are equivalent to one EB.
  199.  
  200.       Each encapsulated message consists of two parts: a headers portion
  201.       and a text portion.  If the text portion is present, it is
  202.       separated from the header portion by a blank line.
  203.  
  204.          2.3.1. The Header Portion
  205.  
  206.          Minimally, there must be two header items in each message being
  207.          forwarded, a "Date:" field and a "From:" field. This differs
  208.          from RFC-822, which requires at least one destination address
  209.          (in a "To:" or "cc:" field) or a possibly empty "Bcc:" field.
  210.          Any addresses occuring in the header items for a message being
  211.          forwarded must be fully qualified.
  212.  
  213.          2.3.2. The Text Portion
  214.  
  215.          This memo makes no restrictions on the format of the text
  216.          portion of each encapsulated message.  (Actually, this memo
  217.          does restrict the format of the text portion of each
  218.          encapsulated message, but these restrictions are discussed
  219.          later.)
  220.  
  221.    Before summarizing the generation/parsing rules for message
  222.    encapsulation, two issues are addressed.
  223.  
  224.  
  225.  
  226.  
  227. Rose & Stefferud                                                [Page 4]
  228.  
  229.  
  230.  
  231. RFC 934                                                     January 1985
  232. Message Encapsulation
  233.  
  234.  
  235. Compatibility with Existing User Agents
  236.  
  237.    The above encapsulation protocol is presently used by many user
  238.    agents in the ARPA-Internet, and was specifically designed to
  239.    minimize the amount of changes to existing implementations of
  240.    forwarding agents in the ARPA-Internet.
  241.  
  242.    However, the protocol is not exactly like the pseudo-standard used by
  243.    those forwarding agents that compose digests.  In particular, the
  244.    post-EB of all messages encapsulated in a digest is preceeded and
  245.    followed by by a blank line.  In addition, the first message
  246.    encapsulated in a digest has a pre-EB that is followed by a blank
  247.    line, but usually isn't preceeded by a blank line (wonderful).
  248.  
  249.    This memo recommends that implementors of forwarding agents wishing
  250.    to remain compatible with existing bursting agents consider
  251.    surrounding each EB with a blank line.  It should be noted that blank
  252.    lines following a pre-EB for an encapsulated message must be ignored
  253.    by bursting agents.  Further, this memo suggests that blank lines
  254.    preceeding a post-EB also be ignored by bursting agents.
  255.  
  256.       NOTE: This recommendation is made in the interest of
  257.       backwards-compatibility.  A forwarding agent wishing to strictly
  258.       adhere to this memo, should not generate blank lines surrounding
  259.       EBs.
  260.  
  261. Character-Stuffing the Encapsulation Boundary
  262.  
  263.    It should be noted that the protocol is general enough to support
  264.    both general forwarding of messages and the specific case of digests.
  265.    Unfortunately, there is one issue of message encapsulation which
  266.    apparently is not addressed by any forwarding agent (to the authors'
  267.    knowledge) in the ARPA-Internet: what action does the forwarding
  268.    agent take when the encapsulation boundary occurs within a the text
  269.    portion of a message being forwarded?  Without exception, this
  270.    circumstance is ignored by existing forwarding agents.
  271.  
  272.    To address this issue, this memo proposes the following
  273.    character-stuffing scheme: the encapsulation boundary is defined as a
  274.    line which starts with a dash.  A special case is made for those
  275.    boundaries which start with a dash and are followed by a space
  276.    (decimal code 32, " ").
  277.  
  278.       During forwarding, if the forwarding agent detects a line in the
  279.       text portion of a message being forwarded which starts with the
  280.       encapsulation boundary, the forwarding agent outputs a dash
  281.       followed by a space prior to outputting the line.
  282.  
  283.  
  284. Rose & Stefferud                                                [Page 5]
  285.  
  286.  
  287.  
  288. RFC 934                                                     January 1985
  289. Message Encapsulation
  290.  
  291.  
  292.       During bursting, if the bursting agent detects an encapsulation
  293.       boundary which starts with a dash followed by a space, then the
  294.       bursting agent does not treat the line as an encapsulation
  295.       boundary, and outputs the remainder of the line instead.
  296.  
  297.    This simple character-stuffing scheme permits recursive forwardings.
  298.  
  299. Generation/Parsing Rules for Message Encapsulation
  300.  
  301.    The rules for forwarding/bursting are described in terms of regular
  302.    expressions.  The first author originally derived simple finite-state
  303.    automata for the rules, but was unable to legibly represent them in
  304.    this memo.  It is suggested that the implementors sketch the automata
  305.    to understand the grammar.
  306.  
  307.    The conventions used for the grammar are simple.  Each state is
  308.    followed by one or more alternatives, which are separated by the "|"
  309.    character.  Each alternative starts with a character that is received
  310.    as input. (CRLF, although two characters is treated as one character
  311.    herein.)  The last alternative for a state is the character "c",
  312.    which represents any character not specified in the preceeding
  313.    alternatives.  Optionally following the input character is an output
  314.    string enclosed by curly-braces.  Following this is the state that
  315.    the automata enters.  The reader should note that these grammars are
  316.    extremely simple to implement (and, in most cases, can be implemented
  317.    quite efficiently).
  318.  
  319.    When the forwarding agent encapsulates a message, it should apply the
  320.    following finite-state automaton.  The initial state is S1.
  321.  
  322.       S1 ::   CRLF {CRLF} S1
  323.             | "-" {"- -"} S2
  324.             | c {c} S2
  325.  
  326.       S2 ::   CRLF {CRLF} S1
  327.             | c {c} S2
  328.  
  329.    This simply says that anytime a "-" is found at the beginning of a
  330.    line, a "- " is output prior to outputting the line.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341. Rose & Stefferud                                                [Page 6]
  342.  
  343.  
  344.  
  345. RFC 934                                                     January 1985
  346. Message Encapsulation
  347.  
  348.  
  349.    When the bursting agent decapsulates the text portion of a draft, it
  350.    should apply the following finite-state automaton.  The initial state
  351.    is S1.
  352.  
  353.       S1 ::   "-" S3
  354.             | CRLF {CRLF} S1
  355.             | c {c} S2
  356.  
  357.       S2 ::   CRLF {CRLF} S1
  358.             | c {c} S2
  359.  
  360.       S3 ::   " " S2
  361.             | c S4
  362.  
  363.       S4 ::   CRLF S5
  364.             | c S4
  365.  
  366.       S5 ::   CRLF S5
  367.             | c {c} S2
  368.  
  369.    Although more complicated than the grammar used by the forwarding
  370.    agent to encapsulate a single message, this grammer is still quite
  371.    simple.  Let us make the simplifying assumption that both the initial
  372.    and final text sections of the draft are messages in addition to the
  373.    encapsulated messages.
  374.  
  375.    To begin, the current message being burst is scanned at state S1. All
  376.    characters are output until the EB is found (state S3).  If "- " is
  377.    found, the automaton enters state S2 and characters from the current
  378.    message are continued to be output.  Finally, a true EB is found
  379.    (state S4).  As the automaton traverses from state S3 to S4, the
  380.    bursting agent should consider the current message ended.  The
  381.    remainder of the EB is discarded (states S4 and S5).  As the
  382.    automaton traverses from state S5 to S2, the bursting agent should
  383.    consider a new message started and output the first character.  In
  384.    state S2, all characters are output until the EB is found.
  385.  
  386. Blind Carbon Copies
  387.  
  388.    Many user agents support a blind-carbon-copy facility.  With this
  389.    facility a draft has two types of addressees: visible and blind
  390.    recipients.  The visible recipients are listed as addresses in the
  391.    "To:" and "cc:" fields of the draft, and the blind recipients are
  392.    listed as addresses in the "Bcc:" fields of the draft.  The basis of
  393.    this facility is that copies of the draft which are delivered to the
  394.    recipients list the visible recipients only.
  395.  
  396.  
  397.  
  398. Rose & Stefferud                                                [Page 7]
  399.  
  400.  
  401.  
  402. RFC 934                                                     January 1985
  403. Message Encapsulation
  404.  
  405.  
  406.    One method of achieving this is to post a single draft, which lacks
  407.    any "Bcc:" fields, and, during posting, to interact with the MTS in
  408.    such a way that copies are sent to both the visible and blind
  409.    recipients.
  410.  
  411.    Unfortunately, a key problem with this arrangement is that the blind
  412.    recipients can accidently reply to the draft in such a way that the
  413.    visible recipients are included as addressees in the reply. This is
  414.    socially unacceptable!  To avoid this problem, the message which the
  415.    visible recipients receive must be different than the message which
  416.    the blind recipients receive.
  417.  
  418.    A second method is to post two drafts.  The first, which goes to the
  419.    visible recipients, is simply the draft without any "Bcc:" fields.
  420.    The second, which goes to the blind recipients, is simply the draft
  421.    with some string prepended to any "To:" and "cc:" field. For example,
  422.    the user agent might prepend "BCC-" to these fields, so that the
  423.    blind recipients get a draft with "BCC-To:" and "Bcc-cc:" fields and
  424.    no "To:" or "cc:" fields. Unfortunately, this is often very confusing
  425.    to the blind recipients.  Although accidental replies are not
  426.    possible, it is often difficult to tell that the draft received is
  427.    the result of a blind-carbon-copy.
  428.  
  429.    The method which this memo suggests is to post two drafts, a visible
  430.    draft for the visible recipients, and a blind draft for the blind
  431.    recipients.  The visible draft consists of the original draft without
  432.    any "Bcc:" fields.  The blind draft contains the visible message as a
  433.    forwarded message.  The headers for the blind draft contain the
  434.    minimal RFC-822 headers and, if the original draft had a "Subject:"
  435.    field, then this header field is also included.  In addition, the
  436.    user agent might explicitly show that the blind draft is the result
  437.    of a blind-carbon-copy, with a "Bcc" header or prior to the first
  438.    encapsulating boundary in the body.
  439.  
  440. Message Distribution
  441.  
  442.    The main purpose of message distribution (often called redistribution
  443.    or resending) is to provide to a secondary recipient, perhaps not
  444.    included among the original addressees, with a "true original" copy
  445.    that can be treated like an original in every respect.
  446.  
  447.    Such distribution is most often done by discussion group moderators
  448.    who use automated agents to simply repost received messages to a
  449.    distribution list.  The better automatic distribution agents insert a
  450.    new "Return-Path" header field to direct address failure notices to
  451.    the discussion group address list maintainer, rather than to the
  452.    original author.  This form of distribution is encouraged because it
  453.  
  454.  
  455. Rose & Stefferud                                                [Page 8]
  456.  
  457.  
  458.  
  459. RFC 934                                                     January 1985
  460. Message Encapsulation
  461.  
  462.  
  463.    most simply serves to deliver messages to discussion group recipients
  464.    as processable originals.  It is performed by trusted pseudo-MTS
  465.    agents.
  466.  
  467.    A second kind of distribution is that done by individuals who wish to
  468.    transfer a processable copy of a received message to another
  469.    recipient. This second form is discouraged in various new standards
  470.    for message transfer.  These include the NBS Standard for Mail
  471.    Interchange [FIPS-98], and the recent CCITT draft MHS (Mail Handling
  472.    Systems) X.400 standards [X.400]. In place of direct reposting of
  473.    received messages as though they are new drafts, the recommendation
  474.    is to forward the received message in the body of a new draft from
  475.    which is can be extracted by its secondary recipient for further
  476.    processing.
  477.  
  478.    It is in support of this recommendation that this standard for
  479.    encapsulation/decapsulation is proposed.
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512. Rose & Stefferud                                                [Page 9]
  513.  
  514.  
  515.  
  516. RFC 934                                                     January 1985
  517. Message Encapsulation
  518.  
  519.  
  520. References
  521.  
  522.    [RFC-822]    D.H. Crocker.  "Standard for the Format of ARPA-Internet
  523.                 Text Messages", University of Delaware.  (August, 1982)
  524.  
  525.    [RFC-821]    J.B. Postel.  "Simple Mail Transfer Protocol",
  526.                 USC/Information Sciences Institute.  (August, 1982).
  527.  
  528.    [FIPS-98]    National Bureau of Standards.  "Specification for
  529.                 Message Format for Computer Based Message Systems."
  530.                 (January, 1983).
  531.  
  532.    [X.400]      Consultative Committee on International Telephone and
  533.                 Telegraph.  "DRAFT Recommendation X.400.  Message
  534.                 Handling Systems: System Model-Service Elements."
  535.  
  536. Authors' Addresses
  537.  
  538.    Marshall T. Rose
  539.  
  540.       Department of Computer and Information Sciences
  541.       University of Delaware
  542.       Newark, DE 19716
  543.  
  544.       MRose@UDel.ARPA
  545.  
  546.    Einar A. Stefferud
  547.  
  548.       Network Management Associates, Inc.
  549.       17301 Drey Lane
  550.       Huntington Beach, CA 92647
  551.  
  552.       Stef@UCI.ARPA
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569. Rose & Stefferud                                               [Page 10]
  570.  
  571.