>サイトトップへ >このカテゴリの一覧へ

X 5810-5:2008

(1)

目  次

ページ

序文

1

1  総則

1

1.1  適用範囲

1

1.2  概要

1

1A  引用規格

2

2  MIME 適合性

2

3  電子メールデータ送信の指針

4

4  正準符号化モデル

6

5  要約

7

6  セキュリティへの考慮

8

附属書 A(参考)複雑なマルチパートの例

9

附属書 B(参考)RFC 1521, 1522 及び 1590 からの変更点

12

附属書 C(参考)参考文献

14


 
X 5810-5:2008

(2)

まえがき

この規格は,工業標準化法第 12 条第 1 項の規定に基づき,財団法人日本規格協会(JSA)から,工業標準

原案を具して日本工業規格を制定すべきとの申出があり,日本工業標準調査会の審議を経て,経済産業大

臣が制定した日本工業規格である。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許

権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に係る確認について,責任は

もたない。

JIS X 5810 の規格群には,次に示す部編成がある。

JIS

X

5810-1  第 1 部:インターネットメッセージ本体のフォーマット

JIS

X

5810-2  第 2 部:メディア型

JIS

X

5810-3  第 3 部:非 ASCII テキストへのメッセージヘッダ拡張

JIS

X

5810-5  第 5 部:適合基準


日本工業規格

JIS

 X

5810-5

:2008

多目的インターネットメール拡張(MIME)−

第 5 部:適合基準

Multipurpose Internet Mail Extensions (MIME)−

Part 5: Conformance criteria and examples

序文

この規格は,1996 年 11 月に Internet Engineering Task Force (IETF)から公表された RFC 2049,Multipurpose

Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples を基に,技術的内容及び構成を

変更することなく作成した日本工業規格である。

なお,この規格で側線を施してある箇所は,RFC 2049 にない事項である。

インターネット公式プロトコル規定 STD 11 である RFC 822 では,US-ASCII メッセージヘッダについて

多くの詳細を規定したメッセージ表現プロトコルを定義しているが,メッセージ内容,すなわち,メッセ

ージ本体については,構造のない US-ASCII テキストだけとしている。JIS X 5810 の規格群は,多目的イ

ンターネットメール拡張又は MIME と総称され,次のことを可能とするために,メッセージのフォーマッ

トを再定義する。

a) US-ASCII 以外の文字集合でのテキストのメッセージ本体

b)  非テキストのメッセージ本体のための異なるフォーマットの拡張集合

c)  マルチパートのメッセージ本体

d) US-ASCII 以外の文字集合でのテキストのヘッダ情報

MIME を規定する JIS X 5810 の規格群は,RFC 934,STD 11 及び RFC 1049 に文書化されている初期の

成果に基づくが,それらを拡張及び改正する。RFC 822 では,メッセージ本体についてはごくわずかに示

しているだけなので,JIS X 5810 の規格群の大部分は,RFC 822 を改正するというより,RFC 822 を補う。

1

総則

1.1

適用範囲

この規格は,JIS X 5810 の規格群の第 5 部であり,MIME 適合基準について規定し,それとともに幾つ

かの MIME メッセージフォーマットの例示及び参考文献を提供する。

注記  JIS X 5810 の規格群の第 1 部(JIS X 5810-1)の原規定は RFC 2045,第 2 部(JIS X 5810-2)の原規

定は RFC 2046,

第 3 部(JIS X 5810-3)の原規定は RFC 2047,

第 5 部(JIS X 5810-5)の原規定は RFC

2049 である。RFC 2045,RFC 2046,RFC 2047 及び RFC 2049 は,RFC 1521,RFC 1522 及び RFC

1590 の改正であって,RFC 1521,RFC 1522 及び RFC 1590 は RFC 1341 及び RFC 1342 の改正

であった。

附属書 に,過去の版との違い及び変更について記載する。

1.2

概要

MIME 関連の一連の規格のうち,1 番目の JIS X 5810-1 及び 2 番目の JIS X 5810-2 は,MIME ヘッダフ



X 5810-5:2008

ィールド及び MIME メディア型の初期集合を定義する。3 番目の JIS X 5810-3 は,US-ASCII 以外の文字集

