RFC 934

RFC 934

[2] RFC 934 はメッセージカプセル化に関する規定でした。 直接の互換性はありませんが、後の PEMMIME の開発へ影響を与えています。

[8] 20世紀にはまだ実装が残っていましたが、現在では使われていないと思われます。 同様の機能は現在は MIME多部分メッセージmessage/rfc822 により実現されています。

仕様書

RFC 934

[5] Message Encapsulation

This memo proposes the following encapsulation protocol: two agents act on behalf of the user, a forwarding agent, which composes the message draft prior to posting, and a bursting agent which decomposes the message after delivery.

このメモは、次のカプセル化プロトコルを提案します。 2つの代理者が利用者の指示に基づき動きます。1つは転送代理者で、 メッセージの草稿を投稿の前に構成し、もう1つは開封代理者で、 配達後のメッセージを紐解きます。

Definitions: a draft forwarding message consists of a header portion and a text portion. If the text portion is present, it is separated from the header portion by a blank line. Inside the text portion a certain character string sequence, known as an "encapsulation boundary", has special meaning. Currently (in existing digestification agents), an encapsulation boundary (EB) is defined as a line in the message which starts with a dash (decimal code 45, "-"). Initially, no restriction is placed on the length of the encapsulation boundary, or on the characters that follow the dash.

定義: 草稿転送メッセージは頭部分と文部分で構成されます。 文部分がある場合、これは頭部分と空白行で区切られます。 文部分の内側では、「カプセル化境界」と呼ばれるある文字列は 特別な意味を持ちます。現在 (既存の要約化代理者は)、 カプセル化境界 (EB) を、メッセージ中のダッシュ (10進符号45, "-") で始まる行と定義しています。まず、カプセル化区切りの長さにも ダッシュの後に続く文字にも制限はありません。

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つの部位から成ります。 最初の文の節, カプセル化メッセージ, 最後の分の節です。

2.1. The Initial Text Section

All text (if any) up to the first EB comprises the initial text section of the draft. This memo makes no restrictions on the format of the initial text section of the draft. In the case of a digest, this initial text is usually the "table of contents" of the digest.

最初の EB までの全ての文は、 (もしあれば) 草稿の最初の文の節です。 このメモは、草稿の最初の文の節の形式には何の制限も 加えません。 要約の場合では、最初の文は大抵要約の「目次」になります。

2.2. The Final Text Section

All text (if any) after the last EB composes the final text section of the draft. This memo makes no restrictions on the format of the final text section of the draft. In the case of a digest, this final text usually contains the sign-off banner for the digest (e.g., "End of FOO Digest").

最後の EB の後の全ての文は (もしあれば) 草稿の最後の文の節 になります。このメモは草稿の最後の文の節の形式には何の制限も 加えません。要約の場合には、最後の分は大抵、要約の〆の印 (例: 「なんとか要約はここまで」) になります。

2.3. Encapsulated Messages

Each encapsulated message is bounded by two EBs: a pre-EB, which occurs before the message; and, a post-EB, which occurs after the message. For two adjacent encapsulated messages, the post-EB of the first message is also the pre-EB of the second message. Consistent with this, two adjacent EBs with nothing between them should be treated as enclosing a null message, and thus two or more adjacent EBs are equivalent to one EB.

各カプセル化メッセージは、2つの EB により挟まれます。 前 EB は、メッセージの前に来ます。後 EB は、メッセージの後に来ます。 2つの隣接カプセル化メッセージの間では、最初のメッセージの 後 EB が2番目のメッセージの前 EB でもあります。 ですから、間に何も無い2つの隣接する EB は空メッセージを囲んでいる ものとして扱うべきで、従って2つ以上の隣接する EB は1つの EB と等価であります。

Each encapsulated message consists of two parts: a headers portion and a text portion. If the text portion is present, it is separated from the header portion by a blank line.

各カプセル化メッセージは2つの部分で構成されます。 頭部分と文部分です。文部分がある場合、これは頭部分と 空行で区切られます。

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つの頭項目がないといけません。 "Date:" 領域と "From:" 領域です。これは、 RFC 822 では最低1つの宛先アドレス ("To:" 領域か "cc:" 領域で) または空の "Bcc:" 領域を必要としている のと異なります。転送されるメッセージの頭項目中のアドレスは、 必ず完全修飾されたものでなければなりません。

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.

メッセージのカプセル化の生成・解析規則をまとめる前に、 2つの問題があります。

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.

BNF

あの図の説明、わかりますか? 理解するのにちょいと時間がかかりましたよ。 我々(誰)には、 ABNF の方が数万倍わかりやすくないですか?

  1. rfc934.message = rfc822.header CRLF text-portion
  2. text-portion = initial-text *(boundary encapsulated) boundary final-text
  3. initial-text = <character-stuffed (*(text CRLF) *text)>
  4. encapsulated = <character-stuffed (rfc822.message)>
  5. boundary = [CRLF] "-" *text CRLF [CRLF]

RFC 934 メッセージの判別

ある RFC 822 メッセージの中身が RFC 934 かどーかを判別する 方法はありません。困ったもんです。

