RFC 1153

RFC 1153

[3] 要約メッセージの書式。 RFC 1153 曰く、由緒正しい方法で、 RFC934 なんて若造でダメダメなのねん。

Description

A digest message is a conventional message consisting of a header and body conforming to RFC 822 as clarified in RFC 1123. There is no fixed size. Limitations may exist in intermediate mail gateways which restrict the size. The typical digest size is 15,000 characters.

The header of a digest message should identify the digest in the Subject line by listname, the key word, Digest, the volume number (usually a sequential number either starting at 1 or the last two digits of the year and incremented by one starting with the first issue of the next calendar year), and an issue number starting at one for the first issue of a new calendar year.

要約メッセージの頭は、 Subject 行に、リスト名・キーワード・Digest ・巻番号 (普通は 1 から始まる連続番号か、年の下2桁で 次の暦年の初めの発行で1つ増えるもの)・新しい暦年の最初の発行 で 1 から始まる発行番号を入れることで識別できるようにするべきです。

The body of a digest message must consist of a Preamble, one or more enclosed messages, and a Trailer.

要約メッセージの本文は前書き, 1つ以上の囲まれたメッセージ, 尻尾で構成しなければなりません。

The Preamble usually contains a table of contents consisting of the subject line contents of the enclosed messages, usually indented or centered, and also may contain brief administrative or other announcements.

前書きは通常目次が書かれていて、そこには囲まれたメッセージの subject 行の内容が、普通は字下げや中央寄せして並べてあって、 それから簡単な管理上その他のお知らせも書かれているかもしれません。

The Preamble must be separated from the remainder of the message by a line of 70 hyphens followed by a blank line.

前書きは、70個のハイフンとそれに続く空白行で、メッセージの連続 と区切らなければなりません。

Each enclosed message is a conventional message consisting of a header and body, separated by a blank line. If they exist in the original message header, the following lines must be retained as-is in the reconstructed header: Date:, From:, To:, Cc:, Subject:, Message-ID:, and Keywords:, rearranged to appear in that order. Retaining the Summary: line is optional. Lines include continuation lines as defined in the RFCs. All other header lines should be discarded, especially Received lines. All leading and trailing blank lines should be removed from the message body. The message body may be scanned to replace with a blank the first character of any lines of exactly and only 30 hyphens.

各囲まれたメッセージは、頭と本文があって空白行で区切られている 通常のメッセージです。次の行はもとのメッセージ頭に存在する場合、 そのまま再構築した頭に入れなければなりません: Date:, From:, To:, Cc:, Subject:, Message-ID:, Keyword:。その順になるように 並べ替えます。 Summary: 行を入れるかは任意とします。行には、 RFC で定義された継続行も含みます。他の全ての頭行、とりわけ Received 行は棄てるべきです。メッセージ本文の全てのはじめと 終わりの空白行は削除するべきです。メッセージの本文は精査して、 丁度ぴったり30個のハイフンの行の最初の文字を空白に置き換えなければ なりません。

Each enclosed message must be separated from the the remainder of the digest message by a blank line before and after a line of 30 hyphens.

各囲まれたメッセージは、前後が空白行であるハイフン30個の行で 残りのメッセージと区切らなければなりません。

The Trailer immediately follows the blank line of message separator following the last enclosed message. The Trailer consists of two lines. The first line must begin with the words, End of, followed by the listname a blank and the word Digest which is usually followed by volume and issue number on the same line. The second and last line of the Trailer and the entire message is a line of asterisks serving to underline the line immediately above it.

尻尾は、最後の囲まれたメッセージの後のメッセージ区切りの 空白行の直ぐ後に来ます。尻尾は2つの行から構成されます。 最初の行は単語 End of で始まって、リスト名空白と単語 Digest, それに通常は巻と発行番号を続けて同じ行に入れたもの でなければなりません。2番目の行、つまり尻尾やメッセージ全体の最後 の行は、直前の行の下線となる星印の行です。

Trailer

Tailer かと思って尻尾と訳しちまったよ・・。 Trailer ってどう訳せばいい? 辞書に拠ると追跡者, 引きずるもの, トレーラー, トレーラーハウス・・・

RFC 1153 メッセージの判別

RFC934 の同じ節からパクって来た:-)

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

MIME 媒体型

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

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

必須パラメーターは無しです。 charset パラメーターは使っては いけません

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

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

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

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

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

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

Trailer については、ほんとはこれもなんとかせなあかんのだろーけど、 面倒なので棚上げ。

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

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

fml の RFC 1153 要約

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

  1. result for mget [1-10 Digest (RFC1153)] (1/1) (testers ML)

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

但し Content-Type:領域

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

となってます。 charset はちゃんと判定してるんでしょうか? ソースは読んでませんが、実際に試したところでは、決め打ちしてるように思えます。

一般メッセージ

CRLF 70( "-" ) CRLF があって、 CRLF CRLF 30( "-" ) CRLF CRLF 'End of ' 1*OCTET ' Digest' *OCTET CRLF *( "*" ) [CRLF] で本文が終わってれば、 RFC 1153 要約メッセージ だってことにしてしまっていいですかね? もちろん CT: がない、非 MIME メッセージだった場合に。

License

See RFCのライセンス