標準仕様書(TS) 　 　　　　　 TS X 0070:2004

序文

1. 導入

1.1 適用範囲

1.2 概要

MIMEのContent-Typeヘッダフィールド及びメディア型の機構は，拡張性をもつように注意深く設計されていて，メディア型／下位型の対の組及びそれらに関連するパラメタが，時間が経つにつれて，著しく増加していくことが期待される。 転送符号化及び"message/external-body"アクセス型の様な，多くの他のMIME機能は，時間が経つにつれて，新しい値を持つことになりそうである。 この様な値の組が，順序良く，上手な定義で，公的な方法で，開発されることを確実にするため，MIMEは，MIMEの多くの拡張性の領域のための中央の登録簿としてInternet Assigned Numbers Authority (IANA)を使った登録処理を設定する。 これらの領域の登録処理については，この標準仕様書(TS)と組をなすRFC 2048を原規定とする標準仕様書(TS)⁽¹⁾で規定する。

この標準仕様書(TS)の残りの部分では，七つの標準の初期の最上位メディア型を定義及び記述する。

2. 最上位メディア型の定義

最上位メディア型の定義は次からなる。

1. 型の名前及び記述。特定の型がその型に認定されるかどうかの基準を含む。
(1) a name and a description of the type, including criteria for whether a particular type would qualify under that type,
2. パラメタの名前及び定義。もしあれば，パラメタが必須又はオプションかを含め，そのパラメタがその型の下位型のすべてに対して定義されたものかどうか。
(2) the names and definitions of parameters, if any, which are defined for all subtypes of that type (including whether such parameters are required or optional),
3. 利用者エージェント及び／又はゲートウェイが，この型の未知の下位型をどのように扱うとよいか。
(3) how a user agent and/or gateway should handle unknown subtypes of this type,
4. もしあれば，この最上位の型の実体をゲートウェイするときに一般的に考慮すること。
(4) general considerations on gatewaying entities of this top-level type, if any, and
5. この最上位型の実体のためのcontent-transfer-encodings上の制限。

3. 初期の最上位メディア型の概要

五つの個別最上位メディア型は次のとおりとする。

1. text
   テキストによる情報。 とりわけ，下位型"plain"は，フォーマット命令又はどんな種類の指示も含まないプレーンテキストを表す。 プレーンテキストは"現状のまま"で表示されることが想定される。 指示された文字集合がサポートされていれば，テキストの完全な意味を得るために，特別なソフトウェアを必要としない。 その他の下位型は，アプリケーションソフトウェアがテキストの見映えを強調してよい形式の，フォーマット付テキストに使われるが，その場合は，内容の一般的な理解のためにそのようなソフトウェアを必要としてはならない。 ゆえに"text"の可能な下位型は，フォーマットを理解するソフトウェアに頼らなくても読むことが可能な，ワードプロセッサのフォーマットを含む。 特に単純で可搬性のある下位型は，RFC 1341で定義された"richtext"であり，RFC 1896では，"enriched"という名前で改定された。
(1) text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched".
2. image
   画像データ。 "image"は，情報を見るために，画像ディスプレイ，画像プリンタ又はファクス機器のような表示機器を必要とする。 広く使われている画像フォーマットであるJPEGのための初期の下位型を定義する。
(2) image -- image data. "Image" requires a display device (such as a graphical display, a graphics printer, or a FAX machine) to view the information. An initial subtype is defined for the widely-used image format JPEG. . subtypes are defined for two widely-used image formats, jpeg and gif.
3. audio
   音声データ。 "audio"は，内容を提示するために，スピーカ又は電話のような音声出力機器を必要とする。 この標準仕様書(TS)では，初期の下位型"basic"を定義する。
(3) audio -- audio data. "Audio" requires an audio output device (such as a speaker or a telephone) to "display" the contents. An initial subtype "basic" is defined in this document.
4. video
   映像データ。 "video"は，典型的には特別なハードウェアとソフトウェアを含め，映像を表示するための性能を必要とする。 この標準仕様書(TS)では，初期の下位型"mpeg"を定義する。
(4) video -- video data. "Video" requires the capability to display moving images, typically including specialized hardware and software. An initial subtype "mpeg" is defined in this document.
5. application
   典型的には，アプリケーションにより処理される，解釈されない2値データ又は情報。 解釈できない2値データの場合は，下位型"octet-stream"が使われ，この場合の最も単純な動作は情報をファイルに書き出すことを利用者に提供することである。 PostScriptのデータを転送するために，"PostScript"下位型も定義する。 その他に期待される"application"の使用法には，表計算，メールを利用したスケジュール管理システムのデータ，"能動的"（計算的）メッセージングのための言語，直接は読むことのできないワードプロセッサのフォーマットを含む。 いくつかの型のアプリケーションデータ，特に"application/PostScript"及びどんな形式であれ，能動的メッセージには，セキュリティに関する考慮が存在するかもしれないので注意すること。 これらの論点に関してはこの標準仕様書（TS)の後の方で論じる。
(5) application -- some other kind of data, typically either uninterpreted binary data or information to be processed by an application. The subtype "octet- stream" is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user. The "PostScript" subtype is also defined for the transport of PostScript material. Other expected uses for "application" include spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) messaging, and word processing formats that are not directly readable. Note that security considerations may exist for some types of application data, most notably "application/PostScript" and any form of active messaging. These issues are discussed later in this document.

二つの複合の最上位メディア型は次のとおりとする。

1. multipart
   複数の独立なデータ型の実体からなるデータ。 次の四つの下位型が初期に定義される。 基本的な"mixed"下位型は，はん（汎）用の混合の部分の組を指定する。 "alternative"は，同じデータを複数のフォーマットで表現する。 "parallel"は，部分を同時に見ることを想定する。 "digest"は，それぞれの部分が"message/rfc822"というデフォルトの型をもつマルチパート実体である。
(1) multipart -- data consisting of multiple entities of independent data types. Four subtypes are initially defined, including the basic "mixed" subtype specifying a generic mixed set of parts, "alternative" for representing the same data in multiple formats, "parallel" for parts intended to be viewed simultaneously, and "digest" for multipart entities in which each part has a default type of "message/rfc822". Freed & Borenstein Standards Track [Page 5] RFC 2046 Media Types November 1996
2. message
   カプセル化されたメッセージ。 メディア型"message"の本体は，それ自体で，ある種類のメッセージオブジェクトの全部又は一部とする。 このようなオブジェクトは，さらに，他の実体を含んでもよいし，含まなくてもよい。 カプセル化されたメッセージ自体がRFC 822メッセージである場合，下位型"rfc822"が使われる。 転送機能へ一つのメッセージとして渡すには大きすぎると考えられる場合，本体を細分化した転送を許容するため，部分的なRFC 822メッセージとして，下位型"partial"を定義する。 もう一つの下位型"external-body"は，外部のデータ源への参照により，大きい本体を指定するために，定義する。
(2) message -- an encapsulated message. A body of media type "message" is itself all or a portion of some kind of message object. Such objects may or may not in turn contain other entities. The "rfc822" subtype is used when the encapsulated content is itself an RFC 822 message. The "partial" subtype is defined for partial RFC 822 messages, to permit the fragmented transmission of bodies that are thought to be too large to be passed through transport facilities in one piece. Another subtype, "external-body", is defined for specifying large bodies by reference to an external data source.

ここで与えられたメディア型の一覧は，上記の機構によって，時間の経過と共に拡張され，下位型の組は大いに増えていくことが予期されることを心に留めておいたほうがよい。

4. 個別メディア型値

七つの初期のメディア型値のうちの五つは，個別の本体を参照する。 これらの型の内容は，MIME処理系では処理せず，非MIME機構で処理されなければならない。

4.1 textメディア型

"text"メディア型は，原則として形式的にテキストのデータを送ることを想定する。 特にプレーンテキストのためのはん（汎）用下位型である"text/plain"下位型を含め，"text"の下位型の本体テキストの文字集合を指示するために，"charset"パラメタを使ってよい。 プレーンテキストは，フォーマット命令，フォント属性指定，処理命令，解釈指示又は内容マーク付けを提供も許容もしない。 プレーンテキストは，行区切り又はページ区切りに割り込まれることはあるが，単純に線形な文字の列に見える。 プレーンテキストは，いくつかの文字をテキスト中の同じ位置に積み重ねることを，許してよい。 アラビア語やヘブライ語のようなスクリプト中でのプレーンテキストでは，逆筆記方向のテキストの区間の任意な混合を許す機能を含めてよい。

プレーンテキスト以上の，”リッチテキスト”として知られているようなものを表現するために，多くのフォーマットがある。 多くのそのような表現の興味深い特徴は，それらを解釈するソフトウェアがないときでさえ，ある程度は読めるということである。 そして，読めないデータを，画像，音声又は読めない形式で表現されたテキストとして，最上位で区別することは有用である。 適当な解釈ソフトウェアがない場合，"text"の下位型のデータを利用者に見せることは妥当であるが，ほとんどの場合非テキストデータを見せることは妥当でない。 フォーマットされたテキストデータは，"text"の下位型を使って表現されるのがよい。

4.1.1 行区切りの表現

全てのMIMEの"text"下位型の正準形式は，いつでも行区切りをCRLF列として表さなければならない。同様に，MIMEの"text"中のCRLFの発生は，行区切りを表さなければならない。CR及びLFを行区切り列以外に使うことも禁止される。

この規則は，フォーマット又は関係する文字集合にかかわらず適用する。

備考  本体が表示されるときの，行区切りの正しい解釈は，メディア型に依存する。 特に，"text/plain"本体を表示するとき，行区切りを新しい行への移動として扱うことは適当だが， "text/enriched" （RFC 1896を参照）のような"text"の他の下位型に対しては，この扱いは，実際に誤りである。 同様に，表示操作中行区切りを加えるのがよいかどうかも，メディア型の機能である。 "text/enriched"の正しい表示には適当な行区切りの付加を要求するが，"text/plain"を正しく表示するためには行区切りは加える必要がない方がよい。

備考  いくつかのプロトコルは最大行長を定義する。 例えば，SMTP [RFC-821]では，次のCRLF列の前に最大998オクテットを許容する。 このようなプロトコルによって転送されるためには，CRLF列なしに長すぎる区間を含むデータは，適当なcontent-transfer-encodingで符号化されなければならない。

4.1.2 charsetパラメタ

"text/plain"データのためにContent-Typeフィールド中に指定されてよい重要なパラメタは，文字集合である。これは"charset"パラメタで，次のように指定される。

Content-type: text/plain; charset=iso-8859-1

その他いくつかのパラメタ値とは違って，charsetパラメタの値は，大文字小文字を区別しない。 charsetパラメタがないときに仮定されなければならない，デフォルトの文字集合は，US-ASCIIとする。

