が原著です。 翻訳版は、翻訳からくる間違いがあり得ます:in progress。 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 加藤泰孝 ----------------------------------------------------------------------  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) Part Five: Conformance Criteria and Examples 適合基準と事例 この覚書の位置付け この文書はインターネット交流社会用のインターネット標準過程手順(プロト コール)を特定し、改善への議論と提案を求めるものです。この手順の標準化 状況や位置付けについては、"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メッセージの一般的な構造を 記載するのに使われる色々なヘッダーを特定しています。二番目の文書は MIMEメディアをタイプ化するシステムの構造とメディアタイプの初期値を定義 しています。三番目の文書、RFC 2047、は非ASCIIのインターネットメール ヘッダーフィールドでの使用ができるRFC 822拡張を記載しています。 四番目の文書、RFC 2048、はMIME関連装備のための色々なIANA登録手順を特定 しています。この五番目で最後の文書は、MIMEメッセージ書式の図解例・謝 辞・文献とMIME適合性基準について記載しています。 これら文書はRFCs 152・1522と1590の改訂で、それらはRFCs 1341 と 1342の 改訂でした。この文書の付録Bに以前のバージョンからの違いと変更点を記載 しています。 目次 1. はじめに .............................................. 2 2. 適合性 ................................................ 2 3. メールデーター送信指針 ................................ 6 4. 正式な符号化モデル .................................... 9 5. 要約 .................................................. 12 6. 安全性問題 ............................................ 12 7. 著者との連絡 .......................................... 12 8. 謝辞 .................................................. 13 A. 複雑なマルチパートの例 ................................ 15 B. RFC 1521, 1522, と 1590 からの変更点................... 16 C. 参考資料 .............................................. 20 1. はじめに この一式の文書の最初と二番目の文書はMIMEヘッダーフィールドとMIMEメディ アタイプの初期設定を定義しています。三番目の文書は、RFC 822書式に、 US-ASCII以外の文字セットを許す拡張について記載してあります。この文書で は、適合MIME装備がサポートしなければならないのはどんな部分かを記載して います。また、MIMEが基盤としている正式符号化モデルとともに現在のメッ セージシステムの様々な落し穴を記載しています。 2. MIME 適合性 これら文書で記載されている機構は公開されています。装備全てが入手可能な メディアタイプを全部サポートしているとも同じ拡張が割り当てられていると、 はっきりと期待はしていません。しかし、相互操作性を促進するために、US- ASCIIテキストとは異なる内容をもったメッセージの、有用な相互作用を可能に する「MIME適合」の概念を定義しておくことは有用です。このセクションで、 そのような適合性の条件を特定します。 MIME適合メール表示代行手段は以下のようでなくてはなりません: (1) 必ず、作成する如何なるメッセージにも"MIME-Version: 1.0"ヘッダー フィールドを生成する。 (2) Content-Transfer-Encodingヘッダーフィールドを認識でき、quoted- printable もしくは base64装備によって受け取った符号化されたデー ターを復元する。7bit・8bitそしてbinaryでのそのままの転送も認識 しなければならない。 符号化しないで送信される如何なる非7ビットデーターもcontent- transfer-encodingに最適なように8bitもしくはbinaryと適切にラベル 付けされなければなりません。基本転送が8bitもしくはbinaryをサ ポート(SMPT[RFC-821]はしていません)していない場合、送信者は quoted-printableやbase64のような適切なContent-Transfer- Encodingを使って符号化しラベル付けしたデーターを要求します。 (3) 認識されない内容転送符号化を、実際の内容タイプが在ってもなくて も、内容タイプ"application/octet-stream"として処理しなければな りません。 (4) Content-Typeヘッダーフィールドを認識解釈し、利用者にテキスト以 外のContent-Typeである生のデーターを見せることを避ける。装備は 少なくともtext/plainメッセージを、US-ASCIIでないならcharsetパ ラーメーターで特定された文字セットで送信できなければなりませ ん。 (5) 認識されない内容タイプパラメーター名はどんなものでも無視する。 (6) 以下のメディアタイプを正確に、少なくとも以下の範囲で処理する: Text: -- 文字セット"US-ASCII"の"text"メールを認識表示する -- その他の文字セット、少なくともメッセージがどんな文字セット を使っているかについて利用者に情報を提供できる範囲で、を認 識する。 -- "ISO-8859-*"文字セットを、ISO-8859-* と US-ASCII即ちオク テック値1~127で表現される全ての文字に共通な文字を表示で きる範囲と、認識する。 -- 既知の文字セットの認識できないサブタイプとして、正式な書式 の内容をローカル書式に変換後そのデーターの「生の」バージョン を利用者に見せるもしくは提供する。 -- 未知の文字セットの素材を"application/octet-stream"である として処理する Image, audio, and video: -- どんな認識されないサブタイプも、"application/octet-stream" であるとして処理する装備を最低提供する。 Application: -- この文書で定義されたquoted-printableもしくはbase64符号化、 これらが使われ生じた情報を利用者ファイルに置く場合、どちらを も取り除く能力を差し出す。 Multipart: -- mixedサブタイプを認識します。メッセージレベルやボディ部分 ヘッダーレベルについての適切な情報を全て表示し、次いで各ボ ディ部分を個々に表示もしくは差しだします。 -- "alternative"サブタイプを認識し、multipart/alternativeメー ルの断長な部分を利用者に見せないようする。 -- "multipart/digest"実体内部のボディ部分のための初期メディア タイプとして "text/plain"ではなく"message/rfc822"を特別に使っ て、"multipart/digest"サブタイプを認識する。 -- 認識されないサブタイプを"mixed"であるかのようにとして処理 する。 Message: -- 少なくともRFC 822メッセージカプセル化を、回帰的な構造を保 持するような方法で、認識しひょうじする、いいかえるとメディア タイプに従ってカプセル化されたデーターを表示もしくは表示する よう差し出す。 -- 認識されないサブタイプを"application/octet-stream"であるか のように取り扱う。 (7) 認識されないContent-Typeフィールドに出合ったら、道具はメディア タイプがサブ主題パラメーターのない"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文字列は如何なるも のであれ正当な符号化-単語(encoded-word)であことを保証しなけれ ばなりません。 (はじまるという意味は:フィールド体部のはじめもしくは行空白ス ペース直前;おわりの意味:フィールド体部のおわりもしくは行空白 スペース直後)。さらに"=?"ではじまり"?="で終わる、「句」内の如 何なる「単語」も正当な符号化-単語(encoded-word)でなければなり ません。 (10) 適合表示代行手段は、"text"・"ctext"もしくは"word"の符号化-単語 (encoded-word)を、メッセージヘッダーで適切な位置に来ていたら何 時でも、セクション4の規則に沿って見分けなければなりません。サ ポートしている文字セット用の"B"と"Q"符号化両者をサポートしなけれ ばなりません。このプログラムは、文字セットがUS-ASCIIの場合、符号 化されていないテキストを表示でkなければなりません。ISO-8859-* 文 字セットでは、メール読み取りプログラムは、少なくとも、US-ASCII セットにもある文字は表示できなければなりません。 上記の状態をうまく処理する表示代行手段はMIME適合であると言われます。こ の句の意味は、適切にマークされた如何なるデーターを、そのようなメールシ ステムの利用者に、実際に送信しても安全であると言えるとことで、何故なら そのようなシステムは少なくともデーターを区別されないバイナリーとして取 り扱うことができ、疑わない利用者の画面に単にそれを跳ね返すだけではない からです。 別の意味で、MIME適合である書式でデーターを送信することは常に「安全」 で、そのようなデーターは、RFC 821とRFC 822に適合している如何なる既知の システムによっても、分断や破壊されません。MIME適合表示代行手段には、利 用者にテキストとして閲覧されることを意図されていないデーターを見せない というさらなる保証があります。 3. メールデーター送信指針 インターネット電子メールは完全で、均一なシステムではありません。メール は最終到着先までの旅の幾つかの段階で不正が働くかもしれません。特にイン ターネットを経て送られるイーメールは、多くの網の目のように配置された技 術をまたがって旅するかもしれません。多くのネットワークとメール技術は SMTP転送環境で可能な完全な機能をサポートしていません。これらのシステム を横切るメールは、転送されることが可能な指令に変更されやすいのです。 インターネト上には多く非適合MTAsが、広く配置されています。これらMTAs、 SMTP手順のことです、で装備されているホストのインターネット構造に有利な ように飛び交うメッセージを変更するかもしくは全く破壊します。 以下の指針は、網の目に配置されている技術と既知の破壊的なMTAsの範囲を無 傷で生き延びると考えられているデーター書式(メディアタイプ)を工夫する 人に役立つかもしれません。base64符号化方式で符号化されたものはどれで も、これらの規則を満たしますが、よく知られた機構、UNIX uuencode装備が 有名で、のなかにはそうではないことに注意してください。またQuoted- Printable符号化方式も大部分のゲートウェイ(通過門)を損なわれないで生 き延びますが、EBCDIC文字セットなどを使用するシステムへの通過門によって は生き延びない可能性があります。 (1) 状況によっては、データーに使われた符号化が、普通のゲートウェイ もしくは表示代行手段操作の一部として、変更されるかもしれませ ん。特にbase64からquoted-printableへまたその逆が必要であるかも しれません。これによって、テキストボディの行分断とCRLF連続体の 区別が付かない結果になります。このように、行分断以外の何かとし て、CRLFの効果に信頼をおくべきではありません。 (2) 多くのシステムが、ローカルな新行慣例を使って、テキストデーター を表現し貯えます。ローカル新行慣例はRFC 822 CRLF慣例と一致しな いかもしれなく -- システムはプレーンなCR・プレーンなLF・CRLFも しくは数えられたレコードを使うことが知られています。その結果 は、分離されたCRやLF文字は一般的に許容されないかもしくはシステ ムによっては識別子に変換され、それゆえに信頼をおくべきではあり ません。 (3) NULs (US-ASCII value 0)の転送はインターネットメールでは問題があ ります。(これは主にCプログラム言語で標準実行時間ライブラリー ルーティンが末尾文字としてNULsを使用している結果によります) 末 尾文字としてNULsを使うことが確立しているので、メッセージは予約さ れたこれらに依存すべきではありません。 (4) TAB(HT)文字は間違って解釈されるかもしれないし、自動的に様々な数 のスペースに変換されるかもしれません。ある環境、US-ASCLL言語 セットに基盤をおいていない、でこれは避けられません。このような 変換は推奨できませんが、起こりそしてメール書式はTAB (HT)文字の 効果に依存すべきではありません。 (5) 76文字より長い行は折り返されるかもしくはある環境では一部が切り 詰められるかもしれません。メール転送によって課せられた行折り返 しや行切り詰めは薦められませんが環境によっては避けられません。 長い行が必要なアプリケーションは、ソフトウェアーとハードウェアー 行分断でいささかことなります。(これをする簡単な方法はquoted- printable符号化を使うことです。) (6) 行での末尾「空白スペース」文字は、転送代行手段によっては抜き取ら れ、一方別の転送手段はこれらの文字のある行に詰め物をし従ってメー ルファイルの行全ては同じ長さです。従って、末尾空白スペースの効果 に依存すべきではありません。 (7) 多くのメールドメインはUS-ASCII文字セットで一様でないものを使 い、もしくは大部分のUS-ASCIIがあるが全がそうではないEBCDICと いった文字セットを使用しています。「一様=invariant」でないセッ トでは、文字の正しい転送は文字変換通過門通過に頼ることはできま せん。例えば、BITNET・EBCDICシステムを経てuuencodeで符号化され た情報を送信する場合、この状況は問題です。同じ様な問題が、ゲー トウェイを経なくても起こり、というのは多くのインターネットホス トが内部でUS-ASCII以外の文字セットを使用しているからです。 X.400の印字可能な列の定義は、ある特別なケースではさらなる制限を 加えます。特に、全てのゲートウェイ通過で不変であると分かってい る文字は73文字で、大文字小文字A-Z・a-z・アラビア数字0-9と以下の 特別な十一文字だけです: "'" (US-ASCII 十進値 39) "(" (US-ASCII 十進値 40) ")" (US-ASCII 十進値 41) "+" (US-ASCII 十進値 43) "," (US-ASCII 十進値 44) "-" (US-ASCII 十進値 45) "." (US-ASCII 十進値 46) "/" (US-ASCII 十進値 47) ":" (US-ASCII 十進値 58) "=" (US-ASCII 十進値 61) "?" (US-ASCII 十進値 63) 最大に移動できるメール表現は、意味がある文字がこの73文字一式か らなる比較的短い行に限られています。base64符号化方式はこの規則 に従っています。 (8) メール転送手段によっては、或る種のアルファベット列を含むデー ターを損います。特にピリオド(".")だけの行は、(不正な)SMTPに よっては、損なわれ、同様に五つの文字"From "(五番目はスペース) で始まる行はよく損なわれることが知られています。注意深い構造に 装置は、データーを符号化して、これらの損傷を防いでいます(例え ば、行のはじめの"From "の場所に"=46rom "そして"."だけの行の場所 に"=2E"を使ったquoted-printable符号化で)。 上記一覧はMTAsのための推薦実践のリストではないことに注意してください。 RFC 821 MTAsは、空白文字や折り返しの長い行を変更することを禁止されてい ます。これらのBADと不正な実践は既存のネットワーク上でおこることが知ら れているもので、手段提供者は原因となるこの悪い効果を処理するに当たり確 固不動であるべきです。 4. 正式な符号化モデル これらの文書の初期バージョンでは、メールデーターが正式書式と符号化され たものに変換される際のモデルに関して、特にこの過程が新しい行の表現がシ ステムとシステムで非常にヴァラエティがありCRLFsの処理にどのように影響 するか、混乱がありました。この理由のために、符号化の正式なモデルが以下 のように提示されています。 MIME実体を構成する過程を、幾つかの段階をへて行われるものとして、モデル 化できます。これらの段階は大まかに言ってPEM[RFC-1421]で使用された段階 に似ていて、各「最も内部のレベル」ボディのために施行されます: (1) ローカル書式の作成 転送されるべきボディはシステムの固有の書式(ネイティブな)で作 成されます。この固有の文字セットが使用され、必要な所では行の ローカル終了慣例も使われます。ボディは、UNIX-スタイルのテキスト ファイル・Sunラスター画像・UMSインデックス化ファイル・メモリー にだけ保存されるシステム独立性書式の音響データーもしくはある形 式の情報表現用ローカルモデルに対応しているその他如何なるもので あるかもしれません。データーは、基本的にはメディアタイプによっ て特殊化されたタイプに対応した「固有の(ネイティブな)」書式 で、作成されます。 (2) 正式書式への変換 ボディ全体が、レコードの長さやできればファイル属性情報といった 「トラック外」情報をふくみ、汎用正式書式に変換されます。ボディ の特別なメディアタイプは、その協調属性とともに、使用されている 正式な書式の性質を指示します。適切な正式書式への変換は、文字 セット変換・音響データー変換・圧縮もしくは様々なメディアタイプ に特有のその他の操作を含み。しかし文字セット変換がある場合、メ ディアタイプ、如何なる文字セット変換に対して言外の意味をもって いて例えば"plain"以外のテキストサブタイプでの構文的に意味がある 文字、の意味を理解することに注意を払わなければなりません。 例えばこの text/plain data データの例で、テキストはサポートされ ている文字セットに変換されるべきで、行はRFC 822のCRLF識別子で区 別されなければなりません。RFC 822によって示唆された行の長さにつ いての制限は、次の段階がquoted-printableかbase64符号化方式のど ちらかを採用しているなら、取りの除かれます。 (3) 転送符号化を使う このボディに最適な内容転送符号化(Content-Transfer-Encoding)が 当てはめられます。メディアタイプと転送符号化の固定的な関係はな いことに注意してください。実際、base64もしくはquoted-printable の選択を、よく遭遇するボディの一定の値に特別な文字に基づくこと は適切であるかもしれません。 (4) 実体内に挿入する 符号化されたボディは適切なヘッダーをつけてMIME実体に挿入されま す。次いで、その実体は必要に応じてハイレベル実体(メッセージも しくはマルティパート)のボディに挿入されます。 実体からローカル書式への変換はこれらの段階を逆にすることで行えます。こ れらの段階の逆は異なった結果を生むかもしてません、というのはオリジナル と最終のローカル書式は同じである保証はないからです。 これらの段階はモデルに過ぎないことに注意しておくことは重要不可欠なこと です。これらは特別に、実際のシステムがどのように構築されるかの青写真で はありません。実際このモデルは二つのよくある設計を説明できません: (1) 多くの場合符号化の前の正式な書式への変換はローカル書式は、直接 理解する符号化自体に組み込まれます。例えば、テキストボディの ローカル新行慣例は、その書式がなんであるかの知識にそって、符号 化そのものをやり遂げます。 (2) 符号化されたものの出力は、メッセージとして転送される前に一つ以 上の追加段階をへなければならないかもしれません。それ自体として この符号化されたものの出力は、RFC 822で特定された書式に適合しな いかもしれません。特に標準RFC 822 CRLF識別子を使うのでなくロー カル新行慣例を使って表現されることが、変換出力には適切なのかも しれません。 同様に、別の装備不統一も想像できます。この議論の重要な側面は、如何なる 最適化・必要な段階の破壊もしくは追加的な処理の挿入にも関わらず、もたら されるメッセージはここで記載されたモデルによって作り出されたものと一致 しなければなりません。例えば、以下のヘッダーフィールドをもったメッセー ジは: Content-type: text/foo; charset=bar Content-Transfer-Encoding: base64 まずtext/foo書式で表現し、次いで(必要なら)"bar"文字セットで表現しそ して最後にbase64アルゴリズムでメール安全書式に変換されなければなりませ ん。 注意:RFC 822 CRLF変換と異なるローカルな新行慣例を使った書式でメッセー ジを表現しているシステムでは、ある種の混乱が生じています。これらの書式 は正式なRFC 822/MIMEではないことを知っておくことは重要です。これらの書 式はRFC 822の*符号化*でなく、正式なメッセージ表現でのCRLF連続体はロー カル新行慣例として符号化されています。CRLF連続体を、例えばLFとして、符 号化する書式は、CRLF行分離連続体の一部でないLFオクテックを含むバイナ リーデーターのあるMIMEメッセージを表現することができません。 5. 要約 この文書は、MIMEによって意味されるのは何か、を定義しています。またイン ターネットメールシステムにあると知られている色々な問題や、MIME使用がこ れらをどのように克服するかを詳しく述べています。 6. 安全性問題 安全性問題はこの一式の二番目の文書、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は、RFC 822拡張についてのthe Internet Engineering Task Force Working Groupの作業の結果です。このグループの座長、Greg Vaudreuil、と の連絡は: Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA EMail: Greg.Vaudreuil@Octel.Com 8. 謝辞 This document is the result of the collective effort of a large number of people, at several IETF meetings, on the IETF-SMTP and IETF-822 mailing lists, and elsewhere. Although any enumeration seems doomed to suffer from egregious omissions, the following are among the many contributors to this effort: 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 The authors apologize for any omissions from this list, which are certainly unintentional. 付録A -- 複雑なマルチパートの例 以下にくるのは、複雑な多元部メッセージのアウトラインです。このメッセー ジは五つの部分からなり、続けて表示されます:二つの導入プレーンテキスト 対象・組み込まれた多元部メッセージ・text/enriched対象そして囲い込まれ た非US-ASCII文字セットのカプセル化されたテキストメッセージです。この組 み込まれた多元部メッセージ自体は平行に表示される二つの対象、画像と音響 部分、からなっています。 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符号化の8000ヘルズ単一チャンネルmu-law-書式音響 データーがここに来ます。 ... --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64 ... base64符号化画像データーがここに来ます。 ... --unique-boundary-2-- --unique-boundary-1 Content-type: text/enriched これは エンリッチ(enriched)タイプで、 RFC 1896で定義されているように 寒い ですよね? --unique-boundary-1 Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in 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からの変更 These documents are a revision of RFC 1521, 1522, and 1590. For the convenience of those familiar with the earlier documents, the changes from those documents are summarized in this appendix. For further history, note that Appendix H in RFC 1521 specified how that document differed from its predecessor, RFC 1341. (1) This document has been completely reformatted and split into multiple documents. This was done to improve the quality of the plain text version of this document, which is required to be the reference copy. (2) BNF describing the overall structure of MIME object headers has been added. This is a documentation change only -- the underlying syntax has not changed in any way. (3) The specific BNF for the seven media types in MIME has been removed. This BNF was incorrect, incomplete, amd inconsistent with the type-indendependent BNF. And since the type-independent BNF already fully specifies the syntax of the various MIME headers, the type- specific BNF was, in the final analysis, completely unnecessary and caused more problems than it solved. (4) 文書にでてくる非公式な用語ASCIIの使用をより特別な "US-ASCII"文 字セットに置き換えました。 (5) The informal concept of a primary subtype has been removed. (6) The term "object" was being used inconsistently. The definition of this term has been clarified, along with the related terms "body", "body part", and "entity", and usage has been corrected where appropriate. (7) The BNF for the multipart media type has been rearranged to make it clear that the CRLF preceeding the boundary marker is actually part of the marker itself rather than the preceeding body part. (8) The prose and BNF describing the multipart media type have been changed to make it clear that the body parts within a multipart object MUST NOT contain any lines beginning with the boundary parameter string. (9) In the rules on reassembling "message/partial" MIME entities, "Subject" is added to the list of headers to take from the inner message, and the example is modified to clarify this point. (10) "Message/partial" fragmenters are restricted to splitting MIME objects only at line boundaries. (11) In the discussion of the application/postscript type, an additional paragraph has been added warning about possible interoperability problems caused by embedding of binary data inside a PostScript MIME entity. (12) Added a clarifying note to the basic syntax rules for the Content-Type header field to make it clear that the following two forms: Content-type: text/plain; charset=us-ascii (comment) Content-type: text/plain; charset="us-ascii" are completely equivalent. (13) The following sentence has been removed from the discussion of the MIME-Version header: "However, conformant software is encouraged to check the version number and at least warn the user if an unrecognized MIME-version is encountered." (14) A typo was fixed that said "application/external-body" instead of "message/external-body". (15) The definition of a character set has been reorganized to make the requirements clearer. (16) The definition of the "image/gif" media type has been moved to a separate document. This change was made because of potential conflicts with IETF rules governing the standardization of patented technology. (17) The definitions of "7bit" and "8bit" have been tightened so that use of bare CR, LF can only be used as end-of-line sequences. The document also no longer requires that NUL characters be preserved, which brings MIME into alignment with real-world implementations. (18) The definition of canonical text in MIME has been tightened so that line breaks must be represented by a CRLF sequence. CR and LF characters are not allowed outside of this usage. The definition of quoted- printable encoding has been altered accordingly. (19) The definition of the quoted-printable encoding now includes a number of suggestions for how quoted- printable encoders might best handle improperly encoded material. (20) Prose was added to clarify the use of the "7bit", "8bit", and "binary" transfer-encodings on multipart or message entities encapsulating "8bit" or "binary" data. (21) In the section on MIME Conformance, "multipart/digest" support was added to the list of requirements for minimal MIME conformance. Also, the requirement for "message/rfc822" support were strengthened to clarify the importance of recognizing recursive structure. (22) The various restrictions on subtypes of "message" are now specified entirely on a subtype by subtype basis. (23) The definition of "message/rfc822" was changed to indicate that at least one of the "From", "Subject", or "Date" headers must be present. (24) The required handling of unrecognized subtypes as "application/octet-stream" has been made more explicit in both the type definitions sections and the conformance guidelines. (25) Examples using text/richtext were changed to text/enriched. (26) The BNF definition of subtype has been changed to make it clear that either an IANA registered subtype or a nonstandard "X-" subtype must be used in a Content-Type header field. (27) MIME media types that are simply registered for use and those that are standardized by the IETF are now distinguished in the MIME BNF. (28) All of the various MIME registration procedures have been extensively revised. IANA registration procedures for character sets have been moved to a separate document that is no included in this set of documents. (29) The use of escape and shift mechanisms in the US-ASCII and ISO-8859-X character sets these documents define have been clarified: Such mechanisms should never be used in conjunction with these character sets and their effect if they are used is undefined. (30) The definition of the AFS access-type for message/external-body has been removed. (31) The handling of the combination of multipart/alternative and message/external-body is now specifically addressed. (32) Security issues specific to message/external-body are now discussed in some detail. 付録 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.