合を可能とするために,RFC 822 フォーマットの拡張について規定する。この規格は,MIME のどの部分

が適合する MIME 実装によってサポートされなければならないかを規定する。また,この規格は,現代の

メッセージングシステムの多くの注意点を示し,MIME が基づいている正準符号化モデルをも規定する。

1A

引用規格

次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。これらの

引用規格は,その最新版(追補を含む。

)を適用する。

JIS X 5810-1  多目的インターネットメール拡張(MIME)−第 1 部:インターネットメッセージ本体の

フォーマット

注記 RFC

2045  "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message

Bodies", November 1996 が,この規格に一致している。

JIS X 5810-2  多目的インターネットメール拡張(MIME)−第 2 部:メディア型

注記 RFC

2046  "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November

1996 が,この規格に対応している。

ISO/IEC 8859 (All parts)  Information technology−8-bit single-byte coded graphic character sets

2

MIME 適合性

MIME 関連規格で示される機構は,拡張に対応している。すべての実装がすべての可能なメディア型を

サポートすることも,それらが同じ拡張を共有することも,全く期待されない。しかし,相互運用性を推

進するため,実装のある水準を定義する“MIME 適合性”の概念を定義することは有用であり,これは,

US-ASCII テキストと異なる内容をもつメッセージの有用な交換を可能にする。箇条 は,この適合性のた

めの要件を規定する。

MIME 適合であるメールの利用者エージェントは,次を満たさなければならない。

a)  それが作成するすべてのメッセージに,常に“MIME-Version: 1.0”ヘッダフィールドを生成しなければ

ならない。

b) Content-Transfer-Encoding(内容転送符号化)ヘッダフィールドを認識し,quoted-printable 実装又は

base64 実装のどちらかによって符号化されたすべての受信データを復号しなければならない。7 bit 同

一変換,8 bit 同一変換及び binary 同一変換も認識されなければならない。

符号化せずに送られるすべての非 7 bit データは,8 bit 又は binary の内容転送符号化で適切にラベル付

けされなければならない。下層にある転送機構が,8 bit 又は binary をサポートしないとき(SMTP [RFC

821]がサポートしないように),送信者は,quoted-printable 又は base64 などの適切な内容転送符号化を

用いて,データを符号化し,かつ,ラベル付けすることが要求される。

c)  認識できないどのような Content-Transfer-Encoding(内容転送符号化)も,実際の Content-Type が認識

されるかどうかにかかわらず,それが“application/octet-stream”の Content-Type をもつように扱わなく

てはならない。

d) Content-Type ヘッダフィールドを認識し解釈しなければならず,text 以外の Content-Type フィールドを

もつ生データを利用者に見せてはならない。実装は,少なくとも text/plain メッセージを,送ることが

できなければならない。このメッセージの文字集合が US-ASCII でない場合には,charset パラメタで

指定される文字集合で送らなければならない。


3

X 5810-5:2008

e)  名前を認識できない内容型のパラメタは無視しなければならない。

f)  次のメディア型値を,少なくとも次の程度まで明示的に処理しなければならない。

text:

1)  文字集合“US-ASCII”をもつ“text”メールを認識し,表示しなければならない。

2)  他の文字集合を,少なくとも,メッセージが使っている文字集合が何であるかについて利用者に知

らせることができる程度まで,認識しなければならない。

3) ISO-8859-X 及び US-ASCII に共通の文字,すなわちオクテット値 1∼127 で表現されるすべての文字

を表示できる程度まで,“ISO-8859-X”文字集合を認識しなければならない。

4)  既知の文字集合の認識できないメディア下位型については,正準形式から局所形式への内容変換の

後に“生”の版のデータを,利用者に見せるか見せることを提案しなければならない。

5)  未知の文字集合のデータは,それが“application/octet-stream”であるかのように扱わなければならな

い。

imageaudio 及び video: 
1)  少なくとも,すべての認識できないメディア下位型を“application/octet-stream”であるかのように扱

う機能を提供しなければならない。

application:

1)  JIS X 5810-1 で定義される quoted-printable 符号化又は base64 符号化が使われ,結果の情報が利用者

のファイルに置かれる場合,それを取り除く能力を提示しなければならない。

multipart:

1)  混合のメディア下位型を認識しなければならない。メッセージレベル及び本体部分ヘッダレベルの

すべての関連する情報を表示し,そして,それぞれの本体部分を独立に表示するか又は表示するか

どうかを提案しなければならない。

2) “alternative”メディア下位型を認識し,multipart/alternative のメールの冗長な部分を利用者に見せるこ

とを避けなければならない。

3) “multipart/digest”メディア下位型を認識しなければならない。特に,“multipart/digest”実体の内部の本

体部分のデフォルトのメディア型として,“text/plain”ではなく“message/rfc822”を使わなければなら

ない。

4)  すべての認識できないメディア下位型を“mixed”であるかのように扱わなければならない。

message:

1)  少なくとも RFC 822 メッセージのカプセル化(message/rfc822)をすべての再帰構造を保持する方法で

認識及び表示しなければならない。すなわち,

このメディア型に従ってカプセル化されたデータを,

表示するか又は表示することを提案しなければならない。

2)  どんな認識できないメディア下位型も“application/octet-stream”であるかのように扱わなければなら

ない。

g)  認識できない Content-Type フィールドに遭遇した場合には,実装は,それがパラメタなしの“application /

octet-stream”のメディア型をもつかのように,それを扱わなければならない。これらのデータをどう処

理するかは実装の問題になるが,これらの認識できないデータを処理する可能な選択肢には,メール

転送フォーマットから復号されるファイルにそれを書き込むことを利用者に提供すること,又は復号

されるデータを入力として渡すプログラムを指名することを利用者に提案することが含まれる。

h)  適合利用者エージェントが,US-ASCII 以外の文字集合を用いる非 MIME メッセージに対して非標準



X 5810-5:2008

のサポートを提供する場合,受信メッセージだけにそれを行うことが,適合利用者エージェントに要

求される。適合利用者エージェントは,US-ASCII テキスト以外を含む非 MIME メッセージを送って

はならない。

特に,MIME-Version フィールドなしのメールメッセージにおける非 US-ASCII テキストの使用は,

異なる局所変換の領域間でメッセージを送るときに相互運用性を妨げるので,強く非推奨とする。適

合利用者エージェントは,US-ASCII 文字集合でプレーンテキスト以外のものを送るとき,正しい

MIME ラベル付けを含まなければならない。

さらに,非 MIME 利用者エージェントは,たとえ MIME 中で他の何もサポートしない場合でも,そ

れが送ったメッセージに適切な MIME ヘッダ情報を含むことが可能なように更新されたほうがよい。

この更新は,あったとしても,ほとんど非 MIME 受信者に影響を与えず,これらのメッセージを正し

く表示するのに MIME を援助する。これは,他の MIME 機能を将来採用することへの円滑な移行の道

筋をも提供する。

i)

適合利用者エージェントは,“=?”で始まり“?=”で終わる“*text”又は“*ctext”の中にある非空白で印字可

能な US-ASCII 文字のどの文字列も,妥当な符号化語(valid encoded-word)であることを保証しなければ

ならない。ここで,“始まる”は,フィールド本体の先頭又は空白の並び(linear-white-space)の直後を

意味し,

“終わる”は,フィールド本体の末尾又は線形空白の直前を意味する。さらに,“=?”で始まり

“?=”で終わる“phrase”の中にあるどんな“word”も,妥当な符号化語でなければならない。

j)  適合利用者エージェントは,符号化語がメッセージヘッダ中の適切な位置に現れたらいつでも,箇条

に規定する規則に従って,符号化語を“text”,“ctext”又は“word”から区別できなければならない。そ

れは,それがサポートするどの文字集合に対しても,“B”符号化及び“Q”符号化の両方をサポートしな

ければならない。そのプログラムは,符号化されないテキストを,文字集合が“US-ASCII”であれば,

表示できなければならない。ISO-8859-X 文字集合に関して,メールを読むプログラムは,少なくとも

US-ASCII 集合にも含まれる文字を表示できなければならない。

これらの条件に適合する利用者エージェントは,MIME 適合であるといえる。この句の意味は,これら

のメールシステムの利用者に,適切にマーク付けされたどんな種類のデータも事実上送ることが,

“安全”