"text"の将来のどんな下位型の仕様も，"charset"パラメタも利用するかどうかを規定しなければならず，さらに場合によってはその値を制限してもよい。 "text/plain"以外の"text"の下位型では，"charset"パラメタのセマンティクスは，"text/plain"のためにここで指定されたものと同一となるように定義したほうがよい。すなわち，本体は，すべて，与えられた文字集合内の文字からなる。 特に，将来の"text"の下位型を定義する者は，下位型の定義における複数オクテット文字集合の関わり合いについて，よく注意したほうがよい。

"text"の下位型の文字集合パラメタは，TR X 0069で定義される"文字集合"のとおりに，文字集合の名前を与える。 4.1.1で詳しく規定している行区切りに関する規則も，遵守されなければならない。 これらの規則に適合しない定義をもつ文字集合は，MIMEの"text"の下位型で使うことはできない。

あらかじめ定義された文字集合名の初期の一覧は，この箇条の最後にある。 追加の文字集合はIANAによって登録してよい。

"text"の下位型の他のメディア型は，CRLF又は行区切りの制限を排除して，ここで定義されたcharsetパラメタを使うことを選んでもよい。 したがって，TR X 0069の"文字集合"の一般的な定義に適合する，すべての文字集合は，MIMEでの使用のために登録できる。

もし，指定された文字集合が8ビット文字を含み，このような文字が本体に使われたら，SMTP [RFC-821]のようないくつかのメール転送プロトコルを通した本体の転送のために，Content-Transfer-Encodingヘッダフィールド及びデータへの対応する符号化が，要求されることに注意すること。

デフォルトの文字集合US-ASCIIは，過去にはいくつかの混乱とあいまい性があった。 定義におけるいくつかのあいまい性だけでなく，実践において広い多様性があった。 このようなあいまい性と多様性を将来なくすため，新しい利用者エージェントは，"Content-Type"ヘッダフィールドのメディア型のパラメタとして，明示的に文字集合を指定することを強く推奨する。 "US-ASCII"は，任意の7ビット文字集合を指すのでなく，本体中の全てのオクテットは，US-ASCII文字集合に従った文字として解釈されなければならない。 ISO 646 [ISO-646]の，国内版及びアプリケーション指向版は，通常は，US-ASCIIと同一ではなく，インターネットメールにおけるそれらの使用は，やめたほうがよいことは明らかである。 この標準仕様書(TS)からISO 646文字集合を省くことは，慎重に考えられたことである。 文字集合名"US-ASCII"は，ANSI X3.4-1986 [US-ASCII]で定義される文字集合を，明示的に参照する。 ISO 646の1991年版である新しい国際参照版(IRV)は，US-ASCIIと同一である。 文字集合名"ASCII"は予約済みであり，どんな目的にも使ってはならない。

備考  RFC 821は，明示的に"ASCII"を指定していて，米国規格の初期の版を参照している。 メディア型及び文字集合を指定する目的の一つが，送信者が解釈される符号化されたメッセージをどのように意図したかを，受信者があいまい性なく決定することを許すことである限りは， デフォルトとしての"厳密なASCII"以外のどんなものも仮定することは，今送信されているメッセージのセマンティクスへの意図しない及び互換性のない変更の危険を起こすであろう。 US-ASCII及び1991 IRV以外のISO 646の他の版に従って符号化された文字を含むメッセージ， 又は，例えばISO 2022の符号切り換え手続きは，8ビット又は複数オクテット文字符号化と同様， MIMEと矛盾しない適切な文字集合指定を使わなければならないことも，示唆する。

完全なUS-ASCII文字集合は，ANSI X3.4-1986に列挙されている。 改行を識別する組合せCRLF(US-ASCII値の13及び10)以外は，DELを含む制御文字(0-31, 127)に，定義された意味は何もないことに注意すること。 次の二つの文字は，広く使われている事実上の意味がある。 FF(12)は"続きのテキストは新しいページの先頭から始める"ことをしばしば意味する。TAB又はHT(9)は，いつもではないけれども，"初めのカラムをカラム0と数えて，現在のカラムより後の次の可能な8の倍数のカラム番号へカーソルを動かす"ことを意味する。 これらの規約とは別に，本体中での制御文字又はDELの使用は，次のどちらかで生じる。

1. "plain"以外の下位型が，いくつかの追加の意味を具体的に割り当てる場合。 (1) because a subtype of text other than "plain" specifically assigns some additional meaning, or
   
   又は
   
   
2. 送信者と受信者の間の私的な合意の状況の場合。 このような私的な合意は，やめたほうがよく，この標準仕様書(TS)で規定する他の機能におきかえたほうがよい。
(2) within the context of a private agreement between the sender and recipient. Such private agreements are discouraged and should be replaced by the other capabilities of this document.

備考  US-ASCII以外にも多くの異なった文字集合が存在する。 部分的又は全体的に重なる文字集合がたくさんあることはよいことではない。 インターネットメールで，世界中の言語の全てを表現できて万国共通に使える，単一の文字集合が好ましい。 しかし，多くのコミュニティでの実在の実践は，近い将来のうちには複数の文字集合を使い続けることに向いている。 したがって，この標準仕様書(TS)では少数の標準的な文字集合を定義する。

定義するcharset値は次とする。

1. US-ASCII
   ANSI X3.4-1986 [US-ASCII]で定義される文字集合。
