[2] [DFN[[[RFC 934]]]] はメッセージカプセル化に関する規定でした。直接の互換性はありませんが、後の [[PEM]] や [[MIME]] の開発へ影響を与えています。 [8] 20世紀にはまだ実装が残っていましたが、現在では使われていないと思われます。同様の機能は現在は [[MIME]] の[[多部分メッセージ]]や [CODE(MIME)@en[[[message/rfc822]]]] により実現されています。 * 仕様書 [REFS[ - [4] [CITE@en[RFC 934 - Proposed standard for message encapsulation]] ([TIME[2015-01-11 15:29:14 +09:00]] 版) ]REFS] * RFC 934 [FIG(quote)[ [FIGCAPTION[ [5] Message Encapsulation ]FIGCAPTION] 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. ]FIG] *BNF あの図の説明、わかりますか? 理解するのにちょいと時間がかかりましたよ。我々(誰)には、 ABNF の方が数万倍わかりやすくないですか? =rfc934.message = rfc822.header CRLF text-portion =text-portion = initial-text *(boundary encapsulated) boundary final-text =initial-text = =encapsulated = =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 パラメーターを次の例のように使うことにしましょう。 =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:領域]]は、 =result for mget [1-10 RFC934(mh-burst)] (1/1) (testers ML) こんな風になります。 X-MLServer: 領域あたりで fml かどうか判定して、かつ Subject: 領域に「RFC934(mh-burst)」と書いてあった場合は、 RFC 934 形式と判断して良いでしょうか。但し [[Content-Type:領域]]は =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" * 関連 -PEM 型 ASCII armor --[[PEM]] --[[PGP]] -[[diff]] 命令の出力 *メモ [1] [TIME[2002-12-21 20:34]] ''[[名無しさん]]'': [[rfc-index]] によると Status: UNKNOWN ですが、 [[IETF]] Application Area は Histrical にしようと考えています。 (''Candidates for Historic status'' ) [6] >>1 未だに UNKNOWN ですがどうなったんですかね。 [TIME[2015-04-10T12:38:15.200Z]] [3] [[man]] によると [CODE@en[[[patch]]]] [[命令]]は [[RFC 934]] を考慮しています。 [FIG(quote)[ [FIGCAPTION[ [9] [CITE[Man page of PATCH]] ([TIME[2015-02-06 06:33:49 +09:00]] 版) ]FIGCAPTION] > patch は差分の前にあるゴミを読み飛ばし、差分を適用し、そして後ろにあるゴミを読み飛ばそうとする。そのため、差分リストを含む記事やメッセージを patch に流し込むことができ、それで動作するはずである。 diff 全体が一定量インデントされている場合や、コンテキスト diff が CRLF で終わる行を含んでいる場合、インターネット RFC 934 で規定されるように "-" で始まる行の先頭に 1個または複数個の "- " が付いている場合には、これらは考慮される。 ]FIG]