であると想定される。それは,これらのシステムが,少なくともそのデータを区別されない binary として

扱うことができ,疑わない利用者の画面上にそれをまき散らすことはないことによる。

MIME 適合のフォーマットでデータを送ることは常に“安全”であるというもう一つ意義がある。それ

は,それらのデータが,壊れることはなく,RFC 821 及び RFC 822 に適合するどんな既知のシステムによ

っても壊されない。MIME 適合の利用者エージェントは,利用者がテキストとして見られることを決して

想定しないデータを見せられないという,追加の保証をもつ。

3

電子メールデータ送信の指針

インターネットメールは,完全で一様なシステムではない。メールは,最終目的地に行く途中の多くの

段階で,壊れてしまうことがある。特に,インターネットを通って送られた電子メールは,多くのネット

ワーク技術を通過し得る。多くのネットワーク技術及びメール技術は,SMTP 転送環境で可能な全機能を

サポートするわけではない。これらのシステムを通過するメールは,それが転送され得るように,変更さ

れやすい。

インターネットには,多くの非適合 MTA (Message Transfer Agent)  がある。これらの MTA は,SMTP プ

ロトコルで交信するときに,それが実装されているホストの内部データ構造を利用して動作中にメッセー


5

X 5810-5:2008

ジを改変するか,又ははっきりと壊される。

次の指針は,最も広範なネットワーク技術及び既知の壊れた MTA で無きずに生き残るために想定され

るデータフォーマット(メディア型)を工夫する人に有用であろう。base64 符号化で符号化されるものは,

これらの規則を満たすが,よく知られた機構,とりわけ UNIX の uuencode 機能はそれを満たさないことに

注意されたい。quoted-printable 符号化で符号化されたものは,大部分のゲートウェイで無きずに生き残る

が,EBCDIC 文字集合を使うシステムへの幾つかのゲートウェイでは生き残れない可能性がある。

a)  幾つかの状況下では,通常のゲートウェイの一部又は利用者エージェント操作として,データに使わ

れる符号化が変更されることがある。特に,base64 から quoted-printable への変換及びその逆変換は,

避けがたいことがある。これは,テキスト本体中の行区切りで,CRLF 列の混乱を起こすかもしれな

い。そうであるから,行区切りではないものとしての CRLF の保存性は,信頼してはならない。

b)  多くのシステムは,システム固有の改行規約を使って,テキストデータを表示し,保存することを選

択することがある。システム固有の改行規約は,RFC 822 の CRLF 規約  には一致しないことがある。

例えば,CR だけ,LF だけ,CRLF,又は文字数区切りレコードを使うシステムが知られている。その

結果,孤立した CR 文字及び LF 文字は,一般には許されない。それらは,あるシステムでは,失われ

るか又は区切り子に変換されるかもしれないので,信頼してはならない。

c) NUL(US-ASCII 値の 0)の転送は,インターネットメールでは問題がある。これは,プログラム言語

C において多くの標準ランタイムライブラリルーチンによって終端文字として使われている NUL の

結果によるところが大きい。終端文字としての NUL の使用の実行は,今では確立されたものだから,

メッセージが保存されることを信じないほうがよい。

d) TAB

(HT)文字は,誤って解釈され得るか,異なる数のスペースへ自動的に変換されるかもしれない。

これは,ある環境では,特に US-ASCII 文字集合に基づかない環境では,避けられない。これらの変

換は,強く非推奨とするが,もしそれが起きる場合には,メールフォーマットは TAB(HT)文字の保存

性に依存してはならない。

e) 76 文字より長い行は,ある環境では,折り返されるか又は切り取られる。メール転送で行われる行の

折返し又は切取りは,強く非推奨とするが,幾つかの場合には避けられない。長い行を要求するアプ

リケーションは,無指定(soft)行区切りと指定(hard)行区切りとを何とかして区別しなければならない。

これを行う簡単な方法に,quoted-printable 符号化の使用がある。

f)  行の末尾の“空白”文字[SPACE,TAB (HT)]は,ある転送エージェントで捨てられるかもしれない。

他の転送エージェントが,これらの文字で行を埋めて,メールファイル中のすべての行を同じ長さに

することもある。したがって,末尾の空白の保存性をあてにしてはならない。