(1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
2. ISO-8859-X
   "X"の部分は，ISO-8859 [ISO-8859]の部分のために，必要に応じて置換する。 インターネットメールで指定された文字集合である，それら8859置換の方を優先し，ISO 646文字集合はわざと省いていることを注記しておく。 この標準仕様書(TS)の原規定のRFC 2046が公表された時点では，"X"の値として数字の1から10が合法である。
(2) ISO-8859-X -- where "X" is to be replaced, as necessary, for the parts of ISO-8859 [ISO-8859]. Note that the ISO 646 character sets have deliberately been omitted in favor of their 8859 replacements, which are the designated character sets for Internet mail. As of the publication of this document, the legitimate values for "X" are the digits 1 through 10.

128-159の範囲の文字は，ISO-8859-Xでは，指定された意味をもたない。 ISO-8859-Xの128より小さい値の文字は，US-ASCIIと同じ指定された意味をもつ。

ISO 8859の第6部（ラテンアルファベット及びアラビアアルファベット）及び第8部（ラテンアルファベット及びヘブライアルファベット）は，左から右への普通の筆記方向の文字及び右から左への反対の筆記方向の文字を両方含むが，双方向テキストを表現するための正準的な順序付け方法は定義していない。 しかし，"ISO-8859-6"及び"ISO-8859-8"のcharset値は，視覚的な方法が使われることを指定する [RFC-1556]。

これらすべての文字集合は，シフト機能又はエスケープ機能なしの，純粋な7ビット又は8ビット集合として使うものとする。 これら文字集合のシフト及びエスケープシーケンスの意味は定義しない。

上記で規定された文字集合は，MIMEの原案作成中比較的自由なものであった。 この標準仕様書(TS)は，US-ASCII以外の特定のどんな文字集合の使用も支持せず，世界文字集合の将来の進化が不明確なままであることを認識する。

US-ASCII以外の文字集合の使用する場合は必ずContent-Typeフィールドに明示的に指定されなければならないことに注意すること。

上記で定義された以外のどんな文字集合名も，公式の仕様の出版及びIANAでの登録，又は，私的な合意によるものでなければならない。私的な合意により使う場合は，"X-"で始まらなければならない。

実装者は，絶対的に必要な場合を除き，新しい文字集合を定義しないほうがよい。

"charset"パラメタは，主としてテキストデータのために定義されていて，そのために，この箇条に記述されている。 しかし，何らかの目的で，同じ構文と値が使われるほうがよいときには，非テキストデータでもcharset値を指定したい場合が考えられる。

一般的にいって，文書作成ソフトウェアは，可能な限りいつも”一番小さい共通の”文字集合を使用するのがよい。 例えば，本体がUS-ASCII文字だけを含む場合，すべてのISO-8859ファミリと同様にUS-ASCIIのスーパセットであるISO-8859-1とするのではなく，US-ASCII文字集合として，マーク付けするのがよい。 もっと一般的にいえば，広く使われている文字集合がもう一つの広く使われている文字集合のサブセットであった場合，本体が広く使われているサブセットの文字だけを含むならば，それはサブセットが使われているとラベル付けするのがよい。 これは，受信者が結果の実体を正しく見ることができる機会を，増やすことになる。

4.1.3 plain下位型

最も単純で最も重要な"text"の下位型は"plain"である。 これは，フォーマット命令又はフォーマット指示を含まない，プレーンテキストを示す。 プレーンテキストは，"そのまま"表示されることが意図される。 すなわち，適正な表示のために，組み込まれたフォーマット命令，フォント属性指定，処理命令，解釈指示又は内容マーク付けの解釈を必要としないほうがよい。 インターネットメールのためのデフォルトのメディア型"text/plain; charset=us-ascii"は，既存のインターネット実践を記述する。 すなわち，これはRFC 822で定義される本体の型である。

他の"text"の下位型は，この標準仕様書(TS)では，定義されない。

4.1.4 認識されない下位型

"text"の認識されない下位型は，MIME実装がcharsetをどう処理するかを知っている限りは，"plain"下位型として扱うのがよい。 認識されないcharsetも指定している，認識されない下位型は，"application/octet-stream"として扱うのがよい。

4.2 imageメディア型

メディア型"image"は，本体が画像を含むことを指示する。 下位型は，特定の画像フォーマットを，名前付けする。 これらの名前は，大文字小文字を区別しない。 初期の下位型は，JFIF符号化[JPEG]を使ったJPEGフォーマットのための，"jpeg"とする。

"image"の下位型の一覧は，排他的でもすべてでもなく，ここで与えられ，これ以上の型は，RFC 2048を原規定とする標準仕様書(TS)⁽¹⁾に記述されている とおりに，IANAで登録されて，増えていくことが期待される。

"image"の認識されない下位型は，少なくとも"application/octet-stream"として扱うのがよい。 実装は，安全で頑健なはん（汎）用画像表示アプリケーションが利用可能ならば，オプションで"image"の下位型をアプリケーションに渡してもよい。

備考  このようにしてはん（汎）用画像表示アプリケーションは，アプリケーションでサポートする最も危険なセキュリティ上の問題を受け継ぐ。

4.3 audioメディア型

メディア型"audio"は，本体が音声データを含むことを示す。 計算機で使う理想的な音声のフォーマットについては，いまだに合意が得られていないが，相互運用可能な振舞いを供給することの出来るフォーマットの強い必要性はある。

初期の下位型"basic"は，絶対的に一番小さい共通の音声フォーマットを提供することによって，この要求に答えるために規定された。 より高品質及び／又はより狭帯域音声のためのより高度なフォーマットは，今後の文書で定義されることが期待される。

"audio/basic"下位型の内容は，標本化周波数8000Hzで，8ビットのISDNの μ則[PCM]により符号化された，単一チャネル音声とする。

"audio"の認識されない下位型は，最低でも，"application/octet-stream"として扱うのがよい。 実装は，オプションで，明確には認識しない"audio"の下位型を，頑健な一般用途音声再生アプリケーションへ，そのようなアプリケーションが利用可能であれば，渡してよい。

4.4 videoメディア型

メディア型"video"は，本体が，時間につれて変動する画像を含むことを示す。 用語'video'は，特定の技術やフォーマットへの参照ではなく，最も一般的な感覚で使われ， それは小さく符号化されるアニメーションの描画のような下位型を排除することを意味しない。 下位型"mpeg"はMPEG標準に従って符号化された映像を参照する。

この標準仕様書(TS)では，一般的には単一の本体に複数のメディアを混ぜることを強く非推奨とするが， 多くのいわゆる映像フォーマットが同期した音声の表現を含むことが認識され， これは"video"の下位型として明確に許される。

"video"の認識されない下位型は，少なくとも，"application/octet-stream"として扱うのがよい。 実装は，オプションで，明確には認識しない"video"の下位型を，頑健な一般用途映像再生アプリケーションへ，そのようなアプリケーションが利用可能であれば，渡してよい。

4.5 applicationメディア型

"application"メディア型は，他の種別には合致しない個別データ，特にいくつかの型のアプリケーションプログラムにより処理されるデータのために使われる。 これは，利用者により見えるようになる前に又は使えるようになる前に，アプリケーションにより処理されなければならない情報とする。 "application"メディア型の想定される使われ方は，ファイル転送，表計算，メールによるスケジュール管理システムのデータ，"能動的"（計算的）内容の言語を含む。 最後のものは，実装者によって理解されなければならないセキュリティ上の問題を起こし得，"application/PostScript"メディア型の議論で深く考える。

例えば，会議スケジューラソフトウェアは，提案の会議日程についての情報の標準的な表現を，定義するかもしれない。 知的な利用者エージェントは，利用者に対話形式で案内するために，この情報を使うかもしれないし，この対話に基づき追加のデータを送るかもしれない。 もっと一般的には，適切に特化した言語によるプログラムが遠隔地に転送され，受信者の環境上で自動的に実行される，多くの"能動的"メッセージング言語が開発されている。

このようなアプリケーションは，"application"メディア型の下位型として定義されてよい。 この標準仕様書(TS)では二つの下位型，octet-stream及びPostScriptを定義する。

"application"の下位型は，データを想定する，アプリケーションの名前であるか又は名前の一部を含むことが多い。 しかし，このこことは，"application"の下位型として，任意のアプリケーションプログラムの名前を使ってよいことは，意味しない。

4.5.1 octet-stream下位型

"octet-stream"下位型は，本体が任意の2値データを含むことを示すのに使う。 現在定義されているパラメタの組は，次の二つである。

1. TYPE
   2値データの一般的な型又は分類。 これは，何らかの自動処理のためではなく，人間の受信者のための情報として意図される。
(1) TYPE -- the general type or category of binary data. This is intended as information for the human recipient rather than for any automatic processing.
2. PADDING
   含まれた8ビットバイト指向のデータを作るために実際の内容を構成するビットストリームに付加されたパディングのビット数。 これは，ビットの総数が8の倍数でないときに，本体中にビットストリームを入れるのに有用である。
(2) PADDING -- the number of bits of padding that were appended to the bit-stream comprising the actual contents to produce the enclosed 8bit byte-oriented data. This is useful for enclosing a bit-stream in a body when the total number of bits is not a multiple of 8.

これらのどちらのパラメタもオプションとする。

追加のパラメタ"CONVERSIONS"がRFC 1341で定義されたが，その後削除された。 RFC 1341は，データをファイルに書き込むときに使われる，推奨されるファイル名のために"NAME"パラメタを使うことも定義している。 これは，後続するRFCで定義される，別の"Content-Disposition"ヘッダフィールドを見越して，非推奨とした。

"aplication/octet-stream"実体を受け取ったときに，実装の推奨される動作は，Content-Transfer-Encodingを解除して，単純にデータをファイルに書き出すか，又は，多分利用者が指定した処理への入力として使うことである。

悪意のあるプログラムを転送する危険をなくすために，Content-Typeパラメタ（例えば，"interpreter="パラメタ）で名前付けされた任意のプログラムが見つかったら，メッセージ本体を入力として使って実行するという，経路探索機構を実装しないことと強く推奨する。

4.5.2 PostScript下位型

"application/postscript"メディア型は，PostScriptのプログラムを示す。 現在，PostScript言語の二つの種類が許容される。 オリジナルのレベル１は[POSTSCRIPT]に記述され，より新しいレベル２[POSTSCRIPT2]に記述されている。

PostScriptはAdobe Systems Inc.の登録商標である。 MIMEメディア型"application/postscript"の使用は，登録商標及びそれに伴う一切の権利を認識することを暗示する。

PostScript言語定義は，与えられたプログラムが使用する，特定の言語の内部的なラベル付けのための機能を，提供する。 このPostScript文書構造化規約又はDSC(document structuring conventions)と呼ばれるラベル付けは，とても一般的であって，言語レベルだけでない十分に多くの情報を提供する。 文書構造化規約の使用は，要求はされないが，相互運用性のための補助として，強く推奨される。 適格な構造化規約を欠いた文書は，与えられた環境で動作するかどうかを見るための検証ができない。 このようにして，いくつかのシステムは，最悪を仮定してもよく，構造化されていない文書を処理することを拒否する。

一般用途のPostScriptインタプリタの実行は，深刻なセキュリティ上の危険を伴い，実装者は，単純に"規格品の"インタプリタにPostScriptの本体を送ることは，しないほうがよい。 典型的なプリンタ環境では害を与える可能性が大いに制限されていて，通常はPostScriptをプリンタに送ることは安全だが， 実装者は，PostScript本体の対話的表示をMIME解読器に追加する前に，次の全てを考慮したほうがよい。

この箇条の残りでは，多分すべてではないけれども，PostScript実体の転送に伴う，可能性のある問題についての概要を述べる。

1. PostScript言語の危険な操作は，PostScriptオペレータ"deletefile", "renamefile", "filenameforall"及び"file"を含むが，これだけとは限らない。 "file"は，標準入力又は標準出力以外の何かに適用するときだけ，危険である。 実装は，追加の非標準のファイルオペレータを定義するかも知れず，それらはセキュリティ上の脅威をを与えるかもしれない。 ワイルドカードファイル検索オペレータの"filenameforall"は，一見したところでは，無害に見えるかもしれない。 しかし，このオペレータは，受信者が，どのファイルにアクセスしているかについての情報を暴露する可能性があり，この情報自体が要注意なものである。 メッセージの送信者は，危険な可能性があるファイルオペレータを，セキュリティを考慮したPostScript実装ではこれらのオペレータは使えないであろうから，避けたほうがよい。 メッセージを受信及び表誦するソフトウェアは，全ての危険な可能性のあるファイルオペレータを完全に無効にするか，又は，これらの操作を行えるなんらかの特別な権威を委任しないように，特別の注意をするほうがよい。 これらのオペレータは，PostScript文書を解釈するとき，外部機関によって見られたほうがよい。 このような無効化及び／又は検証は，PostScript言語自体の及ぶ範囲の外側で，完全に行った方がよい。 これらのオペレータの完全機能版を再有効化するための方法が存在しないことを保証するように，特別な注意を払ったほうがよい。
(1) Dangerous operations in the PostScript language include, but may not be limited to, the PostScript operators "deletefile", "renamefile", "filenameforall", and "file". "File" is only dangerous when applied to something other than standard input or output. Implementations may also define additional nonstandard file operators; these may also pose a threat to security. "Filenameforall", the wildcard file search operator, may appear at first glance to be harmless. Note, however, that this operator has the potential to reveal information about what files the recipient has access to, and this information may itself be sensitive. Message senders should avoid the use of potentially dangerous file operators, since these operators are quite likely to be unavailable in secure PostScript implementations. Message receiving and displaying software should either completely disable all potentially dangerous file operators or take special care not to delegate any special authority to their operation. These operators should be viewed as being done by an outside agency when interpreting PostScript documents. Such disabling and/or checking should be done completely outside of the reach of the PostScript language itself; care should be taken to insure that no method exists for re-enabling full- function versions of these operators.
2. PostScript言語は，通常のインタプリタ又はサーバのループから抜け出す機能を提供している。 この"外部の"環境でなされる変更は，慣例上文書間でも保持され，場合によっては半永久的に不揮発性メモリに保持されるかもしれない。 インタプリタのループから抜け出すことに関連するオペレータは，後続の文書処理に干渉する可能性がある。 このようにして，これらの抑制されない使用は，サービス拒絶の脅威の構成要素となる。 インタプリタのループを抜け出すPostScriptオペレータは，これらだけには限らないが，exitserver及びstartjobオペレータである。 セキュリティを考慮したPostScript実装では，インタプリタのループを抜け出す能力は多分利用不可能だから，メッセージを送るソフトウェアは，動作するのにインタプリタのループを抜け出すことに依存するPostScriptは，生成しないほうがよい。 メッセージを受信し表示するソフトウェアは，"startjob"オペレータ又は"exitserver"オペレータを排除するか又は無効にすることによって，PostScript環境へ保持される変更を行える能力を，完全に無効にしたほうがよい。 もし，これらの操作が，排除されるか完全に無効に出来ない場合，少なくとも，これらに関連する想像されにくいパスワード値を設定したほうがよい。
(2) The PostScript language provides facilities for exiting the normal interpreter, or server, loop. Changes made in this "outer" environment are customarily retained across documents, and may in some cases be retained semipermanently in nonvolatile memory. The operators associated with exiting the interpreter loop have the potential to interfere with subsequent document processing. As such, their unrestrained use constitutes a threat of service denial. PostScript operators that exit the interpreter loop include, but may not be limited to, the exitserver and startjob operators. Message sending software should not generate PostScript that depends on exiting the interpreter loop to operate, since the ability to exit will probably be unavailable in secure PostScript implementations. Message receiving and displaying software should completely disable the ability to make retained changes to the PostScript environment by eliminating or disabling the "startjob" and "exitserver" operations. If these operations cannot be eliminated or completely disabled the password associated with them should at least be set to a hard- to-guess value.
3. PostScriptは，システム全体及び機器特有のパラメタを設定するオペレータを提供する。 これらのパラメタ設定は，ジョブ間で保持されるかもしれず，インタプリタの正しい処理への脅威となる可能性がある。 システムパラメタ及び機器パラメタを設定するPostScriptオペレータは，これらだけとは限らないが，"setsysemparams"オペレータ及び"setdevparams"オペレータである。 メッセージ送信ソフトウェアは，正しく動作するためにシステムパラメタ及び機器パラメタを設定することに依存するPostScriptを生成しないほうがよい。 これらのパラメタを設定する機能は，セキュリティを考慮したPostScript実装では，多分利用不可であろう。 もし，これらの操作が，排除されるか完全に無効に出来ない場合，少なくとも，これらに関連する想像されにくいパスワード値を設定したほうがよい。
(3) PostScript provides operators for setting system-wide and device-specific parameters. These parameter settings may be retained across jobs and may potentially pose a threat to the correct operation of the interpreter. The PostScript operators that set system and device parameters include, but may not be limited to, the "setsystemparams" and "setdevparams" operators. Message sending software should not generate PostScript that depends on the setting of system or device parameters to operate correctly. The ability to set these parameters will probably be unavailable in secure PostScript implementations. Message receiving and displaying software should disable the ability to change system and device parameters. If these operators cannot be completely disabled the password associated with them should at least be set to a hard-to-guess value.
4. いくつかのPostScript実装は，機械語を直接ロードし実行する，非標準の機能を提供する。 このような機能は，多くの悪用への道を開いていることが明白である。 メッセージ送信ソフトウェアは，このような機能の使用を生成しないほうがよい。 完全にハードウェア固有であるほか，これらも，PostScriptのセキュリティを考慮した実装では，おそらく使用不可である。 メッセージ受信及び表示ソフトウェアは，このようなオペレータが存在する場合，それらを使用することを許さないほうがよい。
(4) Some PostScript implementations provide nonstandard facilities for the direct loading and execution of machine code. Such facilities are quite obviously open to substantial abuse. Message sending software should not make use of such features. Besides being totally hardware-specific, they are also likely to be unavailable in secure implementations of PostScript. Message receiving and displaying software should not allow such operators to be used if they exist.
5. PostScriptは拡張性のある言語であって，ほとんどというほどではないにしろその多くの実装は，たくさんの固有の拡張を提供する。 この標準仕様書(TS)は，このような拡張については，未知の要素を構成するので，明示的には論じない。 メッセージ送信ソフトウェアは，非標準拡張の使用を生成しないほうがよい。 メッセージ受信及び表示ソフトウェアは，どの非標準のPostScriptオペレータもセキュリティを考慮されて，どんな種類の脅威も呈さないことを，確認したほうがよい。
(5) PostScript is an extensible language, and many, if not most, implementations of it provide a number of their own extensions. This document does not deal with such extensions explicitly since they constitute an unknown factor. Message sending software should not make use of nonstandard extensions; they are likely to be missing from some implementations. Message receiving and displaying software should make sure that any nonstandard PostScript operators are secure and don't present any kind of threat.
6. 幾つものシステム資源を大量に消費するPostScriptを書くことができる。無限に繰り返すPostScriptを書くこともできる。 どちらのタイプのプログラムも，疑うことのない受信者に送られたならば，障害を引き起こす可能性がある。 メッセージ送信ソフトウェアは，このような反社会的なプログラムの組立て又は拡散を避けたほうがよい。 メッセージ受信及び表示ソフトウェアは，ある程度の時間が経過したら，処理を中断する適当な機構を提供したほうがよい。 さらに，PostScriptインタプリタは，与えられたシステム資源のある程度の量だけを消費するように制限したほうがよい。
(6) It is possible to write PostScript that consumes huge amounts of various system resources. It is also possible to write PostScript programs that loop indefinitely. Both types of programs have the potential to cause damage if sent to unsuspecting recipients. Message-sending software should avoid the construction and dissemination of such programs, which is antisocial. Message receiving and displaying software should provide appropriate mechanisms to abort processing after a reasonable amount of time has elapsed. In addition, PostScript interpreters should be limited to the consumption of only a reasonable amount of any given system resource.
7. 幾つもの形式でPostScriptの中に2値の情報を含むことができる。 これは，全てのPostScriptインタプリタでサポートされていないという理由及びMIME Content-Tranfer-Encodingの使用を著しく複雑にするという理由で， インターネットメールでの使用は推奨されない。 このような2値なしでは，PostScriptは，典型的には，行指向データとして見られてよい。 2値及び行指向データが単一のPostScriptデータストリームに混ざっていた場合，CRLF列の振舞いは非常に問題となる。
(7) It is possible to include raw binary information inside PostScript in various forms. This is not recommended for use in Internet mail, both because it is not supported by all PostScript interpreters and because it significantly complicates the use of a MIME Content- Transfer-Encoding. (Without such binary, PostScript may typically be viewed as line-oriented data. The treatment of CRLF sequences becomes extremely problematic if binary and line-oriented data are mixed in a single Postscript data stream.)
8. 最後に，いくつかのPostScriptインタプリタには，受信者のシステムへの認証されないアクセスを得ることができるかもしれない，不具合が存在するかもしれない。 この可能性とは別に，このような不具合が発見された場合に，タイムリーに修正することのほかには，これを防ぐためにとる特定の措置はない。
(8) Finally, bugs may exist in some PostScript interpreters which could possibly be exploited to gain unauthorized access to a recipient's system. Apart from noting this possibility, there is no specific action to take to prevent this, apart from the timely correction of such bugs if any are found.

4.5.3 その他のapplicationの下位型

将来には，多くの他の"application"の下位型が定義されることが期待される。 MIME実装は，最低限，認識されない下位型を"application/octet-stream"として取り扱わなければならない。

5. 複合メディア型値

5.1 multipartメディア型値

5.1.1 共通構文

この箇条では，"multipart"の下位型のための共通構文を定義する。 全ての"multipart"の下位型は，この構文を使わなければならない。 マルチパートメッセージの単純な例も，この箇条で示す。 もっと複雑なマルチパートメッセージの例は，RFC 2049を原規定とする標準仕様書(TS)⁽¹⁾で与えられる。

マルチパート実体のためのContent-Typeフィールドは，一つのパラメタ"boundary"を要求する。 境界区切り子行は，二つのハイフン文字（"-"，10進値の45）に後続してContent-Typeヘッダフィールドからの境界パラメタ値があり，オプションで線形空白があり，終わりのCRLFで構成される行として，定義される。

備考  ハイフンは，以前のメッセージをカプセル化するRFC 934の方法と大まかな互換性のため，及び，いくつかの実装で検索を容易にするためである。 しかし，マルチパートメッセージは，RFC 934のカプセル化とは，完全には互換性がないこと，特に，ハイフンで始まる埋込み行のためのRFC 934引用規約には従っていないことに注意したほうがよい。 後者は，それぞれの引用のレベルで行の成長を引き起こすから，RFC 934の上にこの機構が選ばれた。 SMTP実装が時々長い行を折り返すという事実と，この成長の結合は，RFC 934の機構を深い入れ子のマルチパート構造付けが望まれるイベントにおいての使用を不適切なものにしている。

実装者への警告
Content-Typeフィールドのパラメタのための文法は，Content-type行上の引用で，境界パラメタ値を囲うのにしばしば必要となることなどである。 これはいつも必要ではないが，支障もない。 実装者は，不正なContent-typeフィールドが生成されないように，注意深く文法を学習した方がよい。 ゆえに，典型的な"multipart" Content-Typeヘッダフィールドは，次のように見える。
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
しかし，次は，正しくない。
Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
なぜならばコロン（：）があるからであり，かわりに，次のようにあらわさなければならない。
Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"

このContent-Type値は，内容が一つ以上の部分からなり，それぞれは，ヘッダ領域が完全に空であることを許すこと及びそれぞれの部分が次に示す行に先行されること以外は，RFC 822メッセージと構文上，同一の構造とする。
--gc0pJq0M:08jU534c0p

境界区切り子は，行の先頭，すなわち，CRLFの直後になければならず，最初のCRLFは，先行する部分の一部ではなく，境界区切り行につけられたものと考える。 境界は，0文字以上の線形空白に後続されてよく，別のCRLF及び次の部分のヘッダフィールドか又は二つのCRLF（この場合，次の部分にヘッダフィールドがない）のどちらかで終了する。 Content-Typeフィールドがない場合，"multipart/digest"中の"message/rfc822"，そうでない場合は，"text/plain"とみなす。

参考  境界区切り行に先行するCRLFは，概念的に境界に付いているので，CRLF（改行）で終わらない部分をもつことができる。 だから，改行で終わる事が想定されなければならない本体部分は，境界区切り行に先行する二つのCRLFをもたなければならず，1番目は先行する本体部分のもの，2番目はカプセル化した境界の部分のものである。

境界区切り子は，カプセル化されたデータ中にあらわれてはならず，二つの先行するハイフンを含まずに，70文字より長くてはならない。

最後の本体部分に続く境界区切り子行は，それ以上本体部分が続かないことを示す，区別された区切り子とする。 このような境界行は，それ以前の区切り行と同一のものに，境界パラメタ値の後ろに二つのハイフンを加えたものとする。
--gc0pJq0M:08jU534c0p--

備考  境界文字列の比較は，それぞれの候補行の始めから境界値を比較しなければならない。 候補行全体の完全な一致は要求されない。 CRLFに後続して境界が完全に現れるだけで十分とする。

一番目の境界区切り行の前及び最後の境界区切り行の後に，追加の情報のための場所がある。 これらの領域は，一般的には，空白のままであり，実装者は，一番目の境界区切り行の前及び最後の境界区切り行の後に現れるどんなものも無視しなければならない。

備考  これらの"まえがき"及び"あとがき"の領域は，これらの部分の適切な型付けがないこと及びゲートウェイ，特にX.400ゲートウェイにおいてこれらの領域をどう処理するか明確なセマンティクスがないことから，一般的には使われない。 しかし，まえがき領域を空白のままにしておくのではなく，MIME適合のソフトウェアでは無視されるので，多くのMIME実装は，MIME以前のソフトウェアでメッセージを読む受信者に，説明的な備考を挿入する便利な場所でなることがわかる。

備考  境界区切り子は，カプセル化された本体部分中には現れてはならないから，利用者エージェントは，一意の境界パラメタ値を選ぶために注意をしなければならない。 上記の例で境界パラメタ値は，データをプレスキャンすることもなくカプセル化されたデータ中にすでに存在する可能性の非常に低い境界区切り子を生成するように設計されたアルゴリズムの結果であり得た。 代替のアルゴリズムは，古い利用者エージェントでの受信者に，もっと”読みやすい”境界区切り子をもたらしうるが，境界区切り子が組み込まれた部分の，ある行の先頭に現れる可能性があることに，特に注意する必要がある。 最も簡単な境界区切り子行は，"---"のようなものであり，それの終了の区切り子行は"-----"のようなものである。

とても簡単な例として，次のマルチパートメッセージは二つの部分をもち，両方ともプレーンテキストで，一つは明示的に型付けされ，もう一つは暗黙的に型付けされる。

　　From: Nathaniel Borenstein 
     To: Ned Freed 
     Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
     Subject: Sample message
     MIME-Version: 1.0
     Content-type: multipart/mixed; boundary="simple boundary"

     これはまえがきである。これは作成エージェントが非MIME適合リーダへの
　　 説明的備考を含めるための手軽な場所であるが，これは無視される。

     --simple boundary

     これは暗黙的にプレーンUS-ASCIIテキストに型付けされる。
　　これは行区切りでは終わらない。

     --simple boundary
     Content-type: text/plain; charset=us-ascii

     これは明示的にプレーンUS-ASCIIテキストに型付けされる。
     これは行区切りで終わる。

     --simple boundary--

     これはあとがきである。これも無視される。

別の"multipart"実体中の本体部分の中に"multipart"メディア型を使用することは，明示的に許可される。このような場合，明白な理由で，それぞれの入れ子になった"multipart"実体は異なる境界区切り子を使うことを保証するように，注意を払わなければならない。 入れ子の"multipart"実体の例は，RFC 2049を原規定とする標準仕様書(TS)⁽¹⁾を参照するとよい。

"multipart"メディア型を単一の本体部分だけで使用することは，ある文脈には便利である場合もあり，明示的に許される。

備考  "multipart"メディア型を単一の本体部分で使用することは，非テキストメディア型を送るのに便利であることを経験が示している。 それは，復号の指示を含める場所としてのまえがきを提供する利点をもつ。 さらに，多くのSMTPゲートウェイは，MIMEヘッダを動かすか又は取り除き，そして，賢いMIME復号器は，Content-Typeヘッダがない場合でもマルチパート境界でよい予測をすることができ，そのためメッセージを成功裡に復号する。

"multipart"メディア型の唯一の必須の大域パラメタは，境界パラメタとし，境界パラメタは，メールゲートウェイを通して非常に耐性のあるものとして知られる文字の組からの，１から70文字からなり，空白で終わってはならない。 もし，境界区切り子行が空白で終わっている場合，その空白はゲートウェイによって加えられたものとみなされ，削除されなければならない。 次のBNFにより，これを形式定義する。

     boundary := 0*69 bcharsnospace

     bchars := bcharsnospace / " "

     bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      "/" / ":" / "=" / "?"

   全般的に，"multipart"実体の本体は，次のように規定してよい。

     dash-boundary := "--" boundary
                      ; Content-Typeフィールドの境界
                      ; 値からとられた境界
                      ; 

     multipart-body := [preamble CRLF]
                       dash-boundary transport-padding CRLF
                       body-part *encapsulation
                       close-delimiter transport-padding
                       [CRLF epilogue]

     transport-padding := *LWSP-char
                          ; 作成者は長さゼロでないトランスポートパディングを
　　　　　　　　　　　　　; 生成してはならないが，
                          ; 受信者はメッセージトランスポートによって
　　　　　　　　　　　　　; 加えられたパディングを処理できなけらばならない。

     encapsulation := delimiter transport-padding
                      CRLF body-part

     delimiter := CRLF dash-boundary

     close-delimiter := delimiter "--"

     preamble := discard-text

     epilogue := discard-text

     discard-text := *(*text CRLF) *text
                     ; 無視又は削除されてよい。

     body-part := MIME-part-headers [CRLF *OCTET]
                  ; 本体部分の行は指定されたダッシュ境界で
                  ; 始まってはならず，区切り子は本体部分の
                  ; どこにも現れてはならない。
                  ; 文中に記述されているとおり，本体部分の
                  ; セマンティクスは，メッセージの
                  ; セマンティクスと異なる。
                  ; 

     OCTET := <0から255の任意のオクテット値>

備考  このBNFは構造化されたヘッダフィールドを規定しないから，このBNFに示される要素間の線形空白及びRFC 822コメントの自由な挿入は許されない。

備考  特定のトランスポートの領域では，印字可能US-ASCII文字に本体を制限することなどRFC 822の制限が有効でないかもしれない。 すなわち，トランスポート領域は，RFC 821で規定される標準的なインターネットメールトランスポートに似ていてRFC 822を想定しているが，特定の制限がないものが存在するかもしれない。 これらの制限の緩和は，これらの拡張がトランスポートによってサポートされてContent-Transfer-Encodingヘッダフィールド中で適切に文書化されている限りは，局所的に拡張した本体の定義と解釈したほうがよい。 しかし，メッセージヘッダ又は本体部分ヘッダのどちらかでも，US-ASCII文字以外を含むことは許されない。

備考  "multipart"型から著しい欠損は，構造化され，関連する本体部分の意向である。 さらに構造化又は統合化されたマルチパートメッセージング機能を提供したい場合は，構文的には同一だが，多くの部分間での関連を定義するマルチパートの下位型を定義することが推奨される。 例えば，他の部分との関連を指定するのに使われ，多分それらのContent-IDフィールドを参照する，個別の部分を含む，マルチパートの下位型を定義できる。 この方法が使われる場合，古い実装は新しい下位型を認識しないが，multipart/mixedとしてあつかわれ，そのため利用者に認識される部分を見せることができる。

5.1.2 入れ子となったメッセージ及びマルチパートの処理

この標準仕様書(TS)の後続の箇条で定義される"message/rfc822"下位型は，データが尽きる以外には，終了する状態をもたない。 同様に，不正に切られた"multipart"実体は，終了境界のマーカをもたないで，メールシステム故障の結果，運用上やめることができる。

別の構造の中に埋め込まれる場合，このような実体が正しく処理されることは，本質的である。そのため，MIME実装には，内側の入れ子のどんなレベルでも外側のレベルの境界を認識することが，要求される。 次の期待されるマーカ又は他の終了状態を検査するだけでは十分でない。

5.1.3 mixed下位型

5.1.4 alternative下位型

"multipart/alternative"下位型は，構文的には"multipart/mixed"と同一であるが，セマンティクスは異なる。特に，本体部分のそれぞれは，同じ情報の"代替"版とする。

システムは，多くの部分の内容は交換可能であることを，認識したほうがよい。 システムは，いくつかの場合には利用者との対話があるにせよ，局所的な環境及び参照に基づいて，”最良の”型を選んだほうがよい。 "multipart/mixed"では，本体部分の順番は顕著とする。 この場合，代替は，原内容に忠実さが増す順番で現れるとする。 一般的に，最良の選択は，受信システムの局所環境によりサポートされる型の最後の部分である。

"multipart/alternative"は，例えば，どこにも簡単に表示できる，装飾的なテキストによるメッセージを送るのに使われてもよい。

     From: Nathaniel Borenstein 
     To: Ned Freed 
     Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
     Subject: Formatted text mail
     MIME-Version: 1.0
     Content-Type: multipart/alternative; boundary=boundary42

     --boundary42
     Content-Type: text/plain; charset=us-ascii

       ... メッセージのプレーンテキスト版がここ来る ...

     --boundary42
     Content-Type: text/enriched

       ... 同じメッセージのRFC 1896 text/enriched版がここに来る ...

     --boundary42
     Content-Type: application/x-whatever

       ... 同じメッセージの最も装飾的な版がここに来る ...

     --boundary42--

この例では，システムの機能に依存して，フォーマット付き又はプレーンテキストだけしか見られない利用者もいるし，"application/x-whatever"フォーマットを理解したメールシステムの利用者は，装飾的な版だけを見る。

一般的に，"multipart/alternative"実体を作成する利用者エージェントは，お勧め度の昇順，すなわちお勧めのフォーマットを最後に，本体部分を配置しなければならない。 装飾的なテキストについては，送った利用者エージェントは，最もプレーンなフォーマットを先に，最もリッチなフォーマットを最後に置くほうがよい。 受信利用者エージェントは，表示可能な最後のフォーマットを取り出して表示するほうがよい。 一つの代替がそれ自身"multipart"の型の場合で認識されない下位部分を含む場合，利用者エージェントは，その代替，それより前の代替，又はそれらの両方か表示するために選んでよい。

備考  実装者の観点からは，この順番を逆にし，最もプレーンな代替を最後に置くほうが，より感覚的によく見えるかもしれない。 しかし，最もプレーンな代替をはじめに置くことは，"multipart/alternative"実体がMIMEに適合しないビュアを使って見られたとき，最も親切な可能性がある選択である。 この方法は，MIMEに適合するビュアに負担をかけるが，この場合，より古いメールリーダとの相互運用性がより重要であると思われる。

いくつかの利用者エージェントで，それらが一つ以上のフォーマットを認識できるなら，どのフォーマットで見るか利用者に選択を提供することを好む場合があるかもしれない。 例えば，メッセージが，きれいにフォーマットされた画像版及び簡単に編集できるテキスト版の両方を含む場合などに，有意義である。 しかし，最も大事なことは，自動的に同じデータの複数の版を利用者が見せられるのではないことである。 利用者は最後に認識された版を見せた方がよいか、又は、選択を与えられた方がよいかである。

multipart/alternate中のContent-IDのセマンティクス  "multipart/alternative"実体のそれぞれの部分は同じデータを表すが，二つの間の対応付けは，必ずしも情報を失わないとは限らない。 例えば，ODAからPostScript又はプレーンテキストへ変換するときは，情報を失う。 二つの部分が同一の情報内容でないときは，それぞれの部分は，異なるContent-ID値を持つことが推奨される。 情報内容が同一のとき，例えば，"message/external-body"のいくつもの部分が，同一のデータにアクセスする代替の方法を指定する場合，受信者側にあり得るキャッシュ機構を最適化するため，同じContent-IDフィールド値が用いられる方がよい。 しかし，部分により使われるContent-ID値は，このようなContent-IDフィールドがあるならば，"multipart/alternative"全体を記述するContent-IDと同じにしない方がよい。 すなわち，一つ以上の他のContent-ID値が実体中の部分を参照するが，一つのContent-ID値が"multipart/alternative"実体を参照する。

5.1.5 digest下位型

この文書は，"multipart"Content-Typeの"digest"下位型を定義する。 この型は，構文的に"multipart/mixed"と同一だが，セマンティクスは異なる。 特に，ダイジェストでは，本体部分のためのデフォルトのContent-Tyep値は，"text/plain"から"message/rfc822"に変更された。 これは，引用の規約を除いて，RFC934と互換性の強い，より読める ダイジェストのフォーマットを許すために行われた。

備考  ダイジェスト中の本体部分に対して，ダイジェスト中のデータの記述を含む"text/plain"部分などのような，"message/rfc822"以外のContent-Type値を指定することは可能であるが，実際にそうすることは好ましくない。 "multipart/digest"Content-Type"は，メッセージを集めたものを送ることを意図する。もし，"text/plain"部分が必要ならば，それは"multipart/mixed"メッセージの別の部分として含まれたほうがよい。

このフォーマットによるダイジェストは，次のようである。

     From: Moderator-Address
     To: Recipient-List
     Date: Mon, 22 Mar 1994 13:34:51 +0000
     Subject: Internet Digest, volume 42
     MIME-Version: 1.0
     Content-Type: multipart/mixed;
                   boundary="---- main boundary ----"

     ------ main boundary ----

       ... 紹介のテキスト又は目次 ...

     ------ main boundary ----
     Content-Type: multipart/digest;
                   boundary="---- next message ----"

     ------ main boundary ----

     From: someone-else
     Date: Fri, 26 Mar 1993 11:13:32 +0200
     Subject: my opinion

       ... 本体がここにくる ...

     ------ next message ----

     From: someone-else-again
     Date: Fri, 26 Mar 1993 10:07:13 -0500
     Subject: my different opinion

       ... もう一つの本体がここにくる ...

     ------ next message ------

     ------ main boundary ------

5.1.6 parallel下位型

この標準仕様書(TS)は，"multipart"内容型の下位型"parallel"を定義する。 この型は，構文的には"multipart/mixed"と同一であるが，セマンティクスは異なる。 特に，パラレル実体では，本体部分の順番は意味をもたない。

この型の普通の表現は，ハードウェア及びソフトウェアですることができるなら同時に部分のすべてを表示する。 しかし，作成エージェントは，多くのメールリーダでこの機能がなく，いずれにせよ部分を直列的に見せることに注意を払った方がよい。

5.1.7 その他のmultipartの下位型

他の"multipart"下位型は将来的に期待される。 MIME実装は，一般的に，認識しない"multipart"の下位型を，"multipart/mixed"と同等なものとして，扱わなければならない。

5.2 messageメディア型

メールを送るとき，別のメールメッセージにカプセル化することは，頻繁に好まれる。 特別のメディア型"message"はこれを推進するために定義されている。 特に，"message"の"rfc822"下位型は，RFC 822メッセージをカプセル化するのに使われる。

備考  転送メッセージ又は拒絶メッセージのため，"message"の下位型を定義できることが推奨される。 しかし，転送メッセージ及び拒絶メッセージは，マルチパートメッセージとして，取り扱うことができ, そのマルチパートメッセージは，１番目の部分が制御又は記述的情報を含み，２番目の部分が"message/rfc822"型の転送メッセージ又は拒絶メッセージである。 このような拒絶の作成及びメッセージの転送は，原メッセージ上の型情報を保存し，それを受信者が正しく表現することを許すので，強く推奨される。

"messege"の下位型は，どの符号化が許されるかについて制限を課す場合がある。 これらの制限は，それぞれの特定の下位型とともに記述する。

メールゲートウェイ，リレー及び他のメール処理エージェントは，RFC 822メッセージの最上位ヘッダを替えることが一般に知られている。 特に，それらは，頻繁にヘッダフィールドを追加，削除又は並び替えを行う。 これらの操作は，"message"型のメッセージの型に組み込まれてカプセル化されたヘッダでは，明示的に禁止される。

5.2.1 RFC822下位型

"message/rfc822"メディア型は，本体が，RFC 822メッセージの構文でカプセル化されたメッセージを含むことを示す。しかし，最上位のRFC 822メッセージとは異なり，それぞれの"message/rfc822"本体が"From","Date"及び少なくとも一つの宛先を含まなければならないという制限が削除され，少なくとも一つの"From","Subject"又は"Date"が現れなければならないという要求に置き換えられる。

しかし，"822"という数字の使用にかかわらず，"message/rfc822"実体は，厳密なRFC 822への適合性のデータに制限されることはなく，"message/rfc822"オブジェクトのセマンティクスが，RFC 822で定義されるセマンティクスに制限されることもない。もっと具体的にいえば，"message/rfc822"メッセージは，ニュース記事又はMIMEメッセージである。

5.2.2 partial下位型

"partial"下位型は，大きい実体を，幾つもに分割したメールの部分として配信し，受信する利用者エージェントにより自動的に再構成することを許容するために定義する。 考え方は，基本的なInternet Protocolにおける，IP断片及び再構成に似ている。 この機構は，中間の転送エージェントが，送ることのできる個別のメッセージの大きさを，制限する場合に使うことができる。 メディア型"message/partial"は，本体がより大きい実体の断片を含んでいることを示す。

"message"型のデータは，base64又はquoted-printableで符号化されることはないので， 2値又は8ビットのトランスポートをサポートする環境で，"message/partial"実体が組み立てられている場合に問題がおこる。 問題は，2値データが複数の"message/partial"メッセージに分割され，それぞれが2値のトランスポートを要求することである。 7ビットのトランスポートへのゲートウェイで，このようなメッセージに遭遇したとき，すべての断片を待ち，内部のメッセージを再組み立てし，そして再組み立てされたデータをbase64又はquoted-printableで符号化する場合を除けば， それらを適切に7ビットの世界に符号化する方法がない。 異なる断片が異なるゲートウェイを通過する場合もあり得るから，再組み立てする方法でさえも，許容できる解決策ではない。 この理由から，"message/partial"型の実体はいつでも7ビット（デフォルト値）のContent-transfer-encodingでなければならないことが規定される。 特に，2値又は8ビットのトランスポートをサポートする環境である場合でさえも，"8bit"又は"binary"のcontent-transfer-encodingの使用は，"message/partical"型のMIME実体には，明示的に禁止される。 このことは，順番に内部のメッセージが"8bit"又は"binary"符号化を使ってはならないことを意味する。

いくつかのメッセージ転送エージェントは大きいメッセージを自動的に細分化してもよいこと，及びそのようなエージェントは大きく異なる細分化の範囲を使ってよいなどから，部分メッセージの断片が，再組み立てにおいてそれら自身が部分メッセージを構成する検証してもよいことが可能である。 これは明示的に許容される。

だから，3つの断片のメッセージの2番目の断片は，次のヘッダフィールドのうちいずれであってもよい。

     Content-Type: Message/Partial; number=2; total=3;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

     Content-Type: Message/Partial;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
                   number=2

しかし，3番目の断片は，断片の総数を指定しなければならない。

     Content-Type: Message/Partial; number=3; total=3;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

細分化番号は，0でなく，1で始まることに注意すること。

このようにして分けた実体の断片が，一緒にされるとき，結果は，いつも，自身のContent-Typeヘッダを持つかもしれず，そして他のデータ型を持つかもしれない，完全なMIME実体である。

5.2.2.1 メッセージ細分化及び再組立て

"message/partial"メッセージの断片の生成及び再構築をする場合，カプセル化されたメッセージのヘッダは，同封の実体のヘッダーで合体させなければならない。 この処理では，次の規則が観察されなければならない。

1. 細分化エージェントはメッセージを行の境界だけで分割しなければならない。 この制限は，行の最後以外の地点での分割がCRLFで終わらないメッセージのセマンティクスを保存することができるメッセージトランスポートに依存するために，課せられた。 多くのトランスポートは，このようなセマンティクスを保存することができない。
(1) Fragmentation agents must split messages at line boundaries only. This restriction is imposed because splits at points other than the ends of lines in turn depends on message transports being able to preserve the semantics of messages that don't end with a CRLF sequence. Many transports are incapable of preserving such semantics.
2. "Content-"で始まるヘッダフィールド並びに特別なヘッダフィールドの"Subject", "Message-ID", "Encrypted"及び"MIME-Version"を除いて，最初の囲まれたメッセージからのすべてのヘッダフィールドは新しいメッセージに順番に複写されなければならない。
(2) All of the header fields from the initial enclosing message, except those that start with "Content-" and the specific header fields "Subject", "Message-ID", "Encrypted", and "MIME-Version", must be copied, in order, to the new message.
3. Content-"と"Subject", "Message-ID", "Encrypted"で始まる囲まれたメッセージのヘッダフィールド及び"MIME-Version"のヘッダフィールドは，新しいメッセージに順番に追加されなければならない。 "Content-"で始まらない囲まれたメッセージの，"Subject", "Message-ID", "Encrypted"及び"MIME-Version"ではないフィールドは，無視されて，落とされる。
(3) The header fields in the enclosed message which start with "Content-", plus the "Subject", "Message-ID", "Encrypted", and "MIME-Version" fields, must be appended, in order, to the header fields of the new message. Any header fields in the enclosed message which do not start with "Content-" (except for the "Subject", "Message-ID", "Encrypted", and "MIME- Version" fields) will be ignored and dropped.

2番目及び後続の囲まれたメッセージからのすべてのフィールドは，再組み立て処理によって廃棄される。

(4) All of the header fields from the second and any subsequent enclosing messages are discarded by the reassembly process.

5.2.2.2 細分化及び再組立ての例

音声メッセージが，二つの部分に分断される場合，最初の断片は，次のようなものであろう。

     X-Weird-Header-1: Foo
     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail (part 1 of 2)
     Message-ID: 
     MIME-Version: 1.0
     Content-type: message/partial; id="ABC@host.com";
                   number=1; total=2

     X-Weird-Header-1: Bar
     X-Weird-Header-2: Hello
     Message-ID: 
     Subject: Audio mail
     MIME-Version: 1.\\0
     Content-type: audio/basic
     Content-transfer-encoding: base64

       ... 符号化された音響データの最初の半分はここに来る ...

そして，後半は，次のようなものであろう。

     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail (part 2 of 2)
     MIME-Version: 1.0
     Message-ID: 
     Content-type: message/partial;
                   id="ABC@host.com"; number=2; total=2

       ... 符号化された音響データの後半はここに来る ...

そして，細分化されたメッセージが再構成されるとき，利用者に表示される結果のメッセージは次のようなものであろう。

     X-Weird-Header-1: Foo
     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail
     Message-ID: 
     MIME-Version: 1.0
     Content-type: audio/basic
     Content-transfer-encoding: base64

       ... 符号化された音響データの最初の半分はここに来る ...
       ... 符号化された音響データの後半はここに来る ...

前の部分のMessage-Idを参照する細分化されたメッセージの2番目及び後続の断片のヘッダに "Reference"フィールドを含めることは，メールリーダが参照を理解し追跡する利点があるかもしれない。 しかし，このような"Reference"フィールドの生成はすべてオプションである。

最後に，"Encrypted"ヘッダフィールドは，Privacy Enhanced Messaging (PEM) [RFC-1421, RFC-1422, RFC-1423, RFC-1424]により，廃止されたが，"message/partial"断片へ及び断片からの変換の文脈において遭遇したとき，上記の規則は，それを取り扱う正しい方法を記述していると信じられている。

5.2.3 external-body下位型

external-body下位型は，実際の本体データは含まれず，単に参照であることを指示する。 この場合，パラメタは，外部データにアクセスする機構を記述する。

MIME実体が，型"message/external-body"の実体であるとき，これは，ヘッダ，連続する二つのCRLF及びカプセル化されたメッセージのメッセージヘッダからなる。別の連続する二つのCRLFの組が現れたとき，これはもちろん，カプセル化されたメッセージのメッセージヘッダを終了する。 しかし，カプセル化されたメッセージの本体は，それ自体外部にあるので，それは後続の領域には現れない。例えば，次のメッセージを考える。

     Content-type: message/external-body;
                   access-type=local-file;
                   name="/u/nsb/Me.jpeg"

     Content-type: image/jpeg
     Content-ID: 
     Content-Transfer-Encoding: binary

     THIS IS NOT REALLY THE BODY!

"見せかけの本体"と呼ばれるかもしれない最後の領域は，殆どのexternal-bodyメッセージで無視される。 しかし，access-typeが"mail-server"である場合などこのようないくつかのメッセージのためには，外部情報を含むのに用いてよい。 この標準仕様書(TS)で定義される，"見せかけの本体"を使うaccess-typeは"mail-server"だけとするが，将来的に，この領域を使う他の使用によって，他のaccess-typesが定義されてよい。

すべての"message/external-body"実体中のカプセル化されたヘッダは，データを参照するために一意の識別子を与えるContent-IDヘッダフィールドを含まなければならない。 この識別子は，キャッシュ機構のため，又は，access-typeが"mail-server"であるときデータの受領を認識するために使ってもよい。

ここで規定するように，ファイル名及びメールサーバ命令のような，externel-bodyのデータを記述するトークンは，US-ASCII文字集合であることが要求されることに注意すること。

実践において問題がある場合，"message/external-body"の新しく定義されたaccess-type又はその他の機構によって，将来のMIMEの拡張として，新しい機構が必要かもしれない。

"message/partial"と同じように，型"message/external-body"のMIME実体は，7bitのcontent-transfer-encodingの使用（デフォルト）でなければならない。 特に，binary又は8bitトランスポートをサポートする環境においてさえ，"8bit"又は"binary"のcontent-transfer-encodingの使用は，型"message/external-body"の実体として，明示的に禁止される。

5.2.3.1 一般のexternal-bodyパラメタ

"message/external- body"で使ってよいパラメタは次とする。

1. ACCESS-TYPE
   ファイル又はデータが得られる，サポートされるアクセス機構を指示する語とする。 この語は，大文字小文字を区別しない。 値は，"FTP"，"ANON-FTP"，"TFTP"，"LOCAL-FILE"及び"MAIL-SERVER"を含むが，これらに限定されない。 "X-"で始まる実験値を除く将来の値は，RFC 2048を原規定とする標準仕様書(TS)⁽¹⁾に記述されているように，IANAに登録されなけらばならない。 このパラメタは，無条件に必須であり，すべての"message/external-body"ごとに存在しなければならない。
(1) ACCESS-TYPE -- A word indicating the supported access mechanism by which the file or data may be obtained. This word is not case sensitive. Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL- FILE", and "MAIL-SERVER". Future values, except for experimental values beginning with "X-", must be registered with IANA, as described in RFC 2048. This parameter is unconditionally mandatory and MUST be present on EVERY "message/external-body".
2. EXPIRATION
   RFC 822の"date-time"構文で，RFC 1123によって年フィールドに4数字を許すように拡張された，外部データの存在が保証されない後の日付。 このパラメタはどんなaccess-typeと共に使ってもよく，いつでもオプションとする。
(2) EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as extended by RFC 1123 to permit 4 digits in the year field) after which the existence of the external data is not guaranteed. This parameter may be used with ANY access-type and is ALWAYS optional.
3. SIZE
   オクテット数によるデータの大きさ。 このパラメタの内容は，受信者が，外部データをもってくるために，必要な資源を拡張するかどうかを決定するのを援助する。 これはデータの大きさを正準形つまり，どのContent-Transfer-Encodingも適用する前又はデータが復号化された後，で記述することに注意すること。 このパラメタはどんなaccess-typeと共に使ってもよく，いつでもオプションとする。
