UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 開始 2000年02月08日 / translation 08 February 2001 翻訳 2000年02月19日 / translation 19 February 2001 修正 2003年12月16日 / correction 16 December 2003 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2049 を訳者(marimo@wdic.org)が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 Network Working Group N. Freed Request for Comments: 2049 Innosoft Obsoletes: 1521, 1522, 1590 N. Borenstein Category: Standards Track First Virtual November 1996 Multipurpose Internet Mail Extensions [多目的インターネットメール拡張] (MIME) パート5: 適応基準と例 このメモの位置づけ この文書は、インターネットコミュニティのための 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メディアタイ プシステムの一般構造を定義し、メディアタイプの初期のセットを定義する。 RFC 2048は、MIME関連の設備のための様々なIANA登録手続を指定する。MIME メッセージフォーマット、確認、および参考文献一覧のいくつかの説明に役 立っている実例を提供しているだけでなく、この5番目および最終的な文書 が、MIME対応標準を説明する。 これらの文書は、それ自身がRFC 1341と1342の改訂だったRFC 1521、1522、 および1590の改訂である。この文書の付録Bは前のバージョンから違いと変 化を説明する。 目次 1. はじめに 2. MIME対応 3. 電子メールデータを送るためのガイドライン 4. 正規の符号化モデル 5. 要約 6. セキュリティ考慮 7. 奥付 8. 謝辞 A. 複雑なマルチパートの例 B. RFC 1521、1522、および1590からの変更点 C. 参考文献 1. はじめに このセットの最初と2番目の文書は、MIMEヘッダフィールドおよびMIMEメ ディアタイプの初期セットを定義する。3番目の文書はUS-ASCII以外のキャ ラクタセットを考慮するために、RFC 822フォーマットへの拡張について述 べる。この文書は、MIMEのどんな部分が対応MIMEインプリメンテーションに よってサポートされるべきかを記述する。同じく、MIMEが基づく正規のエン コーディングモデルど同様に、現代の通信システムの様々な落とし穴も説明 する。 2. MIME対応 これらの文書において述べられたメカニズムは無制限である。すべての実 装がすべての利用可能なメディアタイプをサポートすることと、それらすべ てが同じ拡張を共有するだろうということが、明確に予期されない。しかし、 相互運用性を促進するために、US-ASCIIテクストと異なる内容のメッセージ を有益に相互作動させることを許す実装の一定のレベルを定義するために、 「MIME対応」の概念を定義することは有益である。このセクションでは、我 々はそのような対応のための必要条件を指定する。 MIME対応であるメールユーザーエージェントの【必須事項】: (1) 作成するあらゆるメッセージに "MIME-Version: 1.0" ヘッダフィー ルドを含めること。 (2) Content-Transfer-Encodingヘッダフィールドを参照し、そして、 quoted-printable または base64 実装によって符号化された受け 取られたデータ全てを解読しなさい。7ビット、8ビット、およびバ イナリへの変換は、同等に認識されなければならない。 符号化なしで送られるどのような非7ビットデータでも、8ビットの content-transfer-encodingまたはバイナリによって適切に分類さ れなければならない。もし基本的な輸送により8ビット、またはバ イナリ(SMTP [RFC-821] が行なわない)がサポートされないなら、 送信側は、符号、およびquoted-printableやbase64などの適切な Content-Transfer-Encodingを使う分類データが要求される。 (3) 実際のContent-Typeが認められているかどうかを問わず、それが "application/octet-stream" の内容タイプを持っているかのよう に、どのような未認識のContent-Transfer-Encodingでも扱わなけ ればならない。 (4) Content-Typeヘッダフィールドを識別して、解釈し、テクスト以外 のContent-Typeフィールドによってユーザに未加工のデータを示す ことを回避すること。実装は、もしそれがUS-ASCIIではないならば charsetパラメータによって指定されたキャラクタセットによって 少なくともtext/plainなメッセージを送ることが出来なければなら ない。 (5) 名前を認識できないあらゆるcontentタイプパラメータは無視しな さい。 (6) 少なくとも下記程度の内容は、明示的に次のメディアタイプ値を処 理すること: Text: -- キャラクタセット "US-ASCII" と共に "text" メールを認識 し、表示しなさい。 -- 少なくとも、メッセージがどんなキャラクタセットを使うか、 ユーザーに知らせられる程度まで他のキャラクタセットを認 識すること。 -- ISO-8859-* 及び US-ASCII に共通のキャラクタを表示できる 程度の範囲の "ISO-8859-*" キャラクタセット、すなわちオ クテット値 1-127 で表された全キャラクタを認識すること。 -- 既知のキャラクタセットにおける認識されないサブタイプの ために、表示もしくは内容のローカルなフォームへの正規の フォームからの転換の後に、データの「生の」バージョンを ユーザーに示すことを申し出なさい。 -- まるでそれが "application/octet-stream" であるかのよう に、未知のキャラクタセットの素材を扱うこと。 Image, audio, および video: -- 少なくとも、それらが "application/octet-stream" である かのように、あらゆる認識できないサブタイプを扱うための 機能を提供しなさい。 Application: -- それらが使われた場合、このドキュメントにおいて定義され たquoted-printableもしくはbase64符号化のどちらでも除去 する能力を提供し、かつ、ユーザーファイルにその結果生じ る情報を書きなさい。 Multipart: -- 混合サブタイプを認識すること。個々に各々のボディ部分を 表示するために、メッセージレベル、及びボディパートヘッ ダレベル、そしてディスプレイに関する適切な情報全てを表 示または提供しなさい。 -- "alternative" (代用)サブタイプを認識し、そして、 multipart/alternativeメールの冗長な部分をユーザーに示す ことを回避しなさい。 -- 明確に "text/plain" よりむしろ "message/rfc822" を、 "multipart/digest" 実体の中のボディパーツのためのデフォ ルトメディアタイプとして使って、"multipart/digest" は、 サブタイプであると認識しなさい。 -- あらゆる認識できないサブタイプは、それらが "mixed" であ るかのように扱うこと。 Message: -- どのような再帰的な構造でも保存するため、すなわちそのメ ディアタイプに従ってカプセル化されたRFC 822メッセージ (message/rfc822)を、カプセル化されたデータを表示すると表示 するか認識する方法を少なくとも用意すること。 -- まるでそれが "application/octet-stream" であるかのよう に、未知のサブタイプを扱うこと。 (7) あらゆる認識されないContent-Typeフィールドに遭遇すると、それ がパラメータsub-argumentsなしで "application/octet-stream" のメディアタイプを持っていたかのように、実装はそれを扱わなけ ればならない。どのようにそのようなデータが扱われるかは、実装 次第である。しかし、そのような認識できないデータを処理するた めに適切なオプションは、ファイル(そのメール輸送フォーマット から解読される)または解読されたデータが入力として手渡される べきプログラムを名付けるために、ユーザーを提供することに、そ れを書くためにユーザーを提供することを含む。 (8) 受け取られたメッセージのみに基づいてそうするために、それらが US-ASCII以外のキャラクタセットを使う非MIMEメッセージに非標準 的サポートを提供するならば、対応ユーザーエージェントが必要と される。対応しているユーザーエージェントは、US-ASCIIテクスト 以外の何でもを含む非MIMEメッセージを送ってはいけない。 特に、異なるローカライズ規定と共に領域の間のメッセージを送っ ているとき、それが相互運用性を妨げるので、MIME-Versionフィー ルドなしのメールメッセージにおける非US-ASCIIテクストの使用は、 強く妨害される。対応ユーザーエージェントは、プレーンテクスト 以外の何らかのUS-ASCIIキャラクタセットに送っているとき、分類 する適切なMIMEを【含まなければならない】。 更に、非MIMEユーザーエージェントは、それらが送るメッセージに 適切なMIMEヘッダ情報を入れるために、たとえ、他のMIMEにおける 何らもサポートされないとしても、できる限りアップグレードされ るべきである。このアップグレードは、非MIME受取人への影響をほ とんど持っておらず、そして、MIMEがそのようなメッセージを正し く表示することを援助するだろう。それは、他のMIME機能の最終の 採用にスムーズな移行手順も提供する。 (9) 対応ユーザーエージェントは "=" で始まり "?=" で終わる "*text" または "*ctext" の中のスペース以外の印刷可能US-ASCIIキャラク タのあらゆるストリングが正当に符号化された文字列であることを 保証しなければならない("begins"の意味: フィールドボディまた は直後のlinear-white-spaceの最初; "ends"の意味: フィールドボ ディまたは直前のlinear-white-spaceの最後). 更に、"=" で始ま り、そして "?=" で終わる "phrase" (句)の中のあらゆる "word" は、正当な符号化されたワードでなければならない。 (10) 対応ユーザーエージェントは、セクション4の規則によると、メッ セージヘッダの適切な場所に出る符号化されたワードを、"text"、 "ctext"、もしくは "word" らと区別することが出来ねばならない。 それは、それがサポートするあらゆるキャラクタセットのために、 "B" と "Q" 符号化の両方をサポートしなければならない。そのプ ログラムは、キャラクタセットが "US-ASCII" であるならば、符号 化されていないテクストを表示することが出来ねばならない。 ISO-8859-*のために、キャラクタセット、メール受信プログラムは、 少なくとも同じくUS-ASCIIセットにあるキャラクタを表示すること ができなければならない。 前述のコンディションを満たすユーザーエージェントは、MIME対応である と言われる。この句の意味は、それが実質的にいかなる種類の適切マークさ れたデータでもそのようなメールシステムのユーザーに送ることが『安全で ある』と仮定されることである。なぜなら、そのようなシステムが少なくと もデータを区別されないバイナリのように扱うことができ、そして信用する ユーザーの画面上にそれを単に跳ねかけないからである。 MIME対応であるフォーマットに、データを送るためにそれが常に「安全」 である他の認識がある。それは、そのようなデータが既知のRFC 821及びRFC 822準拠システムによって、一切壊されてはならない。MIME準拠のユーザー エージェントは、ユーザーが決してテクストとして見る事を前提としていな かったデータを示さないという、付加的な保証を持っている。 3. 電子メールデータを送るためのガイドライン インターネット電子メールは、完璧でも均質でもない。メールは、最終的 な宛て先に向かう過程における幾つかのステージで腐敗させられた状態にな るかもしれない。明確に、インターネットの至る所に送られた電子メールは、 多くのネットワーキング技術を経由して移動するかもしれない。多くのネッ トワーク化とメール技術は、SMTP転送環境で可能な全ての機能はサポートし ていない。これらのシステム経由するメールは、それが転送され得るよう、 修正されそうである。 非準拠MTAは、インターネットに多数広範囲に存在する。SMTPプロトコル を話すこれらのMTAたちは、それらが実行されるホストの内部のデータ構造 を利用するようにという飛んでいるメッセージを変更する、または、単に壊 れたプレーンである。 以下のガイドラインは、ネットワーク化技術、および既知の容赦なく破壊 されたMTAの中で最も広範囲に耐えると思われているデータフォーマット(メ ディアタイプ)を考案している誰にでも有益であるかもしれない。base64エ ンコーディングにおいて符号化された何でも、これらの規則を満たすことと いくつかの有名なメカニズム(特にUNIX uuencode)がしないことに注意せよ。 Quoted-Printable符号において符号化されれば、殆ど全てのゲートウェイを、 ことによるとEBCDICキャラクタセットを使うシステムのゲートウェイですら、 そっくりそのまま生き抜けることは注目に値する。 (1) いくらかの状況下で、データに使われる符号化は正常なゲートウェ イ、またはユーザーエージェントオペレーションの一部として変更 される。特に、base64からquoted-printableの変換は、可逆である ことが必要とされる。これは、CRLFシーケンスとテクストボディに おける改行との混同の結果として生じるかもしれない。従って、改 行以外のあらゆるCRLFの持続性には頼ってはならない。 (2) 多くのシステムは、ローカルなnewline規定を使うテクストデータ を表して、格納することを決定するだろう。ローカルなnewline規 定は、システムが、単なるCR、単なるLF、CRLF、もしくはカウント されたレコードを使うことで知られている、RFC822 CRLF規定には 適合しないかもしれない。その結果は、分離したCRとLFキャラクタ は、一般的に許容されていないことだ; それらは、いくらかのシス テム上のデリミタに失われるか、もしくは変換されるかもしれず、 従って信頼してはならない。 (3) NUL(US-ASCII値0)の伝送は、インターネットメールにおいては問題 がある(これは、多数の、Cプログラミング言語における多くの標準 のランタイムライブラリルーチンによる終了キャラクタとして使わ れるNULの結果である)。メッセージはそれらが保存されることを期 待すべきでないが、そのようにNULを終了キャラクタとする実装は 現在使われている。 (4) TAB(HT)キャラクタは誤解されるか、もしくは可変の多くのスペー スに自動的に変換できる。これは、特にUS-ASCIIキャラクタセット に基づかない、いくつかの環境で不可避である。そのような変換は、 【強く思いとどまるべき】であるが、それは発生するかもしれず、 そして、メールフォーマットは、TAB(HT)キャラクタの持続性に頼っ てはいけない。 (5) 76文字より長い行は、幾らかの環境において、折り返されるか、も しくは切り捨てられるかもしれない。メールトランスポートによっ て強制的に折り返されたり、または行を切り捨てたりすることは、 【強く思いとどまるべき】である。しかし、いくらかの場合に避け ることができない。長い行ンを必要とするアプリケーションは、何 らかの方法で、ソフトおよびハードの改行を区別しなければならな い(これを実現するシンプルな方法は、quoted-printable符号化を 使うことである)。 (6) 行末につく「空白」キャラクタ(SPACE, TAB (HT))は、幾つかのト ランスポートエージェントによって削除されるかもしれない。また 他のトランスポートエージェントによっては、メールファイルにお ける全ての行の長さが等しくなるように、行をこれらのキャラクタ で埋めるかもしれない。従って、行末の空白の持続性に頼ってはい けない。 (7) 多くのメールドメインはUS-ASCIIキャラクタセットばかりでなく、 US-ASCIIキャラクタセットのバリエーションや、EBCDICのような キャラクタセットを使う。キャラクタ変換ゲートウェイを経由して のキャラクタの正しい翻訳は、「不変」セットにない。例えば、 BITNET、EBCDICシステムを経由してuuencodeされた情報を送る場合 には、この状況は問題である。多くのインターネットホストが内部 でUS-ASCII以外のキャラクタセットを使うので、同様の問題はゲー トウェイを経由することなく発生し得る。X.400における印刷可能 文字列の定義は、ある特別な場合に更なる制限を加える。特に、全 てのゲートウェイを経由して首尾一貫していることが知られている 唯一のキャラクタは、大文字と小文字のA-Z、a-z、10個の数字0-9、 及び、次の11個の特別なキャラクタと一致する73文字である: "'" (US-ASCII 10進値 39) "(" (US-ASCII 10進値 40) ")" (US-ASCII 10進値 41) "+" (US-ASCII 10進値 43) "," (US-ASCII 10進値 44) "-" (US-ASCII 10進値 45) "." (US-ASCII 10進値 46) "/" (US-ASCII 10進値 47) ":" (US-ASCII 10進値 58) "=" (US-ASCII 10進値 61) "?" (US-ASCII 10進値 63) 最大限にポータブルなメール表現は、自身を唯一の重要キャラクタ73文字 のセット内で、かつ、テクストの行を比較的短くに制限することだろう。 base64符号化によりこの規則に従うことができる。 (8) いくらかのメールトランスポートエージェントは、あるリテラル文 字列を含むデータを腐敗させるであろう。特に、ピリオド(".")が いくらかの(誤った)SMTP実装によって腐敗させられることが知られ ており、そして、5文字 "From " (5文字めのキャラクタは空白)に より始まる行も、一般に腐敗する。注意深い合成エージェントは、 データを符号化(例えば、quoted-printable符号化を使って、行頭 の "From " の代わりに "=46rom " を、"." の代わりに "=2E" を 利用)することによって、これらの腐敗を防止し得る。 前述の一覧は、MTAのための推薦された実践の一覧【ではない】ことに注 意してください。RFC 821 MTAは、空白のキャラクタを変更する、もしくは、 長い行を折り返すことを禁止する。これらの【悪しき】不正な実装が確立し たネットワークに関して発生するということが知られており、そして、実装 は、それらが引き起こすかもしれない悪い効果に対し、頑強であるべきであ る。 4. 正規の符号化モデル これらのドキュメントの初期バージョンにおいて、いくらかの混乱があっ た。いつ電子メールデータが正規のフォームに変換されるかのモデルに関し て、符号化、そして、いかにこのプロセスが、newlinesの表現がシステムか らシステムで大きく変化するCRLFの処置に影響を及ぼすか。この理由のため に、符号化のための正規のモデルは、下で提示される。 MIMEエンティティを構成するプロセスは、いくつかの手順において行なわ れるとしてモデル化され得る。これらの手順がPEM [RFC-1421]に使われる手 順と非常に類似しており、そして、各 "innermost level" ボディのために 遂行されることに注意しなさい: (1) ローカルなフォームの作成。 転送用のボディは、システムのネイティヴ(本来)のフォーマットで 作成される。ネイティヴのキャラクタセットは、適切な箇所でも使 われ、ローカルの行末の規定でも使われる。そのボディは、 UNIX スタイルのテクストファイル、またはサンのラスタイメージ、また はVMS索引編成ファイル、またはメモリへの格納を前提としたシス テム依存のオーディオフォーマット、または、他の、幾らかの形の 情報表現のローカルなモデルと一致する何かであるかもしれない。 基本的に、データは、メディアタイプによって指定されたタイプと 一致する "ネイティヴ" フォームにおいて作成される。 (2) 正規のフォームへの変換。 レコード長や、ひょっとするとファイル属性の情報のような、 "out-of-band" 情報を含む全体のボディは、ユニバーサルな正規の フォームに変換される。その関連する属性の特定のメディアタイプ と同様に、ボディは使われる正規のフォームの性質を表わしている。 適切な正規のフォームへの変換は、キャラクタセットの変換、オー ディオデータ、圧縮、または様々なメディアタイプに特有の様々な 他のオペレーションの変化を包含するかもしれない。 しかし、もしキャラクタセット変換が包含されるならば、あらゆる キャラクタセットの変換に対する(例えば、"plain" 以外のサブタ イプのtextにおける語義的に有意義なキャラクタに関して)強い影 響を持つかもしれないメディアタイプの語義を理解するように注意 を払われなければならない、 例えば、text/plainデータの場合は、そのテクストはサポートされ たキャラクタセットに変換されなければならず、そして、行は、 RFC 822に従ったCRLFデリミッタによって区切られねばならない。 もし次のステップがquoted-printableまたはbase64符号化を使うな らば、RFC 822によって暗示された行長制限が取り除かれることに 注意すべきである。 (3) 転送エンコーディングの適用。 このボディに適切なContent-Transfer-Encodingは、適用される。 メディアタイプ、及び、転送エンコーディングの間の固定した関係 がないことは注意せねばならない。特に、このボディに特有である キャラクタ頻度カウントにbase64またはquoted-printableの選択の 基礎を置くことは、適切かもしれない。 (4) エンティティへの挿入物。 符号化されたボディは、適切なヘッダと共にMIMEエンティティに挿 入される。そのエンティティは必要とされる更に高水準のエンティ ティ(メッセージまたはマルチパート)のボディに挿入される。 エンティティフォームからローカルなフォームまでの変換は、これらのス テップを逆転することによって完遂される。これらのステップの反転が、異 なる結果をもたらすかもしれないことに注意すること。オリジナルと、最終 のローカルなフォームが同じであるという保証はない。 これらのステップがモデルのみであることに注意することは、極めて重要 である; それらは明確にいかに現実のシステムが作られるであろうかのため の青写真【ではない】。特に、そのモデルは二つの共通のデザインを説明す ることができない : (1) 多くの場合、符号化の前の正規なフォームへの変換は、ローカルな フォーマットを直接理解するエンコーダ自身に包括されるだろう。 例えば、テクストボディのためのローカルなnewline規定は、その フォーマットがそうであるものの知識と共にエンコーダ自身に達成 されるだろう。 (2) エンコーダの出力は、メッセージとして送られる前に、1つ以上の 追加の手順を通過する必要があるかもしれない。従って、エンコー ダの出力は、RFC 822によって指定されたフォーマットと同等では ないかもしれない。特に、もう一度、標準のRFC 822 CRLFデリミタ を利用するより、むしろローカルなnewline規定を用いて表わされ ることは、コンバータの出力に適しているかもしれない。 他の実装バリエーションもまた同様に考えられる。この議論の極めて重要 な局面は、いかなる最適化にも関らず、付加的な処理、その結果生じるメッ セージの挿入は、必要とされた手順の崩壊にもかかわらず、それらがここで 示されたモデルによって作る状態で首尾一貫していなければならない。 例えば、下記ヘッダフィールドのメッセージ: Content-type: text/foo; charset=bar Content-Transfer-Encoding: base64 まず最初に(必要なら) "bar" キャラクタセットを表現し、そして最終的 メールセーフなフォームにbase64アルゴリズムによって変換されたtext/foo フォームを表現せねばならない。 注意: いくらかの混乱は、 RFC 822 CRLF規定と異なるローカルなnewline 規定を使うフォーマットでメッセージを表わすシステムによって引き起こさ れた。これらのフォーマットが正規のRFC822/MIMEではないことに注意する ことは重要である。これらのフォーマットは、メッセージの正規な表現にお けるCRLFシーケンスが、ローカルなnewline規定として符号化される代わり に、RFC822の *符号化* である。 CRLFを符号化するフォーマット同様、たとえば、LFは、CRLF行分離シーケ ンスの一部ではないLFオクテットを含んだバイナリデータをMIMEメッセージ で表わすことが不可能であることは注意が必要である。 5. 要約 このドキュメントはMIME準拠で意味されるものを定義する。インターネッ ト電子メールシステムに存在するとことが知られている様々な問題の克服、 及び、MIMEを使う方法を同じく詳述する。最後に、それはMIMEの正規の符号 化模範を示す。 6. セキュリティ考慮 セキュリティ問題はこのセットの2番目の文書、RFC 2046において論じら れる。 7. 奥付 更に情報が必要な場合、インターネットメールがこのドキュメントの著者 との最良の連絡方法である: 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は、インターネット特別技術調査委員会(IETF)会作業部会のRFC822拡 張のためのワーキンググループの成果である。そのグループの会長、Greg Vaudreuilには、以下において達することができるだろう : Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA EMail: Greg.Vaudreuil@Octel.Com 8. 謝辞 この文書は、IETF-SMTP、及びIETF-822メーリングリスト上、ならびに他 の場所でのいくらかのIETF集会での、多くの人々の総力の成果である。どの ような列挙でも、とんでもない省略に苦しむ運命にあるが、以下は多くの貢 献者の努力の間にある: Harald Tveit Alvestrand Marc Andreessen Randall Atkinson Bob Braden Philippe Brandon Brian Capouch Kevin Carosso Uhhyung Choi Peter Clitherow Dave Collier-Brown Cristian Constantinof John Coonrod Mark Crispin Dave Crocker Stephen Crocker Terry Crowley Walt Daniels Jim Davis Frank Dawson Axel Deininger Hitoshi Doi Kevin Donnelly Steve Dorner Keith Edwards Chris Eich Dana S. Emery Johnny Eriksson Craig Everhart Patrik Faltstrom Erik E. Fair Roger Fajman Alain Fontaine Martin Forssen James M. Galvin Stephen Gildea Philip Gladstone Thomas Gordon Keld Simonsen Terry Gray Phill Gross James Hamilton David Herron Mark Horton Bruce Howard Bill Janssen Olle Jarnefors Risto Kankkunen Phil Karn Alan Katz Tim Kehres Neil Katin Steve Kille Kyuho Kim Anders Klemets John Klensin Valdis Kletniek Jim Knowles Stev Knowles Bob Kummerfeld Pekka Kytolaakso Stellan Lagerstrom Vincent Lau Timo Lehtinen Donald Lindsay Warner Losh Carlyn Lowery Laurence Lundblade Charles Lynn John R. MacMillan Larry Masinter Rick McGowan Michael J. McInerny Leo Mclaughlin Goli Montaser-Kohsari Tom Moore John Gardiner Myers Erik Naggum Mark Needleman Chris Newman John Noerenberg Mats Ohrman Julian Onions Michael Patton David J. Pepper Erik van der Poel Blake C. Ramsdell Christer Romson Luc Rooijakkers Marshall T. Rose Jonathan Rosenberg Guido van Rossum Jan Rynning Harri Salminen Michael Sanderson Yutaka Sato Markku Savela Richard Alan Schafer Masahiro Sekiguchi Mark Sherman Bob Smart Peter Speck Henry Spencer Einar Stefferud Michael Stein Klaus Steinberger Peter Svanberg James Thompson Steve Uhler Stuart Vance Peter Vanderbilt Greg Vaudreuil Ed Vielmetti Larry W. Virden Ryan Waldron Rhys Weatherly Jay Weber Dave Wecker Wally Wedel Sven-Ove Westberg Brian Wideen John Wobus Glenn Wright Rayan Zachariassen David Zimmerman このリストから漏れた全著者に謝罪する。それは決して故意ではない。 付録 A -- 複雑なマルチパートの例 以降は複合的なマルチパートメッセージのアウトラインである。このメッ セージは、連続して表示されるべきである5つのパートを含む: 最初の2つが プレーンテクストオブジェクト、埋めこまれたマルチパートメッセージ、 text/enrichedオブジェクト、そしてカプセルに密閉された非ASCIIキャラク タセットのテクストメッセージである。埋め込まれたマルチパートメッセー ジそのものは、画像とオーディオの断片が並列に表示再生されるべき2つの オブジェクトを含んでいる。 【訳注】以下のサンプル内の解説等も全て訳しているが、例ではcharsetが US-ASCIIとなっているものもある。実際に実装する場合は、適時 charsetを設定する必要が有る(日本語ならiso-2022-jpなど)。 MIME-Version: 1.0 From: Nathaniel Borenstein To: Ned Freed Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 これはマルチパートメッセージの前文領域である。マルチパートフォー マットを理解するメールリーダーは、この前文を無視するべきである。 あなたがこのテクストを読んでいるなら、あなたは、マルチパートメッ セージを適切に表示できるメールリーダーへの変更を検討したいだろう。 --unique-boundary-1 ... あるテクストはここで出現する ... [このパートにおけるテクストの境界とスタートの間のブランクが,ヘッ ダフィールドが与えられなかったことを意味し、これがUS-ASCIIキャラ クタセットのテクストであることに注意せよ。それは、次のパートと同 様に、明白なタイプによって行なわれたかもしれない] --unique-boundary-1 Content-type: text/plain; charset=US-ASCII これは前のパートの一部だったかもしれないが、ボディパートの明示に 対する暗黙のタイプを説明する。 --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64 ... base64符号化された8000Hz 1チャンネル μ-law フォーマットオーディオデータがここにある ... --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64 ... base64符号化された画像データがここにある ... --unique-boundary-2-- --unique-boundary-1 Content-type: text/enriched これは装飾文である。 RFC 1896において定義される それは カッコイイかい? --unique-boundary-1 Content-Type: message/rfc822 From: (US-ASCIIのメールボックス) To: (US-ASCIIのアドレス) Subject: (US-ASCIIのサブジェクト) Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable ... ISO-8859-1の付加的なテクストがここにある ... --unique-boundary-1-- 付録 B -- RFC 1521、1522、および1590からの変更点 これらの文書は、RFC 1521、1522、ならびに1590の改訂である。初期の文 書を熟知している人の利便のために、それらのドキュメントからの変更点が この付録に要約されている。 更なる歴史のために、RFC 1521の付録Hが、いかにその文書がその前任で あるRFC 1341と異なるを指定したことに注意しなさい。 (1) このドキュメントは、多重ドキュメントに、完全に再フォーマット されて、分割された。これは、参照コピーとして必要とされるこの 文書のプレーンテクストバージョンの品質を高めるために、行なわ れた。 (2) MIMEオブジェクトヘッダの全体構造を示すBNFが加えられた。これ は文書の変更のみである -- 根本的な構文は、全く変更されていな い。 (3) MIMEの7つのメディアタイプで使われる特定のBNFが除去された。こ のBNFは誤っており、不完全だった。そして、タイプ非依存のBNFと 一致していなかった。加えて、タイプ非依存のBNFが様々なMIMEヘッ ダの構文を既に十分に指定するので、タイプ特定のBNFは、結局全く 必要がなく、しかも解決よりも多くの問題を引き起こしてしまった。 (4) 更に明確な "US-ASCII" キャラクタセット名は、これらの文書の多 くの部分において非公式の用語 ASCII の使用に取って代わった。 (5) 主要なサブタイプの非公式の概念は削除された。 (6) 用語「オブジェクト」の使われ方が矛盾していた。関連用語の「ボ ディ」「ボディパート」、及び「エンティティ」と共に、この用語 の定義は明瞭にされ、そして適切な用法に訂正した。 (7) マルチパートメディアタイプのためのBNFは、境界マーカに先行す るCRLFが実際に前のボディパートよりむしろマーカそのものの一部 であることを明らかにするために、再整理された。 (8) マルチパートメディアタイプを示す散文とBNFは、マルチパートオ ブジェクト中のボディパートが境界パラメータ列で始まる行を【一 切含んではいけない】ことを明らかにするために、変えられた。 (9) "message/partial" MIMEエンティティを再集合する際の規則におい て、"Subject" は内側のメッセージから取るようにヘッダのリスト に加えられ、その例は、このポイントを明確化するために、修正さ れた。 (10) "Message/partial" 断片は、行の境界でのみ、MIMEオブジェクトに 分割することが制限される。 (11) application/postscriptの議論において、付加的なパラグラフは、 PostScript MIMEエンティティ中のバイナリデータの埋込みによって 引き起こされた可能な相互運用性問題に関する警告を加えた。 (12) Content-Typeヘッダフィールドが以下の2つのフォームを生じるこ とを基本的なシンタックス規則に追加した : Content-type: text/plain; charset=us-ascii (comment) Content-type: text/plain; charset="us-ascii" 完全に同等である。 (13) 次の文は、MIME-Versionヘッダの議論から削除された: 「しかし、 準拠ソフトウェアは、バージョン数を照合し、そして、認識されな いMIME-Versionに遭遇するならば、ユーザーに対して少なくとも警 告することが奨励される。」 (14) 誤植の修正のために、"message/external-body" の代わりに、前述 の "application/external-body" を用意した。 (15) キャラクタセットの定義は、要件を更に明瞭にするために、再編成 された。 (16) "image/gif" メディアタイプの定義は、別個の文書に移動させられ た。この変更は、特許が取得された技術の標準化を制限するIETF規 則との潜在的な矛盾のために行なわれた。 (17) 裸のCR、LFの使用が行末シーケンスとして使われ得るよう、"7bit" 及び "8bit" の定義を厳密化した。文書は、NULキャラクタが保存 されることをもはや必要とせず、そして、それはMIMEを実世界の実 装による配置の状態に至らせる。 (18) 改行がCRLFシーケンスで表されなければならないように、MIMEにお ける正規のテクスト定義を厳密にした。CR、及びLFキャラクタは、 この用法以外では許されない。quoted-printableエンコーディング の定義は、はそれに応じて変更された。 (19) quoted-printableエンコーディングの定義は、quoted-printableエ ンコーダがいかに不適当に符号化された材料でも適切に扱えるよう にするための幾つかの提案を含めた。 (20) 散文は、"8bit" または "binary" データをカプセル化するマルチ パートまたはメッセージエンティティの "7bit"、"8bit"、および "binary" 転送エンコーディングの使用を明確化するために追加さ れた。 (21) MIME準拠でのセクションにおいて、"multipart/digest" サポート は、最小のMIME対応の必要条件のリストに加えられた。また、 "message/rfc822" サポートのための要件は、再帰的な構造を認め ていることの重要性を明確化するために強化された。 (22) "message" のサブタイプに対する様々な制限は、完全にサブタイプ の基礎によるサブタイプ上で現在指定される。 (23) "message/rfc822" の定義は、"From"、"Subject"、または "Date" ヘッダのうちの少なくとも1つが存在しなければならないことを示 すために、変更された。 (24) "application/octet-stream" としての認識されないサブタイプの 必要な処理は、タイプ定義セクションと、類似ガイドラインの両方 において更に明白にされた。 (25) text/richtextを使う例は、text/enrichedに変更された。 (26) サブタイプのBNF定義は、Content-Typeヘッダフィールドで、IANA の登録されたサブタイプ、または、非標準な "X-" サブタイプが使 われなければならないことを明らかにするために、変更された。 (27) 使用およびIETFにより規格化されるそれらに単に登録されるメディ アタイプを標準化することは、MIME BNFにおいて現在区別される。 (28) 様々なMIMEレジストレーション手続きの全ては、広く改正された。 キャラクタセットのためのIANAレジストレーション手続きは、個別 のドキュメント(この文書のセットには一切含まれていない)に移動 された。 (29) エスケープの使用、及びこれらのドキュメントが定義するUS-ASCII やISO-8859-Xキャラクタセットにおけるシフトメカニズムが明瞭に された: もし使われるそれらが未定義なら、そのようなメカニズム は、これらのキャラクタセット、及びそれらの効果と共に決して使 われるべきでない。 (30) message/external-bodyのためにAFS access-typeの定義が除去され た。 (31) multipart/alternativeおよびmessage/external-bodyの結合の扱い は、現在具体的にアドレスされている。 (32) message/external-bodyに特有のセキュリティ問題について、もう 少し詳細に論じた。 付録 C -- 参考文献 [ATK] Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, Prentice-Hall, 1990. [ISO-2022] International Standard -- Information Processing -- Character Code Structure and Extension Techniques, ISO/IEC 2022:1994, 4th ed. [ISO-8859] International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed. - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed. - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed. - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed. - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st ed. - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed. - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed. - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed. - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st ed. International Standard -- Information Technology -- 8-bit Single-Byte Coded Graphic Character Sets - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, 1st ed. [ISO-646] International Standard -- Information Technology -- ISO 7-bit Coded Character Set for Information Interchange, ISO 646:1991, 3rd ed.. [JPEG] JPEG Draft Standard ISO 10918-1 CD. [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, 1991. [PCM] CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code Modulation (PCM) of Voice Frequencies", Geneva, 1972. [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, 1985. [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Ed., 1990. [RFC-783] Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, MIT, June 1981. [RFC-821] Postel, J.B., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [RFC-934] Rose, M. and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, Delaware and NMA, January 1985. [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985. [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet Messages", RFC 1049, CMU, March 1988. [RFC-1154] Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1154, Prime Computer, Inc., April 1990. [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992. [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC 1342, University of Tennessee, June 1992. [RFC-1344] Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC 1344, Bellcore, June 1992. [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets", RFC 1345, Rationel Almen Planlaegning, June 1992. [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC 1422, IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1424] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV -- Key Certification and Related Services", IAB IRTF PSRG, IETF PEM WG, February 1993. [RFC-1521] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993. [RFC-1522] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, September 1993. [RFC-1524] Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information", RFC 1524, Bellcore, September 1993. [RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, USC/Information Sciences Institute, October 1993. [RFC-1556] Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC 1556, Israeli Inter-University Computer Center, December 1993. [RFC-1590] Postel, J., "Media Type Registration Procedure", RFC 1590, USC/Information Sciences Institute, March 1994. [RFC-1602] Internet Architecture Board, Internet Engineering Steering Group, Huitema, C., Gross, P., "The Internet Standards Process -- Revision 2", March 1994. [RFC-1652] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and Crocker, D., "SMTP Service Extension for 8bit-MIME transport", RFC 1652, United Nations University, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, March 1994. [RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [RFC-1741] Faltstrom, P., Crocker, D., and Fair, E., "MIME Content Type for BinHex Encoded Files", December 1994. [RFC-1896] Resnick, P., and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February, 1996. [RFC-2045] Freed, N., and and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual Holdings, November 1996. [RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual Holdings, November 1996. [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC 2047, University of Tennessee, November 1996. [RFC-2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, Innosoft, MCI, ISI, November 1996. [RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049 (this document), Innosoft, First Virtual Holdings, November 1996. [US-ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message Handling Systems and Distributed Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North- Holland, 1989, pp. 3-41. Freed & Borenstein Standards Track