MIME 媒体型

MIME では multipart/digest媒体型があるのでそちらを 使うべきだと思うのですが、わけあって RFC 934 形式を出力する 時に、そのことを頭にメモっとくのは悪い考えではないと思います。

そんなわけで、 text/x-message-rfc934 媒体型名を提案します。 message/rfc934 なんてのもいいかなーというきもするのですが、 message/* の未知の媒体型は application/octet-stream媒体型 扱いになるので、それは困ったなーと。 application/*媒体型 にしても良いんですが、いや、同じ理由でよくないでしょう。 ていうか内容は概ね人間可読なので、 text/*媒体型で問題ないかと。

必須パラメーターは無しです。 charset パラメーターは使っては いけません。と現時点ではしと来ますが、 initial-text と final-text を考えれば必要かなあ? でもそれはちと問題だと 思うぞー。てことで棚上げ。

initial-text と final-text の charset 指定はやっぱり 何らかの形であった方がいいでしょうね。 RFC 934 形式は 元々 MIME 以前からの形式であって、 US-ASCII 以外の charset とかでもふつーに使ってたんですから。

んだけど、折角だから(謎)、 charset 以外もってことで、 Content-Type:領域の中身にあたるのを丸ごと媒体型 パラメーターにしてしまった方がいいかも。

てことで、 x-preamble-type と x-epilogue-type パラメーターを 次の例のように使うことにしましょう。

  1. Content-Type: text/x-message-rfc934; x-preamble-type="text/plain; charset=\"iso-2022-jp\""

名前は、 MIME の multipart/*媒体型とも共用できる様に:-) 反則っぽいけどこれでいいでしょ?

で、冗長性を除く為に、値が "text/plain; charset=us-ascii" である場合は省略しても良く、互換性のために 紐解き実装はこれ以外の値が省略されていると見なされる ものも解釈しようと試みなければならないってことで。

それから、値の中身の媒体型は "text/plain" を受け入れなければならず、 それ以外の値は "text/plain" であるものと見なして良くtext/plain媒体型の format パラメーターは無視しても良く、 format=fixed (既定値) の "text/plain" 以外を値に持つ メッセージを生成するべきではない。 (だって実装が 面倒なんだもん。それに、そんなの要らんでしょ。)

CTE は通常 "7bit" で十分でしょうが、カプセル化メッセージが "8bit" やら "binary" やらの可能性もありますから、その時は Quoted-Printable を使うのが良いでしょう。

中継する MTA はカプセル化されたメッセージを勝手に書き換えては いけません。とでも規定しておくのが良かろう。

fml の RFC 934 要約

fml に RFC 934 形式で送るように頼むと、 Subject:領域は、

  1. result for mget [1-10 RFC934(mh-burst)] (1/1) (testers ML)

こんな風になります。 X-MLServer: 領域あたりで fml かどうか判定して、かつ Subject: 領域に「RFC934(mh-burst)」 と書いてあった場合は、 RFC 934 形式と判断して良いでしょうか。

但し Content-Type:領域

  1. Content-Type: text/plain; charset=iso-2022-jp

となってます。 charset はちゃんと判定してるんでしょうか? 色んな charset のが混じってた場合は? うーん、、、

ソースは読んでませんが、実際に試したところでは、 決め打ちしてるように思えます。

で、 fml が送ってくる RFC 934 メッセージには問題があって、 final-text (と、その前の boundary) がありません。 ですから、最後のカプセル化メッセージでメッセージ全体が終わります。

start of forwarded message (RFC 934 encapsulation)

っていう文字列を境界に入れる実装があるみたいだから、 これを判別に使っても良いかな?

んだけど、カプセル化の外側で "-" stuffing が行われてなかったり する気が。 (特に署名前の "-- " とか。)

実際のところ、 RFC 934 は initial-text と final-text で "-" stuff しろともするなとも書いてないんですよね。 してないと機械的に判断しようが無いと思うんですけど。

"-" stuff

character-stuff = "-" SP *text ;; semantically equal to "*text"

関連

メモ

[1] 名無しさん: rfc-index によると Status: UNKNOWN ですが、 IETF Application Area は Histrical にしようと考えています。 (Candidates for Historic status <http://www.apps.ietf.org/maybe-historic.html>)

[6] >>1 未だに UNKNOWN ですがどうなったんですかね。

[3] man によると patch 命令RFC 934 を考慮しています。

[9] Man page of PATCH ( 版) <http://linuxjm.sourceforge.jp/html/GNU_patch/man1/patch.1.html>

patch は差分の前にあるゴミを読み飛ばし、差分を適用し、 そして後ろにあるゴミを読み飛ばそうとする。 そのため、差分リストを含む記事やメッセージを patch に流し込むことができ、それで動作するはずである。 diff 全体が一定量インデントされている場合や、 コンテキスト diff が CRLF で終わる行を含んでいる場合、 インターネット RFC 934 で規定されるように "-" で始まる行の先頭に 1個または複数個の "- " が付いている場合には、 これらは考慮される。