(3) SIZE -- The size (in octets) of the data. The intent of this parameter is to help the recipient decide whether or not to expend the necessary resources to retrieve the external data. Note that this describes the size of the data in its canonical form, that is, before any Content-Transfer-Encoding has been applied or after the data have been decoded. This parameter may be used with ANY access-type and is ALWAYS optional.
4. PERMISSION
   クライアントがデータを上書きしようとするかもしれないことを期待するかどうかを指示する，大文字小文字を区別しないフィールドとする。 デフォルトにより又は許可が"read"の場合，それらが存在しないと仮定して，データが一度とってこられたら，それは再び必要ではない。 PERMISSIONが"read-write"の場合，この仮定は不正であり，局所的な複写が，キャッシュ以上でないことを考えなければならない。 "read"又は"read-write"だけを，許可の値として定義する。 このパラメタはどんなaccess-typeと共に使ってもよく，いつでもオプションとする。
(4) PERMISSION -- A case-insensitive field that indicates whether or not it is expected that clients might also attempt to overwrite the data. By default, or if permission is "read", the assumption is that they are not, and that if the data is retrieved once, it is never needed again. If PERMISSION is "read-write", this assumption is invalid, and any local copy must be considered no more than a cache. "Read" and "Read- write" are the only defined values of permission. This parameter may be used with ANY access-type and is ALWAYS optional.

