UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 翻訳 1999年 4月17日 / translation 17 April 1999 修正 2003年12月16日 / correction 16 December 2003 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2046 を訳者(marimo@wdic.org)が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 Network Working Group N. Freed Request for Comments: 2046 Innosoft Obsoletes: 1521, 1522, 1590 N. Borenstein Category: Standards Track First Virtual November 1996 Multipurpose Internet Mail Extensions [多目的インターネットメール拡張] (MIME) パート２: メディアタイプ このメモの位置づけ この文書は、インターネットコミュニティのための Internet standards track protocol(インターネット標準運用プロトコル)を定義し、改良のため の議論と提案を求めている。標準化についての情報とこのプロトコルの状態 については最新の "Internet Official Protocol Standards" (STD 1) (イ ンターネット公的プロトコル標準) を参照のこと。このメモの配布は無制限 である。 摘要 STD 11 すなわち RFC 822 は、US-ASCII メッセージヘッダについてのか なりの詳細を記述するメッセージ表現のためのプロトコルを定義しており、 メッセージの内容あるいはメッセージボディはフラットな US-ASCII テクス トとしたままである。 正式には Multipurpose Internet Mail Extensions または MIME と呼ば れるこの一連の文書は、次のことを可能にするためにメッセージのフォー マットを再定義する。 (1) US-ASCII 以外のキャラクタセットによるテクストメッセージボディ、 (2) 非テクストのメッセージボディのための種々のフォーマットの拡張 性のセット、 (3) マルチパート（多部分的）なメッセージボディ、そして (4) US-ASCII 以外のキャラクタセットにおけるテクストのヘッダ情報 これらの文書は RFC 934, STD 11 および RFC 1049 に述べられている初期 の作業に基づいているが、それらをさらに拡張し、改訂するものである。 RFC 822 はメッセージボディに関してほとんど述べていないので、これらの 文書は RFC 822 に対する改訂というよりも、むしろ、RFC 822 と概ね直交し たものとなっている。 このセット、RFC 2045 の初期の文書は、MIMEメッセージの構造を記述す るために使用された様々なヘッダを指定する。この2番目の文書が、システ ムをタイプしているMIME媒体の一般構造を定義し、メディアタイプの初期の セットを定義する。3番目の文書、RFC 2047 は、インターネットメールヘッ ダフィールドの 非 US-ASCII テクストデータを許すために、RFC 822 の拡 張を記述する。4番目の文書、RFC 2048 は、MIME関連の設備のための様々な IANA 登録手続を指定する。MIME メッセージフォーマット、受領証、および 参考文献一覧のいくつかの説明に役立っている例を提供するだけでなく、 RFC 2049 という 5番目の最終文書が、MIME 対応標準を述べる。 これらの文書は RFC 1521、1522 および 1590 の改訂版である。それはさ らに RFC 1341 と 1342 の改訂版である。RFC 2049 の付録は、以前の版と の変更点を述べている。 目次 1. はじめに 2. トップレベルメディアタイプの定義 3. 初期のトップレベルメディアタイプの概要 4. 離散メディアタイプの値 4.1 Text メディアタイプ 4.1.1 改行の表現 4.1.2 Charset パラメータ 4.1.3 Plain サブタイプ 4.1.4 未認識のサブタイプ 4.2 Image メディアタイプ 4.3 Audio メディアタイプ 4.4 Video メディアタイプ 4.5 Application メディアタイプ 4.5.1 Octet-Stream サブタイプ 4.5.2 PostScript サブタイプ 4.5.3 他の Application サブタイプ 5. Composite メディアタイプの値 5.1 Multipart メディアタイプ 5.1.1 共通構文 5.1.2 ネストされた Messages と Multiparts の取り扱い 5.1.3 Mixed サブタイプ 5.1.4 Alternative サブタイプ 5.1.5 Digest サブタイプ 5.1.6 Parallel サブタイプ 5.1.7 他の Multipart サブタイプ 5.2 Message メディアタイプ 5.2.1 RFC822 サブタイプ 5.2.2 Partial サブタイプ 5.2.2.1 メッセージフラグメンテーションと再アセンブリ 5.2.2.2 フラグメンテーションと再アセンブリの例 5.2.3 External-Body サブタイプ 5.2.3.1 一般 External-Body パラメータ 5.2.3.2 'ftp' と 'tftp' アクセスタイプ 5.2.3.3 'anon-ftp' アクセスタイプ 5.2.3.4 'local-file' アクセスタイプ 5.2.3.5 'mail-server' アクセスタイプ 5.2.3.6 External-Body セキュリティ問題 5.2.3.7 例と更なる説明 5.2.4 他の Message サブタイプ 6. 実験的メディアタイプ値 7. 要約 8. セキュリティ対策 9. 奥付 A. 収集された文法 （訳注：本訳は都合上ページを振っていないので、上記のページ番号はす べて消した。読みづらい点はご容赦） 1. はじめに このセット、RFC 2046 の最初の文書は、内容タイプを含む多くのヘッダ フィールドを定義する。Content-Type フィールドは、メディアタイプとサ ブタイプ識別子を与えて、一定のメディアタイプのために必要であるかもし れない予備の情報を提供することによって、MIME エンティティのボディの データの性質を指定するために使用される。タイプとサブタイプ名の後に、 ヘッダフィールドの残りは、簡単に、attribute/value 表記において指定さ れたパラメータのセットである。パラメータの命令は重要ではない。 一般に、トップレベルのメディアタイプは、データの一般タイプを宣言す るために使用される一方、サブタイプはそのタイプのデータのための特定の フォーマットを指定する。従って、たとえユーザーエージェントが特定のイ メージフォーマット "xyz" の知識を持っていないとしても "image/xyz" の メディアタイプはユーザーエージェントにデータがイメージであると伝える のに十分である。そのような情報は、例えばユーザーが認識されないサブタ イプから未加工の(生の)データであることを示すかどうか決定するために使 われ得る -- 認識されないサブタイプの"image" または "audio" のそのよ うな動作は、認識されないサブタイプの "text" のために妥当であろう。こ の理由のために "text"、"image"、"autio"、および "video" の登録サブタ イプは、実際に異なるタイプである埋め込まれた情報を含むべきではない。 そのような複合したフォーマットは "multipart" または "application" タ イプを使って表されるべきである。 パラメータは、メディアサブタイプの変更者であり、そしてそれ自体では基 本的に内容の性質に影響を及ぼさない。有意義なパラメータのセットは、メ ディアタイプ及びサブタイプによって変わる。ほとんどのパラメータは一対 一で特定のサブタイプと関係している。しかしながら、agiven トップレベ ルのメディアタイプは、あらゆるサブタイプのそのタイプに適用できるパラ メータを定義するかもしれない。パラメータは、それらの定義するコンテン ツタイプに必要かもしれないし、そうでないならサブタイプまたはそれらは 任意だろう。MIME 実装は、それらが名前を認識しないあらゆるパラメータ を無視しなければならない。 MIME の Content-Type ヘッダフィールドとメディアタイプメカニズムは 拡張性があるように慎重に設計されており、そしてメディアタイプ／サブタ イプペア、およびそれらの関連するパラメータのセットが時間の間ずっと著 しく成長することが予測される。いくらかの他の MIME 設備は、転送符号化 および "message/external-body" アクセスタイプのように時間の間ずっと 定義された新しい値を持っていそうである。そのような値のセットが、整然 とし、よく指定されて、公的な方法で発展させられることを保証するために、 MIMEは、extensibility の MIME の様々なエリアのための中心的な登録者と してインターネットアドレス管理機構（IANA）を使う登録プロセスを設定す る。これらの地域のための登録プロセスは関連文書、RFC 2048において述べ られている。 初期の 7つのトップレベルメディアタイプは、この文書の残りにおいて定 義および記述される。 2. トップレベルメディアタイプの定義 トップレベルメディアタイプの定義は以下から成っている: (1) 名前と記述のタイプ、そのタイプのもとで特有のタイプが資格を得 るかどうかのために標準を含む、 (2) パラメータの名前、定義、及びそのタイプのすべてのサブタイプの ために定義され、もしあれば(そのようなパラメータが必要か、ま たは任意であるかどうかにかかわらず含む)、 (3) ユーザーエージェントおよび／またはゲートウェイは、どのように このタイプの未知のサブタイプを操作するべきであるか、 (4) このトップレベルのタイプのゲートウェイエンティティでの一般考 慮がもしあれば、そして (5) このトップレベルタイプエンティティのための content-transfer- encodings のどのような制限でも。 3. 初期のトップレベルメディアタイプの概要 5つの離散的なトップレベルメディアタイプは下記である: (1) text -- 文章の情報。特に "plain" サブタイプは、どのような種 類のフォーマット命令または指令でも一切含まないプレーンテクス トを示す。プレーンテクストは「あるがまま」(as-is) で表示され ることを意図している。特別なソフトウェアは、示された文字セッ トのためのサポートは別として、テクストの十分な意味を得るのに 必要とはされない。他のサブタイプはアプリケーションソフトウェ アがテクストの外観を強化できるフォームのエンリッチテクストの ために使われるべきだが、そのようなソフトウェアは内容について の一般的なアイデアを得るのに必須であってはならない。従って、 "text" の可能なサブタイプは、このようにフォーマットを理解す るソフトウェアに頼らずに読まれうるあらゆるワープロフォーマッ トをも含んでいる。特に、情報をフォーマットするために埋め込ま れたバイナリを用いるフォーマットは、直接読みやすいとは考えら れない。名前 "enriched" の下の RFC 1896 における更なる改訂に 関し、非常にシンプルでかつポータブルなサブタイプ "richtext" は、RFC 1341 において定義された。 (2) image -- イメージデータ。"Image" は、情報を見るために、表示 機器（グラフィカルディスプレイ、グラフィックスプリンタ、FAX マシンなど）を必要とする。初期のサブタイプは、広く使われたイ メージフォーマット JPEG のために定義される。サブタイプは、2 つの広く使われたイメージフォーマット、jpeg、および gif のた めに定義される。 (3) audio -- オーディオデータ。中身を "Display" するために、オー ディオの出力機器（スピーカーや電話機など）を必要とする。この 文書において初期のサブタイプ "basic" が定義される。 (4) video -- ビデオデータ。"Video" は、専用ハードウェアとソフト ウェアを一般に含む動画を表示するために機能を必要とする。この 文書において初期のサブタイプ "mpeg" が文書にされる。 (5) application -- 他の種類のデータ、典型的に翻訳されないバイナ リデータ、またはアプリケーションによって処理するための情報。 未解釈なバイナリデータについて使われるように "octet-stream" (オクテットの流れ)のサブタイプと最も簡単な推薦された行動は、 ユーザーのためのファイルに情報を書くと申し出ることである。 "PostScript" サブタイプはまた、PostScript 素材の転送のために 定義される。他の予測は "application" 包括スプレッドシート、 メールベースのスケジューリングシステムのためのデータ、直接読 み取り可能ではない "active" (コンピュータ処理)のメッセージン グのための言語、およびワードプロセッシングフォーマットのため に使われる。いくつかのタイプのアプリケーションデータ、特に、 "application/PostScript" の大部分、そしてあらゆる形の活動的 通信には、セキュリティ考察事項が存在するかもしれないことに注 意が必要である。これらの問題はこの文書の後の方で議論される。 2つの合成トップレベルのメディアタイプは下記である: (1) multipart -- 複数の独立データタイプエンティティから成るデー タ。4つのサブタイプは初めに定義される。基本 "mixed" サブタイ プはパートの混在セットの総称の定義を含んでおり "alternative" は多重フォーマットにおいては同じデータを表すため、"parallel" は部分が同時に見られるつもりだった。そして "digest" は各部分 が "message/rfc822" のデフォルトタイプを持っているマルチパー トのためのものである。 (2) message -- カプセル化されたメッセージ。メディアタイプ "message" のボディは、それ自身すべて、またはある種のメッセー ジオブジェクトの部分である。そのようなオブジェクトは他のエン ティティを含むかもしれないし、また含まないかもしれない。カプ セル化された内容自身が RFC 822 メッセージである時は "rfc822" サブタイプが使われる。"partial" (部分的) サブタイプは、1個で 輸送するには大きすぎると考えられるボディを粉々にする転送を許 すために、部分的な RFC 822 メッセージのために定義される。別 のサブタイプ "external-body" は、大きいボディを指定するため に、外部のデータソースの参照により定義される。 ここで与えられたメディアタイプ値のリストが時間内に増やされるだろう ことは言及されるべきで、メカニズムを経て、上での説明およびサブタイプ のそれセットが大幅に成長することが期待されている。 4. 離散メディアタイプの値 7つの初期メディアタイプ値のうちの 5つが別個のボディを参照する。こ れらのタイプの内容は非MIMEメカニズムによって扱われなければならない; それらは MIMEプロセッサのために不透明である。 4.1. Text メディアタイプ "text" メディアタイプは、フォームで主として原文通りの素材(マテリア ル)を送るために設計されている。プレーンテクストのための一般的なサブ タイプである "text" サブタイプ（サブタイプ "text/plain" を特に含む） のためにボディテクストのキャラクタセットを示すために、"charset" パラ メータが用いられる。プレーンテクストはそれに備えず、手順、翻訳指令、 または内容のマークアップを処理して、コマンド、文字修飾仕様書をフォー マットすることを許さない。 プレーンテクストは、単純に改行または改ページによって遮断された連続 的な一連の文字と考えられる。プレーンテクストはテクストの同じポジショ ンのいくつかの文字を積み重ねることを許す。 アラビア語やヘブライ語のように呪文のようなプレーンテクストは、逆の 書き込み方向によってテクストセグメントの任意の混合を許すファシリティ (facilitites) を含むかもしれない。 プレーンテクストを越えて、"rich text" として知られているかもしれな い多くのフォーマットがある。多くのそのような表現の興味深い特徴は、そ れらを解釈するソフトウェアがなくても、ある程度まで読み取り可能なこと である。その時、最も高いレベルにおいて、それら、読む価値のないフォー ムにおいて表されているイメージ、オーディオ、またはテクストのような読 む価値のないデータと区別することが有益である。適切な解釈ソフトウェア の不在では、ほとんどの非原文のデータがそう必要であることが妥当ではな い間、ユーザーに "text" のサブタイプを示すことが妥当である。そのよう なフォーマットされた原文のデータは、"text" のサブタイプを使って表さ れているはずである。 4.1.1. 改行の表現 どのような MIME "text" サブタイプの正規のフォームでも、改行は常に CRLF シーケンスで【なければならない】。同様に、MIME "text" で発生し た CRLF は、どのような発生でも改行を表さ【なければならない】。改行 シーケンス以外で CR と LF を使うことは禁じられている。 この規則は、伴われているフォーマット、キャラクタセット、またはセッ トを問わずあてはまる。 注意事項: ボディが表示される時の改行の適切な解釈は、メディアタイプに依存す る。特に、"text/plain" ボディを表示する時に、改行を変遷とみなすこ とが新種に適切な間、この取り扱いは実際 "text/enriched" [RFC-1896] のような "text" の他のサブタイプのために不正確である。同様に、ディ スプレイオペレーションの間に改行が追加されるべきであるかどうかは、 同じくメディアタイプの機能でもある。あらゆる改行を "text/plain" の 正しい表示に加えることは必要とはいえない。一方、"text/enriched" の 適切なディスプレイは、改行の適切な追加を必要とする。 注意事項: いくつかのプロトコルは、最大の行長を定義している。例えば、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" のためにここ に指定されたそれらと同一であるように定義されるべきで、すなわちボディ は与えられた charset の文字から完全に成っている。特に将来の "text" サブタイプの定義者は、それらのサブタイプ定義のためのマルチオクテット キャラクタセットの意味に深く注意すべきである。 RFC 2045 において "character set" が定義されると、"text" のサブタ イプのための charset パラメータはキャラクタセットの名前を与える。前 のセクションで詳細な改行についての規則は、また遵守されなければならな い -- 定義がこれらの規則に対応しないキャラクタセットは、MIME "text" サブタイプにおいては使われない。 あらかじめ決められたキャラクタセット名の初期のリストはこのセクショ ンの終わりに見つかるかもしれない。付加的なキャラクタセットは IANA に よって登録されるだろう。 "text" のサブタイプより他のメディアタイプは、charset パラメータを 使用することを選ぶことがで、さらに CRLF/改行に関する制限は取り除かれ る。従って、RFC 2045 における "character set" の一般的な定義に順応す る全てのキャラクタセットは、MIME 使用のために登録できる。 指定されたキャラクタセットが 8ビット文字を含み、ボディにおいてその ような文字が使われて、SMTP[RFC-821] などのいくつかのメール転送プロト コルを経たボディを送るために、Content-Transfer-Encoding ヘッダフィー ルドおよびデータでの一致符号化が必要であることに注意しなさい。 デフォルトのキャラクタセット (US-ASCII) は、過去ある混乱と曖昧さの 主題であった。定義中のいくらかの曖昧さばかりでなく、定義においても実 際に大きな変化があった。将来そのような曖昧さや変化を取り除くため、新 しいユーザエージェントが Content-Type ヘッダフィールドにおけるメディ アタイプパラメータとしてセットされたキャラクタを明白に指定することが 強く推薦される。"US-ASCII" は任意の 7ビットのキャラクタセットを示さ ないが、ボディのすべてのオクテットが US-ASCII キャラクタセットに基づ いてキャラクタと解釈されなければならないと明示する。 ISO 646 [ISO-646] の国家的かつアプリケーション指向のバージョンは通 常 US-ASCII と同一【ではなく】、さらに、そのような場合にインターネッ トメールでのそれらの使用が明白に妨害される。この文書からの ISO 646 キャラクタセットの省略は、慎重に配慮すべきである。"US-ASCII" キャラ クタセット名は、ANSI X3.4-1986 [US-ASCII] において定義されたキャラク タセットを明示的に参照する。ISO 646 の 1991年版の新しい国際参照バー ジョン(IRV) は US-ASCIIと同一である。キャラクタセット名 "ASCII" は予 約されるが、いかなる目的であっても使ってはならない。 注意事項: RFC 821 が明示的に特定する "ASCII" は、初期の米国標準の初期バー ジョンを参照付けている。メディアタイプとキャラクタセットを指定する ことの目的のうちの1つに、受信側が、どのように送信側で符号化された メッセージを解釈するかを無多義的に決定することを許すが、その時存在 が伝えられたデフォルトがメッセージの語義に、故意ではないが互換性も ない変化を危険にさらすと、"strict ASCII" (厳密な ASCII) を除いた何 らかが仮定される。同じくこれはメッセージが US-ASCII 及び 1991年版 の IRV、もしくは 8ビットと同様にコード切り替え手続き (例えば ISO 2022 のようなもの) を用いて ISO 646 の他のバージョンに従って符号化 されたキャラクタを含んでいると意味する、もしくは複合オクテットキャ ラクタエンコーディングは、 MIME と一致するよう適切なキャラクタセッ トを【使わなければならない】。完全な US-ASCII キャラクタセットは、 ANSI X3.4- 1986 にリストされている。DEL を含む制御キャラクタ(0-31, 127) が新しい行を示す結合 CRLF (US-ASCII値 13、及び 10)から離れて 定義された意味を持っていないことに注意しなさい。文字のうちの2つは 広範使用において事実上の意味を持っている： FF (12) は、しばしば 「新しいページの最初の開始の次のテクスト」を意味している; そして TAB または HT (9) がしばしば（常にではない）は、「カーソルをカラム 番号が 8の倍数（最初のカラムをカラム0と見なすこと）である現在のポ ジションの後の入手可能なカラムへの移動」を意味している。これらの規 定とは別として、使用されるあらゆる制御キャラクタや DEL は、ボディ 内に発生しなければならない。 (1) "plain" 以外のテクストのサブタイプが明確にいくらかの追加の意 味を割り当てる。もしくは (2) 送信者と受信者の間の私的な協定の中で。そのような私的な協定は 妨害され、この文書の他の機能と交換されるべきである。 注意事項: US-ASCII を越えるキャラクタセットの大増殖。多くの部分的、または 完全にキャラクタセットと重なっている(オーバーラップしている)もの は、よい物【ではない】。インターネットメールにおいて世界の全ての 言語を表すために一般に使われ得る【シングル】キャラクタセットは、 preferrable であろう。不運なことに、近い将来にわたり複数のキャラ クタセットが使われつづけるという指摘がいくつかのコミュニティの活 動中に存在している。従って、少数の標準キャラクタセットが、この文 書でのインターネット使用のために定義される。 定義された charset 値は次の通りである: (1) US-ASCII -- ANSI X3.4-1986 [US-ASCII] で定義されている. (2) ISO-8859-X -- "X" が ISO-8859 [ISO-8859] の部分のために必要 で、交換されることになっている箇所である。ISO 646 キャラクタ セットがそれらの 8859 の置換 (インターネットメールのための示 されたキャラクタセットである) を支持して慎重に省略されたこと に注目しなさい。この文書の発表現在で "X" のための正規な値は 数字 1 から 10 までである。 ISO-8859-X の範囲 128-159 の文字には意味を割り当てない。ISO-8859-X における 128 未満の値を持つ文字は、それらが US-ASCII に割り当てられ たものと同じ意味を持っている。 ISO 8859 のパート6（ラテン／アラビア語アルファベット）、およびパー ト8（ラテン／ヘブライ語アルファベット）は、正常な書き込み方向の右か ら左方向と、左から右の両方の文字を含むが、双方向のテクストを表すため の方法を命令するための規則を定義してはならない。ただし [RFC-1556] で は視覚的な方法として、"ISO-8859-6" と "ISO-8859-8" という charset 値 を指定した。 これらのキャラクタセットのうちの全ては、いかなるシフトやエスケープ 機能も用いない、純粋な 7ビットや 8ビットのセットとして使われる。これ らのキャラクタセットでのシフトとエスケープシーケンスの意味は定義され ない。 上で指定されたキャラクタセットは、 MIME のドラフト中に比較的論争の 余地がなかったものである。この文書は 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" である。これ は、どのような書式コマンドや命令も含んでいない平易なテクストを示す。 プレーンテクストは「ありのままに」(as-is) 表示されることを意味してい る。すなわち、翻訳されない埋め込み書式コマンド、文字修飾仕様書、処理 手順、翻訳指令、または、内容マークアップは、厳密な表示のために必要に なるはずである。インターネットメールのためのデフォルトのメディアタイ プ "text/plain; charset=us-ascii" は、既存のインターネット実行を説明 する。すなわち、それは RFC 822 で定義されたボディのタイプである。 他の "text" サブタイプは、この文書では定義されない。 4.1.4. 未認識のサブタイプ MIME の実装が、いかに charset を処理するかを知る限り、認識されない サブタイプ "text" は、サブタイプ "plain" として扱われるべきである。 認識されない charset を同様に指定する認識されないサブタイプは、 "application/octet-stream" のように扱われるべきである。 4.2. Image メディアタイプ "image" のメディアタイプはボディが画像を含んでいることを示す。サブ タイプは具体的な画像フォーマットを名付ける。これらの名前は文字の大小 を問わない。初期のサブタイプは JFIF符号化 [JPEG] を用いた JPEGフォー マット "jpeg" である。ここで与えられた "image" サブタイプのリストは 排他的でも徹底的でもなく、そして RFC 2048 において示されるように多く のタイプが IANA によって登録され、より成長すると予測される。"image" の未認識サブタイプは、最小扱いにおいて "application/octet-stream" の ように扱うべきである。もしそのようなアプリケーションが利用可能である ならば、実装時には、それらが安全で頑強な多目的画像閲覧アプリケーショ ンが認識しない "image" のサブタイプの受け流し方をオプションで決定す るだろう。 注意事項: 一般的な汎用画像閲覧アプリケーションの使用によりアプリケーショ ンによってサポートされた最も危険なタイプのセキュリティ問題がこの 方法で引き継がれる。 4.3. Audio メディアタイプ "audio" のメディアタイプは、ボディがオーディオデータを含むことを示 す。さらにコンピュータで使われる "ideal" オーディオのフォーマットに は合意がないが、相互操作可能な行動を提供して、有能なフォーマットに押 しているニーズがある。 初期のサブタイプ "basic" は完全に最小の最小公分母オーディオフォー マットを提供して、この要件を満たすように指定される。より高い品質およ び／または更に低い帯域幅オーディオのためのより豊かなフォーマットが後 の方の文書によって定義されるのことが予期される。 "audio/basic" サブタイプの内容は、8000Hz のサンプルレートで単一の チャンネルオーディオ符号化使用8ビットISDN mu-law [PCM] である。 "audio" の未認識サブタイプは、最小の "application/octet-stream" の ように扱われるべきである。もしそのようなアプリケーションが利用可能な らば、実装は、それらが頑強な汎用オーディオ再生アプリケーションが認識 しない "audio" のサブタイプを通過することをオプションで決定するであ ろう。 4.4. Video メディアタイプ 恐らくはカラー、そして、統合された音に関して、"video" のメディアタ イプは、ボディが経時変化する写真イメージを含んでいることを示す。用語 'video' は、あらゆる特別な技術またはフォーマットに関してより、むしろ その最も一般的なセンスに使われ、そして、ぎっしりと符号化された動画サ ブタイプを排除することを意味しない。サブタイプ "mpeg" は、MPEG標準 [MPEG] に従って符号化されたビデオに言及する。 概してこのドキュメントが強く単一のボディにおいて多重メディアのミキ シングを妨害するが、多くのいわゆるビデオフォーマットが同期されたオー ディオのための表現を含み、そして、これが明白に "video" のサブタイプ のために可能にされることが認識されることに注意しなさい。 "video" の未認識サブタイプは、最小の "application/octet-stream" の ように扱われるべきである。もしそのようなアプリケーションが利用可能な らば、実装は、それらが頑強な汎用ビデオディスプレイアプリケーションが 認識しない "video" のサブタイプを通過することをオプションで決定する かもしれない。 4.5. Application メディアタイプ "application" メディアタイプは、他のカテゴリのうちのどれもはめ込ま ない別個のデータのために、更に特にあるタイプのアプリケーションプログ ラムにより処理されるためのデータに使われるべきである。"application" メディアタイプの期待された用途は、ファイル転送、スプレッドシート、 メールベースの日程計画システムのためのデータ、及び "active" (計算の) 材料のための言語を含む（特に、後者は実装者により理解されなければなら ないセキュリティ問題を引き起こすことができ、"application/PostScript" メディアタイプの議論において詳細に考察される）。 例えば、会合スケジューラは、会合日付についての情報のための標準の表 現を定義することができる。インテリジェントなユーザーエージェントは、 ユーザーと共に対話を行なうためにこの情報を使い、そして、それからその 対話に基づく付加的な素材を送るであろう。より一般的にはどちらの適宜専 門化された言語のプログラムが遠隔位置へ転送されるかにおいて開発され、 そして、受取人の環境において自動的に実行されたいくらかの "active" 通 信言語があった。 そのようなアプリケーションは "application" メディアタイプのサブタ イプと定義されるかもしれない。この文書は2つのサブタイプを定義する: octet-stream と PostScript. "application" のサブタイプは、しばしば、名前またはデータが、意図さ れているアプリケーション名の一部を含むであろう。しかし、これはどのよ うなアプリケーションプログラム名でも "application" のサブタイプとし て自由に使われうることは意味していない。 4.5.1. Octet-Stream サブタイプ "octet-stream" サブタイプは、ボディが任意のバイナリのデータを含む ことを示すために使用される。広く定義されたパラメータのセットは下記の とおりである: (1) TYPE -- バイナリデータの一般タイプまたはカテゴリ。これは、ど のような自動的な処理というよりも、むしろ人の受信者のための情 報として意図されている。 (2) PADDING -- それをパディング(穴埋め)しているビット数は、添付 された8ビットバイト指向データを作るために、実際の内容を含む ビットストリームに付加された。これは、ビットの全体の数が8の 倍数ではない時、ボディのビットストリームを取り囲むのに有益で ある。 これらのパラメータは両方ともオプションである。 付加的なパラメータ "CONVERSIONS" は RFC 1341 において定義されてい たが、既に削除されている。同じく RFC 1341 は、データがファイルに書か れる必要があった時に使われるべく提案されたファイル名を与えた "NAME" パラメータの使用を定義した。これは次の RFC において定義されるよう、 別個の Content-Disposition ヘッダフィールドに期待して非難された。 "application/octet-stream" エンティティを受け取る実装のための推奨 動作は、データを取り消されたあらゆる Content-Transfer-Encoding に関 してファイルに入れることを簡単に申し出ることである。さもなくば、多分 ユーザー指定されたプロセスへの入力としてそれは使われる。 悪質プログラムを送る危険を減らすために、実装が、Content-Type パラ メータ（例えば "interpreter=" パラメータ）において指定された任意のプ ログラムが入力としてメッセージボディを用いて発見され、そして実行され るパス検索メカニズムを実装【しない】ことが強く勧められる。 4.5.2. PostScript サブタイプ "application/postscript" のメディアタイプは、PostScript プログラム を示す。現在、PostScript 言語の2つのバリエーションが許される; オリジ ナルのレベル1バリエーションは [POSTSCRIPT] と示され、より最近のレベ ル2バリエーションは [POSTSCRIPT2] と示される。 PostScript は Adobe Systems, Inc. の登録商標である。MIMEメディアタ イプ "application/postscript" の使用は、それが必要とするその商標、及 びすべての権利の認識を意味する。 PostScript 言語定義は、あるプログラムが使う特定の言語機能の内部の 分類することのための設備を提供する。この分類（PostScript文書構造化会 議またはDSCと呼ぶ）は非常に一般的で、そして、単に、単に言語レベルよ り大幅に多くの情報を提供する。規定を構造化するドキュメントの使用は、 要求されない間は、インタオペラビリティ(相互運用性)への補助として強く 推薦される。適切な構造化協定を欠く文書は、与えられた環境において彼ら が働くかどうかをわかるためにテストできない。従って、いくつかのシステ ムが最悪事態を仮定し、そしてプロセスへの廃物は、ドキュメントを構造化 しなかった。 汎用 PostScript インタプリタの実行は重大なセキュリティ上の危険を伴 うので、実装者は単に送信 PostScript ボディを "off-the-shelf" (標準量 産品) インタプリタに思いとどまる。通常、PostScript を、問題のための可 能性が典型的なプリンタ環境によって大いに強制されるプリンタに送ること が安全な間、それらが PostScript ボディのインタラクティブなディスプレ イをそれらの MIME 読み込み処理に追加する前に、実装者は以下のうちのす べてを考慮するべきである。 このセクションの残りは、PostScript エンティティの送信についての可 能な問題のうちのいくつか（しかし、たぶん全てではない）を概説する。 (1) PostScript言語での危険なオペレーションは含むが、PostScriptオ ペレータ "deletefile"、"renamefile"、"filenameforall"、およ び "file" に制限できない。"File" は標準入出力を除いた何かに 適用される時のみ危険である。実装は付加的な標準外のファイルオ ペレータも定義することができる; これらセキュリティの驚異を引 き起こすかもしれない。"Filenameforall" (ワイルドカードのファ イル検索オペレータ) は、一見して無害であるように思われるかも しれない。 しかしこのオペレータは、受信者がどんなファイルにアクセスでき るかについての情報を明らかにする可能性を持っており、しかも、 この情報自身は文字の大小を区別するかもしれないことに注意しな さい。これらのオペレータが安全な PostScript 実装において利用 不可能である可能性があるので、メッセージ送信者は、潜在的に危 険なファイルオペレータの使用を避けるべきである。メッセージの 受領と表示ソフトウェアは、すべての潜在的に危険なファイルオペ レータを完全に使用不可にするか、またはそれらのオペレーション の幾らかの特別な権限にも委任しないため、特別な注意をするべき である。これらのオペレータは、PostScript 文書を解釈する時に 外部のエージェンシーによってなされると見なされるべきである。 そのような使用不可にするおよび／またはチェックは、PostScript 言語そのものの届く範囲の外で行われるべきである; これらのオペ レータの完全な機能バージョンを再可能にするために方法が全然存 在しないことを保証するために気をつけるべきである。 (2) PostScript 言語は、通常のインタプリタまたはサーバから出るた めの設備、ループを提供する。この "outer" の環境において起こ された変化は文書を横切って習慣的に保存され、半永久的に不揮発 性メモリに場合により保存されるかもしれない。インタプリタルー プを出ることと関連したオペレータは、次のドキュメント処理を妨 げる可能性を持っている。従って、それらの無制限利用はサービス 否定の脅威を及ぼす。インタプリタループを出る PostScript オペ レータは含まれるが、exitserver および startjob オペレータに 制限できない。メッセージ送信ソフトウェアは exit する能力が、 たぶん、安全な PostScript 実装においては利用できないので、動 作のためにインタプリタのループを exit することを前提としたオ ペレーションは PostScript では生成するべきではない。メッセー ジ送信と表示のソフトウェアは、"startjob" と "exitserver" オ ペレーションを取り除くこと、または使用不可にすることによって PostScript 環境に保有される変化を起こす能力を完全に使用不可 にするべきである。もしこれらのオペレーションが除去できない、 または完全に使用不可にできないならば、それらと関連していたパ スワードは、それらと結合した推測しづらい(hard-to-guess)値に 少なくとも設定されるべきである。 (3) PostScript はオペレータをシステムワイド (system-wide) でデバ イス依存 (device-specific) パラメータを設定することを提供す る。これらのパラメータ設定は、仕事を横切って記憶され、脅威を インタプリタの正しいオペレーションに潜在的に引き起こすかもし れない。システムおよび機器パラメータを設定した PostScript オ ペレータは含むが、"setsystemparams" および "setdevparams" オ ペレータには制限できない。メッセージ送信ソフトウェアは、シス テムまたは機器パラメータの設定が正しく動作することを前提とし た PostScript を生成するべきではない。これらのパラメータを設 定する能力は、おそらく安全な PostScript 実装においては利用で きないだろう。メッセージ受信と表示ソフトウェアは、システムと 機器パラメータを変更する能力を使用不可にするべきである。もし これらのオペレータが完全に使用不可にできないならば、それらと 関連したパスワードは推測しづらい(hard-to-guess)値に少なくと も設定されるべきである。 (4) いくつかの PostScript 実装は、機械語の直接的なロードと実行に 非標準的能力を提供する。そのような能力は、全く明らかに本質的 乱用に開放されている。メッセージ送信ソフトウェアはそのような 特徴を利用すべきではない。完全にハードウェア依存である上に、 それらは、同じく PostScript の安全な実装において利用不可能で ある可能性がある。もしそれらが存在するならば、メッセージを受 信して表示するソフトウェアは、そのようなオペレータに使われる ことを可能にすべきではない。 (5) もしその実装が多くのそれ自身の拡張を提供することが殆どないな ら、PostScript は拡張可能言語で、かつ多い。それらが未知の要 因(ファクター)を構成しているので、この文書はそのような拡張を 明示的に扱わない。メッセージ送信ソフトウェアは標準外の拡張を 利用するべきではない; それらはいくつかの実装からは欠けていそ うである。メッセージを受信し表示するソフトウェアはどのような 標準外の PostScript オペレータでも安全であることを確保し、そ していかなる種類の脅威でも提示すべきである。 (6) 莫大な量の様々なシステムリソースを消費する PostScript を書く ことが可能である。また無限ループする PostScript プログラムを 書くことも可能である。プログラムの両方のタイプがもし信頼され た受信者に送られたなら、損害を起こす可能性を持っている。メッ セージ送信ソフトウェアは、そのような反社会的なプログラムの作 成や配布を回避すべきである。メッセージを受信し表示するソフト ウェアは、妥当な量の時間が経過した後、処理を中止するための適 切なメカニズムを提供するべきである。さらに PostScript インタ プリタは、適切な量のいくらか与えられたシステム・リソースだけ を消費するよう制限すべきである。 (7) PostScript 内の生(未加工)のバイナリ情報に様々なフォームに含 めることが可能である。それは全ての PostScript インタプリタで サポートされるとは限らず、MIME Content-Transfer-Encoding の 使われ方をかなり複雑にするため、これはインターネットメールで の利用は推薦されない（そのようなバイナリ無しでは、PostScript は典型的な行指向のデータと見られるかもしれない。もしバイナリ とライン指向のデータが一つの Postscript データストリームに混 成されると、CRLF シーケンスの処理は極めて疑わしくなる)。 (8) 最後に、バグは、ことによると受信者のシステムへの不当なアクセ スを得るために利用できるものが、いくつかの PostScript インタ プリタに存在するかもしれない。もしバグがあれば見つけられるそ のようなものの時機を得た修正は別として、この可能性に注目する 以外に、これを妨げるのに費やすための特定の動作がない。 4.5.3. 他の Application サブタイプ 将来、"application" の多くの他のサブタイプが定義されることが予測さ れる。MIME 実装は、最小の扱い "application/octet-stream" に相当する ように、あらゆる未認識サブタイプを扱わねばならない。 5. Composite メディアタイプの値 7つの初期 Content-Type 値のうちの残り2つは、合成のエンティティを参 照する。合成のエンティティは、MIMEメカニズムを使って処理される…MIME プロセッサは、典型的にボディを直接扱う。 5.1. Multipart メディアタイプ マルチパートの場合は、エンティティ（データの1つ以上の異なるセット が単一のボディ "multipart" メディアタイプフィールドにおいて結合され る) は、エンティティのヘッダに現れなければならない。境界デリミタ行、 及び、終りの境界デリミタ行を従えている最後のものによってそれぞれ先行 されて、ボディはそれから 1つ以上のボディ領域を含まなければならない。 その境界デリミタラインの後で、各ボディパートは、ヘッダ領域、ブランク 行、そしてボディ領域から成る。従って、ボディパートの構文は、RFC 822 メッセージと同様である。しかし意味が違う。 ボディパートはエンティティである故に、実際に RFC 822 メッセージで あると解釈される必要は【ない】。まず第一に、ヘッダフィールドはボディ パートでは実際に全く必要と【されない】。従ってブランク行(空行)から開 始されるボディ部分を考慮し、そして、ボディ部分では全てのデフォルト値 が推測される。そのようなケースにおいて、Content-Type ヘッダの欠如は 対応したボディが "text/plain; charset=US-ASCII" の Content-Type を 持っていることを通常示す。 ボディパートのために意味を定義した唯一のヘッダフィールドは、名前が "Content-" から始まるそれらである。全ての他のヘッダフィールドは、ボ ディパートで無視できる。それらが一般にできる限り保存されるべきだが、 もしそれらは必要なら、ゲートウェイによって処分できる。そのような他の フィールドがボディパートに出現することは可能だが、それには依存しては ならない。それらが含む情報がいくらかのゲートウェイで失われるかもしれ ないという認識に関して、"X-" フィールドは、実験的もしくはプライベー トな目的のために作成されるかもしれない。 注意事項: RFC 822メッセージとボディパートの間の区別は微妙だが重要である。 例えばインターネットと X.400 メールとの間のゲートウェイは、イメー ジを含むボディパートとボディが JPEGイメージのカプセル化されたメッ セージボディを含むボディパートの違いを見分けることができなければ ならない。"Content-Type: image/jpeg" ヘッダフィールドに関して、後 者を表すために、ボディパートは "Content-Type: message/rfc822" を 持たねばならず、そのボディ（ブランク行の後で）は、カプセル化され たメッセージでなければならない。同様な構文の使用はメッセージのボ ディパート（逆もまた同様であるが）への変換を容易にする。2つの区別 は実装者により理解されなければならない（パートが実際にメッセージ である特別な場合の間、"digest" サブタイプは同様に定義される）。 前述のとおり、個々のボディパートには、境界デリミタを含んでいる境界 デリミタラインが先行する。境界デリミタは、単独でライン上、もしくはど のような行の接頭辞としても、カプセル化された部分のうちのどれの中でも 出現【してはならない】。これは、構成するエージェントが接頭辞として囲 んでいるマルチパートの境界パラメータ値を抑制しない唯一の境界パラメー タ値を選択し、そして指定することが可能なことが決定的であることを意味 している。 "multipart" タイプのすべての現在および将来のサブタイプは、同一の構 文を使わなければならない。サブタイプはそれらの語義について異なり、付 加的な制限を構文に課すかもしれないが、"multipart" タイプのために必要 な構文に対応しなければならない。この要件は、すべての対応ユーザーエー ジェントが、少なくとも、未認識のサブタイプのそれらでさえ、どのような マルチパートエンティティのパートでも認識し、そして分割できることが保 証される。 Content-Transfer-Encoding フィールド [RFC 2045] の定義において述べ られているように、"7bit"、"8bit"、または "binary" 以外の符号化は、タ イプ"multipart" のエンティティのためには許されていない。個々の適切な ボディパートのための Content-Transfer-Encoding フィールドに関して、 "multipart" 境界デリミタとヘッダフィールドは、あらゆるケース(ヘッダ フィールドが RFC 2047 と同様に 非 US-ASCII ヘッダテキストを符号化す るかもしれないけれども)やボディパート中のデータは7ビット US-ASCII と して常に表現され、そして part-by-part ベースで符号化され得る。 5.1.1. 共通構文 このセクションは "multipart" サブタイプのための共通の構文を定義す る。"multipart" の全てのサブタイプはこの構文を使わなければならない。 同様に、マルチパートメッセージの簡単な例は、このセクションに登場して いる。より複雑なマルチパートメッセージの例は、RFC 2049において示され ている。 マルチパートエンティティのための Content-Type フィールドは、1つの パラメータ "boundary" を必要とする。境界デリミタラインは、完全に、 Content-Type ヘッダフィールド、オプションのリニアの空白文字、および 末端 CRLF から境界パラメータ値が続いている 2つのハイフン文字（"-"、 10進値 45）から成っている行、と定義される。 注意事項: ハイフンは、メッセージカプセル化の早期 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 値は、ヘッダ領域が完全に空であることが可能にされ る以外、内容が、1つ以上の部分 (それぞれ RFC 822 メッセージと構文上同 一の構造を持つ) から成り、パートそれぞれに行が先行することを示す。 --gc0pJq0M:08jU534c0p 境界デリミタは行の最初に発生【しなければならない】。すなわち、CRLF 及び最初の CRLF の後に続くことが、先行部分の一部よりむしろ、境界デリ ミタラインに接続されると考えられる。境界は、リニアの空白の 0以上の文 字により続いているかもしれない。それは、その時次のパートのための別の CRLF とヘッダフィールド、または2つの CRLF によりターミネートされて、 その場合、次のパートのためのヘッダフィールドではない。Content-Type フィールドが存在しないなら、それは別の方法で "multipart/digest" か、 さもなければ "text/plain" 及び "message/rfc822" であるとみなされる。 注意事項: 境界デリミタラインに先行している CRLF が境界に概念的に付加され ているので、CRLF（改行）によって終わらない部分を持つことが可能で ある。従って、改行によって終わると考えられなければならないボディ パートは、境界デリミタライン（が前のボディパートの一部、かつどち らかがカプセル化された境界の一部の二番目）に先行している 2 CRLF を持っていなければならない。 境界デリミタは、カプセル化された素材内で出現してはならず、かつ70文 字を越えてはならず、2つの主要なハイフンをカウントしない。 最後のボディパートの後に続く境界デリミタラインは、それ以上のボディ パートが続かないことを顕著に示すデリミタである。境界パラメータ値の後 の 2個のハイフンの追加に関して、そのようなデリミタラインは、前のデリ ミタラインと同一である。 --gc0pJq0M:08jU534c0p-- 実装者への注意事項: 境界文字列の比較は、境界値を個々の候補者行の最初と比較しなけれ ばならない。全体の候補者行の正確なマッチは必要ではない; 境界が、 CRLF の後に続くその全体で現れることは、十分である。 そこで、追加情報の余地は、最初の境界デリミタ行の前、そして、最後の 境界デリミタ行に引き続きあるように思われる。これらの領域は、ふつう空 白の状態にしておかれるべきであり、実装は、最初の境界デリミタラインの 前か最後の一つ以降に出現するあらゆるものを無視しなければならない。 注意事項: これらの "preamble" (前文)と "epilogue" (末文) 領域は、これらの パートの適切なタイプの不足、及び、特に X.400 gateways というゲー トウェイにおいてこれらの領域を処理するための平易な語義の不足のた め、ふつう使われない。しかし、前文領域をブランクの状態にするより むしろ、そのような通知が MIME-compliant (MIME準拠) ソフトウェアに より無視されるので、多くの MIME 実装は、pre-MIME ソフトウェアによ りメッセージを読んだ受信者のための注記を挿入する便利な場所である と気付いた。 注意事項: 境界デリミタがカプセル化されたボディパートに現れてはならないの で、ユーザーエージェントは、唯一の境界パラメータ値を選択するため に注意せねばならない。上記の例の境界パラメータ値は、既にデータを プリスキャン(前調査)せずにカプセル化されるデータに存在する非常に 低い可能性によって境界デリミタを生み出すようにデザインされたアル ゴリズムの結果であっただろう。交替のアルゴリズムは高齢のユーザー エージェントと受領者のための「より読みやすい」境界デリミタを結果 として生じるかもだろうが、境界デリミタがカプセル化されたパートに おけるあるラインの初めに出現する可能性に対するより多くの注意を必 要とする。"-----" の終わりの境界デリミタラインに関して、可能な限 りの最もシンプルな境界デリミッターラインは、多少 "---" のようであ る。 非常に簡単な例（以下のマルチパートメッセージは2つのパートに双方と もプレーンテキストを持っています）として、それらのうちの1つは明示的 にタイプし、そして、それらのうちの1つはそれとなくタイプしました: From: Nathaniel Borenstein To: Ned Freed Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST) Subject: サンプルメッセージ MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary" これは前文である。MIME 非準拠のリーダに含むことが、合成 エージェントのための便利な場所であるが、それは無視され る必要がある。 --simple boundary これは、それとなくタイプされた平易なUS-ASCIIテクストで ある。それは linebreak(改行) によって【終わらない】。 --simple boundary Content-type: text/plain; charset=us-ascii これは、明示的にタイプされた平易なUS-ASCIIテクストであ る。それは linebreak(改行) によって【終わる】。 --simple boundary-- これは文末である。それはまた無視される必要がある。 〔訳注：上記のメール文は全て訳したが、本当に日本語を本文に記述 する場合は、Content-type で日本語の指定をしたり、base64 など へ変換したりしなければならない〕 他の "multipart" エンティティ内のボディパートにおける "multipart" のメディアタイプの使用は明示的に許される。そのような場合、明らかな理 由のため、個々のネスティングされた "multipart" エンティティが異なる 境界デリミタを利用することを保証するために気をつけなければならない。 ネスティングされた "multipart" エンティティの例のための RFC 2049 を 見よ。 単一ボディパートのみに関する "multipart" メディアタイプの使用は、 一定の文脈で有益であるかもしれず、そして明示的に許される。 注意事項: 経験は、単一のボディパートに関する "multipart" メディアタイプが 非テクストメディアタイプを送るのに有益であることを示した。それは 命令を解読することを含む場所として前文を提供するより有利である。 さらに、幾つかの SMTP ゲートウェイは MIME ヘッダを動かすか、また は削除し、そして賢い MIME デコーダは、Content-Type ヘッダが無い時 さえマルチパート境界でよい推測を取り、それによってメッセージを首 尾よく解読できる。 "multipart" メディアタイプのための、唯一の強制的なグローバルなパラ メータは境界パラメータであり、非常に頑強であると知られている文字セッ トから空白で【終わらない】メールゲートウェイまでの 1 ～ 70 文字か ら成る ) である。 "multipart" メディアタイプのための唯一強制的なグローバルなパラメー タは境界パラメータであり、メールゲートウェイを通して非常に頑強である と知られている文字のセットの 1～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 範囲外に含むように、ボディの定義をローカルに拡張す ると解釈されるべきである。しかし、どのイベントにおいても、ヘッダ （メッセージヘッダまたはボディパートヘッダのいずれか）が US-ASCII 文字を除いた何でも含んでいることは可能にされない。 注意事項: "multipart" タイプから目立って外れることは、関連したボディパー トの構造化の観念である。より多くの構造化された、もしくは、統合さ れたマルチパートな通信設備を提供することを望むそれらが構文的に同 じであるが、様々な部分の間の関係を定義するマルチパートのサブタイ プを定義するべきであるということが勧められる。例えば、マルチパー トのサブタイプは、他の部分の間の関係を指定するために交互に使われ る顕著な部分を含み、おそらくそれらの Content-ID フィールドの近く でそれらを参照するように定義されるだろう。もしこのアプローチが使 われるならば、古い実装は新しいサブタイプを認識しないだろう。しか し multipart/mixed であるので、それを扱い、そしてこのように認識さ れるパートをユーザーに示すことができるだろう。 5.1.2. ネストされた Messages と Multiparts の取り扱い この文書の次のセクションで定義された "message/rfc822" サブタイプは データを実行以外の終端条件を持っていない。同様に、不適切に切りつめら れた "multipart" エンティティは、どのような終端境界マーカーも持つこ とができず、メールシステム誤動作のため操作上現れるかもしれない。 それらがそれら自身が別の "multipart" 構造の中の埋め込まれるとき、 そのようなそのようなエンティティが正しく処理されることは必須である。 従って、MIME 実装は【あらゆる】レベルの内側のネスティングで外のレベ ル境界マーカーを認識するために必要である。隣の予期されたマーカー、ま たは他の終端条件をチェックすることだけが十分ではない。 5.1.3. Mixed サブタイプ ボディパートが独立し、そして、特別な順番にバンドルされる必要がある とき、"multipart" の "mixed" サブタイプが使われるように意図されてい る。実装が認識できないあらゆる "multipart" サブタイプは "mixed" とい うサブタイプであるとして扱われなければならない。 5.1.4. Alternative サブタイプ "multipart/alternative" タイプは、"multipart/mixed" と構文上は同一 であるが、語義は違う。特に、ボディパートのうちのそれぞれは、同じ情報 の "alternative" (代替) バージョンである。 システムは、様々なパートの内容が交換可能であることを認識すべきであ る。ユーザーインタラクションによってさえも、いくらかの場合において、 システムは、ローカルな環境と参照に基づく "best" タイプを選択するべき である。"multipart/mixed" と同様に、ボディパートのオーダーは重要であ る。この場合、これに代るものは、忠実さをオリジナルの内容に増加するこ との順番に現れる。一般に、最も良い選択は受信者システムのローカルな環 境によってサポートされたタイプの【最後】の部分である。 "Multipart/alternative" は、例えば、それがどこにでも容易に表示でき るように、メッセージを装飾的なテクストフォーマットで送るために使われ るかもしれない: From: Nathaniel Borenstein To: Ned Freed Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST) Subject: フォーマットされたテクストメール 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-- 〔訳注：上記のメール文は全て訳したが、本当に日本語を本文に記述 する場合は、Content-type で日本語の指定をしたり、base64 など へ変換したりしなければならない〕 この例でいうと、それらのシステムの能力に応じて、メールシステムが "application/x-whatever" フォーマットを理解したユーザーは、装飾的な バージョンのみ見るであろう。一方、他のユーザーはエンリンッチ、もし くは平易なテクストバージョンのみ見るであろう。 一般に "multipart/alternative" エンティティを構成するユーザーエー ジェントは、すなわち、好まれたフォーマットによる最後に、ボディーパー トを増大注文に置かなければなりません。装飾的なテクストのために、発送 ユーザーエージェントは、最初に最も平易なフォーマットを、そして最も豊 かなフォーマットは最後に置くべきである。受領ユーザーエージェントは、 それらが表示できる最後のフォーマットを選び、表示するべきである。選択 肢のうちの1つがそれ自身 "multipart" というタイプをもっている場合、お よび認識できないサブパートを含んでいることにおいて、ユーザーエージェ ントは、その選択肢、より早い選択肢、または両方を示すことを選ぶことが できる。 注意事項: 実装者の展望から、この注文を逆転することは、更に賢明なように思 われ、そして、最後に最も明瞭な代替を持つかもしれない。しかしなが ら、"multipart/alternative" エンティティが MIME 非準拠ビューアを 使って見られる時、最初に最も平易な選択肢を置くことは、友好的可能 性のあるオプションである。このアプローチが、ある負担を MIME 準拠 ビューアに課す、と同時に、更に年上のメールリーダに関する相互運用 性は、この場合更に重要であると考えられた。 それらがフォーマットのうちの 1つより多くを承認するならば、幾らかの ユーザーエージェントが、どちらのフォーマットを見るかの選択をユーザー に提供する方を好むであろうことは、そのケースであるかもしれない。例え ば、メッセージがきちんとフォーマットされたイメージバージョンと、簡単 に編集されたテクストバージョンを含むならば、これは意味を成すだろう。 しかしながら、最も危険なのはユーザーが同じデータの多重バージョンを自 動的に示さないことである。同様に、ユーザーは最後に認識されたバージョ ンを示すか、または選択を行うべきである。 multipart/alternative の content-id の語義: "multipart/alternative" エンティティの個々の部分は、同じデータ を表している。しかし、2つの間のマッピングは、必ずしも情報損失がな いとは限らない。例えば、ODA を PostScript またはプレーンテクスト に変換する時に情報は失われる。2つのパートの情報内容が異なる場合に は、個々のパートが異なる Content-ID 値を持つことを推奨される。そ して受信者の終わりの時に存在するかもしれないどのようなキャッシュ メカニズムでも最適化するために、情報内容が同一である … 例えば、 タイプ "message/external-body" の幾らかの部分は、交互の方法が同一 のデータにアクセスすると明示する … とき、同じ Content-ID フィー ルド値は使われるべきである。しかし、あらゆるそのような Content-ID フィールドがあるならば、パーツによって使われる Content-ID 値は、 全体として "multipart/alternative" を記述するのと同じ Content-ID 値である【べきではない】。すなわち、1つの Content-ID 値は、 "multipart/alternative" エンティティを参照する一方、1つ以上の他の Content-ID 値は、それの中のパートを参照するだろう。 5.1.5. Digest サブタイプ この文書は "multipart" Content-Type の "digest" サブタイプを定義す る。このタイプは "multipart/mixed" と構文は同一だが、語義は違う。特 にダイジェストにおいて、ボディパートのためのデフォルト Content-Type 値は、"text/plain" から "message/rfc822" に変えられる。これは、主と して RFC 934 と互換性がある（引用している規定を除いて）より読みやす いダイジェストフォーマットを許すために行われる。 注意事項: 実際に行うダイジェストに材料の記述を含む "text/plain" パート部 分のような、"message/rfc822" より他のものであるダイジェストにお いて、部分的ボディのために Content-Type 値を指定することが可能で あるけれども、実際にそうすることが望ましい。"multipart/digest" Content-Type は、メッセージのコレクションを送るために使用される ことを意図している。もし "text/plain" パートが必要ならば、それは "multipart/mixed" メッセージの個別部分として含まれるであろう。 このフォーマットのダイジェストは、その時、多少これのように見えるか もしれない: From: 議長のアドレス To: 受領者リスト Date: Mon, 22 Mar 1994 13:34:51 +0000 Subject: インターネットダイジェスト 第42巻 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- main boundary ----" ------ main boundary ---- … 入門のテクストまたは目次 … ------ main boundary ---- Content-Type: multipart/digest; boundary="---- next message ----" ------ next message ---- 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 ------ 〔訳注：上記のメール文は全て訳したが、本当に日本語を本文に記述 する場合は、Content-type で日本語の指定をしたり、base64 など へ変換したりしなければならない〕 5.1.6. Parallel サブタイプ この文書は、"multipart" Content-Type の "parallel" サブタイプを定 義する。このタイプは "multipart/mixed" と構文は同一だが語義は違う。 特に、パラレルエンティティでのボディパートの順番は重要ではない。 このタイプの共通のプレゼンテーションは、そうする可能性があるハード ウェアとソフトウェアにおいて、同時にパートのすべてを表示することであ る。しかし、エージェントを構成することは、多くのメールリーダがこの機 能を欠き、そして、連続してとにかくパートを示すことに気づいているはず である。 5.1.7. 他の Multipart サブタイプ 他の "multipart" サブタイプは将来に予約される。 MIME 実装は、"multipart/mixed" と等しいこととしての "multipart" の 概して未認識であるサブタイプにおいてしなければならない。 5.2. Message メディアタイプ 別のメールメッセージをカプセル化するために、メールを送る際、それは 頻繁に望ましい。特別なメディアタイプ "message" は、これを容易にする ために定義される。特に、"message" の "rfc822" サブタイプは、RFC 822 メッセージをカプセル化するために使用される。 注意事項: 転送された、または拒絶されたメッセージのために "message" のサブ タイプが定義されうることが提案された。しかし、転送されたおよび拒絶 されたメッセージは、最初の部分がどのようなコントロールまたは記述的 な情報でも含んでいるマルチパートメッセージとして処理できて、タイプ "message/rfc822" で、2番目の部分が、転送されたまたは拒絶されたメッ セージである。この方法での創作拒絶と転送メッセージは、オリジナルな メッセージについてのタイプ情報を保存し、それが受信者に正しく提示さ れることを可能にし、それゆえ強く奨励される。 "message" のサブタイプは、符号化がが許されることに制限をしばしば課 す。これらの制限は、個々の特定のサブタイプと連携して示される。 メールゲートウェイ、リレー、および他のメール処理エージェントは、一 般的に RFC 822 メッセージのトップレベルのヘッダを変更するということ が知られている。特にそれらは、remove または reorder ヘッダフィールド を頻繁に付け加える。これらのオペレーションは、タイプ "message" の、 メッセージのボディに埋め込まれた、カプセル化されたヘッダのために明示 的に禁じられる。 5.2.1. RFC822 サブタイプ "message/rfc822" のメディアタイプは、RFC822 メッセージの構文によっ て、ボディがカプセル化されたメッセージを含んでいることを示す。しかし トップレベルの RFC822 メッセージと異なり、個々の "message/rfc822" ボ ディが含まかければならない制限 "From" と "Date"、そして最低1つの宛先 ヘッダは削除され、要件と交換される。少なくとも "From"、"Subject"、そ して "Date" のうちの最低1つは存在しなければならない。 数 "822" の使用にもかかわらず、"message/rfc822" エンティティが RFC 822 への厳密な対応における素材に限定されない、そして、RFC 822 におい て定義された語義に限定された "message/rfc822" オブジェクトの語義であ ることは言及されるべきである。より明確に、"message/rfc822" メッセージ は、よくニュース記事または MIMEメッセージであるだろう。 "7bit"、"8bit"、または "binary" を以外の符号化は、"message/rfc822" エンティティのボディのためには許されていない。メッセージヘッダフィー ルドはともかく常に US-ASCII であり、ボディ内のデータがまた符号化でき て、その場合、カプセル化されたメッセージの Content-Transfer-Encoding ヘッダフィールドは、これを反映する。カプセル化されたメッセージのヘッ ダの 非 US-ASCIIテクストは、RFC 2047 において説明されたメカニズムを 使って指定される。 5.2.2. Partial サブタイプ "partial" サブタイプは、大きいエンティティがメールのいくつかの別個 の断片として届けることを可能にするために定義され、そして受信ユーザー エージェントによって自動的に再集合される（概念は基本的なインターネッ トプロトコルのIPフラグメンテーションと再アセンブリと同様である）。中 間のトランスポートエージェント(輸送エージェント)が、送られうる個々の メッセージのサイズを制限する時このメカニズムは使われうる。メディアタ イプ "message/partial" が示すボディが更に大きいエンティティの断片を 含むことをこのように示す。 タイプ "message" のデータが base64 または quoted-printable では決 して符号化されないかもしれないので、"message/partial" エンティティが サポートするバイナリまたは 8ビットトランスポートの環境において組み立 てられるならば、問題が起こるだろう。 問題は、バイナリのデータが複数の "message/partial" メッセージに分 割されて、それらのうちの各々がバイナリトランスポート(バイナリ輸送)を 必要とすることである。もしトランスポート環境にゲートウェイでそのよう なメッセージに遭遇したなら、断片の全てを待つことから離れ、内側のメッ セージを再び集め、そして base64 または quoted-printable において再び 集められたデータを符号化するために、7ビット環境のためにそれらを適切 に符号化する方法がないだろう。異なる断片が異なるゲートウェイを通過す ることも可能なので、これさえ容認できる解決策ではない。この理由のため に、タイプ "message/partial" 必需品の実体が 7ビット(デフォルト) の content-transfer-encoding を常に持つことが明示される。特に、バイナリ や 8ビットのトランスポート環境でさえ "8bit" や "binary" の content- transfer-encoding の使用は、明白にタイプ "message/partial" の MIME実 体のために禁止される。これは、内側のメッセージが "8bit" や "binary" の符号化を使ってはいけないことを次々暗示している。 何人かのメッセージ証券代行業者が、大きいメッセージを自動的にばらば らにすることを決め、そして、そのようなエージェントが非常に種々の断片 化のしきい値を使うかもしれないので、部分的なメッセージから成るように 再アセンブリに関して部分的なメッセージを含むことをそれら自体が証明す ることが可能である。これは明白に許される。 3つのパラメータは、タイプ "message/partial" の Content-Type フィー ルドにおいて指定されなければならない: 1番目 "id" は、できる限り世界 的に一意な識別子で、断片に共にマッチするために使われる一意の識別子で ある(一般に、message-id は本質的に message-id である; ダブルクォート に配置されたそれが【どんな】message-id であっても、それは "parameter" のために RFC 2045 において与えられた BNF に従う)。2番目、"number" 整 数は断片の番号であり、それは、どこでこの断片が断片の連続に納まるかを 示している。3番目、"total"、他の整数が断片の全体の数である。この3番 目のサブフィールドが最後の断片において必要となるが、それ以前の断片で はオプションである（が、付けることを薦める）。これらのパラメータがあ らゆる順番に示されるかもしれないことに同じく注意しなさい。 従って、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から始まることに注意しなさい。 この方法で分割されたエンティティの断片が組み立てられる時には、結果 はいつも完全な MIMEエンティティであり、それ自身の Content-Type ヘッ ダフィールドを持ち、従って、どのような他のデータ型でも含んでいるかも しれない。 5.2.2.1. メッセージフラグメンテーションと再アセンブリ 再集合された部分的なメッセージの語義は、内側のメッセージを含むメッ セージというよりも、むしろ "inner" (内側の) のメッセージのそれらでな ければならない。これは、例えば、いくつかの部分的なメッセージとして大 きなオーディオのメッセージを送ることを可能にし、さらに、オーディオの メッセージを含んでいるカプセル化されたメッセージというよりも、まだそ れをシンプルなオーディオのメッセージとして受信者に出現させたい。すな わち、メッセージのカプセル化は "transparent" (透明だ) と考えられる。 "message/partial" メッセージの断片を生成し、そして再集合する時は、 カプセル化されたメッセージのヘッダは包囲エンティティのヘッダと合併さ れなければならない。このプロセスにおいて、以下の規則は遵守されなけれ ばならない: (1) 断片化エージェントは、行の境界だけでメッセージを分割しなけれ ばならない。行端以外のポイントでの分割は、メッセージトランス ポートが交互に CRLF シーケンスで終わらないメッセージの語義を 守ることができることにより変わるためこの制限は課される。多く のトランスポートは、そのような語義を守ることが不可能である。 (2) 初期包囲メッセージからのヘッダフィールドの全ては "Content-"、 及び、特定のヘッダフィールド "Subject"、"Message-ID"、 "Encrypted"、および "MIME-Version" 以外で始まる新しいメッセー ジに順番にコピーされなければならない。 (3) "Content-" に加え、"Subject"、"Message-ID"、"Encrypted"、そし て "MIME-Version" フィールドで新しいメッセージのヘッダフィー ルドは、新しいメッセージのヘッダフィールド順番に付加されねば ならない。"Content-" （"Subject"、"Message-ID"、"Encrypted"、 および "MIME-Version" フィールドを除く）で始まらない同封され たメッセージのあらゆるヘッダフィールドでも無視されて、落とさ ねばならない。 (4) 2番目、及び、あらゆる次の包囲メッセージからのヘッダフィール ドのうちの全てでも再アセンブリプロセスにより処分される。 5.2.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 … 符号化されたオーディオデータの前半はここに … … 符号化されたオーディオデータの後半はここに … 2番目のヘッダ、及び、前の断片の Message-Id が参照を付けるばらばら にされたメッセージの、次の断片における "References" フィールドの包含 は、参照を理解し、そして追跡するリーダをメールするために、利点がある かもしれない。しかし、そのような "References" フィールドの発生は完全 にオプションである。 最後に、"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" であるとき、それはヘッ ダ、2つの連続的な 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 【これは本当はボディではない！】 "phantom body" と呼ばれうる終わりの領域は、大部分の external-body メッセージのために無視される。しかし、それは、実にいつアクセスタイプ "mail-server" であるかなので、いくらかのそのようなメッセージのために 補助の情報を含むために使われるかもしれない。phantom ボディを使うこの 文書において定義された唯一のアクセスタイプは、"mail-server" である。 しかし、将来他のアクセスタイプは、この領域を使う他の仕様書において定 義されるかもしれない。 【すべて】の "message/external-body" エンティティのカプセル化され たヘッダは、一意な識別子でデータのどちらに参照を付けるかを与えるため に、Content-IDヘッダフィールドを【含まなければならない】。この識別子 はメカニズムをキャッシュする、そしてアクセスタイプが "mail-server" である時にデータの受け取りを認めるために使われるかもしれない。 ここで外部のボディデータを示すトークンがファイル名やメールサーバコ マンドなどのように US-ASCII キャラクタセットにあることが必要とされる ことが指定されるように、注意しなさい。 "message/external-body" のための新しく定義されたアクセスタイプ、あ るいは他のメカニズムによって、もしこれが実際の場で疑わしいと判明する ならば、新しいメカニズムが MIME への未来の拡張として必要となろう。 "message/partial" として、タイプ "message/external-body" の MIME エンティティは、7ビット (デフォルト) の content-transfer-encoding を持っていなければならない。特に、バイナリ、もしくは 8ビットのトラン スポートをサポートする環境においてさえも、"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" に制限されない。RFC 2048 において説明され るように、将来の値は、"X-" から始まる実験的な値を除き、IANA によって登録されなければならない。このパラメータは無条件に必 須であり、そして【すべて】の "message/external-body" 上で存 在【しなければならない】。 (2) EXPIRATION -- その後に外部のデータの存在が保証されない日付 （これは、RFC 1123 により年のフィールドで4桁を許可するように 拡張された RFC 822 "date-time" の構文による）。このパラメー タは【どのような】アクセスタイプでも使われ、そして【常に】オ プションである。 (3) SIZE -- データのサイズ(オクテット)。このパラメータの意図は、 受信者が外部のデータを検索するために、必要な資源を費やすかど うかを決める手助けすることである。これがその正規のフォームに おいて、すなわち、どのような Content-Transfer-Encoding でも 適用される前に、またはデータが解読された後にこれがデータのサ イズを説明することに注意せよ。このパラメータは【どのような】 アクセスタイプによっても使われ、【常に】オプションである。 (4) PERMISSION -- クライアントが、データに上書きすることを試みる ことが予期されるかどうかを示す、大文字小文字を問わないフィー ルド。デフォルトか、もしくは permission が "read" ならば、仮 定はそれではなく、もしデータが一旦検索されるならば、決して再 びそれが必要とされないということである。もし PERMISSION が、 "read-write" なら、この仮定が無効で、そしてどのようなローカ ルなコピーでもキャッシュと考えられなければならない。"Read"、 および "Read-write" は、許可の唯一の定義された価値である。こ のパラメータは【どのような】アクセスタイプによっても使われ、 【常に】オプションである。 ここで定義されたアクセスタイプの正確な語義は、後続のセクションで説 明される。 5.2.3.2. 'ftp' と 'tftp' アクセスタイプ それぞれ、FTP または TFTP のアクセスタイプは、メッセージボディーが FTP [RFC-959] または TFTP [RFC-783] プロトコルを使うファイルとしてア クセス可能であることを示す。これらのアクセスタイプのために、以下の付 加的なパラメータが必須となる: (1) NAME -- 実際のボディデータを含んでいるファイルの名前。 (2) SITE -- ファイルが、与えられたプロトコルを使って得られうるマ シン。これはニックネームではなく、完全なドメイン名でなければ ならない。 (3) どのようなデータでも検索される前に、FTP、ユーザーを使うこと は、一般にサイトパラメータにより指定されたマシンにログインid とパスワードをを提供するように要求される必要があるだろう。セ キュリティ理由のために、そのような id 及びパスワードは、コン テンツタイプパラメータとしては指定されないが、しかしユーザー から獲得されなければならない。 さらに、以下のパラメータはオプションである: (1) DIRECTORY -- NAME によって指定されたデータが取り出されるべき ディレクトリ。 (2) MODE -- 情報検索時に使われるモードを示す大文字小文字を問わな い文字列。TFTP プロトコル [RFC-783] で指定されるようにアクセ スタイプ "TFTP" のための有効な値は "NETASCII"、"OCTET"、およ び "MAIL" である。アクセスタイプ "FTP" のための有効な値は、 "ASCII"、"EBCDIC"、"IMAGE"、及び "n" が10進の整数（一般に8） である "LOCALn" である。FTP プロトコル [RFC-959] により指定 されるように、これらは表現タイプ "A" "E" "I"、及び "L n" と 一致する。"BINARY" と "TENEX" が、MODE のための有効な値では ないため、"OCTET"、"IMAGE"、もしくは "LOCAL8" が代わりに使わ れるべきであることに注意せよ。もし、MODE が指定されないなら ば、デフォルト値は別の方法で TFTP、そして "ASCII" のために "NETASCII" である。 5.2.3.3. 'anon-ftp' アクセスタイプ 指定されたサイトに名前とパスワードを提供するために、ユーザーに必要 性が尋ねられるということを除けば、"anon-ftp" アクセスタイプは、"ftp" アクセスタイプと同じである。その代わりに、ftp プロトコルは、ログイン を "anonymous" の状態にして使われる。そして、ユーザーのメールアドレ スと一致するパスワードが使われる。 5.2.3.4. 'local-file' アクセスタイプ "local-file" のアクセスタイプは、実際のボディがローカルなマシン上 のファイルとしてアクセス可能であることを示す。このアクセスタイプのた めに2つの付加的なパラメータが定義される: (1) NAME -- 実際のボディデータを含むファイルの名前。このパラメー タは "local-file" アクセスタイプのために必須である。 (2) SITE -- マシンのためのドメイン指定子、またはデータファイルに アクセスできると知られているマシンのセット。このオプションの パラメータは、データ、すなわちファイルが見えることが期待され ているサイト、またはサイトのための参照の場所を記述するために 用いられる。データが直接見えるはずのマシンのセットを示すため に、アステリスクは、"*.bellcore.com" のようなドメインネーム の一部にマッチするワイルドカードのために利用される一方、1つ のアステリスクは、例えばグローバルなファイルシステムによって 一般に入手可能であると予測されるファイルを示すために使われう る。 5.2.3.5. 'mail-server' アクセスタイプ "mail-server" アクセスタイプは、実際のボディがメールサーバから入手 可能であることを示す。このアクセスタイプのために、2つの付加的なパラ メータが定義される: (1) SERVER -- 実際のボディデータが得られるはずの、メールサーバの addr-spec。このパラメータは "mail-server" アクセスタイプのた めに必須である。 (2) SUBJECT -- データを獲得するために送られるメールに使われるべ きサブジェクト(主題)。サブジェクト行上でメールサーバを合わせ ることは推奨【されない】が、そのようなメールサーバが存在する ことが知られていることに注意しなさい。これはオプションのパラ メータである。 メールサーバが各種の構文 (いくらかがマルチライン[複数行]である) を 受け付けるので、メールサーバに送られる完全なコマンドは content-type ヘッダフィールドのパラメータとして含まれない。その代わり、メディアタ イプが "message/external-body" であり、アクセスタイプが mail-server である時は、"phantom body" として提供される。 MIME がメールサーバ構文を定義しないことに注意しなさい。それどころ か、それは phantom ボディに任意のメールサーバコマンドの含有を許して いる。実装では、適切なデータを検索するために、それがメールサーバアド レスに送るメッセージのボディに phantom ボディを含めねばならない。 他のアクセスタイプと違って、メールサーバアクセスは非同期で、将来予 測不可能な時間に起こる。この理由のために、返されたデータがオリジナル の "message/external-body" エンティティとマッチさせられ得るメカニズ ムがあることは、重要である。そのようなマッチを容易にするように、MIME メールサーバはオリジナルな "message/external-body" エンティティに使 われたのと同じ返されたメッセージの同じ Content-ID フィールドを使わな ければならない。 5.2.3.6. External-Body セキュリティ問題 "Message/external-body" エンティティは、2つの重要なセキュリティ問 題を起こす: (1) 効果的に "message/external-body" 参照によりデータにアクセス することは、メッセージ発信者により指定されたオペレーションを 実行しているメッセージ受信者を結果として生じる。従って、メッ セージ発信者は、受信者をだましてそれらが別の方法でしなかった であろう何かをしさせることが可能である。例えば、受取人にある セキュリティ方針に知らず知らずに違反させて、発信者は、受信者 が獲得する、権限を与えられない素材の検索を試みる動作を指定す るだろう。この理由のために外部参照の解決が可能であるユーザー エージェントは、それを実行することに先がけて受取人を好きにな り、明白な権限を求め、常にそれらに対するものである動作を示す 措置をとらなければならない。 内容が、オリジナルメッセージの発信者により指定されている新し いメッセージを送信することが、受領者をもたらすという点で、 'mail-server' アクセスタイプは特に無防備である。乱用の可能性 が与えられて、構成されるあらゆるそのような要求メッセージは、 それらが MIME "message/external-body" 参照を解決する試みにお いて自動的に(例えば Comments: ヘッダフィールドにおいて) 生成 されたという明瞭な徴候を抑制すべきである。 (2) MIME は、メッセージの完全性と確実性のある保証を提供する環境 において時々使われる。もし存在するならば、そのような保証は、 メッセージの実際の直接的な内容にのみあてはまるであろう … そ れらは、MIMEの "message/external-body" メカニズムを通ってア クセスされたデータに適用されるもしれないし、または適用されな いかもしれない。特に、通信システムそのものが安全な時でさえ、 あるアクセスメカニズムを破壊することは可能かもしれない。 この問題が同様に MIME メカニズムの有望性に伴い、または伴わず に存在することは注目されるべきである。安全なメッセージのテク ストに文書を含んでいる FTP サイトへの偶然の参照により同様な 問題が提出される … 唯一の違いは、MIME がそのような素材の自 動的な検索を備えることであり、ユーザーは不当な信頼を置くこと ができるかもしれない。そのような自動検索メカニズムであるとい うことである。 5.2.3.7. 例と更なる説明 外部のボディメカニズムが "multipart/alternative" メディアタイプと 連携して使われる時、同じエンティティが同じフォーマット (但し異なるア クセスメカニズム)で提供される場合を含むよう "multipart/alternative" は機能を拡張する。これが行われるとき、メッセージの発信者は、最初に好 まれたフォーマットについて、その後は好まれたアクセスメカニズムによっ てパートを並べなくてはならない。受信者のビューアはその時フォーマット とアクセスメカニズムについて、リストを双方共に評価するべきである。 非常に広い領域のファイルシステムの出現可能性に関して、ファイルシス テムでファイルが直接アクセス可能ではないマシンのセットでマシンのセッ トを前もって知ることは、非常に困難であろう。従って、それは直接試され るために、双方共にファイル名、そしてファイルがアクセス可能だと知られ ている 1つ以上のサイトの名前を提供するために意味を成すかもしれない。 匿名のファイル検索の利用、もしくは、必要な名前やパスワードの入力を ユーザーに要求し、実装は、FTP や他の何らかのプロトコルを使ってリモー トのファイルを取り出そうとすることができる。外部のボディが複数のメカ ニズムを経てアクセス可能ならば、送信側は包囲 "multipart/alternative" エンティティのボディパート内のタイプ "message/external-body" の複数 のエンティティを含むであろう。 しかし、external-body メカニズムは、mail-server アクセスタイプによ り示されたファイル検索に制限されることを意図していない。これを越え、 例えばビデオクリップに外部参照のためのビデオサーバを使うことが想像し 得る。 もし、そのタイプを宣言するために、外部のボディがヘッダセクションを 持っていないので、それが平易な US-ASCII テクスト以外の何かであるなら ば、"message/external-body" データのボディにおいて出現する埋め込まれ た message ヘッダフィールドは、外部のボディのメディアタイプを宣言す るために使用されなければならない。同様に、"7bit" 以外のどのような Content-Transfer-Encoding であっても宣言されなければならない。従って PostScriptフォーマットの目的を参照する完全な "message/external-body" メッセージは、以下の通りだろう: From: 誰でも To: 誰か Date: いつでも Subject: 何でも 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-- 上記の例において "7bit" のデフォルト Content-Transfer-Encoding が 外部の PostScript データのために推測されることに注意しなさい。 "message/partial" タイプのように、"message/external-body" メディア タイプは、そのタイプのボディのメッセージを伝えるというよりも、むしろ 透明である、すなわち、外部のボディでデータ型を伝えることを意図してい る。このように、外部および内側のパーツ上のヘッダは "message/partial" に関しては、同じ規則を使って合併されなければならない。特に、これは、 Content-type と Subjectフィールドがオーバーライドされる、しかし From フィールドが保存されることを意味している。 外部のボディが外部のボディ参照とともにがトランスポートされないので 参照そのもの適用される制限をトランスポートするためにそれらが対応する 必要がないことに注意しなさい。特に、インターネットメール輸送は 7ビッ ト、及び行長限界を課すかもしれない。だが、これらはバイナリの外部のボ ディ参照に自動的に適用されない。従って、それは可能であるが、一般に Content-Transfer-Encoding は必要がない。 タイプ "message/external-body" のメッセージのボディが RFC 822 メッ セージのための基本的な構文により制御されることに注意しなさい。特に、 最初の連続的なペアの CRLF の前の何でもヘッダ情報である一方、それの後 の何でもボディ情報である間、ほとんどのアクセスタイプのために無視され る。 5.2.4. 他の Message サブタイプ MIME エンティティは、概して "application/octet-stream" に相当する として認識されないサブタイプの "message" を扱わなければならない。 将来のサブタイプの電子メールによる使用のためのものである "message" は、"7bit" エンコーディングに限定されるべきである。もし "7bit" への 制限が不可能なら、"message" を除いたタイプが使われるべきである。 6. 実験的メディアタイプ値 "X-" という文字から始まるメディアタイプ値は、双方の合意によるシス テムに同意することによって使われるためのプライベートな値である。厳格 かつ公的な定義の無いあらゆるフォーマットは "X-" 接頭辞によって名付け られなければならず、公に指定された値は、決して "X-" から始まらないこ とになっている（広く使われたアンドリューシステムの更に古いバージョン は、"X-BE2" 名を使う。従って、新しいシステムは、おそらく違う名前を選 ぶべきである）。 一般に "X-" トップレベルタイプの使用は強く思いとどまるべきである。 実装者は、可能ならいつでも既存のタイプのサブタイプを発明するべきであ る。多くの場合、"application" のサブタイプは、新しいトップレベルのタ イプより適切であろう。 7. 要約 5つの別個のメディアタイプは、"audio"、"image"、またはいくつかの他 の種類のデータとしてのエンティティを加えるために標準化されたメカニズ ムを提供する。合成された "multipart" と "message" メディアタイプは、 一つのメッセージにおいて異なるタイプのエンティティの混在と階層的な構 造化を単一のメッセージに添えることを許す。顕著なパラメータ構文はデー タフォーマット詳細の更なる仕様、特に交替のキャラクタセットの仕様を許 す。付加的なオプションのヘッダフィールドは、多くの実装者によって望ま しいと思われた特定の拡張部分にメカニズムを提供する。最後に、幾つかの 有益なメディアタイプは、ユーザーエージェント、特に "message/partial" および "message/external-body" に同意することによって一般使用のため に定義される。 8. セキュリティ対策 セキュリティの問題については、"application/postscript" タイプ、 "message/external-body" タイプの文脈と RFC 2048 において論じられる。 実装者は、受信者の環境において、あらゆる動作のリモートの実行でも起こ すことが出来るあらゆるメディアタイプのセキュリティ含意に特別な注意を 払うべきである。そのような場合、"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 は、RFC 822 拡張の IETF(インターネット特別技術調査委員会)ワー キンググループの仕事の結果である。以下において、そのグループの議長、 Greg Vaudreuil に連絡することができる: Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA EMail: Greg.Vaudreuil@Octel.Com 付録 A -- 収集された文法 この付録は、この文書により指定されたすべての構文のための完全なBNF 文法を含んでいる。 しかしながら、単独ではこの文法は不完全である。それは、RFC 822 によ り定義されるいくつかの構文規則を名前で参照する。それどころか、ここで (２つの間の危険の故意でない差異) それらの定義を再現するより、このド キュメントは、残っている定義のために RFC 822 を読者に簡単に参照させ る。どこに用語が定義されていないなら、それは RFC 822 で定義されてい るだろう。 boundary := 0*69 bcharsnospace bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?" body-part := < ボディパート行は、指定されたダッシュ境界で 始まってはらない。また、デリミタはボディ部 分のどこにも出現してはならない。テクストに 述べられたように、ボディパートの語義がメッ セージの語義と異なることに注意しなさい。> close-delimiter := delimiter "--" dash-boundary := "--" boundary ; Content-Type フィールドの境界パラメータ値 ; から取り去られた境界。 delimiter := CRLF dash-boundary discard-text := *(*text CRLF) ; 無視されるか、または処分できる。 encapsulation := delimiter transport-padding CRLF body-part epilogue := discard-text multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] preamble := discard-text transport-padding := *LWSP-char ; コンポーザーは非ゼロ長の転送パディングを ; 生成【してはならなず】、またレシーバは、 ; メッセージ転送により追加されるパディング ; を処理【できねばならない】。