#?SuikaWiki/0.9 [1] message/* 媒体型は、各種プロトコルにおけるメッセージのための媒体型です。 しかし、 [[MIME]] において使える [[CTE]] に著しい制限が加えられている ([[MIME'r]] の判断ミスだったんじゃないかな。今から考えれば。) ため、多くの媒体型は [[application/*]] にも対応するものがあります。 ,[[message/coffeepot]] ,[[HTCPCP]] メッセージ ,"[[RFC2324]]" ,[[message/delivery-status]] ,配送状態報告 ,"[[[RFC1894]]], [IANAREG]" ,[[message/disposition-notification]] ,受信者動作報告 ,"[[[RFC2298]]], [IANAREG]" ,[[message/external-body]] ,外部実体の参照 ,"[[[MIME]]], [IANAREG]" ,[[message/x-gnu-rmail]] ,[[GNU]] [[rmail]] message ,[[message/http]] ,HTTP メッセージ ,"[[[HTTP]]], [IANAREG]" ,[[message/x-netnews]] ,->[CODE[application/news-transmission]] ,[[message/news]] ,->[CODE[application/news-transmission]] ,"[[[son-of-RFC1036]]] obsoleted by [[usefor-article]] , [IANAREG]" ,[[message/partial]] ,分割メッセージ ,"[[[MIME]]], [IANAREG]" ,[[message/rfc822]] ,RFC 822 メッセージ ,"[[[MIME]]], [IANAREG]" ,[[message/s-http]] ,[[S-HTTP]] メッセージ ,"[[[RFC2660]]], [IANAREG]" ,[[message/sip]] ,[[SIP]]メッセージ ,"[[[RFC3261]]], [IANAREG]" ,[[message/sipfrag]] ,[[SIP]] 断片 ,"[[[RFC3420]]] [DEL[(まだ I-D)]], [IANAREG]" [[IANA]] 登録簿 *RFC 2046 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" を、これを促進するために 定義します。とりわけ、 "message" の "rfc822" 亜型は、 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" の亜型を、転送または拒絶されたメッセージ用に定義する ことを提案します。しかし、転送または拒絶されたメッセージは、 最初の部分が制御や説明情報, 2番目の部分が "message/rfc822" で 転送または拒絶されたメッセージ, で構成されている多部分メッセージ として取り扱うことが出来ます。拒絶および転送メッセージをこの作法で構成する ことで、元のメッセージの型情報を保持し、受信者に正しく提示することが 出来ますから、これを強く推奨します。 >Subtypes of "message" often impose restrictions on what encodings are allowed. These restrictions are described in conjunction with each specific subtype. "message" の亜型にはしばしば、どの符号化が認められるかについての制限を 課されます。この制限はそれぞれの亜型の規定と共に説明します。 [INS[ 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 で説明されている 方法を使って記述出来ます。 ]INS] >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" 以外の型を使用するべきです。 [INS[ 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 [INS[ 2#3partial-param は 2*3 の誤りでしょう。 # だったらえらいこっちゃ。 ]INS] 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 ; 大文字・小文字を区別しない ]INS] *RFC の部分の License See [[RFCのライセンス]] *メモ