ここで定義されるaccess-typeの正確なセマンティクスは，後続の箇条に記述される。

5.2.3.2 'ftp'及び'tftp' access-type

FTP又はTFTPのaccess-typeは，メッセージ本体が，FTP[RFC-959]プロトコル又はTFTP[RFC-783]プロトコルにより，ファイルとしてアクセスできることを指示する。これらのaccess-typeには，次の追加のパラメタが必須とする。

1. NAME
   実際の本体データを含むファイルの名前。
(1) NAME -- The name of the file that contains the actual body data.
2. SITE
   与えられたプロトコルを使用して，ファイルが得られるかも知れない。
(2) SITE -- A machine from which the file may be obtained, using the given protocol. This must be a fully qualified domain name, not a nickname.
3. FTPを使用して，どんなデータでも引き出すときにも，サイトのパラメタによって名付けられた機械のために，利用者は一般にログインID及びパスワードを尋ねられる必要がある。 セキュリティ上の理由から，このようなIDとパスワードはcontent-typeパラメタとして指定されないが，利用者から得られなければならない。
(3) Before any data are retrieved, using FTP, the user will generally need to be asked to provide a login id and a password for the machine named by the site parameter. For security reasons, such an id and password are not specified as content-type parameters, but must be obtained from the user.

加えて，次のパラメタをオプションとする。

