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.

このメモは、草稿の頭部分には何の制限も加えていません。 但しこれは RFC 822 標準に適合するべきです。

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.

草稿転送メッセージの文は3つの部位から成ります。 最初の文の節, カプセル化メッセージ, 最後の分の節です。

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

しかし、このプロトコルは、要約を構成する転送代理者が使う擬似規格と きっちり同じではありません。特に、要約中にカプセル化された 各メッセージの後 EB の前と後には空白行が来ます。また、 要約中にカプセル化された最初のメッセージの前 EB は、後に空白行が来ますが、普通は前には空白行は来ません (わお!)。

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.

このメモでは、既存の紐解き代理者との互換性を保っておきたいと思う 転送代理者の実装者は各 EB を空白行で囲むことにするのを推奨します。 カプセル化メッセージの前 EB の後の空白行を紐解き代理者は 無視しないといけないことに注意して下さい。更に、このメモは、 後 EB の前にある空白行も紐解き代理者は無視することを提案します。

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.

注意: この推奨は、後方互換性のために行うものです。 このメモを厳密に運用しようと思う転送代理者は、 EB を囲む空白行を生成するべきではありません。

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.

このプロトコルは、一般のメッセージの転送と要約という特定場面の 両者に使うのに通常十分であることに注意して下さい。不幸にも、 ARPA-Internet のどの転送代理者も (著者の知識では) 気にしていないと 思われる問題があります。転送するメッセージの文部分中に カプセル化区切りが出現した時に転送代理者はどうしたら良いでしょうか。 例外無く、この問題は既存の転送代理者から無視されています。

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, " ").

この問題について、このメモは次の文字埋め方式を提案します。 カプセル化境界はダッシュで始まる行と定義されました。 ダッシュで始まって次に間隔 (10進符号 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.

転送の際に、転送代理者が転送されるメッセージの文部分中の行で、 カプセル化境界で始まるものを見つけたら、転送代理者は出力する行の 前に、ダッシュとそれに続けて感覚を出力します。

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.

   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.