が原著。 翻訳版は、翻訳からくる間違いがあり得ます。 message メッセージ:通信(交流) o a communication passed or sent by speech, in writing, by signals etc. o a official communication/the President's message to Congress o RFC 822:messages (mail) By 1977, the Arpanet employed several informal standards for the text messages (mail) sent among its host computers. Yasutaka Kato 加藤泰孝 ----------------------------------------------------------------------  rfc2046 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) Part Two: Media Types メディアタイプ この覚書の位置付け この文書はインターネット交流社会用のインターネット標準過程手順(プロト コール)を特定し、改善への議論と提案を求めるものです。この手順の標準化 状況や位置付けについては、"Internet Official Protocol Standards" (STD 1)の最新版を見てください。この覚書の配布の制限はありません。 要約 STD 11、RFC 822、は US-ASCII通信ヘッダーについての詳細を特定する通信表 現手順を定義していますが、通信内容もしくは通信本体は平坦なUS-ASCIIテキ ストとしたままです。多目的インターネットメール拡張もしくはマインムと総 称されるこの一組の文書は、以下のことが可能になる通信形式を再定義します。 (1)通信本体でのUS-ASCII以外の文字セットによるテキスト、 (2)通信本体での非テキストの色々な形式への拡張、 (3)多元的な通信本体、そして (4)ヘッダー情報でのUS-ASCII以外の文字セットによるテキスト これら文書は、RFC 934、STD 11、と RFC 1049で文書化されている初期の作業 に基づいていますが、これを拡張改訂しています。RFC 822は通信本文につい て殆ど言及していませんので、これらの文書は(改訂というより)RFC 822と は別方向のものです。 この最初の文書、RFC 2045、はMIME通信(メッセージ)の構造を記載するため に使われる様々なヘッダーを特定します。二番目の文書、RFC 2046、はメディ アタイプシステムの一般的な構造を定義しメディアタイプの初期設定を定義し ます。三番目の文書、RFC 2047、はインターネットメールヘッダー領域(フィ ールド)に非ASCIIテキストデーターを可能にするRFC 822の拡張を記載します。 四番目の文書、RFC 2049、はMIME関連装備の色々なIANA登録手順を特定しま す。第五番目で最後の文書、RFC 2049、はMIME適合基準を記載し同時にMIME 通信書式の図解例・謝辞そして文献を提供しています。 これらの文書は、RFCs 1521・1522そして1590の改訂版で、これらそのもの はRFCs 1341と1342の改訂版でした。RFC 2049の付録に前のバージョンとの 差異と変更点が記載されています。 目次 1. はじめに ............................................. 3 2. トップレベル・メディアタイプの定義 ................... 4 3. 初期トップ-レベルメディアタイプ概要 .................. 4 4. 個別メディアタイプの値................................ 6 4.1 テキスト・メディアタイプ Text Media Type ........... 6 4.1.1 行分断の表現 .................................... 7 4.1.2 文字セット(Charset) パラメーター ................ 7 4.1.3 プレーン(Plain) サブタイプ ...................... 11 4.1.4 認識されないサブタイプ .......................... 11 4.2 画像メディアタイプ ................................. 11 4.3 音響メディアタイプ ................................. 11 4.4 ビデオ・メディアタイプ ............................. 12 4.5 アプリケーション・メディアタイプ ................... 12 4.5.1 オクテット-連続体(Octet-Stream)サブタイプ.. ..... 13 4.5.2 ポストスクリプト(PostScript)サブタイプ .......... 14 4.5.3 その他のアプリケーション・サブタイプ ............ 17 5. 合成メディアタイプの値 ............................... 17 5.1 多元部分メディアタイプ ..................... ....... 17 5.1.1 共通構文 ........................................ 19 5.1.2 入れ子メッセーとマルチパートの取り扱い .......... 24 5.1.3 混在(Mixed)サブタイプ ........................... 24 5.1.4 代替(Alternative)サブタイプ ..................... 24 5.1.5 ダイジェスト(Digest)サブタイプ .................. 26 5.1.6 並列(Parallel)サブタイプ ........................ 27 5.1.7 その他のマルチパート・サブタイプ ................ 28 5.2 メッセージメディアタイプ ........................... 28 5.2.1 RFC 822 サブタイプ .............................. 28 5.2.2 部分(Partial)サブタイプ ......................... 29 5.2.2.1 メッセージ断片化と再集合 ..................... 30 5.2.2.2 断片化と再集合の事例 ......................... 31 5.2.3 外部ボディ(External-Body)サブタイプ ............. 33 5.2.4 その他のメッセージサブタイプ .................... 40 6. 試験的なメディアタイプの値 ........................... 40 7. 要約 ................................................. 41 8. 安全性問題 ........................................... 41 9. 著者への連絡 ......................................... 42 A. 文法集 ............................................... 43 1. はじめに この一式の最初の文書、RFC 2045、はContent-Typeを含み、幾つものヘッダー フィールドを定義しています。Content-Typeフィールドは、メディアタイプと サブタイプ識別子を与えまた或る種のメディアタイプに必要であるかもしれな い補助情報を提供して、MIME実体のボディのデーターの性質を特定します。タ イプとサブタイプの後残っているものは単に一式のパラメーターだけで、 attribute/valueという命名法で特定されます。パラメーターの順序付けは意 味がありません。 一般的にトップレベル・メディアタイプは、データーの一般的なタイプを宣言 するのに使用され、一方サブタイプはデーターのそのタイプの特別な書式を特 定します。かくてメディアタイプ"image/xyz"は、たとえ特別な画像書式 "xyz"を知らなくても、表示代行手段がそのデーターは画像であること、を表 示代行手段に十分に伝えます。例えば、このような情報は認識されないサブタ イプから生のデーターを利用者に見せるかどうかを決めるのに使うことができ ます。 -- このような行動は"text"の認識されないサブタイプの場合は理に 適っていますが、 "image"もしくは"audio"の場合は理に適っていません。こ の理由から、"text"・"image"・"audio"そして"video"の登録サブタイプは、 全く異なったタイプである情報の組み込みを内容にすべきではありません。こ のような合成書式は、"multipart"もしくは"application"タイプを使って表現 すべきです。 パラメーターはメディアタイプも修正子で、内容の性質に基本的には影響を与 えません。意味のあるパラメーター設定はメディアタイプとサブタイプに依存 しています。多くのパラメーターは単一の特別なサブタイプで支援されていま す。しかし、一定のトップレベル・メディアタイプはそのタイプの如何なるサ ブタイプにも適用されるパラメーターを定義するかもしれません。パラメー ターは、メディアタイプもしくはサブタイプをもしくは選択性でであるかもし れないことを定義付けすることがひつようであるかもしれません。MIME装備は また認識されない名前のパラメーターを無視しなければなりません。 MIMEのContent-Typeヘッダーフィールドとメディアタイプ機構は、拡張されう るように注意して設計されていて、メディアのtype/subtype一対の組と支援パ ラメーター一式は、時を超えて有意義に発展することを予想しています。その ような値が注文道理の・十分特殊化されている・公的な手順によって発展する ために、MIMEの拡張の様々な領域のための中央登録としてInternet Assigned Numbers Authority (IANA) を使う登録て順を、MIMEは用意しています。これ らの領域の登録手順は随伴文書、RFC 2048、に記載されています。 初期の七つのトップレベル・メディアタイプは、この文書の後のほうで定義説 明されています。 2. トップレベル・メディアタイプの定義 トップレベルのメディアタイプの定義は、以下のように構成されています: (1) タイプの名前と説明、特殊なタイプがそのタイプの下で的確かどうか の基準(クライテリア)を含みます。 (2) パラメーター名前と定義、それがある場合は、それらがそのタイプの 全てのサブタイプ用に定義されます(このようなパラメーターは、必 須か選択性かを含みます)。 (3) 表示代行手段及び/またはゲートウェーが、このタイプの未知のサブ タイプをどう取り扱うべきか。 (4) このトップレベル・タイプ、それが如何なるものであれ、実体のゲー トウェイについての一般的な考慮、そして (5) このトップレベル・タイプの実体用の内容転送符号化での如何なる制 限についての考慮 3. 初期トップ-レベル・メディアタイプ概要 五つ別個のトップレベルメディアタイプには: (1) text -- テキスト情報。特にサブタイプ"plain"は、書式化されたコマ ンドもしくは如何なる種類の指示をいっさい内容にしていないプレー ンテキストを指しています。プレーンテキストは、"その通りに"表示 されます。指示された文字セットのサポートのことも一切考えなく、 テキストの意味全部を得るのに何ら特別なソフトウェアーを必要とし ません。その他のサブタイプは、アプリケーションソフトウェアーが テキストの表示を高めますが、そのようなソフトウェアーはその内容 の一般的な考えを得るには必要ではない、enriched text用に使用され なければなりません。かくて、"text"の可能なサブタイプは書式を理 解しているソフトウェアーに保存しなくても判読できる如何なるワー ドプロセッサーを含みます。特に、組み込まれたバイナリー書式の情 報を採用している書式は直接判読できることを考えていません。簡単 で転送可能なサブタイプ"richtext"がRFC 1341で定義され、RFC 1896 で改訂され"enriched"となっています。 (2) image -- 画像データー。"Image"は、情報を閲覧するには、表示装置 (グラフィックディスプレイ・グラフィックプリンターもしくはFAX機 器といった)が必要です。初期のサブタイプは広く使用されている画 像書式JPEGと定義されていて...サブタイプには二つの広く使用さ れている画像書式であるjpegとgifが定義されています。 (3) audio -- 音響データー "Audio"は内容を表示するするのに、音響出 力装置を必要とします(スピーカーや電話など)。初期値サブタイプ "basic"がこの文書では定義されています。 (4) video -- ビデオ・データー "Video"は動画を表示する能力が必要で、 典型的には特殊化されたハードウェアーとソフトウェアーです。初期 値サブタイプ"mpeg"がこの文書では定義されています。 (5) application -- 或る種のデーター、典型的には解釈されないバイナ リー・データーもしくはアプリケーションによって処理される情報。 解釈されないバイナリー・データーの場合、この場合最もシンプルな 推奨される行動は利用者用のファイル情報を書くことです、サブタイ プ"octet-stream"が使用されなければなりません。"PostScript"サブ タイプもポストスクリプト(PostScript)素材の転送用に定義されて います。 "application"で使われることが考えられその他のものとし て、表計算、メールベースの計画システム・ "active"(computational) メッセージ用の言語・直接判読できないワードプロセッサー書式があ ります。安全性問題がアプリケーション、最も有名なものは "application/PostScript"と "active"メッセージ形式で、によっては 存在します。この問題はこの文書の後半で言及します。 二つの合成トップレベル・メディアタイプがあります: (1) multipart -- 独立したデータータイプの多元的な実体から構成されて いるデーター。四つの初期値が定義されていて、パートの包括的な混 合されたセットを特定する基本的な"mixed"サブタイプ・多元的な書式 で同じデーターを表現するための"alternative"・同時に閲覧されるこ とを狙ったパートのための"parallel"・各パートが初期値タイプが "message/rfc822"であるものの多元的な実体のための"digest"などが あります。 (2) message -- カプセル化されたメッセージ メディアタイプ"message" のボディは、それ自身或る種のメッセージ対象そのももしくは一部で す。このような対象は、交互に別の実体を含むかもしくは含まないか もしれません。カプセル化された内容自体がRFC 822メッセージである 場合、rfc 822サブタイプが使われます。 "partial"サブタイプは部分 的なRFC 822メッセージのために定義されていて、一つとして転送装備 を通過するには余りにも大きいと考えられるボディの断片転送ができ ます。別のサブタイプ"external-body"は、外部のデーター資源の参照 による大きなボディを特定するために定義されています。 ここにあげたメディアタイプの値は、上記の機構を経由して、ゆくゆく増えて いくでしょうし、サブタイプは大幅に増えると考えられます。 4. 個別メディアタイプの値 七つのうち五つの初期メディアタイプ値は、個別ボディを参照します。これら ののタイプの内容は、非MIME機構によって取り扱れるべきです;これらは MIME処理では理解しがたいものです。 4.1. テキスト・メディアタイプ(Text Media Type) "text"メディアタイプは、書式上原理的にテキスト的な素材を送信することを 意図しています。"charset"パラメーターは"text"サブタイプ、注目すべきは プレーンテキスト用の包括的なサブタイプであるsubtype "text/plain"をふく み、のボディ・テキストの文字セットを指すのに使われます。プレーンテキス トは、書式コマンド・文字属性仕様・処理装置・指示解釈・内容マーク付けを 提供もしくは支給しません。プレーンテキストは単に文字の行として見られ、 改行や改頁で途切れることはあります。プレーンテキストは、テキストの同じ 位置に幾つかの文字の積み重ねを許します。アラビアとヘブライのようなスク リプトでのプレーンテキストは、反対に書く方向のある断片の任意の混在を許 すという機構をも持っています。 プレーンテキストを超えて、"rich 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列(連続体)のない余 りにも長い断片は適当な内容転送符号化で符号化されなければなりません。 4.1.2. Charset パラメーター "text/plain"データーのContent-Typeフィールドで特定される重要なパラメー ターは文字セットです。これは、"charset"パラメーターで以下のように特定 されます: Content-type: text/plain; charset=iso-8859-1 別のパラメーターと違って、文字パラーメーターの値は大文字小文字を区別し ません。初期値文字セット、文字パラメーターが存在しない場合推定されなけ ればならない、はUS-ASCIIです。 将来の"text"サブタイプの仕様は、 "charset"パラメーターも利用するかどう かを特定しなければなりませんし、同様にその値を制限する可能性もあり得ま す。"text/plain"以外の"text"サブタイプには、"charset"パラメーターの構 文は"text/plain"のためにここで特定されたものと同じであると定義されるべ きで、例えばボディは一定のcharsetの文字から全て構成されます。特に将来 の"text"サブタイプの定義者は、そのサブタイプ定義の多元オクテットの装備 提供に十分注意を払うべきです。 "text"のサブタイプのcharsetパラメーターは、"character set"はRFC 2045で 定義されているように、文字セットの名前を与えます。前のセクションで詳し く述べられた行分断に関わる規則も観察されなければなりません -- 定義がこ れらの規則に適合しない文字セットは、 MIME "text"サブタイプで使用できま せん。 前もって定義された文字セットの初期値リストは、このセクションの終にあり ます。追加文字セットはIANAに登録されるかもしれません。 "text"のサブタイプ以外のメディアタイプは、ここで定義されたように、しか しCRLF/行分断制限を除いた、charsetパラメーターを利用することを選ぶか もしれません。従って、RFC 2045での"character set"の一般的な定義に適合 する文字セットは全てMIME使用に登録されることが可能です。 特定された文字セットが8ビット文字を含み、そのような文字がボディで使用 される場合、Content-Transfer-Encodingヘッダーフィールドとそれに対応す るデーターの符号化が、SMTP [RFC-821]といった或る種のメール転送手順経由 でボディを転送するには、必要であることに注意してください。 初期値文字セット、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= International References Version)では、US-AASCIIと同じです。 文字セッ ト名"ASCII"は予約されていて、如何なる目的にも使用されるべきではありま せん。 注意:RFC 821ははっきりと"ASCII"を特定し、米国標準の初期バージョンを照 合します。この点に限れば、メディアタイプと文字セットを特定することの目 的のひとつは、"strict ASCII"以外の如何なるもの--この初期値は転送中であ るメッセージの構文を意図されないまた互換性のない変更の危険に曝します- -であっても、送信者が符号化メッセージがどのように解釈されるよに意図し たのかを、受信者が曖昧なく決定できることです。 このことは、8ビットもしくは多元オクテット文字符号化と同様に、US-ASCII 以外のISO 646や1991 IRVバージョンに従ったりコード切り替え手順(例え ば、ISO 2022)を使用して符号化された文字を含んでいるメッセージは、 MIMEに一致した適切な文字セット仕様をつかわなければならないことも、意味 します。 完全なUS-ASCII文字セットは、ANSI X3.4- 1986に一覧表があります。DEL (0-31, 127)を含む制御文字は、改行を指すCRLF(US-ASCII値13と10)の組み 合わせと違って定義された意味はありません。二つの文字は広くつかわれてい る事実上の意味があります:FF (12)はしばしば「新ページの始まりでテキス ト連続体を開始する」を意味し;TABもしくはHT(9)はしばしば(常にではない が)「当該の位置の後次の得られる列、列番号は8の倍数(最初の列を0とし て)、にカーソルを移動する」を意味します。この慣例以外に、ボディの制御 文字もしくはDELがつかわれます。というのは、 (1) "plain"以外のテキストのサブタイプがある追加的な意味、もしくは (2) 送信者と受信者間の私的な了解の文脈上で、特別に意味を割り当てる からです。このような私的な了解は奨励されなく、この文書の別の能 力に置き換なければなりません。 注意:非常に多くの文字セットが、US-ASCII以外にもあります。一部分もしく は大部分で重複する文字が多いのは、いいことではありません。インターネッ トメールで世界の言語の全てを表現するのに広く使用されることができる、単 一文字セットが好ましいものです。残念ながら、幾つかの交流社会(コミュニ ティ)での既存の実践は、近い将来も多元的な文字セットの使用が続くことを 指しているように思われます。従って少数の標準文字セットが、インターネッ トでの使用として、この文書で定義されています。 定義されたcharset値は: (1) US-ASCII -- ANSI X3.4-1986 [US-ASCII]の定義の通り。 (2) ISO-8859-X -- ISO-8859 [ISO-8859]で必要に応じて、"X"を置き換え ます。ISO 646文字セットは、インターネットメール用に設計された 8859への置き換えの利点ゆえに、熟慮の上割愛されたことに注意して ください。この文書の公開以後は、"X"の合法の値は、1から10までの アラビ数字です。 範囲128-159は、ISO-8859-xでは意味は割り当てられていません。ISO-8859-X の120以下の範囲は、US-ASCIIと同じ意味が割り当てられています。 ISO 8859(Latin/Arabicアルファベット)のパート6とパート8(Latin/ Hebrewアルファベット)には、普通の書き方である右から左用の文字と左から 右である文字の両者がありますが、双方向テキストの表現で正式な順位付け方 法は定義されていません。しかしISO-8859-6"と"ISO-8859-8"というcharset値 は、視覚的な方法が使われていることを特定します[RFC-1556]。 これらの文字セットは全て、シフトやエスケープなしの純粋な7ビットもしく は8ビットとして使用されます。シフトやエスケープの意味はこれらの文字 セットでは定義されていません。 上で定義された文字セットは、MIMEの候補中比較的論争にならなかったもので す。この文書はUS-ASCII以外の特殊な文字セットの使用を是認していませんし、 世界文字セットの将来の改革はなお明確でないままであることを認めます。 使用されている文字セットが、US- ASCII以外の文字なら如何なるものでも、 Content-Typeフィールドで必ず明確に特定されなければなりません。 インターネットメールでは正式な仕様の公開とそれのIANA登録、もしくは文字 セット名 "X-"ではじまる私的了解がないと、上で定義されたもの以外の文字 セット名、如何なるものでも、は使用されないかもしれません。 手段提供者は、絶対的な必要性がないなら、新しい文字セットの定義は薦めら れません。 "charset"パラメーターは、主にテキスト・データーのために定義されてき、 この理由でこのセクションで記載されています。しかし非テキストデーターで も目的によってはcharset値、その場合同じ構文と値が使用されるべきで、を 特定したくなる場合もありことも考えられます。 一般的にいって、合成ソフトウェアーは、可能な「最小公分母」"lowest common denominator"を必ず使用します。例えば、ボディがUS-ASCII文字だけ を含む場合、US-ASCII文字で、文字セットISO-8859と同じようにUS-ASCIIの上 位セットであるISO-8859-1でなく、あるとしてマーク付けされるべきです。 もっと一般的には、広く使用されている文字セットが別の文字セットの下位集 合(サブセット)の場合そのサブセットであるとラベル付けされるべきです。 これは、受信者がもたらされる実体を正しく閲覧できる機会を増進します。 4.1.3. プレーン(Plain) サブタイプ "text"の最もシンプルで重要なサブタイプは、"plain"です。これは、如何な る書式化命令(コマンド)や指示を内容としていないプレーンなテキストを指 します。プレーンなテキストは「そのまま」表示、言い替えると組み込まれた 書式命令解釈・文字属性仕様・処理装備・解釈指示もしくは内容マーク付け が、適切な表にとって、一切必要ではありません。インターネットメール用の "text/plain; charset=us-ascii"という初期メディアタイプは、既存のイン ターネット実践を記載しています。つまり、それはRFC 822で定義されたボ ディタイプです。 "text"以外のサブタイプはこの文書で定義されていません。 4.1.4. 認識されないサブタイプ "text"の認識されないサブタイプは、MIME装備がその文字をどう処理するかが 分かっている限り、サブタイプ"plain"として処理されるべきです。認識され ないcharsetを特定している認識されないサブタイプは、 "application/ octet- stream"として処理されるべきです。 4.2. 画像メディアタイプ メディアタイプ"image"はボディに画像があることを指します。サブタイプ名 は特別な画像書式を特定します。これらの名前は大文字小文字を区別しませ ん。サブタイプの初期値は、JFIF符号化をつかったJPEG書式 [JPEG]である "jpeg"です。 ここにあげた"image"のサブタイプのリストは、他を入れる余地がないわけで もなく完全なものでもなく、もっと多くのタイプがIANAに、RFC2048に記載さ れているように、登録されるので発展すると期待されます。 "image" の認識されないサブタイプは少なくとも"application/octet- stream"として処理されるべきです。手段提供者は安全で確固不動な一般的目 的の画像閲覧アプリケーション、そのようなアプリケーションが入手できるな ら、にわたすために、特別に認識されない"image"のサブタイプを通せるよう に選択肢をあたえておくかもしれません。 注意:包括的な目的の画像閲覧アプリケーションを使う場合、この方法はアプ リケーションがだかえている最も危険なタイプの安全性問題を引き継ぎます。 4.3. 音響メディアタイプ メディアタイプ"audio"は、ボディが音響データーを内容にもっていることを 指します。コンピューターでの使用に「理想的な」音響書式についての合意は まだありませんが、相互操作可能な振るまいを提供できる書式の要求は緊急課 題です。 初期サブタイプ"basic"は、全く最小最低の共通分母を提供することで、この 要求に応ずるために、特定されています。高品質でもしくは低通信帯域幅な音 響用のいい書式が最新文書で定義されることが期待されています。 "audio/basic"サブタイプの内容は、8000 ヘルツで8ビットISDN mu-law [PCM]を使った単一チャンネル音響です。 認識されない"audio"サブタイプは、少なくとも"application/octet-stream" として処理されるべきです。手段提供者は確固不動な一般的目的の音響演奏ア プリケーション、そのようなアプリケーションが入手できるなら、にわたすた めに、特別に認識されない"audio"のサブタイプを通せるように選択肢をあた えておくかもしれません。 4.4. ビデオ・メディアタイプ メディアタイプ"video"は、ボディに時間変化画像、出来れば色彩と同調音響 をともなった、を内容としていることを指します。「ビデオ"video"」という 用語は、特別な技術もしくは書式ではなく一般的に使われている意味で、使用 されていて、コンパクトに符号化されたアニメ化されて描かれたものといった サブタイプを排除することを意味されていません。サブタイプ"mpeg" は、MPEG 標準 [MPEG]に従って符号化されたビデオを参照します。 一般的にはこの文書は単一ボディにマルチメディアの混合を強くすすめていま せんが、多くの所謂ビデオ書式は同調された音響の表現を含み、これは "video"サブタイプとしてはっきりと許されることを認めていることに注意し てください。 認識されない"video"のサブタイプは、少なくとも"application/octet- stream"として処理すべきです。手段提供者は確固不動な一般的目的のビデオ 表示アプリケーション、そのようなアプリケーションが入手できるなら、にわ たすために、特別に認識されない"video"のサブタイプを通せるように選択肢 をあたえておくかもしれません。 4.5. アプリケーション・メディアタイプ "application"メディアタイプは、他の範疇のどんなものにも合わない個別の データー、特にアプリケーション・プログラムで処理されるデーター、用に使 われなければなりません。これは、閲覧可能もしくは利用者が利用可能になる 前に、アプリケーションによって処理されなければならない情報です。 "application"メディアタイプとして考えられる使用には、ファイル転送・表 計算・メールベース=スケジュールシステムそして "active" (計量言語学 の)素材用言語があります。(特に後者では手段提供者が理解しておかなあけ ればならない安全性問題に曝される可能性があり、"application/ PostScript" メディアタイプの議論で詳しく考えます。) 例えば、会合予定制作は提案された会合日付についての情報用の標準表現を定 義するかもしれません。統合表示代行手段は、利用者にテーターベースを伝え るのにこの情報を使い、次いでそのデーターベースに基づかれた追加素材を送 信するかもしれません。より一般的には、幾つかの開発された"active"メッ セージする言語があり、適切に特殊化された言語のプログラムが遠隔地に転送 され、自動的に受信者の環境で作動します。 このようなアプリケーションは"application"メディアタイプのサブタイプと して定義されるかもしれません。この文書は二つのサブタイプを定義していま す: オクテト-連続体とポスト・スクリプト "application"のサブタイプは、データーが意図されているもの用のアプリ ケーションの名前かもしくはの一部を含んでいます。しかしこれは、どんなア プリケーションプログラム名でも自由に"application"のサブタイプとして使 われるということを意味するものではありません。 4.5.1. オクテット連続体とポスト・スクリオプト(Octet-Stream Subtype) "octet-stream"サブタイプは、ボディが任意のバイナリーデーターを 内容としていることを指します。最近定義されたパラメーターのセッ トは: (1) TYPE -- バイナリーデータの一般的タイプもしくは範疇。こて は、自動的な処理のためではなく受取人への情報として意図さ れています。 (2) PADDING -- 一塊8ビット指向データーを作成するために、実際 の内容を構成しているビット連続体に添え付けられたビット詰 め物の数。これは、ビット総数が8の倍数でない場合ボディ内 でビット連続体を囲うのに役立ちます。 これらパラメターは両者とも選択性です。 補足的なパラメーター、 "CONVERSIONS"、はRFC 1341で定義されてい ますが、それ以後取り除かれています。RFC 1341は"NAME"の使用も定 義し、データーがファイルに書き込まれなければならない場合その ファイル名を指していました。これは、個別のContent-Disposition ヘッダーフィールドを見越して、以後のRFCで定義されますので、いず れ廃止になるものです。 "application/octet-stream"を受け取る手段提供者の、勧告されてい る振るまいは、ファイルにデーター、施されたContent-Transfer- Encodingがどんなものであれ、を置くことをもしくは利用者特殊化処 理過程への入力としてそれを利用することを単に行うだけです。 危険なプログラムを転送することの危険を減らすために、手段提供者はパス- 検索機構、そこでContent-Typeパラメーター(例えば、"interpreter=" パラ メーター)で命名された任意のプログラムが発見されそして入力としてメッ セージを使うこと実行する、を装備しないことが強く薦められています。 4.5.2. ポストスクリプト・サブタイプ "application/postscript" のメディアタイプはポストスクリプト言語を指し ています。最近、ポストスクリプト言語に二つの亜型があります;オリジナル なレベル1は[POSTSCRIPT]に記載され、より新しいレベル2亜型は [POSTSCRIPT2]に記載されています。 ポストスクリプトはAdobe Systems, Incの登録商標です。MIMEメディアタイプ "application/postscript" の使用は、その商標とそれに伴う全ての権利の承 認を必ず伴います。 ポストスクリプト言語定義は、一定のプログラムが使う特別な言語機能のイン ターネットのラベル付けのための装備を提供します。このラベル付けは、ポス トスクリオプト文書構造規約(PostScript document structuring conventions)もしくは DSCといわれます、非常に一般的でその言語レベルだ け以上により多くの情報を提供します。文書構造規約の使用、必須ではありま せんが、は相互操作性の目的として強く推奨されます。適切な規約の構造化を 欠いているか文書は、一定の環境で十分に機能するどうかをみるためにテスト されることができません。そのようなので、システムによっては悪いと決めて かかり非構造化文書を処理することを拒みます。 一般的目的のポストスクリプト解釈の実行は重大な安全性危険を引き起こし、 単にポストスクリプト・ボディを特別でない解釈に送ることを手段提供者は思 いとどまることです。ポストスクリプトをプリンターに送ることは、そこでは 害の可能性は典型的な印刷環境によって閉じ込められ、通常安全でですが、ポ ストスクリプトボディをMIMEリーダーに双方向的表示を追加する前に、手段提 供者は以下のこと全てを考慮すべきです。 このセクションの後半で、ポストスクリプトの転送での幾つかの可能性のある 問題、恐らく全部ではなく、を概観します。 (1) ポストスクリプト言語での危険な操作には、これだけに限りません が、ポストスクリプト操作"deletefile"・"renamefile"・ "filenameforall"そして"file"があります。"File"は標準入力もしく は出力以外のものに適用される場合危険になるだけです。手段提供者 はまた、追加的なファイル操作を定義するかもしれません;これらは 安全に脅威も課せるかもしれません。"Filenameforall"、ワイルド カード・ファイル検索操作、は一見無害であると思われるかもしれま せん。 しかし、この操作は受信者がどんなファイルにアクセスしているかに ついての情報を明かす可能性を持ち、これは微妙なことになるという 点に注意して下さい。メッセージ送信者は潜在的に危険なファイル操 作を使うこと避けるべきで、というのもこれらの操作は安全なポスト スクリプト装備では無効であるべきだから。ソフトウェアーを受け取 り表示するメッセージは潜在的に危険なファイル操作を完全に無効に するかもしくはこの操作に特別な如何なる権威も任命しないように特 別な配慮を取らなければなりません。ポストスクリプト文書を解釈す る際外部代行手段によってなされるように、これらの操作は閲覧され るべきです。このような無効化ともしくはチェックは、完全にポスト スクリプト言語自身の届く範囲外でなされるべきです;これらの操作 の全機能を再び可能にする方法が全くないことを確認する配慮が取ら れるべきです。 (2) ポストスクリプト言語は、正常の解釈もしくはサーバー・ループを抜 け出す装備を提供しています。この「外部」環境で作られた変化は文 書を越えて常に保持され、ある場合には不揮発性のメモリーに半永久 的に存続させられます。解釈ループを抜け出すことを支援する操作は、 引き続く文書処理に干渉する可能性を持っています。そのように、そ れらの無制限な使用は供給拒否の脅威を形成します。解釈ループを抜 け出すポストスクリプト操作に、それにかぎりませんが、 exitserver と startjob 操作が含まれます。ソフトウェアーを送る メッセージは、操作のために解釈ループを抜け出すことに依存するポ ストスクリプトを生成すべきではなく、というのは抜け出す能力は安 全なポストスクリプト装備では多分得られないだろうからです。ソフ トウェアーを受け取り表示するメッセージは、ポストスクリプト環境 への変化を保持する能力を、"startjob" と "exitserver" 操作を排除 もしくは無効にすることによって、無能にすべきです。これらの操作 が排除もしくは完全に無効にされ得ない場合、少なくともこれらと協 調するパスワードを推定し難い値に設定すべきです。 (3) ポストスクリプトは汎システムと装置特異的なパラメーターを設定す る操作を提供します。これらのパラメーターを設定することは、ジョ ブ(コンピューターの仕事の単位)を越えて保持され解釈の正しい操 作に脅威を潜在的に課せるかもしれません。システムと装置パラメー ターを設定するポストスクリプトは、これにかぎりませんが、 "setsystemparams" と "setdevparams" を含みます。 ソフトウェアーを送るメッセージは、正しく操作するためにシステム と装置パラメーターに依存するポストスクリプトを生成すべきではあ りません、というのも安全なポストスクリプト装備ではこれらのパラ メーターを設定する能力は恐らく得られないからです。ソフトウェ アーを受け表示するメッセージはシステムと装置パラメーターを変更 する能力を無効にすべきです。これらの操作が完全に無効にされない なら、それらと協調されるパスワードがすくなくとも推理し難い値に 設定されるべきです。 (4) ポストスクリプト装備によっては、機械コードの直接の読み込みや実 行の能力を提供しています。この様な装置は、明らかに、かなりの悪 用への道を開きます。ソフトウェアーを送るメッセージはこのような 機能を使用すべきではありません。全くハードウェアー特異的である 以外に、これらは安全なポストスクリプト装備で得られないでしょう。 ソフトウェアーを受け表示するメッセージはこのような操作、もしあ るならば、を許さないようにすべきです。 (5) ポストスクリプト言語は拡張可能な言語で、多くの、大部分ではあり ませんが、装備は多くの自己拡張を提供しています。この文書はその ような拡張を十分にはっきりと説明していません、というのは不明な 因子が関わっているからです。ソフトウェアーを送るメッセージは非 標準拡張を使用すべきではありません;これらは装備によっては間違 えられます。ソフトウェアーを受け表示するメッセージは、如何なる 非標準ポストスクリプト操作も安全でどんな種類の脅威も提示しない こと、を確認しなければなりません。 (6) 膨大な色々なシステム資源を消費するポストスクリプを書くことがで きます。また無限にループするポストスクリプトプログラムも書くこ とができます。この両タイプのプログラムは、思いがけない受信者に 送信すると、潜在的に損害の原因となります。ソフトウェアーを送る メッセージは、適当な時間が経過したら処理を中断する適切な機構を 提供すべきです。さらにポストスクリプト解釈は、システム資源の妥 当な量だけの消費に制限すべきです。 (7) ポストスクリプト内に生のバイナリー情報を色々な書式で含むことが できます。インターネットメールでは薦められなくて、それには二つ の理由があり、一つはポストスクリプト解釈全てがサポートしていな いからで、二つ目はMIME内容転送符号化の使用を非常に込み入っても のにするからです。(このようなバイナリーを伴わないポストスクリ プトは、典型的には行指向データーとして閲覧されます。バイナリー と行指向データーが単一ポストスクリプトデーターシステムに混在さ れているなら、CRLF連続体の取り扱いが非常に問題となります。) (8) 最後にポストスクリプト解釈によってはバグがあるかもしれなく、受 信者のシステムに不当なアクセスを得ることに利用される可能性があ ります。この可能性を知ること以外に予防に取られる特別な行動はあ りません、このようなバグ、どんなものでも発見されたならば、を迅 速に修正すれば別ですが。 4.5.3. その他のアプリケーション・サブタイプ "application" のその他多くのサブタアイプが将来定義されると思われま す。MIME手段提供者は認識しないサブタイプを少なくとも "application/ octet-stream" として処理しなければなりません。 5. 合成メディアタイプの値 七つの初期Content-Type値の残りの二つは、合成実体を参照します。合成実体 はMIME機構を使って取り扱われます -- MIME処理は典型的にはボディを直接取 り扱います。 5.1. マルチパート(Multipart)メディアタイプ マルチパート実体の場合、そこでは単一ボディに一つ以上のデーター組が結合 されていて、"multipart" メディアタイプは実体のヘッダーに来なければなり ません。ボディは一つ以上のボディ部分を内容にし、境界識別行と閉じ境界識 別行が続く最後のものに先行されています。境界識別行がきてそれから、各ボ ディ部分がヘッダー領域・空白行・ボディ領域から構成されます。かくて、ボ ディ部分は構文がRFC 822メッセージと似ていますが、意味が異なります。 ボディ部分は実体で、従って実際にRFC 822メッセージであるとして解釈され るべきではありません。始まるにあたり、ボディ部分ではなんらヘッダー フィールドは実際必要ありません。したがって空白行で始まるボディ部分は許 され、全ての既定値は当然のものとされるボディ部分です。このような例で、 Content-Typeヘッダーがなくても、普通対応するボディが "text/plain; charset=US-ASCII"のいう内容タイプをもっているとされます。 ボディ部分の意味を定義した唯一のヘッダーフィールドは、"Content-" で始 まる名前のものです。その他のヘッダーフィールドはボディ部分内で無視され るかもしれません。これらは出来るだけ保存されますが、必要ならゲートウェ イによって除かれるかもしれません。このようなその他のフィールドがボディ 部分に来ることを許されますが、これに依存されてはなりません。ゲートウェ イによってはそこで内容にしている情報が失われることを認めた上で、"X-" ファイルは実験的もしくは個人的な目的用に作成されるかもしれません。 注意: RFC 822メッセージとボディ部分との違いは、捉え難いのでうが重要 なことです。例えばインターネットとX.400 メール間の通過門(ゲートウェ イ)は、画像を内容としているボディ部分とカプセル化されたメッセージ、ど のボディがJPEG画像か、を内容としているボディ部分との違いを伝えなければ なりません。後者を表現するためにボディ部分は "Content-Type: message/ rfc822" を持ち、そのボディ()はそれ自身の"Content-Type: image/jpeg" ヘッダーフィールドのあるカプセル化されたメッセージでなければなりませ ん。同じ様な構文の使い方は、メッセージをボディ部分へ変換、またその逆、 を容易にしますが、二つの違いを厳密に手段提供者は理解しなければなりませ ん。(部分がメッセージそのものという特殊なケースでは、"digest" サブタ イプも定義されます。) 前に述べたように、各ボディ部分は境界識別子を内容とする境界識別行によっ て先行されます。境界識別子はカプセルカ化された部分内で、それ自身による 行上にもしくは行の接頭語として、現われてはいけません。これは、基礎をな す表示代行手段が、囲われたマルチパートの境界パラメーター値を接頭語とし て内容にしていない、特異な境界パラメーター値を選択特定できることが極め て大切であることを指しています。 現在と将来の"multipart"タイプ全ては同じ構文で使用されなければなりませ ん。サブタイプは意味上異なり構文に追加的な制限を課すかもしれませんが、 "multipart"タイプの必須構文に適合しなければなりません。この要求は、適 合表示代行手段は全て少なくともマルチパート実体の部分、例え認識されない サブタイプのボディであっても、を認識し分離することができることを保証し ます。 内容転送符号化フィールドの定義で述べたように[RFC 2045]、"7bit"・ "8bit"もしくは"binary"以外のどんな符号化方法も"multipart"タイプの実体 に許されていません。"multipart"境界子とヘッダーフィールドは必ずどんな ケースでも7ビットUS-ASCIIとして表現され(ヘッダーフィールドが非US- ASCIIヘッダーテキストを、RFC 2047によるように、符号化するかもしれませ んが)そしてボディ部分内のデーターは、部分部分の基本にそって各々適切な ボディ部分用のContent-Transfer-Encodingフィールドで、符号化できます。 5.1.1. 共通の構文(Common Syntax) このセクションは"multipart"のサブタイプに共通の構文を定義しています。 "multipart"のサブタイプ全てがこの構文を使用しなければなりません。多元 部分メッセージの簡単な例がこのセクションにもあります。より複雑な多元部 分メッセージの例はRFC 2049にあります。 マルチパート実体用のContent-Typeフィールドは、パラメーター"boundary"を 必要とします。この境界識別行は、もっぱら二つのハイフェン("-", 十進値 45)から構成される行として定義され、Content-Typeヘッダーからのパラメー ター値・選択性の空白行(linear whitespace)・終わりのCRLFと続きます。 注意: ハイフェンはメッセージのカプセル化の初期RFC 934の方法との大ま かな互換性のためのもので、装備によっては境界検索を容易にするためのもの です。しかし、マルチパートメッセージはRFC 934カプセル化と完全に互換性 ではなく、特にハイフェンで始まる組み込まれた行のためのRFC 934引用慣例 に従わない、と言うことを知っておくべきです。この機構はRFC 934機構を越 えて選ばれました、と言うのも後者は引用の各レベルで行が増大する原因にな るからです。この増大とSMTP装備は時々長い行を折り返す、という事実の結合 が、RFC 934機構を、深く入れ子になったマルチパート構造が必要な事象で の、使用に適しないものにしました。 手段提供者への警告: Content-typeフィールドについての文法は、 Content-type行で引用符号で境界パラメーターを囲うことがしばしば必要で あるといったものです。これは必ず必要ではないが、支障もないものです。 手段提供者は不正なContent-typフィールドを作り出すのを避けるために注 意して文法を学ぶようにしなければなりません。かくて、典型的な "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は先行部分 ではなく境界識別行に付随している考えられます。境界に続いて、空白行 (linear whitespace = SPCE CRLF 折り重なり)が幾つか来るもしくは来ない こともあります。次いで、別のCRLFか次の部分のヘッダーフィールドか若くは 二つのCRLF、この場合は次のページ用のヘッダーフィールドはありません、で 終わりです。Content-Typeフィールドがない場合、"multipart/digest"の "message/rfc822"やそうでないなら"text/plain"と看做されます。 注意: 境界識別行に先行するCRLFは、概念的には境界に付属するもので、と いうのもCRLFで終わらない(行分断)部分を持つことが可能だからです。ボ ディ部分は行分断で終わる、従って境界識別行に先行する二つのCRLF、はじめ のがボディ部分の一部で二番目がカプセル化境界の部分、を持たねばならない と考えなければなりません。 境界識別子はカプセル化されている資料内にきてはいけませんまた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を見てください。 単一ボディ部分だけの "multipart"メディアタイプの使用は、或る種の文脈で は有効であるかもしれませんし、許されると明言されています。 注意:単一ボディ部分だけの "multipart"メディアタイプは、非テキストメ ディアタイプの送信にとって利用価値があると経験から分かってきています。 これには、命令復元を含むための場所として前文を提供することの利点があり ます。さらに、多くのSMTPゲートウェイ(通過装置)がMIMEヘッダーを通した り除去したりし、また賢明なMIME解読器は、Content-Typeヘッダーがなくて も、マルティパート境界でいい推測ができ、それ故にメッセージをうまく復元 します。 "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 ; May be ignored or discarded. body-part := MIME-part-headers [CRLF *OCTET] ; ボディ部分の行は特定されたdash-boundary ; ではじまるべきではありません、そして ; 識別子はボディ部分には来るべきではありません。 ; ボディ部分の意味はメッセージの意味と、 ; このテキストに記載されているように、 ; 異なることに注意してください。 OCTET := 重要: このBNFに示す要素間に空白行(linear-white-space)とRFC 822コメ ントを自由に挿入することは、許されてなく、というのはBNFは構造化された ヘッダーフィールドを特定していなきからです。 注意: 或る転送領域外では、ボディを印字可能なUS-ASCII文字に限定すると いった、RFC 822 制限は有効でないかもしれません。(言い替えると、 RFC 821で特定されRFC 822、或種の制限はない、と看做されている標準インター ネットメール転送に似た転送ドメインが現存するかもしれません。)これら制 限の緩和は、ボディ定義のローカルな拡張として、例えばこれらの拡張が転送 によってサポートされ内容転送符号化ヘッダーフィールドで十分注釈されてい る限りにおいてUS-ASCII範囲の外のクテックを記載する目的で、構成されるべ きです。しかしヘッダー(メッセージヘッダーかボディ部分ヘッダー)は、 US-ASCII文字以外の如何なるものも許されていません。 注意: "multipart" タイプのそれと分かるミスは、関連するボディ部分の構 造概念です。より構造化もしくは統合化された多元メッセージ装備の提供をし たい場合は、構文的には同じで色々な部分の関係を定義する、多元部分のサブ タイプを定義することが薦められます。例えば、Content-IDフィールドを照合 して別の部分との関係を特定するのに順に使われる区別された部分を含む、サ ブタイプを定義できます。古い装備は、この接近方法が使われる場合、この新 しいサブタイプを認識しないでしょうが、multipart/mixedとして処理し、従っ て利用者に認識される部分を表示できます。 5.1.2. 入れ子になったメッセージとマルチパートの取り扱い この文書の後のセクションで定義される"message/rfc822"スブタイプは、デー ターを終わる以外なんら終わる条件を持っていません。同様に不適切に切り捨 てられた"multipart"実体はなんら終末境界印を持たず、メールシステム機能 不全によって操作性上調整できなくなります。 そのような実体は、自身が別のマルチパート構造内に組み込まれている場 合、正しく処理されることが本質的なことです。従って、MIME装備は、内部的 な入れ子の如何なるレベルででも外部レベル境界印を認識すること、を要求さ れます。次の考えられ流印もしくは別の終末条件をチェックするだけでは、十 分ではありません。 5.1.3. 混在(Mixed)サブタイプ マルチパートの 混在(Mixed)サブタイプは、ボディ部分が独立していて特殊 な順番で束ねられる必要がある場合の使用を意図されています。装備が認識し ないマルチパートサブタイプは如何なるものでもサブタイプ"mixed"であると して処理されなければなりません。 5.1.4. 代替(Alternative)サブタイプ "multipart/alternative" タイプは構文的には"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"書式を理解できるメールシステムの利用 者だけが変わった版を見、一方他の利用者はenrichedもしくはplainテキスト しか見えなく、システムの能力に依存しています。 一般的に、"multipart/alternative"実体を構成する表示代行手段は、好みの 高い順、つまり特定書式を最後に、にボディ部分を配置しなければなりませ ん。変わったテキストの場合、送信表示代行手段はプレーンテキスト書式を最 初に、エンリッチ書式を最後に置くべきです。受信表示代行手段は表示できる 最後の書式を選んで表示すべきです。代替のひとつがタイプ"multipart" 自身 で認識されないサブ部分を含んでいる場合、表示代行手段は代替、より早い代 替、もしくは両者を表示すかもしれません。 手段提供者の見通しでは、この順序を逆にし代替プレーンを最後に置くのがセ ンスがいいように見えます。しかし、最初に代替プレーンを置くことが、 "multipart/alternative" 実体をMIME非適合性のビュアーで閲覧する場合、最 も優しくなる可能性がある選択です。この接近ではMIME適合ビュアー上では何 がしかの負担を課しますが、このケースでは古いメールリーダーとの相互操作 性の方がより重要です。 表示代行手段によっては、一つ以上の書式を認識できる場合、どの書式を閲覧 するかの選択を利用者に差し出すようにするものもあります。例えば、メッ セージが奇麗に書式課された画像と編集し易いテキスト版の両者を持っている 場合、これは道理に適っています。しかし、最も重大なのは、同じデーターの 多元バージョンを自動的に利用者に見せないことにあります。利用者は、最後 に認識したバージョンをみるかもしくは選択が与えられるかのどちらかです。 MULTIPART/ALTERNATIVEでのCONTENT-ID 意味: "multipart/alternative"実 体の各部分は同じデーターを表現していますが、両者間のマッピングは情報損 失がないとはいえません。例えば、ODA を PostScriptもしくはプレーンテキ ストに変換する際情報は失われます。各部分は、二つの部分の情報内容が同じ でない場合、異なったContent-ID値を持つべきであるということが推奨されま す。そして情報内容が同じ場合、 -- 例えばタイプ"message/external-body"の 幾つつかの部分が同一データーにアクセス代替方法を特定する -- 受信者側に あるかもしれないキャッシング機構を最適化するために、同じContent-ID値が 使われるべきです。しかし部分によって使用されているContent-ID値は、その ようなContent-IDがあるなら、"multipart/alternative" を全体として記載す る同じContent-ID値ではいけません。つまり、一つのContent-ID値は、 "multipart/alternative" 実体を照合し、一方別の一つ以上の Content-ID値は その内部の部分を参照します。 5.1.5. ダイジェスト(Digest)サブタイプ この文書はマルチパートContent-Typeの"digest"サブタイプを定義していま す。このタイプは構文的には"multipart/mixed"と同等ですが、意味は異なり ます。特に、ダイゲストでボディ部分の既定のContent-Type値は、"text/ plain"から"message/rfc822"に変更されます。これはRFC 934との互換性が高 い(引用慣例を除いて)より判読可能なダイジェスト書式を許すことが行われ ます。 注意: ダイジェスト、"text/plain"部分など"message/rfc822"以外でダイ ジェストの資料説明がきているもの、実際にそうすることは望ましくありませ んが、のボディ部分のContent-Type値を特定することは可能です。 "multipart/digest"はメッセージの束を送るのに使用することを狙ったもので す。"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 ----" ------ 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 ------ 5.1.6. 並列(Parallel)サブタイプ この文書はマルチパートContent-Typeのサブタイプ"parallel"を定義していま す。このタイプは構文的には"multipart/mixed"と同じですが、意味は異なり ます。特に、パラレル実体で、ボディ部分の順位は意味がありません。 このタイプの普通の表現はハードウェアーとソフトウェアーで同期的、そうで きるなら、に部分全てを表示することです。しかし、合成表示代行手段は、多 くのメールリーダーはこの能力がなくとにかく部分を逐次に見せることに築気 付いて置くべきです。 5.1.7. その他のマルチパートサ・ブタイプ その他のマルチパートサ・ブタイプは将来を見越したものです。MIME装備は、 一般的には、認識されない"multipart"のサブタイプを"multipart/mixed"と同 じものとして処理しなければなりません。 5.2. メッセージ・メディアタイプ メール送信で、別のメールメッセージをカプセル化することがしばしば望まれ ます。特別なメディアタイプ、"message"、がこれを容易にするために定義さ れています。特に、"RFC822"サブタイプ"message"は、RFC 822メッセージを カプセル化するのに使われます。 注意: "message"のサブタイプは転送と拒絶メッセージ用に定義されること が示唆されてきました。しかし、転送と拒絶メッセージはマルチパートメッ セージとして取り扱われ、最初の部分に制御もしくは説明情報が来、二番目が、 "message/rfc822"タイプで、転送と拒絶メッセージの情報です。この方法で拒 絶と転送メッセージを構成することは、オリジナルメッセージについてのタイ プ情報保持し、受信者に適切に提示されることができ、従って推奨されるやり 方です。 "message"のサブタイプは、しばしば符号化の方法について制限を課します。こ れらの制限は各特殊サブタイプと結び付けて説明されます。 メールゲートウェイ・中継そしてメール表示代行手段は、RFC 822メッセージ のトップレベルヘッダーを変更することがよく知られています。特にヘッダー フィールドを追加したり除去したり整理しなおします。これら操作は、 "message."タイプのメッセージボディに組み込まれているカプセル化された ヘッダーには、はっきりと禁止されています。 5.2.1. RFC 822 サブタイプ メディアタイプ"message/rfc822"は、そのボディがカプセル化されたメッセー ジをRFC 822メッセージの構文で内容としていることを指します。しかし、 トップレベルのRFC 822メッセージと違って、各"message/rfc822"ボディが "From"と"Date"そしてすくなくとも一つ届け先(destination)ヘッダーを含 まなければならないと言う制限は除去され、少なくとも"From"と"Subject"も しくは"Date"がなければならないという要求に置き換えられます。 822という番号を使用していますが"message/rfc822"実体は、RFC822の厳格な 適合での資料への制限もなく、"message/rfc822"対象の意味はRFC 822で定義 されている意味ではないこのに、注意すべきです。より特異的で、"message/ rfc822"メッセージは、新しい作品もしくはMIMEメッセージです。 "7bit"・"8bit"もしくは"binary" 以外の符号化は、"message/rfc822"実体の ボディでは許されていません。メッセージヘッダーフィールドは、如何なる場 合でも必ず US-ASCIIでなければなりませんし、ボディ内のデーターは符号化 はでき、この場合カプセル化されたメッセージの内容転送符号化ヘッダー フィールドはこれを反映します。カプセル化されたメッセージのヘッダーに来 る非ASCIIテキストは、RFC 2047で記載された機構を使って特定化できます。 5.2.2. 部分(Partial)サブタイプ "partial"サブタイプは、大きな実体をメールが幾つかに分けられたものとし て配達し、受信表示代行手段が自動的に再結合されることを可能にするために 定義されています。(この概念は基本的なインターネットプロトコールでのIP断 片化と再集合に類似しています。)中間転送代行手段が送信可能な個々のメッ セージサイズを制限している場合、この機構が使えます。かくて、 "message/partial"メディアタイプは、ボディが大きな実体の断片を内容にし ていることを指しています。 "message"タイプのデーターはbase64もしくは quoted-printableで符号化され ないかもしれないので"message/partial"実体が、バイナリーもしくは8ビット 転送をサポートしている環境で構築される場合問題が生じる。バイナリーデー ターが、多元"message/partial" メッセージに分割され、各々がバイナリー転 送を要求するということが問題です。このようなメッセージがゲートウェイで 7ビット転送環境に遭遇するなら、7ビット世界用にそれらを適切に符号化する 方法が、全ての断片を待って内部のメッセージを再集合し次いで再集合された データーをbase64もしくはquoted-printableで符号化すること以外、全くあり ません。異なる断片は異なるゲートウェイを通過することが可能なので、これ でも受け入れられる解決ではありません。この理由から、 "message/partial" タイプの実体は必ずcontent-transfer-encodingは 7bit(規定値)でなければ なりません。特に、バイナリーもしくは8ビット転送をサポートしている環境 でさえも、"message/partial"タイプのMIME実体には、"8bit"もしくは"binary" のcontent- transfer-encodingの使用は、はっきりと禁止されます。これは、 内部メッセージは "8bit"もしくは "binary"符号化を使用してはいけないこと に、順次適用されます。 メッセージ転送代行手段によっては大きなメッセージを自動的に断片化するよ うにしそのような代行手段は非常に異なる断片化域値を使いますので、部分 メッセージの断片は、再集合によって、それ自身が部分メッセージを含むこと を示すことが可能です。これはあきらかに許されることです。 三つのパラメーターが、"message/partial"タイプのContent-Typeフィールド で特定されなけばなりません。最初は"id"で、断片をひと纏めにするのに使わ れるユニークな、出来る限り世界唯一の識別子としての、識別子です。(一般 的に識別子は本質的にはmessage-idです;二重引用符号で囲まれると、 RFC 2045で与えられた"parameter"用のBNFに沿って、如何なるmessage-idにもなれ ます。)二番目は整数の番号"number"で、この断片が断片連続体の何処に合う かを指す断片番号数です。三番目は別の整数をとる"total"で、断片の総数で す。この三番目サブフィールドは、最終断片に必須で、それより前の断片では オプッション (使用を薦められていますが)です。これらのパラメーターは どんな順番ででも与えられることにも注意してください。 従って、三断片メッセージの二番目の断片は以下のようなヘッダーフィールド があります: 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 しかし、三番目の断片は断片総数を特定しなければなりません: Content-Type: Message/Partial; number=3; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com" 断片番号は1、0からでなく、から始まりることに注意してください。 この方法で分断された実体断片が一緒に配置されるとき、その結果は必ず完全 なMIME実体で、それ自体のContent-Typeヘッダーを持ち、かくて別のデーター タイプも内容にするかもしれません。 5.2.2.1. メッセージ断片化と再集合 再集合された部分メッセージの意味は、内部メッセージを含むメッセージでは なく「内部」メッセージの意味でなければなりません。例えば、大きな音響 メッセージを幾つかの部分的なメッセージとして送信し、音響メッセージを含 カプセル化されたメッセージとしてではなく、単一の音響メッセージとして受 信者に表現することを可能にします。つまり、メッセージのカプセル化は「透 過性」と考えられます。 "message/partial"メッセージの断片の生成と再集合する場合、カプセル化さ れたメッセージのヘッダーは囲われた実体のヘッダーと合体されなければなり ません。この過程で以下の規則に注意しなければなりません: (1) 断片化代行手段は行境界だけでメッセージを分割しなければなりませ ん。行の終でなくポイントでの分割は、メッセージ転送がCRLF連続体 で終らないという、メッセージ転送の意味を保つことができる、かに 次々と依存しているので、この制限が課せられます。多くの転送はそ のような意味を保つことができません。 (2) 最初の囲われたメッセージからのヘッダーフィールド全ては、"Content-" ではじまるものや特別なフィールドである"Message-ID"・"Encrypted" と"MIME-Version"を除いて、新しいメッセージに適切に写されなけれ ばなりません。 (3) "Content-"と"Subject"・"Message-ID"・"Encrypted"で始まる囲われ たメッセージのヘッダーフィールドと"MIME-Version"フィールドは、 新しいメッセージのヘッダーフィールドに適切に添えられなければな りません。"Content-"("Subject"・"Message-ID"・"Encrypted"そし て"MIME-Version"フィールドを除き)で始まっていない囲われたメッ セージの如何なるヘッダーフィールドも無視され抜け落とされます。 (4) 二番目とそれに続く囲われたメッセージからのヘッダーフィールドは 全て再集合過程によって抜き取られます。 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 ... 符号化された音響の最初の半分がここにきます ... ... 符号化された音響の二番目の半分がここにきます ... 断片化されたメッセージの二番目とそれに続く部分のヘッダーの "References"フィールド、前の部分のMessage-Idを照合する、の封入は、照合 を理解し追跡するメールリーダーにとって有益であるかもしれません。しかし そのような "References" フィールドの生成は、全く選択性(オプッション) です。 最後に暗号化"Encrypted"ヘッダーフィールドは、Privacy Enhanced Messaging (PEM) [RFC-1422, RFC-1423]によって廃止されていますが、上の規 則はそれにもかかわらず、"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 ここは、実際のボディではありません! この終にある領域、「幻影ボディ= "phantom body"」と言われ、大部分の外 部ボディメッセージ用で無視されます。しかしメッセージの、access-typeが "mail- server" である場合実際にそうであるように、補助的な情報を内容と するために使われるかもしれません。この文書で幻影ボディを使用すると定義 されたaccess-typeは、"mail-server"だけで、その他のaccess-typesは将来こ の領域を使う別の仕様書で定義されるかもしれません。 "message/external-body"実体内の全てのカプセル化されたヘッダーは、 Content-IDヘッダーフィールドを持ち、データーを照合するためにユニークな 識別子が与えれれなければなりません。この識別子はキャッシング機構と access-typeが"mail-server"である場合そのデーターの受け取りを確認するの に使用されるかもしれません。 ここで特定化されたように、外部ボディデーター、ファイル名やメールサー バー命令といった、を記載する字句(トークン)はUS-ASCII文字セットが必須 です。 これが実際上問題があると分かったら、新しい機構が将来の拡張として、 "message/external-body"で新しくaccess-typesを定義するかもしくは別の何 らかの機構によって、MIMEに要求されるかもしれません。 "message/partial"と同じ様に、タイプ"message/external-body"のMIME実体は 内容転送符号化は7ビット(既定値)でなければなりません。特に、内容転送 符号化8ビットもしくはバイナリーの使用は、タイプ"message/external- body"の実体にははっきりと禁止されています。 5.2.3.1. 一般的な外部ボディパラメーター "message/external- body"で使用されるパラメーターは: (1) ACCESS-TYPE -- サポートされているアクセス機構、これによってファ イルやデーターを入手する、を指す単語。この単語は大文字小文字を 区別します。値としては、これだけに限りませんが、"FTP"・"ANON- FTP"・"TFTP"・"LOCAL-FILE"そして"MAIL-SERVER"が来ます。将来の 値、"X-"で始まる試験的な値を除いて、 RFC 2048に記載されているよ うにIANAに登録されなければなりません。このパラメーターは、無条 件に自由ですが、全ての"message/external-body"に来なければなりま せん。 (2) EXPIRATION -- 外部データーの存在が保証されなくなった後の日付 (年フィールドに桁数4を可能にするために、RFC 1123によって拡張さ れたものとしてのRFC 822 "date-time" 構文)。このパラメーターはど んなaccess-typeにも使われますが、常に選択性です。 (3) SIZE -- データーのサイズ(オクテックでの)。このパラメーターの 狙いは、外部データーを取ってくるのに必要なソースを使うかどう か、を決定することを助けることです。これは正式な書式、言い替え るとなんらかの内容転送符号化が適用される前かもしくはそのデー ターが復元された後、でのデーターサイズを記載することに注意して ください。このパラメーターはどんなaccess-typeにも使われますが、 常に選択性です。 (4) PERMISSION -- クライアントもそのデーターを上書きを試みるかと考 えられているかどうかを示唆する大文字小文字を区別するフィールド。 既定値によりもしくはpermissionが "read" の場合、それらは存在しな いと考え、デターが一旦取って来られると二度と必要がなくなります。 PERMISSIONが"read-write"なら、この前提は正しくなく、どんなローカ ル写しもキャッシュ以上ではないと考えられます。"Read" and "Read-write"が、許可(permission)での唯一の定義された値です。この パラメーターはどんなaccess-typeにも使われますが、常に選択性です。 ここで定義されたaccess-typesの正確な意味は、続くセクションで説明されま す。 5.2.3.2. 'ftp'と 'tftp' アクセスタイプ(Access-Types) FTPもしくはTFTPというaccess-typeは、メッセージボディがFTP [RFC- 959]も しくはTFTP [RFC- 783] プロトコールを使ってファイルとしてアクセスするこ とを指しています。これらaccess-typesには、以下の補足パラメーターは必須 です: (1) NAME -- 実際のボディがあるファイル名 (2) SITE -- ファイルを、一定のプロトコールを使って、そこから入手す る機械。これは、ニックネームでなく、完全に正しいドメイン名でな ければなりません。 (3) FTPを使ってデーターを取る前に、利用者に一般的に、そのサイトのパ ラメーターによって命名された機械用の、ログインIDとパスワードを提 供するよう頼む必要があります。安全性の理由から、そのようなIDとパ スワードはcontent-typeパラメーターとして特定されなくて、利用者か ら入手されねばなりません。 更に、以下のパラメーターが選択できます: (1) DIRECTORY -- NAMEによって名付けられてデーターを取ってくるべき ディレクトリー (2) MODE -- 情報を取ってくる際使用されるモードを示唆する大文字小文 字を区別しない文字列。アクセスタイプ"TFTP"の正しい値は、TFTPプ ロトコール[RFC-783]によって特定されているように、"NETASCII"・ "OCTET"そして"MAIL"です。アクセスタイプ"FTP"の正しい値は "ASCII"・"EBCDIC"・"IMAGE"そして"LOCALn"、ここでの"n"は整数十進 値で典型的には8、です。これらは、表現タイプ"A"・"E"・"I"そして "L n"、FTPプロトコール[RFC-959]で特定されるように、に対応しま す。"BINARY"と"TENEX"がモードにとって正しくない値で、その代わり に"OCTET"もしくは"IMAGE"もしくは"LOCAL8"が使用されるべきです。 モードが特定されていない場合既定値はTFTPには"NETASCII"、その他 では"ASCII"です。 5.2.3.3. 'anon-ftp' アクセスタイプ "anon-ftp"アクセスタイプは"ftp"アクセスタイプと同じですが、利用者は特 定されたサイトの名前やパスワードの提出を要求される必要がありません。そ の代わり、ftpプロトコールは、"anonymous"ログインと利用者のメールアドレ スに対応するパスワードを使います。 5.2.3.4. 'local-file' アクセスタイプ "local-file"アクセスタイプは実際のボディがローカル機械にあるファイルと してアクセス可能であることを指します。二つの追加パラメーターがこのアク セスタイプ用に定義されています: (1) NAME -- 実際のボディデーターを内容としているファイル名。このパ ラメーターは"local-file"アクセスタイプに必須です。 (2) SITE -- データファイルへのアクセス権を持っていると知られている 機械もしくは機械一式のためのドメイン特定値。この選択性のパラ メーターはデーター照合の場所、つまりファイルが見られると考えら れるサイトもしくはサイト群、を記載するのに使用されます。アスタ リックはドメイン名の一部に合うワイルドカードとして"*.bellcore.com" のように使用され、データーが直接見えるべき機械一式を示唆し、一 方単一アスタリックはあまねく入手できると考えられるファイル、例 えばグローバルファイルシステムを経て、を指すのに使われます。 5.2.3.5. 'mail-server' アクセスタイプ "mail-server"アクセスタイプは、実際のボディがメールサーバーから入手で きることを指しています。二つの追加パラメターがこのアクセスタイプ用に定 義されています: (1) SERVER -- 実際のボディデーターを入手できるメールサーバーのアド レス(addr-spec)です。このパラメーターは"mail-server"アクセスタ イプで必須です。 (2) SUBJECT -- データーを入手するために送られるメールで使用されなけ ればならない表題(subject)。表題行にメールサーバーを入力するこ とは薦められませんが、そのようなメールがあることが知られていま す。これは、選択性のパラメーターです。 メールサーバーは様々な構文、多行など、を受け入れますので、メールサー バーに送られる命令指示(コマンド)には、content-typeヘッダーフィールド のパラメーターを含んではいけません。その代わりに、メディアタイプが "message/external-body"でアクセスタイプがmail-serverの場合、「幻影ボ ディ="phantom body"」として提供されます。 MIMEはメールサーバー構文を定義していないことに注意して下さい。そうでは なく、幻影ボディに任意のメールサーバー指令の封入が可能です。装備は、適 切なデーターを取り出すためにメールサーバーアドレスに送るメッセージボ ディに、幻影ボディを含まなければなりません。 他のアクセスタイプとは異なって、メール-サーバーアクセスは非同期で、先 の予測が出来ない時に起こります。この理由から、返送されてきたデーターを オリジナルの"message/external-body"実体と一致させることができる、機構 がありことは重要なことです。そのような一致を容易にするために、MIMEメー ルサーバーは同じ、オリジナルの"message/external-body"実体で使用された、 Content-IDフィールドを返送されたメッセージに使用しなければなりません。 5.2.3.6. 外部-ボディ安全性問題 "Message/external-body"実体は、二つの重要な安全性問題が生じます。 (1) "message/external-body"照合経由のデーターアクセスによって、メ ッセージ発信者によって特定された操作の実行が、メッセージ受信者 に、効果的にもたらされます。それ故に、メッセージ送信者は、メッ セージ受信者をだまして、それ以外ではできないようなものをさせる ことが可能になります。例えば、発信者は、受信者が権威付けされな いで入手する素材取り込みを試みる行為、を特定することができ、受 信者が意に反して安全性問題に違反する原因になります。この理由か ら、外部照合を解決できる表示代行手段は、それを実行するする前に 受信者に使う行動を説明し、明確な許可を求める段階を踏まなければ なりません。 'mail-server'アクセスタイプは、元の発信者メッセージによって内容 が特定された新しいメッセージを送信することを受信者にもたらすと 言う点で、特に弱い。悪用の可能性を与えるので、構成されたそのよ うな請求メッセージは、自動的に(例えば、コメントやヘッダー フィールドに)MIME"message/external-body" 参照を解決しようとの 試みで、それらが生成されることの明確な示唆を含むべきです。 (2) MIMEシステムは、時にはメッセージ完全性と信頼性の保証を提供する 環境で使用されます。それがある場合その様な保証はメッセージの実 際の直接の内容にだけ適用されかもしれません -- それらはMIMEの "message/external-body" 機構を通してアクセスされたデーターに適 用されるかもしれないし、されないかもしれません。特にメッセージ システム自体は安全な場合でも、或る種のアクセス機構を誤らせる可 能性があるかもしれません。 この問題は、MIME機構を利用してもしなくても、存在することに注意 すべきです。安全なメッセージのテキストに文書を含むFTPサイトへの 偶然の照合は、同じ問題をもたらします -- ただ違う点は、MIMEはそ のような素材の自動的な取り込みを提供していることで、利用者は保 証されない委託はそのような自動的な取り込み機構であると位置付け るかもしれません。 5.2.3.7. 事例と詳しい説明 外部-ボディ機構が"multipart/alternative"メディアタイプと結合して使用さ れる場合、"multipart/alternative"の機能性を、同じ実体が同じ書式だが異 なるアクセス機構経由で提供される例に、拡張します。これがなされると、 メッセージの発信者は、はじめ書式用語で次いで好みのアクセス機構で、部分 を配置しなければなりません。従って受信者の閲覧は、書式とアクセス機構両 者のリストを評価すべきです。 非常に広域ファイルシステムの出現が可能になり、前もって機構一式がファイ ルシステムから直接アクセスできるどうかを知ることが困難になってきていま す。従って、直接試みられるためのファイル名とファイルがアクセス可能なひ とつ以上のサイト名を提供するのは道理に適っています。装備は、FTPや別の プロトコールを使って、匿名ファイル回収もしくは必要な名前とパスワードを 利用者に促すことで、遠隔ファイルを回収する試みができます。外部ボディが 多元機構経由でアクセス可能の場合、送信者は、囲われた"multipart/ alternative" 実体のボディ部分内の"message/external-body"タイプの多元実 体を含むかもしれません。 しかし、外部-ボディ機構は、mail-serverアクセスタイプべ見られるように、 ファイル回収に制限されることを狙っていません。さらに、例えばビデオク リップへの照合用外部照合ビデオサーバーを使うことも想像できます。 "message/external-body"のボディに現われる組み込まれたメッセージヘッ ダーフィールドは、外部ボディのメディアタイプ、US-ASCIIのプrーンテキス ト以外なら、を宣言するのに使われなければならなく、というのは外部ボディ はタイプを宣言するヘッダーセクションを持っていないからです。同じ様に、 7ビット以外の内容転送符号化もここで宣言されなければなりません。かく て、完全な"message/external-body"メッセージは、ポストスクリプト (PostScrip)書式の対象を照合し、以下のようなります: 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-- 上の例では、既定値内容転送符号化"7bit"が外部ポストスクリプトデーター用 と看做されていることに注意してください。 "message/partial"タイプと同じ様に、"message/external-body"メディアタイ プは透過性であること、言い替えるとそのタイプのボディのあるメッセージを 運ぶのではなく外部ボディのデータータイプを運ぶことを狙っています。かく て、外側と内側部分でのヘッダーは、"message/partial"用の規則を使って結 合されなければなりません。特にこれは、内容タイプ(Content-type) Subject(表題)フィールドは無効にされますがFromフィールドはそのまま残 されること、を意味します。 外部ボディは外部ボディ参照にそって転送されないので、参照自体に適用され る転送制限に適合する必要はありません。特に、インターネットメール転送は 7ビットと行の長さ制限を課すかもしれませんが、これらはバイナリー外部ボ ディ参照に自動的に適用されません。かくて、内容転送符号化は一般的には必 要、許されてはいますが、がありません。 タイプ"message/external-body"のメッセージボディはRFC 822メッセージの基 本的な構文によって決定されていることに注意してください。特に、CRLFの連 続部分の最初の前にくものは如何なるものでもヘッダー情報で、一方その後に くるものは如何なるものでもボディ情報、大部分のアクセスタイプを無視す る、です。 5.2.4. その他のメッセージ・サブタイプ MIME装備は一般的にはメッセージの認識されないサブタイプを"application/ octet-stream"と同じものとして取り扱わなければなりません。 メールでの使用を意図した"message"の将来のサブタイプは、「7ビット」符号 化に制限されるべきです。"message"以外のタイプは、7ビット制限が不可能な ら、使用されるべきではありません。 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で議論されています。装備は、受信者 環境への如何なる働きかけの遠隔実行を起こす可能性ある如何なるメディアタ イプの安全への影響に、特別な配慮を払うべきです。このような例で、 "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 Working GroupのRFC 822に関する 作業の成果です。そのグループの座長は、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 := <"message" as defined in RFC 822, with all header fields optional, not starting with the specified dash-boundary, and with the delimiter not occurring anywhere in the body part. Note that the semantics of a part differ from the semantics of a message, as described in the text.> close-delimiter := delimiter "--" dash-boundary := "--" boundary ; boundary taken from the value of ; boundary parameter of the ; Content-Type field. delimiter := CRLF dash-boundary discard-text := *(*text CRLF) ; May be ignored or discarded. 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 ; Composers MUST NOT generate ; non-zero length transport ; padding, but receivers MUST ; be able to handle padding ; added by message transports.