1. DIRECTORY
   NAMEにより名付けられたデータがとられてよいディレクトリ。
(1) DIRECTORY -- A directory from which the data named by NAME should be retrieved.
2. MODE
   情報をとってくるとき，使われるモードを指示する，大文字小文字を区別しない文字列。 access-type"TFTP"に正当な値は，TFTPプロトコル[RFC-783]で規定されるとおり，"NETASCII"，"OCTET"及び"MAIL"とする。 access-type"FTP"に正当な値は，"ASCII"， "EBCDIC"，"IMAGE"，"LOCALn"，ここで，"n"は10進の整数で典型的には8，とする。 これらは，FTPプロトコル[RFC-959]で規定されるとおり，表現の型"A""E""I"及び"L n"に対応している。 "BINARY"及び"TENEX"はMODEの値として正しくなく，かわりに"OCTET"，"IMAGE"又は"LOCAL8"を使ったほうがよいことに注意すること。 MODEが指定されなかった場合，TFTPの場合のデフォルト値は"NETASCII"，それ以外は"ASCII"とする。
(2) MODE -- A case-insensitive string indicating the mode to be used when retrieving the information. The valid values for access-type "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the TFTP protocol [RFC- 783]. The valid values for access-type "FTP" are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a decimal integer, typically 8. These correspond to the representation types "A" "E" "I" and "L n" as specified by the FTP protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid values for MODE and that "OCTET" or "IMAGE" or "LOCAL8" should be used instead. IF MODE is not specified, the default value is "NETASCII" for TFTP and "ASCII" otherwise.

