Yasutaka Kato 加藤泰孝
<email:y.kato@personal.email.ne.jp>
<email:ykato-ind@umin.ac.jp>
［rfcディレクトリーのトップへ］
http://www.cis.ohio-state.edu/hypertext/information/rfc.html
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拡張を記載しています。
Freed & Borenstein Standards Track [Page 1]
RFC 2049 MIME Conformance November 1996
四番目の文書、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適合」の概念を定義しておくことは有用です。このセクションで、
そのような適合性の条件を特定します。
Freed & Borenstein Standards Track [Page 2]
RFC 2049 MIME Conformance November 1996
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"メールを認識表示する
-- その他の文字セット、少なくともメッセージがどんな文字セット
を使っているかについて利用者に情報を提供できる範囲で、を認
識する。
Freed & Borenstein Standards Track [Page 3]
RFC 2049 MIME Conformance November 1996
-- "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"であるかのようにとして処理
する。
Freed & Borenstein Standards Track [Page 4]
RFC 2049 MIME Conformance November 1996
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）であことを保証しなけれ
ばなりません。
Freed & Borenstein Standards Track [Page 5]
RFC 2049 MIME Conformance November 1996
（はじまるという意味は：フィールド体部のはじめもしくは行空白ス
ペース直前；おわりの意味：フィールド体部のおわりもしくは行空白
スペース直後）。さらに"=?"ではじまり"?="で終わる、「句」内の如
何なる「単語」も正当な符号化-単語（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手順のことです、で装備されているホストのインターネット構造に有利な
ように飛び交うメッセージを変更するかもしくは全く破壊します。
Freed & Borenstein Standards Track [Page 6]
RFC 2049 MIME Conformance November 1996
以下の指針は、網の目に配置されている技術と既知の破壊的な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文字より長い行は折り返されるかもしくはある環境では一部が切り
詰められるかもしれません。メール転送によって課せられた行折り返
しや行切り詰めは薦められませんが環境によっては避けられません。
長い行が必要なアプリケーションは、ソフトウェアーとハードウェアー
Freed & Borenstein Standards Track [Page 7]
RFC 2049 MIME Conformance November 1996
行分断でいささかことなります。（これをする簡単な方法は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に
Freed & Borenstein Standards Track [Page 8]
RFC 2049 MIME Conformance November 1996
よっては、損なわれ、同様に五つの文字"From "（五番目はスペース）
で始まる行はよく損なわれることが知られています。注意深い構造に
装置は、データーを符号化して、これらの損傷を防いでいます（例え
ば、行のはじめの"From "の場所に"=46rom "そして"."だけの行の場所
に"=2E"を使ったquoted-printable符号化で）。
上記一覧はMTAsのための推薦実践のリストではないことに注意してください。
RFC 821 MTAsは、空白文字や折り返しの長い行を変更することを禁止されてい
ます。これらのBADと不正な実践は既存のネットワーク上でおこることが知ら
れているもので、手段提供者は原因となるこの悪い効果を処理するに当たり確
固不動であるべきです。
[#^]
4. 正式な符号化モデル
これらの文書の初期バージョンでは、メールデーターが正式書式と符号化され
たものに変換される際のモデルに関して、特にこの過程が新しい行の表現がシ
ステムとシステムで非常にヴァラエティがありCRLFsの処理にどのように影響
するか、混乱がありました。この理由のために、符号化の正式なモデルが以下
のように提示されています。
MIME実体を構成する過程を、幾つかの段階をへて行われるものとして、モデル
化できます。これらの段階は大まかに言ってPEM[RFC-1421]で使用された段階
に似ていて、各「最も内部のレベル」ボディのために施行されます：
(1) ローカル書式の作成
転送されるべきボディはシステムの固有の書式（ネイティブな）で作
成されます。この固有の文字セットが使用され、必要な所では行の
ローカル終了慣例も使われます。ボディは、UNIX-スタイルのテキスト
ファイル・Sunラスター画像・UMSインデックス化ファイル・メモリー
にだけ保存されるシステム独立性書式の音響データーもしくはある形
式の情報表現用ローカルモデルに対応しているその他如何なるもので
あるかもしれません。データーは、基本的にはメディアタイプによっ
て特殊化されたタイプに対応した「固有の（ネイティブな）」書式
で、作成されます。
Freed & Borenstein Standards Track [Page 9]
RFC 2049 MIME Conformance November 1996
(2) 正式書式への変換
ボディ全体が、レコードの長さやできればファイル属性情報といった
「トラック外」情報をふくみ、汎用正式書式に変換されます。ボディ
の特別なメディアタイプは、その協調属性とともに、使用されている
正式な書式の性質を指示します。適切な正式書式への変換は、文字
セット変換・音響データー変換・圧縮もしくは様々なメディアタイプ
に特有のその他の操作を含み。しかし文字セット変換がある場合、メ
ディアタイプ、如何なる文字セット変換に対して言外の意味をもって
いて例えば"plain"以外のテキストサブタイプでの構文的に意味がある
文字、の意味を理解することに注意を払わなければなりません。
例えばこの text/plain data データの例で、テキストはサポートされ
ている文字セットに変換されるべきで、行はRFC 822のCRLF識別子で区
別されなければなりません。RFC 822によって示唆された行の長さにつ
いての制限は、次の段階がquoted-printableかbase64符号化方式のど
ちらかを採用しているなら、取りの除かれます。
(3) 転送符号化を使う
このボディに最適な内容転送符号化（Content-Transfer-Encoding）が
当てはめられます。メディアタイプと転送符号化の固定的な関係はな
いことに注意してください。実際、base64もしくはquoted-printable
の選択を、よく遭遇するボディの一定の値に特別な文字に基づくこと
は適切であるかもしれません。
(4) 実体内に挿入する
符号化されたボディは適切なヘッダーをつけてMIME実体に挿入されま
す。次いで、その実体は必要に応じてハイレベル実体（メッセージも
しくはマルティパート）のボディに挿入されます。
実体からローカル書式への変換はこれらの段階を逆にすることで行えます。こ
れらの段階の逆は異なった結果を生むかもしてません、というのはオリジナル
と最終のローカル書式は同じである保証はないからです。
Freed & Borenstein Standards Track [Page 10]
RFC 2049 MIME Conformance November 1996
これらの段階はモデルに過ぎないことに注意しておくことは重要不可欠なこと
です。これらは特別に、実際のシステムがどのように構築されるかの青写真で
はありません。実際このモデルは二つのよくある設計を説明できません：
(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メッセージを表現することができません。
[#^]
Freed & Borenstein Standards Track [Page 11]
RFC 2049 MIME Conformance November 1996
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
[#^]
Freed & Borenstein Standards Track [Page 12]
RFC 2049 MIME Conformance November 1996
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
Freed & Borenstein Standards Track [Page 13]
RFC 2049 MIME Conformance November 1996
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.
[#^]
Freed & Borenstein Standards Track [Page 14]
RFC 2049 MIME Conformance November 1996
付録A -- 複雑なマルチパートの例
以下にくるのは、複雑な多元部メッセージのアウトラインです。このメッセー
ジは五つの部分からなり、続けて表示されます：二つの導入プレーンテキスト
対象・組み込まれた多元部メッセージ・text/enriched対象そして囲い込まれ
た非US-ASCII文字セットのカプセル化されたテキストメッセージです。この組
み込まれた多元部メッセージ自体は平行に表示される二つの対象、画像と音響
部分、からなっています。
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: Ned Freed <ned@innosoft.com>
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
Freed & Borenstein Standards Track [Page 15]
RFC 2049 MIME Conformance November 1996
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
これは <bold><italic>エンリッチ（enriched）</italic></bold>タイプで、
<smaller>RFC 1896で定義されているように</smaller>
<bigger><bigger>寒い</bigger></bigger>
ですよね？
--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.
Freed & Borenstein Standards Track [Page 16]
RFC 2049 MIME Conformance November 1996
(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.
Freed & Borenstein Standards Track [Page 17]
RFC 2049 MIME Conformance November 1996
(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.
Freed & Borenstein Standards Track [Page 18]
RFC 2049 MIME Conformance November 1996
(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.
Freed & Borenstein Standards Track [Page 19]
RFC 2049 MIME Conformance November 1996
(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.
Freed & Borenstein Standards Track [Page 20]
RFC 2049 MIME Conformance November 1996
[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.
Freed & Borenstein Standards Track [Page 21]
RFC 2049 MIME Conformance November 1996
[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.
Freed & Borenstein Standards Track [Page 22]
RFC 2049 MIME Conformance November 1996
[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.
Freed & Borenstein Standards Track [Page 23]
RFC 2049 MIME Conformance November 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 [Page 24]