message

MIME型群 message/*

[1] message/* 媒体型は、 各種プロトコルにおけるメッセージのための媒体型です。

仕様書

message/* MIME 型の一覧

[2]

message/coffeepotHTCPCP メッセージ未登録RFC 2324
message/cpimCPIM メッセージIETF 提案標準, IANAREG 登録済RFC 3862, [IANAREG]
message/delivery-status配送状態報告 (DSN)RFC 1894, [IANAREG]
message/disposition-notification受信者動作報告 (MDN)RFC 2298, [IANAREG]
message/exampleIETF RFC, IANAREG 登録済RFC, [IANAREG]
message/external-body外部実体の参照[MIME], [IANAREG]
message/x-gnu-rmailGNU rmail message
message/httpHTTP メッセージ[HTTP RFC], [IANAREG]
message/x-netnewsUsenet ニュース・メッセージ時代遅れ ->application/news-transmission
message/newsUsenet ニュース・メッセージ時代遅れ->application/news-transmissionson-of-RFC 1036, [IANAREG]
message/partial分割メッセージ[MIME], [IANAREG]
message/rfc822RFC 822 メッセージ[MIME], [IANAREG]
message/rfc822-headersRFC 822 メッセージ頭部非標準 →text/rfc822-headers
message/s-httpS-HTTP メッセージRFC 2660, [IANAREG]
message/sipSIP メッセージRFC 3261, [IANAREG]
message/sipfragSIP メッセージ断片RFC 3420, [IANAREG]
message/teapot
message/tracking-statusIETF 提案標準, IANAREG 登録済RFC 3886, [IANAREG]

意味

[13] message/* は、カプセル化されたメッセージを表します。 本体は、何らかのメッセージの一部または全部です。 >>8

構文

[5] message/* 全体に共通した構文は特に定められていません。多くは RFC 822 に由来する似たような構造を持っていますが、それが message/* に属する条件とはなっていません。 似たように見えても実際には処理器を共通化し難い程度に違っています。また、 XML ベースのものなど、全く異なる構文のものも登録されています。

[11] message/* MIME型は、 RFC 2046, >>9 の構文その他の要件に適合しなければなりません >>10

分類

[12] message/* は、composite type です >>10

CTE

[15] MIME型によっては、CTE に制限があります >>14

[19] 電子メールを想定した新しい message/* MIME型は、 7bit に制限するべきです。制限できなければ message/* 以外を使うべきです。 >>14

[6] message/* は、 7bit8bitbinary 以外の CTE の使用が禁じられています。 HTTP など任意のバイト列を転送できる近代的なプロトコルでは問題ありませんが、 SMTP など MIME が当初想定していた古いプロトコルでは仕様に沿った形で利用できないデータもあり得ます。

[4] message/* を含む合成型における非同一内容転送符号化 (Base64 など) の使用は禁止されてきましたが (RFC 2045 6.4)、 RFC 5335 によって制限が緩和され、 message/* に属する亜型は個別に内容転送符号化の使用を認められるように変更されました (RFC 5335 4.1)。第1号として、 message/global内容転送符号化の使用が認められています。

処理

[16] 関門その他電子メールの処理器は、 RFC 822 メッセージヘッダーを変更することがあります。 しかし message/* で埋め込まれたメッセージヘッダーを変更してはなりません。 >>14

[18] 認識できない message/* のデータは、 application/octet-stream のように扱わなければなりません >>14

歴史

[17] RFC 2046 (MIME インターネット媒体型) 5.2. Message Media Type

It is frequently desirable, in sending mail, to encapsulate another mail message. A special media type, "message", is defined to facilitate this. In particular, the "rfc822" subtype of "message" is used to encapsulate RFC 822 messages.

メイルを送る際に、他のメイル・メッセージをカプセル化するのが望ましい ことがしばしばあります。 この目的のために特別な媒体型 message を定義します。 特に、 messagerfc822 亜型は RFC 822 メッセージのカプセル化のために使います。

NOTE: It has been suggested that subtypes of "message" might be defined for forwarded or rejected messages. However, forwarded and rejected messages can be handled as multipart messages in which the first part contains any control or descriptive information, and a second part, of type "message/rfc822", is the forwarded or rejected message. Composing rejection and forwarding messages in this manner will preserve the type information on the original message and allow it to be correctly presented to the recipient, and hence is strongly encouraged.

参考: message の亜型を転送メッセージや拒絶メッセージ用として定義したらどうかと提案されています。 しかし、転送メッセージや拒絶メッセージは、 最初の部分に制御情報や説明的情報を含み、 二番目の部分が型 message/rfc822 で転送メッセージや拒絶メッセージとする多部分メッセージとして取扱うことができます。 拒絶メッセージや転送メッセージをこの方法で構成すれば元のメッセージの型情報を保存することができますし、 受信者に正しくみせることができますから、 こちらを強く推奨いたします。

(RFC 2046 より) Subtypes of "message" often impose restrictions on what encodings are allowed. These restrictions are described in conjunction with each specific subtype.

message の亜型にはしばしば、 どの符号化が認められるかについての制限を課します。 この制限は各亜型の規定と共に説明します。

(RFC 1341, RFC 1521 より) As stated in the definition of the Content-Transfer-Encoding field, no encoding other than "7bit", "8bit", or "binary" is permitted for messages or parts of type "message". Even stronger restrictions apply to the subtypes "message/partial" and "message/external-body", as specified below. The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this. Non-ASCII text in the headers of an encapsulated message can be specified using the mechanisms described in [RFC-1522].

CTE 領域の定義で述べたように、 〜 以外の符号化はメッセージや型 "message"の部分には認められていません。より強い制限を、 下に説明するように亜型 "message/partial" および "message/external-body" には課します。メッセージ頭領域は常にどんな場合も US-ASCII で、本文中のデータは符号化されていても構いません。その場合はカプセル化 メッセージの Content-Transfer-Encoding 頭領域がこれを反映しています。 カプセル化メッセージの頭中の非 US-ASCII 文は、 RFC 1522 で説明されている 方法を使って記述出来ます。

Mail gateways, relays, and other mail handling agents are commonly known to alter the top-level header of an RFC 822 message. In particular, they frequently add, remove, or reorder header fields. These operations are explicitly forbidden for the encapsulated headers embedded in the bodies of messages of type "message."

メイル関門・中継者・その他メイルを取り扱う代理者は、 RFC 822 メッセージの最上位の頭をいじることが良く知られています。 特に、よく頭領域を追加したり削除したり並べ替えたりします。 こうした操作は、型 "message" のメッセージの本文に埋め込まれている カプセル化されたかしらに対しては、ここに明示的に禁止します。

5.2.1. RFC822 Subtype

See message/rfc822

5.2.2. Partial Subtype

See message/partial

5.2.3. External-Body Subtype

See message/external-body

5.2.4. Other Message Subtypes 他の Message 亜型

MIME implementations must in general treat unrecognized subtypes of "message" as being equivalent to "application/octet-stream".

MIME 実装は通常、認識出来ない "message" の亜型を、 "application/octet-stream" と同等であるものとして扱わなければなりません。

Future subtypes of "message" intended for use with email should be restricted to "7bit" encoding. A type other than "message" should be used if restriction to "7bit" is not possible.

将来の電子メイルでの使用を意図した "message" の亜型は、 "7bit" 符号化に制限されるべきです。 "7bit" に制限することが可能では 無い場合は、"message" 以外の型を使用するべきです。

(RFC 1521 より) The formal grammar for content-type header fields for data of type message is given by:

型 message のデータの content-type 頭領域の正式な文法は次の通りです。

   message-type := "message" "/" message-subtype
>
   message-subtype := "rfc822"
                   / "partial" 2#3partial-param
                   / "external-body" 1*external-param
                   / extension-token

編集者注: 2#3partial-param2*3 の誤りでしょう。 # だったらえらいこっちゃ。

   partial-param :=     (";" "id" "=" value)
              /  (";" "number" "=" 1*DIGIT)
              /  (";" "total" "=" 1*DIGIT)
         ; id & number required; total  required  for  last part
           id と number は必須。 total は最後の部分には必須
>
   external-param :=   (";" "access-type" "=" atype)
              / (";" "expiration" "=" date-time)
                   ; Note that date-time is quoted
              / (";" "size" "=" 1*DIGIT)
              / (";"  "permission"  "="  ("read"  /  "read-write"))
                   ; Permission is case-insensitive
                     permission は大文字・小文字を区別しない
              / (";" "name" "="  value)
              / (";" "site" "=" value)
              / (";" "dir" "=" value)
              / (";" "mode" "=" value)
              / (";" "server" "=" value)
              / (";" "subject" "=" value)
          ; access-type required;others required based on access-type
            access-type は必須。他は access-type によっては必要
>
   atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
                  / "afs" / "mail-server" / extension-token
                  ; Case-insensitive
                    大文字・小文字を区別しない

メモ

[7] MIME において使える CTE に著しい制限が加えられている (MIME'r の判断ミスだったんじゃないかな。今から考えれば。) ため、多くの媒体型は application/* にも対応するものがあります。