5.2.3.3 'anon-ftp' access-type

5.2.3.4 'local-file' access-type

"local-file"のaccess-type"は，実際の本体が，局所の機械上のファイルとしてアクセス可能であることを指示する。 このaccess-typeのために二つの追加のパラメタが定義される。

1. NAME
   実際の本体データを含むファイルの名前。 このパラメタは，"local-file" access-typeで必須とする。
(1) NAME -- The name of the file that contains the actual body data. This parameter is mandatory for the "local-file" access-type.
2. SITE
   データファイルへアクセスを持つために知られる，機械又は機械の組のための，ドメイン指定子。 このオプションのパラメタは，データのための参照の局所性，すなわち，ファイルが視覚化されることが期待される単数又は複数のサイト，を記述するために使われる。 例えば大域ファイルシステム経由のように，広く可能にすることを期待するファイルを指定するために，単一のアステリスクを使ってもよいけれども， 直接可視化したほうがよいデータの機械の組を指示するため， "*.bellcore.com"のように，ドメイン名の一部をワイルドカード対応するために，アステリスクを使ってよい。
(2) SITE -- A domain specifier for a machine or set of machines that are known to have access to the data file. This optional parameter is used to describe the locality of reference for the data, that is, the site or sites at which the file is expected to be visible. Asterisks may be used for wildcard matching to a part of a domain name, such as "*.bellcore.com", to indicate a set of machines on which the data should be directly visible, while a single asterisk may be used to indicate a file that is expected to be universally available, e.g., via a global file system.

5.2.3.5 'mail-server' access-type

"mail-server" access-typeは，実際の本体がメールサーバから可能であることを指示する。 このaccess-typeのために，二つの追加のパラメタが定義される。

1. SERVER
   実際の本体データを得ることのできる，メールサーバのaddr-spec。 このパラメタは"mail-server" access-typeで必須とする。
(1) SERVER -- The addr-spec of the mail server from which the actual body data can be obtained. This parameter is mandatory for the "mail-server" access-type.
2. SUBJECT
   データを得るために送られるメールの中で，使われる主題。 主題行のメールサーバをキーイングすることは推奨しないが，このようなメールサーバは存在することが知られている。 このパラメタはオプションとする。
(2) SUBJECT -- The subject that is to be used in the mail that is sent to obtain the data. Note that keying mail servers on Subject lines is NOT recommended, but such mail servers are known to exist. This is an optional parameter.

メールサーバは様々な構文を受け入れ，それらのいくつかは複数行なので，メールサーバへ送られる完全な命令は，content-typeヘッダフィールドのパラメタとして含まれない。 かわりに，メディア型が"message/external-body"及びaccess-typeがmail-serverであるとき，"見せかけの本体"として，それは提供される。

MIMEは，メールサーバの構文を定義しないことに注意すること。 そうではなく，見せかけの本体の中に任意のメールサーバの命令を含むことを許す。 実装は，関連のデータを引いてくるためにメールサーバアドレスへ送ったメッセージの本体の中に，見せかけの本体を含まなければならない。