g)  多くのメールドメインは,US-ASCII 文字集合での変種を使うか,又は US-ASCII の文字の多くを含む

がすべては含んでいない EBCDIC などの文字集合を使う “不変の”集合にない文字の正しい翻訳は,

文字変換ゲートウェイに頼ることはできない。例えば,この状況は,uuencode された情報を,EBCDIC

システムである BITNET を通して送る場合に問題となる。多くのインターネットのホストは,内部で

は US-ASCII 以外の文字集合を使うので,類似の問題は,ゲートウェイを通さない場合にも起こる。

X.400 における Printable String(印字可能文字列)の定義は,ある特定の場合に更に制限を加えている。

特に,すべてのゲートウェイを通して一貫性があると知られている文字は,大文字の A から Z まで,

小文字の a から z まで,

0 から 9 までの 10 数字,及び次の 11 の特別な文字である 73 文字だけである。

  “'”  (US-ASCII の 10 進値で 39)

  “(”  (US-ASCII の 10 進値で 40)



X 5810-5:2008

  “)”  (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 符号化はこの規則に従う。

h)  幾つかのメール転送エージェントは,ある文字列を含むデータを壊す。特に,ピリオド(“.”)だけの行

は,幾つかの(正しくない)SMTP 実装によって壊されることが知られており,“From ”の 5 文字(最

後の文字は SPACE)で始まる行も通常壊される。注意深い作成エージェントは,そのデータを符号化

することによって破壊を防ぐことができる。例えば,quoted-printable 符号化において行の先頭にある

“From ”の場所に“=46rom”を使い,行の“.”だけの場所には“=2E”を使う。

上記の一覧は,MTA に関する推奨される実行の一覧ではないことに注意されたい。RFC 821 の MTA は,

空白の文字を変更すること又は長い行を折り返すことを禁止している。これらの悪い不正な実行は,設置

されたネットワークで起こることが知られていて,実装は,それらが引き起こし得る悪い影響を扱う場合

に頑健であることが望ましい。

4

正準符号化モデル

MIME 規定の初期の版では,混乱があった。それは,どのようなときに電子メールデータが正準形式に

変換し符号化されるか,そして,システムごとに改行の表現が大きく異なるとき,この変換・符号化が CRLF

の振る舞いにどのように影響するかについてのモデルに関する混乱であった。このため,符号化の正準モ

デルを次に示す。

MIME 実体を作成する過程は,幾つかの段階で行われるものとしてモデル化できる。これらの段階は,

大雑把にいって,PEM [RFC 1421]で使われる段階と似ていて,それぞれの“最も内側のレベル”の本体に

対して実行される。

a)  局所形式の作成  システムの固有フォーマットで,転送する本体を生成する。固有の文字集合が使わ

れ,適切であれば,同様に局所的な行の終端の変換が行われる。本体は,UNIX スタイルのテキスト

ファイル,Sun のラスタ画像,VMS のインデックス付きファイル,メモリ内だけに保存される形式の

システム依存の音声データ,又は情報のある形式の表現のための局所的なモデルに対応するその他の

ものであってもよい。基本的に,データは,メディア型で指定される型に対応する“固有の”形式で

作成される。

b)  正準形式への変換  レコード長,可能なファイル属性情報などの“out-of-band”情報を含むすべての本

体は,普遍的な正準形式に変換される。本体の特定のメディア型及び関連する属性は,使われる正準

形式の性質を指示する。正しい正準形式への変換は,文字集合の変換,音声データの変換,圧縮,又

は様々なメディア型に固有の多くの他の操作を含んでよい。しかし文字集合の変換を含む場合には,

どんな文字集合の変換にも強い意味をもつであろう,メディア型のセマンティクス(例えば,plain 以


7

X 5810-5:2008

外のテキストメディア下位型においては,ある種の文字が構文上の意味をもつ。

)について注意を払わ

なければならない。例えば,text/plain データの場合,テキストはサポートされる文字集合に変換され

なければならず,RFC 822 に従って CRLF 区切り子で行を区切らなければならない。ただし,次の段

階で quoted-printable 符号化又は base64 符号化のどちらかを用いるならば,RFC 822 に伴う行の長さの

制限はなくなる。

