UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 翻訳 1999年 1月15日 / translation 15 January 1999 修正 2003年12月16日 / correction 16 December 2003 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2045 を訳者(marimo@wdic.org)が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 Network Working Group N. Freed Request for Comments: 2045 Innosoft Obsoletes: 1521, 1522, 1590 N. Borenstein Category: Standards Track First Virtual November 1996 Multipurpose Internet Mail Extensions [多目的インターネットメール拡張] (MIME) パート1: インターネットメッセージ本文のフォーマット このメモの位置づけ この文書は、インターネットコミュニティのための 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 と概ね直交し たものとなっている。 この最初の文書は、MIME メッセージの構造を記述するために使用された様 々なヘッダを指定する。 2番目の文書(RFC 2046) は、システムをタイプしているMIMEメディアの一 般構造を定義し、メディアタイプの初期のセットを定義する。 3番目の文書(RFC 2047) は、インターネットメールのヘッダフィールドの 非 US-ASCIIテクストデータを許すために、RFC 822 の拡張方法を示す。 4番目の文書(RFC 2048) は、MIME-関連の設備のための様々なIANA登録手続 を指定する。 最後の5番目の文書(RFC 2049) は、MIMEメッセージフォーマット、受領証、 および参考文献一覧のいくつかの説明に役立っている例を提供するだけでな く、RFC 2049 は MIME対応標準を記述する。 これらの文書は RFC 1521、1522 および 1590 の改訂版である。それはさ らに RFC 1341 と 1342 の改訂版である。RFC 2049 の付録は、以前の版と の変更点を述べている。 目次 1. はじめに 2. 定義、規定、および一般的なBNF文法 2.1. CRLF 2.2. キャラクタセット 2.3. メッセージ 2.4. エンティティ 2.5. ボディパート 2.6. ボディ 2.7. 7ビット データ 2.8. 8ビット データ 2.9. バイナリデータ 2.10. 行 3. MIME ヘッダフィールド 4. MIME-Version ヘッダフィールド 5. Content-Type ヘッダフィールド 5.1. Content-Type ヘッダフィールドの文法 5.2. Content-Type デフォルト 6. Content-Transfer-Encoding ヘッダフィールド 6.1. Content-Transfer-Encoding 構文 6.2. Content-Transfer-Encodings 語義 6.3. 新しい Content-Transfer-Encodings 6.4. 解釈と使用 6.5. 翻訳と符号化 6.6. 正規の符号化モデル 6.7. Quoted-Printable と Content-Transfer-Encoding 6.8. Base64 Content-Transfer-Encoding 7. Content-ID ヘッダフィールド 8. Content-Description ヘッダフィールド 9. 付加的な MIME ヘッダフィールド 10. 要約 11. セキュリティ対策 12. 奥付 A. 収集された文法 (訳注:本訳は都合上ページを振っていないので、上記のページ番号はす べて消した。読みづらい点はご容赦) 1. はじめに 1982年の発表以来、RFC 822 は、インターネットでテクストのメールメッ セージの標準のフォーマットを定義した。その成功は、RFC 822 フォーマッ トが採用されたようなものであったが、RFC 821 により定義されるインター ネットSMTP転送はインターネットの限界をかなり過ぎ、全面的に不十分だっ た。フォーマットがより広い使用を見ると、多くの制限がユーザコミュニテ ィのためにいよいよ制限的であると判明した。RFC 822 はテクストメッセー ジのためのフォーマットを指定することを意図していた。従って、オーディ オ、またはイメージを含むであろうマルチメディアメッセージのような非テ クストメッセージは全く言及されていない。しかし、テクストについてさえ RFC 822 は、言語が US-ASCII より多くのキャラクタセットの使用を必要と するメールユーザのニーズには不十分である。RFC 822 が、オーディオ、ビ デオ、アジアの言語テクスト、または、ほとんどのヨーロッパの言語のテク ストさえもを含むメールのためのメカニズムを指定していないので、仕様の 追加が必要である。 RFC 821/822 に基づくメールシステムの著しい制限のうちの1つは、それ らが、電子メールメッセージの行を相対的に短い(例えば、1000文字以下 [RFC-821])の 7ビットUS-ASCII に制限したという事実である。 これは、彼らがローカルなメール UA (ユーザエージェント。人間のユー ザがメールを送り、受け取るプログラム)をもたらす前に、印刷可能な US-ASCII 文字として再提供可能な7ビットのバイトで送る事を望んでいたの かもしれない。そして、あらゆる非テクストデータでも (7ビット US-ASCII 文字に)変換することをユーザに強制した。インターネットで現在使われて いるそのような符号化の例は、純粋な16進法、uuencode、RFC 1421 で規定 された 3-in-4 base64 方式、アンドリューツールキット表現 [ATK]などの ほか、多くのものが使われている。ゲートウェイが RFC 822 ホスト、及び X.400 ホストの間のメールメッセージの交換を認めるように設計されている ため、RFC 822 メールの制限は更に明白になる。X.400 [X400] は電子メー ルメッセージ内の非テクストのマテリアル(textual)の含有のためのメカニ ズムを指定する。 RFC 822 メッセージへの X.400 メッセージのマッピングのための現在の 標準は、X.400 非テクストのマテリアルが IA5Text フォーマットに変換さ れる(中で符号化されない)か、または、それらが RFC 822 ユーザに処分 が起こったことを通知したうえで処分されなければならないと規定する。だ がこれはユーザが受け取ることを望むかもしれない情報が失われるので、か なり不適当であるといえる。たとえユーザエージェントが非テクストのマテ リアル(textual)を扱う機能を持っていなくても、ユーザは UA のために外 部のあるメカニズムを持つことができマテリアルから有益な情報を抽出でき る。更にそれは結局メッセージが非テクストの情報が明確に再び有益になる (すなわちX.400メッセージはインターネットメールを経て "トンネリング" される)X.400メッセージ操作システムにゲートウェイされるかもしれない という事実を考慮しない。〔訳注:この辺の訳は難しい〕 この文書は、既存の RFC 822 メールの世界と、どのような重大な不一致 をも含めずにこれらの問題の殆どを解決するために結合する、いくつかのメ カニズムについて述べる。 特に、これらが述べられている: (1) MIME-Version ヘッダフィールドは MIME により規定されたメッセー ジを宣言するために、バージョン番号を用いてそのようなメッセー ジを区別しているメール処理エージェント、および更に古い、また はそのようなフィールドを欠くように推定される未対応ソフトウェ アで生成されたそれらを許す。 (2) Content-Type ヘッダフィールドは RFC 1049 から一般化していて、 メッセージのボディのデータのメディアタイプおよびサブタイプを 指定し、そのようなデータの生来の表現(正規のフォーム)を十分 に指定するために使用できる。 (3) Content-Transfer-Encoding ヘッダフィールドは、結果のボディと 領域に適用された両方の符号化変換と、結果のドメインの両方を指 定するために使用される。同一性変換を除いた符号化変換は、それ に、データまたは文字設定制限を持つことができるメール転送メカ ニズムを通過することを許すために、通常データに適用される。 (4) 更に一団となってデータを示すために使われ得る、2 つの付加的な ヘッダフィールドが、Content-ID および、Content-Description ヘッダフィールドである。 この文書において定義されたヘッダフィールドの全ては、RFC 822 におい て指定されたヘッダフィールドのための一般的な構文の規則が適用される。 特に、Content-Disposition のこれらのヘッダフィールドのうちのすべては RFC 822 コメントを含むかもしれないが、意味のある内容を全く持たないの で、MIME 処理の間に無視されるべきである。 最終的にインタオペラビリティを指定し促進するために、RFC 2049 は最 小のレベルのこのドキュメントへの「対応」を定義する前述のメカニズムの サブセットに基礎的で応用のきくステートメントを提供する。 歴史的な記録: ドキュメントのこのセットにおいて記述されたメカニズムのいくつか は、最初の表示でいくぶん意外な、もしくは、本当にバロック式のよう に思われるかもしれない。 既存の実行を横切る現存標準【と】頑丈な互換性が、ドキュメントのこの セットを開発したワーキング・グループに対する最も高い優先順位のうちの 2 つであったことに注目することは重要である。特に互換性は、常にエレガ ントさより優先されてきた。 どうか、標準化状態のための "インターネット公的プロトコル標準" の現 在の版、及び、このプロトコルの状態を参照してほしい。RFC 822 と STD 3、 RFC 1123 は、MIME のどの対応実行によってもそれらが違反できないので、 必須の背景も MIME に提供する。更に、いくつかの他の情報の RFC ドキュ メント、特に RFC 1344、RFC 1345、及び、RFC 1524 においては、MIME イ ンプリメント者(実装者)への関心となるだろう。 2. 定義、規定、および一般的なBNF文法 ドキュメントのこのセットにおいて指定されたメカニズムは、散文で全て 記述されるが、大部分は RFC 822 の増やされた BNF 表記法において正式に 示される。インプリメント者(実装者) は、ドキュメントのこのセットを理 解するためにこの表記法に精通している必要があり、さらに、増加させられ た BNF 表記法の完全な説明のための RFC 822 を参照する。 ドキュメントのこのセットの追加されたBNFのうちのいくらかが、構文規 則の指定された参照を RFC 822 において定義された状態にする。完全な正 式文法は、その時、RFC の BNFを 持つこのセットの個々の文書 RFC 822 へ の部分修正、RFC 1123 (どれによって『リターン』、『日付』、および、郵 便受けのための構文を明確に変更するか) において定義する状態でこのセッ トにおける各ドキュメントにおいて集められた、文法付録を結合することに よって獲得される。すべての数値とオクテット値はドキュメントのこのセッ トにおける 10進記数法において与えられる。全てのメディアタイプ値、サ ブタイプ値、及び定義されたパラメータ名は、大文字小文字を区別しない。 但し、パラメータ値は特定のパラメータのために違った形で指定されない限 り、大文字小文字をはっきり区別する。 フォーマットについての注意事項 : これは、読者によりあらゆる本質的な要素を逃されても、省略できる 付加的な非必須の情報のようなものの記録を提供する。これらの必須で ない記録の一次目的は、ドキュメントのこのセットの理論的基礎に関す る情報を伝える、もしくは、これらのドキュメントを適切な、歴史的な、 もしくは、発展の文脈に配置することである。そのような情報は、完全 に対応するインプリメントを作ると集中する人々によって、特に読み飛 ばされるかもしれない。しかし、なぜ一定のデザイン選択がされたかを 理解したい人々には有用であるかもしれない。 2.1. CRLF 用語 CRLF は、ドキュメントのこのセットにおいて、一緒に扱われ、かつ この順序を取り RFC 822 メールでの改行を示す 2 US-ASCII文字、CR(10進 の13)、および LF(10進の10)と一致しているオクテット列を意味する。 2.2. キャラクタセット 用語 "character set" (キャラクタセット; 文字集合)は、MIME において 一連のオクテットを一連のキャラクタに変換する方法を参照するために用い られる。他の方向における無条件の、そして曖昧な変換は必要としないこと に注意する。それでは全ての文字は与えられたキャラクタセットの近くで再 提供可能であるかもしれず、特有の一連の文字を表すよう、キャラクタセッ トがオクテットの複数のシーケンスを提供できる。 この定義は、キャラクタセットとして使われるために、US-ASCIIのような 単純なシングルテーブルマッピングから ISO 2022 の手法を使うそれらのよ うな方法を変える複合的なテーブルまでの様々な種類のキャラクタエンコー ディングを可能にすることを意図している。しかしながら、 MIME キャラク タセット名と関連した定義は、実行されるマッピングを十分に指定しなけれ ばならない。特に、正確なマッピングを決定する外部のプロファイリング情 報の使用は許されない。 注意事項: 用語 "character set" (キャラクタセット; 文字集合) は、元来 1つの オクテットから 1つのキャラクタまで、シンプルな一対一のマッピングを 持つ US-ASCII 及び ISO-8859-1 のような簡単なスキームを示すことだっ た。マルチオクテットなキャラクタセットを符号化し、そして、切り換え る技術は状況をより複雑にしている。例えば、幾つかのコミュニティは、 整数(非オクテット)から文字に抽象的なマッピングを示すように、 "coded character set" (符号化されたキャラクタセット) という句を用 いる間、MIME が "character set" と 呼ぶもののために、用語 "character encoding" を使う。 2.3. メッセージ さらに資格のない時の用語 "message" (メッセージ) は、ネットワークに 移されている(完全または「トップレベル」である)RFC 822メッセージか、 "message/rfc822" または "message/partial" タイプのボディにおいてカプ セル化されたメッセージを意味している。 2.4. エンティティ "entity" (エンティティ[実体]) という用語は、メッセージまたはマルチ パートエンティティのボディのパーツのうち、1つの MIMEで定義されたヘッ ダフィールドと中身を明確に補充する。そのようなエンティティの仕様が、 MIME の本質である。しばしばエンティティの中身が "body" (ボディ) と呼 ばれるので、エンティティのボディについて話すことは道理にかなう。あら ゆる種類のフィールドはエンティティのヘッダに存在するかもしれないが、 名前が実際に "content-" で始まるそれらのフィールドのみが、あらゆる MIME 関連の意味を持っている。これが、それらが全く意味を持っていない ことを意味【しない】ことに注意せねばならない…メッセージでもあるエン ティティは、意味がRFC 822 により定義されている 非MIMEヘッダフィール ドを持っている。 2.5. ボディパート 用語 "body part" (ボディパート) は、マルチパートエンティティの内側 のエンティティを指す。 2.6. ボディ 用語 "body" (ボディ) は更に資格が与えられないときに、エンティティ のボディ、すなわち、どちらものメッセージのボディ、またはボディパート のボディを意味している。 注意事項: 前の 4 つの定義は、明らかにまどろっこしい。MIME メッセー ジの全体の構造が実に再帰的なため、これは避けようが無い。 2.7. 7ビット データ "7bit data" (7ビットデータ) は、CRLF で改行するシーケンス [RFC-821] の間で、998 オクテット以下の相対的に短い行ですべてが表されるデータを 参照する。10進数値で 127を超えるオクテットは一切許されず、さらに、ど ちらも NUL ではない(10進数値 0 を持つオクテット)。CR(10進数値13) お よび LF(10進数値10) オクテットのみが、CRLF 改行のシーケンスの一部と して発生する。 2.8. 8ビット データ "8bit data" (8ビットデータ) は、CRLF で改行するシーケンス [RFC-821] の間で、998 オクテット以下の相対的に短い行ですべてが表されるデータを 参照する。そして、10進数値 127を超えるオクテットも使われうる。 "7bit data" (7ビットデータ) と同様に、CR と LF オクテットは、CRLF 改行シーケンスの一部として起こるだけである。さらに、NUL は一切許され ない。 2.9. バイナリデータ "Binary data" (バイナリデータ) は、オクテットのどのようなシーケンス のデータでも許される。 2.10. 行 "Lines" (行) は、CRLF シーケンスによって分離されたオクテットのシー ケンスと定義される。これは、RFC 821 と RFC 822 の双方で一致している。 "Lines" (行) は、実際、ユーザエージェントにより表示される何かと不 一致かもしれないメッセージのデータのユニットを参照するだけである。 3. MIME ヘッダフィールド MIME は、MIME エンティティの内容を記述するために使用されるいくつか の新しい RFC 822 ヘッダフィールドを定義する。これらのヘッダフィール ドは、少なくとも 2 つの文脈に存在する: (1) 規則的な RFC 822 メッセージヘッダの一部として。 (2) マルチパート構造の MIMEボディ部分ヘッダ内において。 これらのヘッダフィールドの正式の定義は、次の通りである : entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF ) MIME-message-headers := entity-headers fields version CRLF ; このBNF定義により暗示されて ; いるヘッダフィールドの命令は ; 無視されるべきである。 MIME-part-headers := entity-headers [ fields ] ; "content-" で始まらないあらゆる ; フィールドは、定義された意味を ; 持つことができず、そして、無視 ; されるかもしれない。 ; このBNF定義により暗示されている ; ヘッダフィールドの命令は無視され ; るべきである。 様々な特定の MIME ヘッダフィールドのシンタックスは、次のセクション で述べられるであろう。 4. MIME-Version ヘッダフィールド RFC 822 は 1982年に公表されたが、実際にインターネットメッセージの ためにわずか 1つのフォーマット標準があり、そして、使用中のフォーマッ トが標準であると宣言する必要性は、ほとんど気づかれなかった。この文書 は、RFC 822 を補足する独立した仕様である。このドキュメントにおける拡 張は RFC 822 と互換性があるような方法で定義されたが、まだメッセージ が心(mind)における新しい標準によって構成されたかどうかを知るために、 それがメール処理エージェントのために望ましいであろう情況がある。 従って、このドキュメントは、新しいヘッダフィールド "MIME-Version" (インターネットメッセージボディフォーマット標準のバージョンを使用中 であると宣言するために使われるべきである) を定義する。 このドキュメントに従って構成されたメッセージは、そのようなヘッダ フィールドに次と全く同じテクストを入れなければならない : MIME-Version: 1.0 このヘッダフィールドの存在は、この文書に従ってメッセージが創作され たという主張である。 将来のドキュメントで再びメッセージフォーマット標準を拡張することも 可能なので、正式の BNF は、MIME-Version フィールドの内容のために与え られる: version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT 従って、交換できるか、または "1.0" より拡張される未来のフォーマット 仕様は、ピリオドにより隔てられている 2つの整数フィールドであることが 強制される。もしメッセージが "1.0" を除いた MIME-Version 値によって 受け取られるなら、それは、その文書に対応することができないと推定され る。 メッセージの一番上のレベルにおいて MIME-Version ヘッダフィールドが 必要であることに注意する。それは、マルチパートエンティティの個々のボ ディ部分のために必要とはされない。もし、埋めこまれたメッセージ自身が MIME-conformant であると主張されるならば、それは "message/rfc822" ま たは "message/partial" タイプのボディのの埋め込まれたヘッダのために 必要とされる。 いかに、メールリーダがこのドキュメントにおいて定義された MIME に対 応しても、"1.0" 以外の MIME-Version のある値によって将来到着するだろ うメッセージを扱うべきであるかを、具体的に述べることは不可能である。 特定のメディアタイプのためのバージョンコントロールが遂行されないこ とに注意することは、同じく注目する価値がある。特に、いくらかのフォー マット(アプリケーション/ポストスクリプトのような)は、メディアフォー マットに内部的なバージョンナンバリング規定を持っている。そのような規 定が存在する所では、 MIME は何もそれらに取って代わることをしない。そ のような規定が存在しない所で、 MIME メディアタイプは、もし必要ならば コンテンツの型フィールドに "version" パラメータを使うであろう。 実装者への注意事項: MIME-Version 値をチェックするとき、存在するあらゆる RFC 822 コメ ント文字列を無視せねばならない。つまり、以下の 4つのMIME-Versionは 等価である: MIME-Version: 1.0 MIME-Version: 1.0 (produced by MetaSend Vx.x) MIME-Version: (produced by MetaSend Vx.x) 1.0 MIME-Version: 1.(produced by MetaSend Vx.x)0 MIME-Version フィールドがない時は、受け取っているメールユーザエー ジェント (MIME 要求に順応しているか否かにかかわらず) は、ローカルな 規定に従ってメッセージのボディの翻訳を任意に選ぶことができる。 多くのそのような規定は現在使用中であり、そして実際何でも非MIMEメッ セージにだいたい含んでいるかもしれないことが注目されるべきである。 それが、よく、MIME を前の日付にする標準外のローカル仕様のあるセッ トを使い、自動的に認められえない方法で示された別のキャラクタセットの テクストまたは非テクストのデータを含むメッセージであるかもしれないの で、非MIME メールメッセージが US-ASCII キャラクタセットの実際に明瞭 なテクストであると確信することは不可能である(例えば、uuencoded され た圧縮された UNIX tar ファイル)。 5. Content-Type ヘッダフィールド Content-Type フィールドの目的は、データをユーザに提示するために受 け取っているユーザエージェントが適切なエージェントやメカニズムを選ん だり、もしくは他の場合には、適切な方法におけるデータを扱うことができ る程十分に、ボディに含まれるデータを示すことである。このフィールドに おける値は、メディアタイプと呼ばれる。 歴史的な記録: Content-Type ヘッダフィールドは、最初 RFC 1049 において定義され た。RFC 1049 はここで与えられたメカニズムと大きな互換性があるが、 よりシンプルで、強力とはいえない構文を使っている。 Content-Type ヘッダフィールドは、メディアタイプ、及びサブタイプ識 別子を与え、そして、あるメディアタイプのために必要になるかもしれない 補助の情報を提供することにでエンティティのボディにおけるデータの性質 を指定する。メディアタイプおよびサブタイプの後に、attribute=value 表 記法において指定されるヘッダフィールドの残りは単なるパラメータのセッ トである。パラメータの順序は重要ではない。 一般に、トップレベルのメディアタイプは、データの一般タイプを宣言す るために使用される一方、サブタイプはそのタイプのデータのための特定の フォーマットを指定する。従って、たとえ、ユーザエージェントが特定のイ メージフォーマット "xyz" の知識を持っていないとしても "image/xyz" の メディアタイプは、ユーザエージェントにデータがイメージであると伝える のに十分である。そのような情報は、例えば、ユーザが認識されないサブタ イプから未加工の(生の)データであることを示すかどうか決定するために使 われ得る -- 認識されないサブタイプのイメージまたはオーディオのそのよ うな動作は、認識されないサブタイプのテクストのために妥当であろう。こ の理由のために、テクスト、イメージ、音声、およびビデオの登録サブタイ プは、実際に異なるタイプである埋め込まれた情報を含むべきではない。そ のような複合したフォーマットは、"multipart" または "application" タ イプを使って表されるべきである。 パラメータは、メディアサブタイプの変更者であり、そしてそれ自体では基 本的に内容の性質に影響を及ぼさない。有意義なパラメータのセットは、メ ディアタイプ及びサブタイプによって変わる。ほとんどのパラメータは一対 一で特定のサブタイプと関係している。しかしながら、agiven トップレベ ルのメディアタイプは、あらゆるサブタイプのそのタイプに適用できるパラ メータを定義するかもしれない。パラメータは、それらの定義するコンテン ツタイプに必要かもしれないし、そうでないならサブタイプまたはそれらは 任意だろう。MIME 実装は、それらが名前を認識しないあらゆるパラメータ を無視しなければならない。 例えば、"charset" パラメーターは "text" のどのようなサブタイプにで も適用できる一方、"boundary" パラメーターは "multipart" メディアタイ プのどのようなサブタイプのために必要となる。 すべてのメディアタイプにあてはまる世界的に有意義なパラメーターは全 く【ない】。本当に世界的なメカニズムは、付加的な Content-* ヘッダ フィールドの定義により MIME モデルに最もよくアドレスされる。7つのトッ プレベルのメディアタイプの最初のセットについては RFC 2046 で定義され ている。これらのうちの5つは、MIME処理が関係する限り、内容が本質的に 不透明な別個のタイプである。残る2つは、中身が MIME処理系によって付加 的な扱いを必要とする合成されたタイプである。 トップレベルのメディアタイプのこのセットは、大幅に完全であることを 意図している。サポートされたタイプの更に大きいセットへの追加が新しい サブタイプのこれらの最初のタイプの創造によって一般に遂行されることが 予測される。将来において、更にトップレベルのタイプは、この標準への標 準トラック拡張によってのみ定義されるかもしれない。もし別のトップレベ ルのタイプが何かの理由のために使われるべきならば、それは、その非標準 的状態を示し、かつ将来の公式の名前との潜在的な対立を回避するために、 "X-" で始まる名前を与えなければならない。 5.1. Content-Type ヘッダフィールドの文法 RFC 822の引き数 BNF 表記法について、Content-Type ヘッダフィールド 値は次の通り定義される: content := "Content-Type" ":" type "/" subtype *(";" parameter) ; メディアタイプおよびサブタイプと ; マッチするのは【常に】無関係である。 type := discrete-type / composite-type discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token composite-type := "message" / "multipart" / extension-token extension-token := ietf-token / x-token ietf-token := <標準トラックRFCとIANAに登録された 拡張トークンにより定義される> x-token := <どのような証拠のためでも、空白を介在せずに "X-" または "x-" が続いていた2文字> subtype := extension-token / iana-token iana-token := <公に定義された拡張トークン。このフォームの証 拠は RFC 2048 において指定されるように IANA によって登録されなければならない。> parameter := attribute "=" value attribute := token ; 属性とマッチングするのは ; 【常に】無関係である。 value := token / quoted-string token := 1*<空白、コントロール文字、及び tspecials を除いた全ての US-ASCII 文字> tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; パラメーター値の中で使うために、 ; 引用された文字列でなければならない 3文字 "/"、"?" と "="、および "." の除去の付加によって "tspecials" の定義が "specials" の RFC 822 定義と同等であることに注意すること。 サブタイプ指定が【半ば義務】であることにも注意すること -- それは Content-Type ヘッダフィールドから省略できない。そのようなものとして デフォルトサブタイプは存在しない。 タイプ、サブタイプ、およびパラメータ名は、大文字小文字を問わない。 例えば、TEXT、Text、および TeXt は、すべて等しいトップレベルメディア タイプである。パラメータ値は普通、大文字小文字を区別するが、時々、意 図された使用に応じた大文字小文字を区別しない方式で解釈される(例えば、 マルチパート境界は大文字小文字を区別するが、message/External-body の ための "access-type" (アクセスタイプ) パラメータは、そうではない)。 引用されたストリングパラメータの値が引用文を含まないことに注意する こと。すなわち、引用されたストリングの引用符はパラメータの値の一部で はないが、単にそのパラメータ値の境界を定めるために使用される。さらに、 コメントは構造化されたヘッダフィールドのための RFC 822 規則に従って 許される。 従って、以下の2つのフォーム Content-type: text/plain; charset=us-ascii (Plain text) Content-type: text/plain; charset="us-ascii" は、完全に等しい。 この構文を越えて、サブタイプ名の定義における唯一の構文の制限は、そ れらの利用が対立してはいけないという願望である。 すなわち、2つのそれぞれの共同体に、2つのそれぞれの物を意味するよう に、"Content-Type: application/foobar" を使用させておくことは不適当 である。 新しいメディアサブタイプを定義するプロセスは、それらの定義、及び、 使用を広告するために単にメカニズム以外の制限を課すためのメカニズムを 意図するつもりはない。従って、新しいメディアサブタイプを定義すること に、2つの容認できるメカニズムがある: (1) プライベートな値("X-" で始まる)は外部の登録または規格外で、 2人のエージェント間の協力で対照的に定義されるかもしれない。 そのような値は登録または規格化できない。 (2) 新しい標準値は RFC 2048 において記述されるように IANA によっ て登録されるべきである。 このセット、RFC 2046 の 2番目の文書は、MIME のためのメディアタイプ の初期のセットを定義する。 5.2. Content-Type デフォルト MIME Content-Type ヘッダなしのデフォルト RFC 822 メッセージは、 US-ASCII キャラクタセットにおいて明白に指定され得る明瞭なテクストで あるためのこのプロトコルによってとられる : Content-type: text/plain; charset=us-ascii もし Content-Type ヘッダフィールドが全く指定されないなければ、この デフォルトが仮定される。文法的に無効の Content-Type ヘッダフィールド に遭遇した時に、このデフォルトが仮定されることもまた推奨する。 MIME-Version ヘッダフィールドの存在、および、あらゆる Content-Type ヘッダフィールドの欠如においても、受け取るユーザエージェントが明瞭な US-ASCII テクストが発信者の意図だったと仮定することができる。プレー ン US-ASCII テクストは、MIME-Version が存在しないとき、または、文法 的に無効の Content-Type ヘッダフィールドの時はまだ仮定されうる。だけ れども、発信者の意思は違っていたかもしれない。 6. Content-Transfer-Encoding ヘッダフィールド 電子メール経由で有効に転送できた多くのメディアタイプは、それらの 「自然な」フォーマットにおいて8ビット文字またはバイナリのデータとし て表されている。そのようなデータは、いくつかの転送プロトコル上に送信 できない。例えば、RFC 821 (SMTP) は、どのような末尾 CRLF 改行でも含 む1000文字よりも短い行で、メールメッセージを 7ビットUS-ASCIIデータに 制限している。 従って、7ビットの短いラインフォーマットにそのようなデータをコード 化するための標準のメカニズムを定義することが必要である。それほど制限 的ではないフォーマットの非符号化マテリアルへの適当な分類は、直接的な 使用のためには、それほど制限的ではない転送の要求に適している。 このドキュメントは、そのようなエンコーディング(符号化)が、新しい "Content-Transfer-Encoding" ヘッダフィールドにより示されると規定す る。このフィールドは、どのような以前の標準によっても定義されていな かった。 6.1. Content-Transfer-Encoding 構文 Content-Transfer-Encoding フィールドの値は、下に列挙されるように符 号化のタイプを指定している単一のトークンである。本式: encoding := "Content-Transfer-Encoding" ":" mechanism mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token これらの値は大文字小文字を問わない -- Base64、BASE64、および bAsE64 は全て等価である。7ビットの符号化タイプは、すでにボディが 7ビットメー ル表現であることを必要とする。これがデフォルト値である -- すなわち、 もし Content-Transfer-Encoding ヘッダフィールドが存在しないならば、 "Content-Transfer-Encoding: 7BIT" が仮定される。 6.2. Content-Transfer-Encodings 語義 この単一な Content-Transfer-Encoding トークンにより、実際に 2個の 情報が提供される。それは、ボディがどのような種類の符号化変換に従って いたかを指定し、従って、それをそのオリジナルなフォームに返すために解 読オペレーションが用いられなければならない。そしてそれは、結果のドメ インが何であるかを指定する。 あらゆる Content-Transfer-Encodings の変換部分は、1つの明確なデコー ディングアルゴリズムを明白に、或いは、それとなく指定し、符号化された オクテットのいくらかシーケンスのうちのいずれがそれを変えるか、符号化 されたオクテットのオリジナルのシーケンス、もしくは、それが符号化され たシーケンスとして不正であることを示す。 Content-Transfer-Encodings の変換は、決して適当なオペレーションに ついてどのような付加的な外部の側面情報にでも依存しない。 デコーダが正当なエンコーディングのために 1つの明確な出力を生み出さ なければならないことと同時に、そのような制限がエンコーダのために存在 しないことに注目せよ: オクテットのあるシーケンスを異なる同等のコード 化されたシーケンスに符号化することは、完全に合法的である。 現在 3つの変換が定義される: 同一(つまり変換されていないのと同じ)、 "quoted-printable" 符号化、および "base64" 符号化である。これらのド メインは、"binary"、"8bit" 、および "7bit" である。 Content-Transfer-Encoding は、"7bit"、"8bit"、および "binary" の同 一性(すなわち非)符号化変換が実行されたすべての平均を見積もる。そ のようなものとして、それらは単にボディデータの領域のインジケータとし て役立つ。さらに、それを符号化する種類についての有益な情報を提供する ことについては、与えられた転送システムのトランスミッションのために必 要であるかもしれない。"7bit data"、"8bit data"、および "binary data" という用語は、すべてセクション2で定義されている。 quoted-printable と base64 符号化は、恣意的な領域から "7bit" 範囲 のマテリアルにそれらの入力を変換し、それにより限定された輸送路上でも 安全に届くようにする。変換の特定の定義は下で与えられる。 いつも適切な Content-Transfer-Encoding 分類が使われねばならない。 "7bit" として 8ビット文字を含む符号化されないデータを分類するこは許さ れない。そして符号化されない non-line-oriented データを "binary" (バ イナリ) を除いた何にでも分類することを許す。 メディアサブタイプとは違い、Content-Transfer-Encoding 値の増殖は不 適当で、かつ不要である。しかしながら、ひとつの変換のみ "7bit" ドメイ ンに確立すること不可能と思われる。巨大なバイナリデータの、コンパクト な、そして効率的なエンコーディングに対する願望、及び、完全にではなく たいてい 7bit であるデータの幾分読みやすいエンコーディングに対する願 望の間にトレードオフ(tradeoff) がある。 この理由のために、最低 2つの符号化メカニズムが必要である: 多少読み やすい符号化(quoted-printable)、および「濃い」または「均一な」符号化 (base64)。 符号化されていない 8ビットデータのためのメール転送は、RFC 1652 に おいて定義される。このドキュメントの最初の発表段階では符号化されない バイナリデータをメールボディに入れることが合法的であるような標準化さ れたインターネットメールトランスポートはない。従って実際インターネッ トメールで "binary" Content-Transfer-Encoding が有効な状況はまず無い。 しかし、バイナリメール転送がインターネットメールで現実的になること、 または MIME がどのような他のバイナリ可能なメール転送メカニズムと連携 して使われる場合でも、バイナリボディは、このメカニズムを使って、その ようなものとして分類されなければならない。 注意事項 : 符号化されなかったならば、Content-Transfer-Encoding フィールドの ために定義された 5つの値は、それが何でエンコードされたか、または、 もしエンコードされていないシステム要求のアルゴリズム以外のメディア タイプについては、何もほのめかしてはならない。 6.3. 新しい Content-Transfer-Encodings 実装者は、必要なら、私的な Content-Transfer-Encoding 値を定義する ことができるが、それが非標準のステータスであることを示すために、"X-" により前置された名前である x-token を使わなければならない。例えば、 "Content-Transfer-Encoding: x-my-new-encoding"。付加的な規格化された Content-Transfer-Encoding 値は、標準トラックRFCにより規定されなけれ ばならない。そのような仕様を満たしているはずの要求は、RFC 2048 にお いて与えられる。 従って、"X-" で始まるものを除く content-transfer-encoding 名前空間 の全ては、将来の使用のため IETF により明白に予約される。メディアタイ プやサブタイプと違い、新しい Content-Transfer-Encoding の創造は、小 さな潜在的な利益によってインターオペラビリティを妨げることがあると思 われているため、強く妨害される。 6.4. 解釈と使用 Content-Transfer-Encoding ヘッダフィールドがメッセージヘッダの一部 として現れるなら、それはそのメッセージの全体のボディにあたる。もし、 Content-Transfer-Encoding ヘッダフィールドがエンティティのヘッダの一 部として出現するなら、それはそのエンティティのボディにだけ当たる。エ ンティティがタイプ "multipart" なら、Content-Transfer-Encoding が、 "7bit"、"8bit" または "binary" 以外の値を持つことは不可能である。更 に厳しい制限はいくらかのサブタイプ "message" タイプに適用される。 ビットというより、殆どのメディアタイプがオクテットにで定義されるこ とが言及されるべきなので、ここで記述されたメカニズムは、恣意的なオク テットのストリーム(流れ)を符号化するためのメカニズムであることが言 及されるべきであり、ビットのストリーム自体を指しているのではない。 もしビットのストリームがこれらのメカニズムのうちの1つを経て記号化 される必要があるならば、最初、ストリームのより早いビットが 8ビット のバイトのより高いオーダービットになるネットワーク基準ビットオーダー (ビッグエンディアン)を使って 8ビットのバイトのストリームに変換され なければならない。また 8ビット境界で終わらないビットのストリームは、 ゼロでパディング(穴埋め)されなければならない。 RFC 2046 は「パディング」パラメータを持つ application/octet-stream のメディアタイプについてそのようなパディングの付加メカニズムを提供す る。ここで定義された符号化メカニズムによって、US-ASCIIのすべてのデー タが明示的に符号化される。従って、例えば、エンティティは以下のような ヘッダフィールドを持っていると思われる: Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 これは、ボディが ISO-8859-1 に元々あったデータの base64 US-ASCII 符号化であり、解読の後に再びそのキャラクタセットにあるのを意味するよ うに説明されなければならない。一定の Content-Transfer-Encoding 値は 一定のメディアタイプにより使われる。ただし、それが "7bit"、"8bit" も しくは "binary" を除いて符号化することは【明確に禁じられる】。すなわ ち、他の Content-Type フィールドを再帰的に含む。現在唯一の合成メディ アタイプは "multipart" と "message" である。符号化の必要がある実際の ボディを符号化することで、multipart(マルチパート) や message (メッ セージ) のタイプのボディのために望まれる全てのエンコーディングは、最 も深いレベルで行われなければならない。合成されたエンティティが "7bit" などの transfer-encoding 値を持っているが、取り囲まれたエンティティ のうちの1つが "8bit" 等のそれほど制限的ではない価値を持ち、その時、8 ビットデータが含まれること、または置かれる内側の "8bit" ラベル付けに より実際の含まれたデータが実際に 7ビットセーフであったので、不必要に 高い要求が輸送システムに置かれたので、外の "7bit" ラベル付けがエラー にあることを定義でもまた明らかに言及すべきである。 符号化制限における記録: 合成されたボディデータに関して content-transfer-encodings を使うこ とを禁止することは過度に制限的だと思われるかもしれないが、データが 符号化アルゴリズムを何度も通過すれば、適切に見られるようにするには 複数回復号化しなければならないので、符号化のネスト(多重化される) を妨げることは必要である。 ネストした符号化は、かなりの複雑さをユーザエージェントに加える : そのような多重符号化に関する明白な効率問題は別として、それらはメッ セージの基礎的な構造を不明瞭にする。特に、それらは、いくらかの復号 化オペレーションが単にメッセージがどのようなボディのタイプを含むか を見い出すために必要であるかを意味している。ネストした符号化を禁止 することは、あるメールゲートウェイのジョブを複雑にするかもしれない が、これはユーザエージェントへのネストした符号化の影響より問題が少 なように思われる。 Content-Type ヘッダフィールドが実際に言うものに関係なく、それが "application/octet-stream" の Content-Type を持っているかのように、 認識されない Content-Transfer-Encoding を持つどんなエンティティでも 扱わなければならない。 CONTENT-TYPE と CONTENT-TRANSFER-ENCODING の間の関係の記録: Content-Transfer-Encoding が符号化されるべきであるメディアの特性か ら推論できたと思われるかもしれない、または、ちょうどその最小では、 一定の Content-Transfer-Encoding を使用するために特定のメディアタイ プにより矯正された。これが大文字小文字を区別するいくつかの理由があ る。最初に、変化しているタイプのメールのために使われるトランスポー トを行われて、いくらかのエンコーディングは、他のものではなくメディ アタイプ、及びトランスポートのいくらかの結合に適しているかもしれな い。(例えば、8bitトランスポートにおいて、エンコーディングがあるキャ ラクタセットにおけるテキストのために必要ではないだろう。その一方、 そのような符号化が 7bit SMTP のために明瞭に必要とされる)。第二に、 一定のメディアタイプは、種々の状況の下で符号化する転送の 種々のタイプを必要とするかもしれない。例えば、多くの PostScript ボ ディは完全に 7ビットデータの短い行でから構成されているため、符号化 することすら必要としないかもしれない。他の PostScript ボディ(特に それらの使用レベル2 PostScript のバイナリの符号化メカニズム)は、バ イナリ転送符号化を使って適切に表されているかもしれないだけである。 最後に、Content-Type フィールドが、無制限の指定メカニズムであること を意図しているので、メディアタイプの間の協会の仕様と符号化すること は、特定のより低いレベルの転送によって適用プロトコルの指定を効果的 に結合する。 6.5. 翻訳と符号化 それらの間の変換は、quoted-printable と base64 で符号化し、デザイ ンされるので可能である。そのような変換において生じる唯一の問題は、 quoted-printable 符号化の出力での固定長行改行 (hard line break) の扱 いである。quoted-printable から base64 に変換する時には、quoted- printable フォームでの固定長行改行がデータの正規のフォームでの CRLF シーケンスを表している。従って、それはデータの base64 フォームの一致 記号化された CRLF に変換されなければならない。同様に、base64 復号化 が quoted-printable できる固定長行改行に変換されなければならなくた後 で、しかし、テクストデータを変換している時【のみ】、正規な形のデータ における CRLF シーケンスが通用される。 6.6. 正規の符号化モデル この RFC の前のバージョンにおいて、いくらか混乱があった。電子メー ルデータが正規のフォームに変換され符号化される必要があった時のための モデルを考慮に入れていること、さらに CRLF の取り扱いがどのようにこの プロセスに影響するかの事項、新しい行の表現がシステムからシステムに変 化する、そして content-transfer-encodings とキャラクタセットの間の関 係が定着する。符号化するための正規のモデルはこの理由のため RFC 2049 において規定される。 6.7. Quoted-Printable と Content-Transfer-Encoding Quoted-Printable 符号化は、US-ASCII キャラクタセットに印刷可能な文 字と一致しているオクテットから主として成っているデータを表しているこ とを意図している。それがデータをそのような方法で記号化するので、結果 として生じたオクテットがメール転送により修飾されることはありえない。 符号化されているデータの大半が US-ASCII テクストであるなら、データの 符号化されたフォームは、大いに人間によって認識できる状態を維持する。 完全に US-ASCII であるボディは、データの完全性を保証するため Quoted-Printable において character-translating および/または、 line-wrapping ゲートウェイを通るメッセージパスと同じく符号化されるか もしれない。 この符号化においては、オクテットは以下の規則のため決定されるように 表されている必要がある: (1) (一般8ビット表現) どのようなオクテットでも、符号化されてい るデータの正規のフォームの CRLF 改行の一部である CR または LF を除いて、"=" に続くオクテットの値の 2ディジット16進法表 現より説明できる。16進法のアルファベットの数字は、この目的の ために "0123456789ABCDEF" である。大文字を使われなければなら ない;小文字は許されない。従って、例えば 10進値の12(US-ASCII のフォームフィード…改頁)は "=0C" で表され、そして、10進値 の61(US-ASCII の等号)が "=3D" で表され得る。この規則は、以 下の規則が代わりの符号化を許す時を除いて従われなければならな い。 (2) (文字どおりの表現) 33 から 60 まで、および 62 から 126 までの 範囲の数値のオクテットは、【多分】それらのオクテットと一致し ている US-ASCII文字として説明できる(感嘆符からチルダの範囲 内)。 (3) (空白) 【多分】9 と 32 の値のオクテットが US-ASCII TAB(HT) と SPACE 文字であるのが見せられうる。しかし、符号化されたラ インの終わりにおいてそう説明【されてはならない】。従って、そ の行において、記号化されたラインのどのような TAB(HT)または SPACE 文字にでも印刷可能な文字が続いているに【違いない】。 特に、符号化された行の終わりの時の "=" は、ソフト的に改行を 示し(規則#5 を見よ)、1つ以上の TAB(HT)または SPACE 文字 が続いているかもしれない。符号化された行の終わりにおいて 9 または 32 で出現する数の値を持つオクテットは規則#1 に従って 表されているに違いないことになる。いくつかの MTA(メッセージ 転送エージェント、1人のユーザからメッセージを別の人へ輸送す るプログラムまたはそのような転送の部分を実行する)が、スペー スによってテクストのラインをパディングすると知られているので、 この規則が必要で、他は「空白」文字を行の終わりから取り去ると 知られている。従って、Quoted-Printable なボディを解読する時 には、必ず、それがトランスポートエージェントにより付加されて いようと、行のどのような引きずっている空白でも削除されなけれ ばならない。 (4) (改行)テクストボディ(テクスト正規フォームでの CRLF シーケン スとして表されている)での改行は、Quoted-Printable 符号化に おいて、CRLF シーケンスでもある(RFC 822)改行で表されている にちがいない。テクスト一般不包括を除いたメディアタイプの正規 表現以来、行の表現が CRLF シーケンスとして起こる強制改行(す なわち、有意義で、ユーザに表示される改行)は、そのようなタイ プの quoted-printable 符号化には存在していない。 もちろん、"=0D", "=0A", "=0A=0D" や "=0D=0A" のようなシーケ ンスは、quoted-printable の代表である非テクストデータ中にお いて頻繁に出現するだろう。最初に生じる正規の変換より、むしろ 様々なコンテンツの型のローカルな表現を直接符号化するために多 くの実装が選出されるかもしれない注意事項は、符号化、そして、 変換をローカルな表現へ形成する。特に、これは、 CRLF 末端シー ケンス以外の新しい行の規定を使うシステム上の明瞭なテクスト材 料に適用されるかもしれない。そのような実装の最適化は、許すこ とができる。しかし、結合された canonicalization-encoding (正 規化された符号化) ステップが機能に相当する時のみ 3つのステッ プは別々に実行される。 (5) (ソフト改行) Quoted-Printable 符号化は、符号化された行が長さ わずか76文字を超えないことが【要求】される。更に長い Quoted- Printable 符号化行が符号化される必要があるなら、"soft" 改行 が使われなければならない。符号化された行の最後の文字としての 等号は、符号化されたテクストでのそのような非重要な("soft") 改行を表している。 従って、もし行の "raw" フォームが、単一の符号化されていないライン であるというならば: Now's the time for all folk to come to the aid of their country. (訳: 今は、すべての人々がそれらの国の援助に来るという時間です。) これは以下としての Quoted-Printable 符号化において表されているかも しれない: Now's the time = for all folk to come= to the aid of their country. これは、長い行が、ユーザエージェントにより復元される方法で符号化さ れるメカニズムを提供する。76 の文字限界は、末尾の CRLF はカウントし ないが、どのような等号でも含むすべての他の文字をカウントする。 符号化されたボディにおいて境界デリミタがどこにも現れないことを保証 するために、ハイフン文字("-") が Quoted-Printable 符号化において自身 として表明されるので 1つ以上の multipart の中で Quoted-Printable で きる符号化されたボディをカプセルに入れているとき、注意が行われなけれ ばならない(よい戦略は、決して quoted-printable なボディにおいて出現 できない "=_" などの文字シーケンスを含む境界を選択することである。 RFC 2046 のマルチパートメッセージの定義を見よ)。 注意事項: quoted-printable 符号化は、転送時における読み易さ、及び信頼性の 間での妥協点のうちのいくらかを表す。quoted-printable によって符号 化されたボディは殆どのメールゲートウェイ上で確実に機能するだろう。 しかし、いくつかのゲートウェイ、特に EBCDIC への翻訳を包含するそれ らでは完全に機能されないかもしれない。更に高いレベルの信頼性は、 base64 Content-Transfer-Encoding によって提供される。EBCDIC ゲート ウェイを経ても適度に信頼できる転送結果を得るためには、規則#1どおり に US-ASCII 文字 !"#$@[\]^`{|}~ を同じく引用することである。 quoted-printable なデータは line-oriented(行指向) であると一般にみ なされるので、それは予期される必要があり、転送し quoted-printable な データの行間の改行表現は、同じ方法において様々な新しい行の規定による システムの間で通過しているとき、その明瞭なテクストメールは、インター ネットメールにおいて常に変更できる。もしそのような変更がデータの堕落 を構成しそうなら、quoted-printable 符号化よりむしろ base64符号化を使 うほうが、恐らくより賢明だろう。 注意事項: サブストリングのいくらかの種類は quoted-printable な content- transfer-encoding のための符号化規則に従って生成できないので、もし quoted-printable な符号化処理の出力に於いてそれらが出現するなら、 それ故に正式には違反である。この注意書はこれらのケースを列挙し、も し解読されるべき quoted-printable にていくらか遭遇するならば、その ような違反サブストリングを扱うための方法を示唆する。 (1) "=" の後に続く 2つの16進数値の1つ、またはどちらかが "abcdef" の小文字である場合は正式には違反である。堅牢な実装なら、それ らを一致する大文字と承認することに決めるだろう。 (2) "=" の後に 16進法("abcdef" を含む)と CRLF ペアの CR文字で はない文字が続くのは違反である。このケースは quoted-printable な符号化でそれ自体支配されずにメッセージの quoted-printable な部分に含まれた US-ASCII テクストの結果であり得る。堅牢な実 装による妥当なアプローチは、"=" 文字、及び次の文字をあらゆる 変化なしの解読されたデータに入れることであり、そして、可能で あれば適切な復号処理がこの点でデータにおいて可能ではなかった ことをユーザに示すであろう。 (3) "=" は、符号化されたオブジェクトにおける語尾または最後から 2 番目のキャラクタであり得ない。これは、上のケース (2) と同様 に扱われるであろう。 (4) TAB または CRLFペアのパーツ CR や LF 以外のコントロールコー ドが現れてはならない。同じものは、10進数値 126 より大きいオ クテットにあてはまっている。もし復号処理で quoted-printable 中に発見されたなら、堅牢な実装は、解読されたデータからそれら を除外し、そして違法のキャラクタが発見されたとユーザに警告す るだろう。 (5) 符号化された行は、行末の CRLF を含まないで 76文字より長くて はならない。にもかかわらず、万一より長い行が符号化されたデー タにおいて発見されたなら、堅牢な実装は、それでもなお行を解読 するだろう。そして、誤った符号化であることをユーザに報告する だろう。 実装者に対する警告: もし quoted-printable でバイナリのデータが符号 化されるならば、"=0D" および "=0A" として CR と LF 文字をそれぞれ符 号化するために気を付けねばならない。特に、バイナリデータにおけるCRLF シーケンスは、"=0D=0A" として符号化されるべきである。さもなくば、も し CRLF が矯正改行として判断されたならば、それは、異なる改行規定を持 つプラットホームでは不正確に解読されるであろう。 形式主義者のために、quoted-printable のデータの構文は、次の文法に よって記述される: quoted-printable := qp-line *(CRLF qp-line) qp-line := *(qp-segment transport-padding CRLF) qp-part transport-padding qp-part := qp-section ; 最大長は 76文字 qp-segment := qp-section *(SPACE / TAB) "=" ; 最大長は 76文字 qp-section := [*(ptext / SPACE / TAB) ptext] ptext := hex-octet / safe-char safe-char := <10 進値で 33~60、および 62~126 までのあらゆる オクテット> ; RFC 2049 において「mail-safe」として、リスト ; されなかったキャラクタは、同じく推薦されない。 hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; 127 を超える文字、行末の =、空白、または TAB、 ; そして RFC 2049 において「mail-safe」として、 ; リストされなかったあらゆるキャラクタが推薦さ ; れる。 transport-padding := *LWSP-char ; 送信側は non-zero 長のトランスポート ; パディングを生成【してはならない】。 ; しかし、受信側はメッセージ転送によっ ; て加えられたパディングを扱うことが ; 【できなければならない】。 重要: この BNF が構造化されたヘッダフィールドを指定しないので、こ の BNF で示された要素間の LWSP の追加は、許され【ない】。 6.8. Base64 Content-Transfer-Encoding Base64 Content-Transfer-Encoding は、人間的に読みやすい必要のない フォームにおいてオクテットの任意のシーケンスを表すように設計されてい る。符号化と解読のアルゴリズムは簡単である。しかし符号化されたデータ は符号化されないデータよりほんの僅か、約33%大きくなる。RFC 1421 にお いて定義されたように、この符号化は、実質的に Privacy Enhanced Mail (PEM) アプリケーションに使われるものと同じである。 US-ASCII のサブセットの 65文字を使い、6ビットが印刷できるキャラク タとして表すことを可能とする(余分の第65のキャラクタ "=" は、特別な 機能処理を意味するために使われる)。 注意事項: このサブセットは、それが全く同じに ISO 646 (US-ASCII を含む) の全てのバージョンの代表を務める重要なプロパティを持っており、そして サブセットにおける全てのキャラクタは、 EBCDIC の全てのバージョンにお いても全く同じく表される。マッキントッシュ binhex 4.0 [RFC-1741] 、 及び base85 符号化は、Level 2 ポストスクリプトの一部として、 エンコーディングのような他のポピュラーな符号化が uuencode ユーティリ ティによって使用したことを指定した。これらの資産を分配しないこと。そ して、メールのためのバイナリトランスポート符号化処理が満たさなければ ならないような可搬性の要求を満たしてはならない。 符号化プロセスは、4つの符号化された出力文字列が、入力ビットの24 ビットグループを表現している。左から右へ処理し24ビットの入力グルー プは、3つの8ビット入力グループのシーケンスにより形成される。 これらの 24ビットは、4つの連結された 6ビットグループ (各々がbase64 アルファベットにおける 1桁の数字に変換される) のように、その時扱われ る。base64 符号化を経たビットストリームを符号化する時には、ビットの ストリームは、最初、最も多く重要なビットによって命じられると推定され なければなりません。すなわち、流れの最初のビットは、高いオーダービッ トの最初の8ビットバイトであり、8番目のビットは、低いオーダービットの 最初の8ビットバイトなどである。 各 6ビットグループは、一連の 64個の印刷可能な文字へのインデックス として使われる。インデックスによって参照を付けられた文字は、出力文字 列に配置される。下記表1に示したこれらの文字は、一般的に再提供可能な ように選択されて、セットは、特有の意味によって、RFC 2046において定義 されたSMTP(例えば、"."、CR、LF)およびマルチパートの境界デリミタの 文字を遮断する(例えば "-")。 表1: Base64 アルファベット 値 符号化 値 符号化 値 符号化 値 符号化 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (穴埋め) = 15 P 32 g 49 x 16 Q 33 h 50 y 符号化された出力ストリームは、わずか 76文字しかない行で表されなけ ればならない。すべての改行、または表1に発見されなかった他の文字は、 ソフトウェアで解読する際に無視されなければならない。base64 において、 データ、表1以外のキャラクタ、改行、及び、他の空白文字は、おそらく伝 送エラー(警告メッセージ、またはメッセージ拒絶さえも、いくらかの情況 下に於いては適切だろう)を示す。 もし最大 24ビットで符号化されたデータの終りに利用可能であるなら、 特別な処理が行われる。完全なエンコーディング量は、ボディの終りで常に 完成される。最大 24 入力ビットが入力グループにおいて利用可能であると き、ゼロのビットは、必須の数の 6 ビットグループを形成するために加え られる(右に)。データの終りのパディング(穴埋め)は、"=" 文字を用いて行 われる。全ての base64 入力が必須の数のオクテットであるので、次の場合 のみが起こるかもしれない: (1)入力を符号化することの最終の量は、24ビ ットの必須の倍数である; ここで、符号化された出力の最終のユニットは、 "=" パディングなしの 4文字の必須の倍数であろう。(2)入力を符号化する ことの最終の量は、ちょうど 8ビットである; ここで、符号化された出力の 最終ユニットは、2個の "=" パディング文字が続いている 2文字であろう。 もしくは (3)入力を符号化することの最終の量は、ちょうど 16ビットであ る; ここで、符号化された出力の最終のユニットは、1個の "=" パディング 文字が続いている 3文字であろう。 それがデータの終りの穴埋めにのみ使われるので、あらゆる "=" キャラ クタの発生は、データの終りに到達した (通過における切頭なしで) という 証拠として考えられるだろう。しかし、違う。送られたオクテット数が 3の 倍数であり、どの "=" 文字も無い時には、そのような保証が可能である。 base64 アルファベット以外のあらゆる文字は、base64 符号化されたデー タにおいては無視されねばならない。 base64 符号化が直接正規のフォームに変換されなかったテクスト材料に 適用されるならば、改行に適したオクテットを使うために注意が行われなけ ればならない。特に、テクスト改行は、base64 符号化の前に CRLF シーケ ンスに変換されていなければならない。重要な注意点として、これがいくら かの実装(インプリメント)における前の正規化ステップにおいてより、むし ろ直接符号化処理(エンコーダ)によって行われるかもしれないことである。 注意事項: base64 符号化の時にハイフン文字は全く使われないので、マルチパート なエンティティ内の base64符号化ボディ中の潜在的な境界デリミタについ て悩む必要はない。 7. Content-ID ヘッダフィールド 高レベルユーザエージェントを構成する時に、1つのボディに別のものへ の参照を許すことは望ましいかもしれない。従ってボディは "Message-ID" ヘッダフィールドと構文的にに同一の "Content-ID" ヘッダフィールドを用 いラベル付けされるかもしれない: id := "Content-ID" ":" msg-id Message-ID 値のように、Content-ID 値は世界的に一意であるように生成 されなければならない。 Content-ID 値は、特に、message/external-body メカニズムにより参照 を付けられるデータを隠すためのいくつかの文脈において、MIME エンティ ティを独特に識別するために使われるかもしれない。Content-ID ヘッダは 一般に任意であるが、その使用は、"message/external-body" という任意の MIMEメディアタイプのデータを生成する実装においては【義務】である。す なわち、個々の message/external-body エンティティは、そのようなデー タを隠すことを可能にするために、Content-ID フィールドを持っていなけ ればならない。 Content-ID 値が multipart/alternative メディアタイプについて特別な 語義を持っていることに注意することは、同じく注目する価値がある。これ は、multipart/alternative を扱う RFC 2046 のセクションで説明される。 8. Content-Description ヘッダフィールド あるボディにいくらかの記述的情報を結び付ける能力は、しばしば望まし い。例えば「スペースシャトル エンデバーの絵」として "image" ボディを 示すことは有益かもしれない。そのようなテクストは Content-Description フィールドに配置されるかもしれない。このヘッダフィールドは常に任意で ある。 description := "Content-Description" ":" *text 記述は RFC 2047 において指定されたメカニズムが 非US-ASCII Content- Description のために使われるかもしれないが、US-ASCIIキャラクタセット において与えられると推定される。 9. 付加的な MIME ヘッダフィールド 未来の文書は、様々な目的のために付加的な MIMEヘッダフィールドを定 義することを決定するかもしれない。更にメッセージの内容を示すあらゆる 新しいヘッダフィールドは、普通の RFC 822 メッセージヘッダフィールド と区別されるためにメッセージヘッダに現れるそのようなフィールドを許す ために、文字列 "Content-" で始まるべきである。 MIME-extension-field := <"Content-" という文字列で始まる あらゆる RFC 822 ヘッダフィール ド> 10. 要約 MIME-Version、Content-Type、及び、Content-Transfer-Encoding ヘッダ フィールドを用いて、標準化された方法で随意のタイプのデータを RFC 822 構造メールメッセージに含めることが可能である。RFC 821 か RFC 822 の いずれかによって課された制限を破ることなく、そしていくらかのインター ネットメール転送メカニズム(RFC 2049 を見よ) の特性によって課された追 加の制限によって引き起こされた問題を回避するために注意をはらった。こ のセット、RFC 2046 における次のドキュメントは、これらのヘッダを用い ての分類と、転送できるメディアタイプの初期のセットを指定する。 11. セキュリティ対策 セキュリティ問題はこのセット、RFC 2046 の2番目の文書において論じら れる。 12. 奥付 更に情報が必要な場合、インターネットメールがこのドキュメントの著者 との最良の連絡方法である: 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 によ り定義されるいくつかの構文規則を名前で参照する。それどころか、ここで (2つの間の危険の故意でない差異) それらの定義を再現するより、このド キュメントは、残っている定義のために RFC 822 を読者に簡単に参照させ る。どこに用語が定義されていないなら、それは RFC 822 で定義されてい るだろう。 attribute := token ; 属性とマッチングするのは ; 【常に】無関係である。 composite-type := "message" / "multipart" / extension-token content := "Content-Type" ":" type "/" subtype *(";" parameter) ; メディアタイプおよびサブタイプと ; マッチするのは【常に】無関係である。 description := "Content-Description" ":" *text discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token encoding := "Content-Transfer-Encoding" ":" mechanism entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF ) extension-token := ietf-token / x-token hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; 127 を超える文字、行末の =、空白、または TAB、 ; そして RFC 2049 において「mail-safe」として、 ; リストされなかったあらゆるキャラクタが推薦さ ; れる。 iana-token := <公に定義された拡張トークン。このフォームの証 拠は RFC 2048 において指定されるように IANA によって登録されなければならない。> ietf-token := <標準トラックRFCとIANAに登録された 拡張トークンにより定義される> id := "Content-ID" ":" msg-id mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token MIME-extension-field := <"Content-" という文字列で始まる あらゆる RFC 822 ヘッダフィール ド> MIME-message-headers := entity-headers fields version CRLF ; このBNF定義により暗示されて ; いるヘッダフィールドの命令は ; 無視されるべきである。 MIME-part-headers := entity-headers [fields] ; "content-" で始まらないあらゆる ; フィールドは、定義された意味を ; 持つことができず、そして、無視 ; されるかもしれない。 ; このBNF定義により暗示されている ; ヘッダフィールドの命令は無視され ; るべきである。 parameter := attribute "=" value ptext := hex-octet / safe-char qp-line := *(qp-segment transport-padding CRLF) qp-part transport-padding qp-part := qp-section ; 最大長は 76文字 qp-section := [*(ptext / SPACE / TAB) ptext] qp-segment := qp-section *(SPACE / TAB) "=" ; 最大長は 76文字 quoted-printable := qp-line *(CRLF qp-line) safe-char := <10 進値で 33~60、および 62~126 までのあらゆる オクテット> ; RFC 2049 において「mail-safe」として、リスト ; されなかったキャラクタは、同じく推薦されない。 subtype := extension-token / iana-token token := 1*<空白、コントロール文字、及び tspecials を除いた全ての US-ASCII 文字> transport-padding := *LWSP-char ; 送信側は non-zero 長のトランスポート ; パディングを生成【してはならない】。 ; しかし、受信側はメッセージ転送によっ ; て加えられたパディングを扱うことが ; 【できなければならない】。 tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; パラメーター値の中で使うために、 ; 引用された文字列でなければならない type := discrete-type / composite-type value := token / quoted-string version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT x-token := <どのような証拠のためでも、空白を介在せずに "X-" または "x-" が続いていた2文字>