他のaccess-typeと異なり，mail-serverアクセスは非同期で，将来予想できない時間に起きる。 この理由により，戻ってきたデータを原"message/external-body"実体とマッチさせることができる，機構があることは重要である。 MIMEメールサーバは，このようなマッチングを容易にするため，原"message/external-body"実体に使われた，戻ってきたメッセージ同じContent-IDを使わなければならない。

5.2.3.6 external-bodyのセキュリティ上の論点

"message/external-body"実体は，二つの重要なセキュリティ上の論点を起こす。

1. "message/external-body"参照を通したデータへのアクセスは，メッセージ作成者により指定された操作をメッセージ受信者が実行するのを，効果的にできる。 ゆえに，メッセージ作成者が，受信者をだまして，別な方法では成せないものをするようにする可能性がある。 例えば，受信者が得ることを承認されていないデータを引き取る動作を指定することができ，受信者は，知らないうちに，あるセキュリティポリシを破ることを起こす。 この理由により，外部参照を解決できる利用者エージェントは，受信者にもたらす動作の記述をいつも段階的に行い，それを実行する前に明示的な許可を求めなければならない。
   
   'mail-server' access-typeは，受信者に，もともとのメッセージ作成者による指定された内容の新しいメッセージを送ることをおこすので，特に攻撃されやすい。 不正の可能性があるとすると，MIMEの"message/external-body"参照を解決しようとするときに，例えば，ヘッダフィールドの注釈内で，構成された要求メッセージが自動的に生成されたものであることを示す，明確な通知を含むほうがよい。
(1) Accessing data via a "message/external-body" reference effectively results in the message recipient performing an operation that was specified by the message originator. It is therefore possible for the message originator to trick a recipient into doing something they would not have done otherwise. For example, an originator could specify a action that attempts retrieval of material that the recipient is not authorized to obtain, causing the recipient to unwittingly violate some security policy. For this reason, user agents capable of resolving external references must always take steps to describe the action they are to take to the recipient and ask for explicit permisssion prior to performing it. The 'mail-server' access-type is particularly vulnerable, in that it causes the recipient to send a new message whose contents are specified by the original message's originator. Given the potential for abuse, any such request messages that are constructed should contain a clear indication that they were generated automatically (e.g. in a Comments: header field) in an attempt to resolve a MIME "message/external-body" reference.
2. MIMEは時々メッセージの完全性と確実性のなんらかの保証を抵抗する環境で，使われ得る。 もしそうなら，このような保証は，メッセージの実際の直接のないように対してだけ適用してよい。それらは，MIMEの"message/external-body"機構を通してアクセスされるデータには適用してもよいし，適用しなくてもよい。 特に，メッセージングシステム自身がセキュリティがあるときでさえ，特定のアクセス機構を失う可能性をもつかもしれない。
   
   MIME機構の利用可能である又はないどちらの場合にも，この問題はが存在することに注意するほうがよい。 安全なメッセージのテキストでの文書を含むFTPサイトへの安易な参照も同様の問題を起こす。ただ一つの違いは，MIMEはこのようなデータへの自動的な引き取りを提供することで，利用者は，保障されない信頼はこのような自動的な引き取り機構であると 位置付けるかもしれない。
(2) MIME will sometimes be used in environments that provide some guarantee of message integrity and authenticity. If present, such guarantees may apply only to the actual direct content of messages -- they may or may not apply to data accessed through MIME's "message/external-body" mechanism. In particular, it may be possible to subvert certain access mechanisms even when the messaging system itself is secure. It should be noted that this problem exists either with or without the availabilty of MIME mechanisms. A casual reference to an FTP site containing a document in the text of a secure message brings up similar issues -- the only difference is that MIME provides for automatic retrieval of such material, and users may place unwarranted trust is such automatic retrieval mechanisms.

5.2.3.7 例と追加説明

external-body機構が"multipart/alternative"メディア型と結合して使われるとき，同じ実体が同じフォーマットであるが異なったアクセス機構を経由する場合を含むように，"multipart/alternative"の機能を拡張する。 これが行われる場合，メッセージの発信者は，最初，好みのフォーマットそして好みのアクセス機構で，部分を順序付けしなければならない。 受信者のビュアは，フォーマット及びアクセス機構の両方により，一覧を評価した方がよい。

非常に広い領域のファイルシステムの新しい可能性とともに， ファイルシステムから直接ファイルがアクセスできるのかできないのかの機械の組を，前もって知ることは大変難しくなった。 それゆえ，直接に試みるファイル名及びファイルがアクセス可能であることが知られている一つ以上のサイトの名前の両方を提供することは意味があるかもしれない。 実装は，FTP又はその他のプロトコルを使うか，匿名ファイル検索を使うか，又は，利用者に必要な名前とパスワードを入力するように促すことによって，遠隔のファイルを引き出すことを試みることができる。 もし，外部本体が，複数の機構でアクセス可能ならば， 送信者は，中に入っている"multipart/alternative"実体の本体部分のなかに，"message//external-body"型の複数の実体を含めることができる。

しかし，external-body機構は，mail-server access-typeに示されるように，ファイル検索に限定することを想定していない。 これを超えて，例えば，ビデオクリップへの外部参照のためのビデオサーバを使うことが想像できる。

"message/external-body"データの本体内に現われる，組み込みメッセージヘッダフィールドは，プレーンUS-ASCIIテキスト以外の何かであったら，外部本体はその型を宣言するヘッダ部を持たないから，外部本体のメディア型を宣言するために使わなければならない。 同様に，"7bit"以外のContent-transfer-encodingも，ここで宣言されなければならない。 だから，PostScriptフォーマットでのオブジェクトを参照する，完全な"message/external-body"メッセージは次のようになる。

     From: Whomever
     To: Someone
     Date: Whenever
     Subject: whatever
     MIME-Version: 1.0
     Message-ID: 
     Content-Type: multipart/alternative; boundary=42
     Content-ID: 

     --42
     Content-Type: message/external-body; name="BodyFormats.ps";
                   site="thumper.bellcore.com"; mode="image";
                   access-type=ANON-FTP; directory="pub";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: 

     --42
     Content-Type: message/external-body; access-type=local-file;
                   name="/u/nsb/writing/rfcs/RFC-MIME.ps";
                   site="thumper.bellcore.com";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: 

     --42
     Content-Type: message/external-body;
                   access-type=mail-server
                   server="listserv@bogus.bitnet";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: 

     get RFC-MIME.DOC

     --42--

上記の例題では，外部PostScriptデータのために，デフォルトのContent-transfer-encodingの"7bit"が仮定される。

"message/partial"型のように，"message/external-body"メディア型が透過的であることが想定される，すなわち，その型の本体のメッセージを運ぶのではなく，外部本体のデータ型を運ぶことが想定される。 ゆえに，外側及び内側部分のヘッダは，"message/partial"と同じ規則で，結合されなければならない。 特に，このことは，Content-typeフィールド及びSubjectフィールドは上書きされるが，Fromフィールドは保存されることを意味する。

外部本体は，外部本体参照とともには転送されないため，参照自身に適用される転送制限に適合する必要はないことに注意すること。 特に，インターネットメールトランスポートは7bit及び行長制限を課すが，これらは，2値の外部本体参照に自動的に適用されることはない。 だから，Content-Transfer-Encodingは，許容されるが，一般に必要ではない。

"message/external-body"型のメッセージの本体は，RFC 822メッセージのための基本構文が適用されることに注意すること。 特に，最初のCRLFが連続した組の前は，ヘッダ情報であり，その後は，多くのaccess-typeで無視される，本体情報である。

5.2.4 その他のメッセージ下位型

MIME実装は，一般的にいって，認識されない"message"の下位型を，"application/octet-stream"と同等であるものとして，扱わなければならない。

電子メールで用いることを想定した，将来の"message"の下位型は，"7bit"符号化に制限するほうがよい。 "7bit"に制限することができない場合は，"message"以外の型を使うほうがよい。

6. 実験メディア型値

文字"X-"で始まるメディア型値は，相互の合意の上で同意するシステムによって使われる私的な値とする。 厳密な公的定義以外のフォーマットは，"X-"接頭辞とともに命名されなければならず，公的に規定される値は"X-"で始まってはならない。 広く使われているAndrewシステムの旧版では"X-BE2"という名前を使っているので，新しいシステムは多分異なる名前を選んだほうがよい。

一般的に，最上位の型で"X-"を使うことは強く非推奨とする。 実装者は，可能な限り，存在する型の下位型を作ったほうがよい。 多くの場合，新しい最上位の型より，"application"の下位型とするほうが適当である。

7. まとめ

五つの個別メディア型は，"audio"，"image"又は多くの他の種類のデータとして，実体をタグ付けするための標準的な機構を提供した。 複合メディア型の"multipart"及び"message"は，単一のメッセージ中に，異なる型の実体の混合と階層的構造化を可能にした。 一つの個別のパラメタ構文は，データフォーマットの詳細の追加の指定，特に代替の文字集合の指定を可能にした。 追加のオプションのヘッダフィールドは，たくさんの実装者に望まれると思われる，信頼できる拡張を提供した。 最後に，同意した利用者エージェントによる一般的な使用のため，特に"message/partial"及び"message/external-body"が注目されるが，たくさんの便利なメディア型が定義された。

8. セキュリティへの考慮

セキュリティに関する論点は，"application/postscript"型及び"message/external-body"型の箇所並びにRFC 2048を原規定とする標準仕様書(TS)⁽¹⁾で論じられている。 実装者は，受信者の環境でのあらゆる動作の遠隔実行を起すことができるすべてのメディア型のセキュリティとの関わり合いに特別の注意を払ったほうがよい。 このような場合，"application/postscript"型の議論は，遠隔実行機能をもつ他のメディアについて考えるためのモデルとして提供されるであろう。

9. 原著者の連絡先

追加の情報のために原規定の著者に連絡をとるにはインターネットメールを使うのがよい。

   Ned Freed
   Innosoft International, Inc.
   1050 East Garvey Avenue South
   West Covina, CA 91790
   USA

   Phone: +1 818 919 3600
   Fax:   +1 818 919 3614
   EMail: ned@innosoft.com

   Nathaniel S. Borenstein
   First Virtual Holdings
   25 Washington Avenue
   Morristown, NJ 07960
   USA

   Phone: +1 201 540 8967
   Fax:   +1 201 993 3032
   EMail: nsb@nsb.fv.com

MIMEは，Internet Engineering Task ForceのRFC 822拡張に関する作業グループの作業の結果である。作業グループ議長のGreg Vaudreuilには，次の連絡先によって連絡できる。

   Gregory M. Vaudreuil
   Octel Network Services
   17080 Dallas Parkway
   Dallas, TX 75248-1905
   USA

   EMail: Greg.Vaudreuil@Octel.Com