c)  内容転送符号化の適用  メッセージの本体に適切な Content-Transfer-Encoding(内容転送符号化)を適

用する。メディア型と内容転送符号化との間には固定的な関係はないことに注意する。特に,base64

か quoted-printable の選択の基礎を,本体の与えられたインスタンスに固有の文字頻度数に置くことは

適切であろう。

d)  実体への挿入  符号化された本体は,MIME 実体に適切なヘッダとともに挿入される。それから実体

は,必要に応じてもっと高いレベルの実体(メッセージ又はマルチパート)に挿入される。

実体形式から局所形式への変換は,これらの段階を逆にすることによって達成される。元の形式と最終

的な局所形式とが同じである保証はないので,これらの段階の逆は異なる結果を生成するかもしれないこ

とに注意する。

これらの段階はモデルにすぎないことに注意することは重要である。これらは,実際のシステムがどの

ように構築されるかの青写真では決してない。特にモデルは,次の二つの共通設計を説明できない。

a)  多くの場合,符号化に先立つ正準形式への変換は,局所フォーマットを直接理解できる符号化器その

ものに含まれる。例えば,テキスト本体の局所的な改行の変換は,そのフォーマットが何であるかの

知識に基づいて,符号化器そのものを通して実行されるであろう。

b)  符号化器の出力は,メッセージとして転送される前に,一つ以上の追加の段階を通らなければならな

いかもしれない。したがって,符号化器の出力は,RFC 822 に規定されるフォーマットに適合しない

かもしれない。特に,変換器の出力が,標準的な RFC 822 の CRLF 区切り子を使うのではなく,局所

的な改行変換を使って表現されることが再び適切であるかもしれない。

他の実装上の多様性も同様に考えられる。この議論の重要な点は,要求される段階を崩したり追加処理

を挿入したりする最適化にかかわらず,結果のメッセージはここに示されたモデルによって生成されたも

のと整合していなければならないことである。例えば,次のヘッダファイルをもつメッセージは,始めに

text/foo 形式で表現され,それから必要に応じて,“bar”文字集合によって表現され,最後に base64 アルゴ

リズムによって mail-safe 形式に変換されなければならない。 

Content-type: text/foo; charset=bar

 Content-Transfer-Encoding:

base64

注記 RFC 822 の CRLF 変換と異なる局所的な改行変換を使うフォーマットでメッセージを表現する

システムによって,ある混乱が起きていた。これらのフォーマットが正準な RFC 822/MIME で

はないことに注意することは,重要である。これらのフォーマットは,メッセージの正準表現

における CRLF 列が局所的な改行変換として符号化される,RFC 822 の代理“符号化”である。

例えば,CRLF 行分離列の部分でない LF オクテットを含む binary データを含む MIME メッセ

ージを表現できないことに注意。

5

要約

この規格では,MIME 適合が何を意味するかを定義した。それは,インターネットの電子メールシステ

ムに存在することが知られている様々な問題,及びこれらを克服するために MIME をどのように使うかを



X 5810-5:2008

も詳述した。最後に,MIME の正準符号化モデルを示した。

6

セキュリティへの考慮

セキュリティについては,MIME 関連の第 2 部である JIS X 5810-2 に示されている。


9

X 5810-5:2008

附属書 A

参考)

複雑なマルチパートの例

この附属書は,本体に関連する事柄を補足するものであって,規定の一部ではない。

複雑なマルチパートメッセージの概要を,次に示す。このメッセージは,連続的に表示される五つの部

分,すなわち,二つの導入のプレーンテキストオブジェクト,組み込まれたマルチパートメッセージ,

text/enriched オブジェクト,非 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)が書かれている ...

          [このパートの境界とテキストの開始との間の空白は,

            ヘッダフィールドが与えられなかったことを意味し,

            これは US-ASCII 文字集合でのテキストである。

            次の部分のように,明示的に打ち込むこともできる。]

     --unique-boundary-1

     Content-type: text/plain; charset=US-ASCII


