第1部分 —— 人間可読メッセージ

[9] 第1部分は人間可読なメッセージとします。 その内容は、報告する事項をわかりやすく解説したものとします。 第2部分を利用者エージェントが理解できなくてもこの部分から人間利用者が報告の意味を理解できます。 また、第2部分で形式的に記述できないことの説明にも使えます。 RFC-REPORT 1.

[10] 媒体型・言語: 記述の方法は任意の標準化過程の媒体型、 charset、言語を使って構いません。 multipart/alternative により複数種類を同梱することもできます。 RFC-REPORT 1.

[11] 省略: この部分は必須です。 RFC-REPORT 1.

第2部分 —— 機械可読報告

[12] 報告する内容についての詳しい情報を機械可読な形式で入れます。 第1部分で説明しなかった細かい内容も含めることができます。 RFC-REPORT 1.

[13] この部分が multipart/report メッセージ全体を特徴付けることになります。 multipart/report 媒体型の report-type 引数には、 この第2部分の媒体型の亜型を指定します。 RFC-REPORT 1.

[22] 媒体型: この部分で使用する媒体型については特に制限はないようで、 >>12 の目的を果たせるなら何でも良いと思われます。 今のところ標準化されているものは全て message/* ですが、 そのような制限もないようです。

[14] 省略: この部分は必須です。 RFC-REPORT 1.

第3部分 —— 元のメッセージ

[15] 第3部分には報告の対象となった元のメッセージの一部又は全部を含めることができます。 この情報は人間の専門家が問題の分析のために使うことができます。 (報告を受け取った側で自動的に対応する元のメッセージを決定するために使うこともできますが、そのための情報は第2部分に含めることが想定されています。) RFC-REPORT 1.

[16] 元のメッセージを報告に含めるかどうか、 含めるとしたら全部含めるか、 どの部分を含めるかは報告の種類と報告の要求者の希望などによります。 詳しくは各報告種の説明をご覧下さい。

[17] multipart/report 媒体型自体は常に Content-Transfer-Encoding が 7bit とされています。第3部分に含めるメッセージは通常 message/* なので、 やはり規定により 7bit か 8bit か binary に制限されてしまいます。

第3部分に含めるメッセージが 7bit で表現できない場合、合法的な 7bit MIME メッセージになるように再符号化しても構いませんし、 頭部だけを取り出して text/rfc822-headers 媒体型としても構いません。RFC-REPORT 1.

text/rfc822-headers だけなら任意の内容転送符号化が使えますし、 通常診断には頭部があれば十分ということなのでしょう。

[22] 媒体型: この部分に使用する媒体型は、 >>17 の通り text/rfc822-headers を使うことが特に提案されていることを除き、 特に制限されていないようです。 報告の種類によっては具体的に規定があるかもしれません。

[21] 省略: この部分は省略可能です。 RFC-REPORT 1.