956.txt

[3] 要約メッセージの書式。 

* 仕様書

[REFS[
- [5] [CITE@en[RFC 1153 - Digest message format]], [TIME[2021-01-31T10:00:43.000Z]], [TIME[2021-03-13T07:36:51.517Z]] <https://tools.ietf.org/html/rfc1153>
]REFS]

* 構文

[FIG(quote)[ [6] [SRC[>>5]]

>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番目の行、つまり尻尾やメッセージ全体の最後
の行は、直前の行の下線となる星印の行です。
]FIG]

*Trailer

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


*RFC 1153 メッセージの判別

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

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

**MIME 媒体型

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

[8] 
そんなわけで、 
[DFN[[CODE[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 パラメーターを
次の例のように使うことにしましょう。

=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:領域]]は、

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

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

但し [[Content-Type:領域]]は

=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]] メッセージだった場合に。

* メモ

[4] 
[[RFC 1153]] 曰く、由緒正しい方法で、
[[RFC934]] なんて若造でダメダメなのねん。




- [1] [WEAK[2002-11-15 (金) 17:21]] ''[[名無しさん]]'': <http://www.sapporo.iij.ad.jp/staff/fukachan/fml/advisories/FA1999_005/5.html>
- [2] [WEAK[2002-12-21 20:35]] ''[[名無しさん]]'': [[rfc-index]] では Status: EXPERIMENTAL ですが、 [[IETF]] Application Area ではいずれ HISTRICAL にしようとしています。 (''Candidates for Historic status'' <http://www.apps.ietf.org/maybe-historic.html>)