10 
X 5810-5:2008

          これは前の部分の一部とすることもできるが,ここでは

          本体部分の打込みの明示対暗黙の対比として示す。

     --unique-boundary-1

     Content-Type: multipart/parallel; boundary=unique-boundary-2

     --unique-boundary-2

     Content-Type: audio/basic

     Content-Transfer-Encoding: base64

              ...  ここに base64 符号化された,8 000 Hz の

       ... mu-law フォーマットの音声データが置かれる ...

     --unique-boundary-2

     Content-Type: image/jpeg

     Content-Transfer-Encoding: base64

              ...  ここに base64 符号化された画像が置かれる ...

     --unique-boundary-2--

     --unique-boundary-1

     Content-type: text/enriched

     This is<italic>enriched.</italic>であり,

     <smaller>as defined in RFC 1896</smaller>

          (これは RFC 1896 に定義されているとおり,フォーマット付きである。)

     Isn't it

     <bigger><bigger>cool?</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


11

X 5810-5:2008

              ...  ここに ISO-8859-1 での追加のテキストが置かれる ... 

     --unique-boundary-1--


12 
X 5810-5:2008

附属書 B

参考)

RFC 1521, 1522 及び 1590 からの変更点

この附属書は,本体に関連する事柄を補足するものであって,規定の一部ではない。

MIME 関連の JIS X 5810 規格群は,RFC 1521,1522 及び 1590 の改正である。RFC 1521,1522 及び 1590

を熟知している人に便利なように,RFC 1521,1522 及び 1590 からの変更点をこの附属書に要約する。そ

れ以前の履歴に関して,

RFC 1521 がその前の版の RFC 1341 とどのように異なるかを RFC 1521 の Appendix

H が示している。

a) RFC

1521,1522 及び 1590 は完全に再構成され,複数の規格に分割された。これは,参照原稿である

ために必要とされる,RFC 1521,1522 及び 1590 のプレーンテキスト版の品質を高めるために行われ

た。

b) MIME オブジェクトヘッダの全体構成を記述する拡張 BNF が追加された。これは,文書化の変更だけ

で,根本的な構文は変わっていない。

c) MIME の七つのメディア型のための固有の拡張 BNF は削除された。この拡張 BNF は,不正確で,不

完全で,型独立の拡張 BNF と矛盾していた。型独立の拡張 BNF は既に多くの MIME ヘッダの構文を

完全に規定しているので,型固有の拡張 BNF は,結局,完全に不要であり,かえって問題を起こした。

d) RFC

1521,1522 及び 1590 の多くの部分における非公式の用語である ASCII の使用は,もっと固有の

“US-ASCII”という文字集合名に置き換えられた。

e)  主メディア下位型という非公式の概念を削除した。

f)  用語“オブジェクト”は,一貫性なしに用いられていた。この用語の定義は,関連の用語“本体”,

“本

体部分”及び“実体”とともに明確化され,用法は適切に訂正された。

g)  境界マーカに先行する CRLF が,先行する本体部分ではなくマーカそのものの一部であることを明確

にするため,マルチパートメディア型のための拡張 BNF は再整理された。

h)  マルチパートオブジェクト内の本体部分は,境界パラメタ文字列で始まる行を含んではならないこと

を明確にするため,マルチパートメディア型を記述する普通文及び拡張 BNF は変更された。

i) “message/partial”MIME 実体を再組立する規則において,内部メッセージからとるために,ヘッダの一

覧に“Subject”が追加され,この点を明確にするため例が修正された。

j) “message/partial”素片化子は,行境界での MIME オブジェクトの分割だけに制限される。

k) application/postscript 型の議論において,PostScript MIME 実体の中での binary データの組込みによって

引き起こされる可能性のある相互運用可能性の問題についての警告をする追加の段落を加えた。

l)

次の二つの形式を明確にするために,Content-Type ヘッダフィールドのための基本構文規則に対して

明確化の注記を加えた。

   Content-type: text/plain; charset=us-ascii (comment)

   Content-type: text/plain; charset="us-ascii"

これらは,完全に等価である。

m) MIME-Version ヘッダの議論から次の文を削除した “しかし,適合ソフトウェアは,版番号を検査し,

認識できない MIME-Version に遭遇したとき,利用者に少なくとも警告することが推奨される。


13

X 5810-5:2008

n) “message/external-body”ではなく“application/external-body”とした誤植を修正した。

o)  要件を明確にするため,文字集合の定義を再構成した。

p) “image/gif”メディア型の定義は,別文書に移した。この変更は,特許で保護された技術の標準化を管

理する IETF 規則と矛盾が生じる可能性があるため,行われた。

q) “7

bit”及び“8 bit”の定義を厳しくしたので,はだかの CR 及び LF は行終端列として使用されるだけと

した。この規格はまた,NUL 文字を保存することをもはや要求しない。それは,MIME を実世界の実

装と整合させる。

r) MIME における正準テキストの定義を厳しくしたため,行区切りは CRLF 列で表現されなければなら

ない。CR 文字及び LF 文字は,この用法以外には許容されない。それに伴って,quoted-printable 符号

化の定義が変更された。

s) quoted-printable 符号化の定義は,quoted-printable 符号化器が不適切に符号化されたデータをどう扱う

のが最もよいかについて,今では多くの推奨を含む。

t) “8

bit”又は“binary”データにカプセル化するメッセージ実体又はマルチパートで,“7 bit”,“8 bit”及び

“binary”の内容転送符号化の使用を明確にする普通文を加えた。

u) MIME 適合性の箇条において,最小限の MIME 適合性に関する要件の一覧に“multipart/digest”のサポー

トを追加した。“message/rfc822”のサポートのための用件も,再帰構造を認識することの重要性を明確

にするために,強化された。

v) “message”のメディア下位型の様々な制限は,今ではメディア下位型ごとに完全に規定されている。

w) “message/rfc822”の定義は,“From”,“Subject”又は“Date”ヘッダの少なくとも一つが存在しなければな

らないことを示すように変更した。

x)  認識できないメディア下位型の“application/octet-stream”としての必す(須)処理は,型定義の節及び

適合性指針の両方において,もっと明示的に作成された。

y) text/richtext を用いた例は,text/enriched に変更された。

z)  メディア下位型の拡張 BNF 定義は,IANA 登録済みメディア下位型又は非標準の“X-”メディア下位型

のどちらかが Content-Type ヘッダフィールドで使わなければならないことを明らかにするために変更

された。

aa)  使用するために単に登録される MIME メディア型と,IETF によって標準化される MIME メディア型

とは,今では MIME  拡張 BNF において区別される。

ab)  様々な MIME 登録手続のすべてを広範囲に改正した。文字集合に関する IANA 登録手続は,この JIS X 

5810 規格群の規定に含まれない別の規格に移動した。

ac) RFC 1521,1522 及び 1590 が定義している US-ASCII 文字集合及び ISO-8859-X 文字集合におけるエス

ケープ機構及びシフト機構の使用を明確にした。これらの機構は,これらの文字集合,及びそれらの

使用が定義されないときの影響と一緒に用いてはならない。

ad) message/external-body のための AFS アクセス型の定義を削除した。

ae) multipart/alternative と message/external-body との組合せの処理には,今は特に言及していない。

af) message/external-body に固有のセキュリティの課題は,今では細かく示されている。


14 
X 5810-5:2008

附属書 C 

参考)

参考文献

この附属書は,参考文献について記載するものであって,規定の一部ではない。

ATK  Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, Prentice-Hall,

1990

ISO/IEC 646:1991, 3rd ed., Information technology−ISO 7-bit coded character set for information interchange

注記  JIS X 0201:1997  7 ビット及び 8 ビットの情報交換用符号化文字集合 (MOD)

JIS X 0202  情報技術−文字符号の構造及び拡張法

注記  ISO/IEC 2022:1994, 4th ed., Information technology − Character code structure and extension

techniques (IDT)

JPEG  JPEG Draft Standard ISO/IEC 10918-1 CD

MPEG  Video Coding Draft Standard ISO/IEC 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 and Character Sets", RFC 1345, Rationel Almen Planlaegning,

June 1992


15

X 5810-5:2008

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) Part One: Mechanisms

for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,

September, 1993

RFC 1522  Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for

Non-ASCII Text", 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 8-bit-MIME transport", RFC 1652, United Nations University, Innosoft, Dover Beach Consulting,

Inc., Network Management Associates, Inc., The Branch Office, July 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 2048  Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four:

Registration Procedures", RFC 2048, Innosoft, MCI, ISI, 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