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

X 5810-2:2008

(1)

目  次

ページ

序文

1

1  総則

1

1.1  適用範囲

1

1.2  概要

1

1A  引用規格

2

2  最上位メディア型の定義

3

3  初期最上位メディア型の概要

3

4  個別メディア型値

4

4.1  text メディア型

4

4.2  image メディア型

8

4.3  audio メディア型

8

4.4  video メディア型

8

4.5  application メディア型

9

5  複合メディア型値

12

5.1  multipart メディア型

12

5.2  message メディア型

20

6  実験メディア型値

30

7  要約

30

8  セキュリティへの考慮

30

附属書 A(参考)文法一覧

31

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

33

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

35


 
X 5810-2: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-2

:2008

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

第 2 部:メディア型

Multipurpose Internet Mail Extensions (MIME)−Part 2: Media Types

序文

この規格は,

1996 年 11 月に Internet Engineering Task Force (IETF)  から公表された RFC 2046,Multipurpose

Internet Mail Extensions (MIME) Part Two: Media Types を基に,技術的内容及び構成を変更することなく作成

した日本工業規格である。

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

インターネット公式プロトコル規定 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 の規格群の第 2 部であり,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

概要

JIS X 5810 の規格群の最初であって,RFC 2045 を原規定とする JIS X 5810-1 では,Content-Type を含む

多くのフィールドを定義している。Content-Type フィールドは,メディア型及びメディア下位型の識別子



X 5810-2:2008

を与えること並びに特定のメディア型で要求してよい外部情報を提供することによって,MIME 実体の本

体中のデータの性質を指定するために使われる。メディア型名及びメディア下位型名の後のヘッダフィー

ルドの残りは,単純に,属性/値の記法で指定されるパラメタの組である。パラメタの順番は区別しない。

一般的に,最上位メディア型は,データの一般の型を宣言するために使われ,メディア下位型は,その

データの型の特定のフォーマットを指定するために使われる。“image/xyz”というメディア型は,利用者エ

ージェントが“xyz”という特定の画像フォーマットに関して知識をもたない場合でも,そのデータが画像で

あるということを利用者エージェントに知らせるのに十分である。このような情報は,例えば,認識され

ないメディア下位型から生データを利用者に見せるのかどうかを決めるために,使うことができる。この

ような動作は,“text”メディア型の認識されないメディア下位型には妥当であるかもしれないが,“image”

又は“audio”の認識されないメディア下位型には妥当でない。この理由から,“text”,“image”,“audio”及び

“video”の登録されたメディア下位型には,型とは実際に異なる組み込んだ情報を,含まないほうがよい。

このような複合フォーマットは,“multipart”型又は“application”型を使って表現したほうがよい。

パラメタは,メディア下位型の修飾子だから,基本的には内容の性質に影響を与えてはならない。意味

のあるパラメタの組は,メディア型とメディア下位型とに依存する。大部分のパラメタは,単一の特定の

メディア下位型と関連する。しかし,与えられた最上位メディア型は,その型のどのメディア下位型にも

適用可能なパラメタを定義してよい。パラメタは,それらを定義するメディア型又はメディア下位型に対

して,必す(須)であってもよいし,オプションであってもよい。MIME 実装は,認識しないすべてのパ

ラメタ名を,無視しなければならない。

MIME の Content-Type ヘッダフィールド及びメディア型の機構は,拡張性をもつように注意深く設計さ

れていて,

メディア型/メディア下位型の対の組及びそれらに関連するパラメタが,

時間が経つにつれて,

著しく増加していくことが期待される。内容転送符号化及び“message/external-body”アクセス型のような,

多くの他の MIME 機能は,時間が経つにつれて,新しい値をもつことになりそうである。このような値の

組が,順序よく,上手な定義で,公的な方法で,開発されることを確実にするため,MIME は,MIME の

多くの拡張性の領域のための中央の登録簿として Internet Assigned Numbers Authority ( IANA )を使った登

録処理を設定する。これらの領域の登録処理については,RFC 2048 で規定する。

この部の残りの部分では,七つ( text,image,audio,video,application,multipart,message )の標準の初

期の最上位メディア型を定義及び規定する。

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-3  多目的インターネットメール拡張(MIME)−第 3 部:非 ASCII テキストへのメッセージ

ヘッダ拡張

注記 RFC 2047   "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header

Extensions for Non-ASCII Text", November 1996 が,この規格に一致している。

JIS X 5810-5  多目的インターネットメール拡張(MIME)−第 5 部:適合基準


3

X 5810-2:2008

注記 RFC

2049  "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and

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

ISO/IEC 646  Information technology−ISO 7-bit coded character set for information interchange

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

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

2

最上位メディア型の定義

最上位メディア型の定義は,次からなる。

a)  型の名前及び記述。特定の型がその型に認定されるかどうかの基準を含む。

b)  パラメタの名前及び定義。もしあれば,パラメタが必す(須)か又はオプションかを含め,そのパラ

メタがその型のメディア下位型のすべてに対して定義されたものかどうか。

c)  利用者エージェント及び/又はゲートウェイが,この型の未知のメディア下位型をどのように扱うと

よいか。

d)  この最上位の型の実体をゲートウェイするときに一般的に考慮する事項(もしあれば)。

e)  この最上位型の実体のための Content-Transfer-Encodings 上の制限。

3

初期最上位メディア型の概要

五つの個別の最上位メディア型は,次のとおりとする。

a)  text  テキストによる情報。とりわけ,“plain”メディア下位型は,フォーマット命令又はどんな種類の

指示も含まないプレーンテキストを表す。プレーンテキストは“そのまま”で表示されることが想定

される。指示された文字集合がサポートされていれば,テキストの完全な意味を得るために,特別な

ソフトウェアを必要としない。その他のメディア下位型は,アプリケーションソフトウェアがテキス

トの見映えを強調してよい形式の,フォーマット付テキストに使われるが,その場合でも内容の一般

的な理解のためにそのようなソフトウェアが必要になってはならない。したがって,“text”メディア型

のメディア下位型として許されるものは,どのようなワードプロセッサのフォーマットでも,そのフ

ォーマットを理解するソフトウェアに頼らなくても読むことが可能ならば,含むことができる。この

場合,2 進のフォーマット情報を含むようなフォーマットは直接読むことが可能なものとは考えない。

単純で可搬性のあるメディア下位型は,RFC 1341 で定義された“richtext”であり,RFC 1896 では,

“enriched”という名前で改定された。

b)  image  画像データ。“image”は,情報を見るために,画像ディスプレイ,画像プリンタ又はファクス

機器のような表示機器を必要とする。広く使われている画像フォーマットである jpeg と gif とが

“image”のメディア下位型として定義されている。

c)  audio  音声データ“audio”は,内容を提示するために,スピーカ又は電話のような音声出力機器を必要

とする。この規格では,初期の“basic”メディア下位型を定義する。

d)  video  映像データ。“video”は,映像を表示するための能力(概して,特別なハードウェア及びソフト

ウェアを含む。

)を必要とする。この規格では,初期の“mpeg”メディア下位型を定義する。

e)  application  典型的には,説明なしの binary データ又はアプリケーションによって処理される情報。

解釈できない binary データの場合は,“octet-stream”メディア下位型が使われ,この場合の最も単純な

動作は情報をファイルに書き出すことを利用者に提供することである。PostScript のデータを転送する

ために,“PostScript”メディア下位型も定義する。その他に期待される“application”の使用法には,表計



X 5810-2:2008

算,メールを利用したスケジュール管理システムのデータ,

“能動的”

(計算的)メッセージングのた

めの言語,直接は読むことのできないワードプロセッサのフォーマットを含む。幾つかの型のアプリ

ケーションデータ,特に“application/PostScript”及びどんな形式であれ,能動的メッセージには,セキ

ュリティに関する考慮が存在するかもしれないので注意する。これらの論点に関してはこの規格の後

のほうで論じる。

二つの複合の最上位メディア型は次のとおりとする。

f)  multipart  複数の独立なデータ型の実体からなるデータは,次の四つのメディア下位型が初期に定義

される。基本的な“mixed”メディア下位型は,はん(汎)用の混合の部分の組を指定する。“alternative”

は,同じデータを複数のフォーマットで表現する。“parallel”は,部分を同時に見ることを想定する。

“digest”は,それぞれの部分が“message/rfc822”というデフォルトの型をもつマルチパート実体である。

g)  message  カプセル化されたメッセージ(“message”メディア型の本体)は,それ自体で,ある種類の

メッセージオブジェクトの全部又は一部とする。このようなオブジェクトは,更に,他の実体を含ん

でもよいし,

含まなくてもよい。

カプセル化されたメッセージ自体が RFC 822 メッセージである場合,

“rfc822”メディア下位型が使われる。転送機能へ一つのメッセージとして渡すには大きすぎると考えら

れる場合,本体を細分化した転送を許容するため,部分的な RFC 822 メッセージとして,“partial”メ

ディア下位型を定義する。もう一つの“external-body”メディア下位型は,外部のデータ源への参照によ

って,大きい本体を指定するために,定義する。

ここで与えられたメディア型の一覧は,上記の機構によって,時間の経過とともに拡張され,メディア

下位型の組は大いに増えていくことが予期されることを心に留めておいたほうがよい。

4

個別メディア型値

七つの初期のメディア型値のうちの五つは,個別の本体を参照する。これらの型の内容は,MIME 処理

系では処理せず,非 MIME 機構で処理されなければならない。

4.1

text メディア型

“text”メディア型は,通常形式的にテキストのデータを送ることを想定する。特にプレーンテキストのた

めのはん(汎)用メディア下位型である“text/plain”メディア下位型を含め,“text”メディア型のメディア下

位型の本体テキストの文字集合を指示するために,“charset”パラメタを使ってよい。プレーンテキストは,

フォーマット命令,フォント属性指定,処理命令,解釈指示又は内容マーク付けを提供も許容もしない。

プレーンテキストは,行区切り又はページ区切りに割り込まれることはあるが,単純に並んでいる文字の

列に見える。プレーンテキストは,幾つかの文字をテキスト中の同じ位置に積み重ねることを,許してよ

い。アラビア語及びヘブライ語のようなスクリプト中でのプレーンテキストでは,逆筆記方向のテキスト

の区間の任意な混合を許す機能を含めてよい。

プレーンテキスト以上の,

“リッチテキスト”として知られているようなものを表現するために,多くの

フォーマットがある。多くのそのような表現の興味深い特徴は,それらを解釈するソフトウェアがないと

きでさえ,ある程度は読めるということである。そして,画像,音声又は読めない形式で表現されたテキ

ストのような読めないデータと,リッチテキストなどのある程度は読めるデータとを,最上位で区分する

ことは有用である。

4.1.1

行区切りの表現

すべての MIME の“text”メディア下位型の正準形式は,いつでも行区切りを CRLF 列として表さなけれ


5

X 5810-2:2008

ばならない。同様に,MIME の“text”メディア型中の CRLF の発生は,行区切りを表さなければならない。

CR 及び LF を行区切り列以外に使うことも禁止される。

この規則は,フォーマット又は関係する文字集合にかかわらず適用する。

注記 1  本体が表示されるときの,行区切りの正しい解釈は,メディア型に依存する。特に,“text/plain”

本 体 を 表 示 す る と き , 行 区 切 り を 新 し い 行 へ の 移 動 と し て 扱 う こ と は 適 切 だ が ,

“text/enriched”(RFC 1896 を参照)のような“text”メディア型の他のメディア下位型に対して

は,この扱いは,実際に誤りである。同様に,表示操作中,行区切りを加えるのがよいかど

うかも,メディア型によって決まる。“text/plain”を正しく表示するときに行区切りを追加す

る必要はないが,“text/enriched”の正しい表示には適切な行区切りの追加が必要である。

注記 2  幾つかのプロトコルは最大行長を定義する。例えば,SMTP [RFC 821]では,行末の CRLF 列

を除く最大行長を 998 オクテットと定義している。このようなプロトコルによって転送され

るためには,CRLF 列なしに長すぎる区間を含むデータは,適切な Content-Transfer-Encoding

で符号化されなければならない。

4.1.2

charset パラメタ

“text/plain”データのために Content-Type フィールド中に指定されてよい重要なパラメタは,文字集合で

ある。これは“charset”パラメタで,次のように指定される。

Content-type: text/plain; charset=iso-8859-1

その他幾つかのパラメタ値とは違って,charset パラメタの値は,大文字・小文字を区別しない。charset

パラメタがないときに仮定されなければならない,デフォルトの文字集合は,US-ASCII とする。

“text”メディア型の将来のどんなメディア下位型の仕様も,“charset”パラメタも利用するかどうかを規定

しなければならず,更に,場合によってはその値を制限してもよい。“text/plain”以外の“text”メディア型の

メディア下位型では,“charset”パラメタのセマンティクスは,“text/plain”のためにここで指定されたものと

同一となるように定義したほうがよい。すなわち,本体は,すべて,与えられた文字集合内の文字からな

る。特に,将来の“text”メディア型のメディア下位型を定義する者は,メディア下位型の定義における複数

オクテット文字集合のかかわり合いについて,よく注意したほうがよい。

“text”メディア型のメディア下位型の文字集合パラメタは,JIS X 5810-1 で定義される“文字集合”のと

おりに,文字集合の名前を与える。4.1.1 で詳しく規定している行区切りに関する規則も,遵守しなければ

ならない。これらの規則に適合しない定義をもつ文字集合は,MIME の“text”メディア型のメディア下位型

で使うことはできない。

あらかじめ定義された文字集合名の初期の一覧は,この箇条の最後にある。追加の文字集合は IANA に

よって登録してよい。

“text”メディア型のメディア下位型ではない,他のメディア型は,CRLF 又は行区切りの制限を排除して,

ここで定義された charset パラメタを使うことを選んでもよい。したがって,JIS X 5810-1 の“文字集合”

の一般的な定義に適合する,すべての文字集合は,MIME での使用のために登録できる。

もし,指定された文字集合が 8 bit 文字を含み,このような文字が本体に使われたら,Content-Transfer-

Encoding ヘッダフィールド及び対応するデータの符号化が,必要となることに注意する。これは,SMTP

[RFC 821]のような幾つかのメール転送プロトコルを通して本体を転送するためである。

デフォルトの文字集合 US-ASCII は,過去には幾つかの混乱とあいまい性とがあった。定義における幾

つかのあいまい性だけでなく,実践において広い多様性があった。このようなあいまい性及び多様性を将

来なくすため,新しい利用者エージェントは,“Content-Type”ヘッダフィールドのメディア型のパラメタと



X 5810-2:2008

して,明示的に文字集合を指定することを強く推奨する。“US-ASCII”は,任意の 7 bit 文字集合を指すので

なく,

本体中のすべてのオクテットは,

US-ASCII 文字集合に従った文字として解釈されなければならない。

ISO/IEC 646 [ISO/IEC 646]の,国内版及びアプリケーション指向版は,通常は,US-ASCII と同一ではなく,

インターネットメールにおけるそれらの使用は,やめたほうがよいことは明らかである。この規格から

ISO/IEC 646 文字集合を省くことは,慎重に考えられたことである。文字集合名“US-ASCII”は,ANSI

X3.4-1986 [US-ASCII]で定義される文字集合を,明示的に参照する。ISO/IEC 646 の 1991 年版である新し

い国際参照版( IRV )は,US-ASCII と同一である。文字集合名“ASCII”は予約済みであり,どんな目的にも

使ってはならない。

注記 1 RFC

821 は,明示的に“ASCII”を指定していて,米国規格の初期の版を参照している。メディ

ア型及び文字集合を指定する目的の一つが,送信者が解釈される符号化されたメッセージを

どのように意図したかを,受信者があいまい性なく決定することを許すことである限りは,

デフォルトとしての“厳密な ASCII”以外のどんなものも仮定することは,今送信されてい

るメッセージのセマンティクスへの意図しない及び互換性のない変更の危険を起こすであろ

う。US-ASCII 及び 1991 IRV 以外の ISO/IEC 646 の他の版に従って符号化された文字を含む

メッセージ,又は,例えば JIS X 0202 の符号切換え手続は,8 bit 又は複数オクテット文字符

号化と同様,MIME と矛盾しない適切な文字集合指定を使わなければならないことも,示唆

する。

完全な US-ASCII 文字集合は,

ANSI X3.4-1986 に列挙されている。改行を識別する組合せ CRLF(US-ASCII

値の 13 及び 10)以外は,DEL を含む制御文字( 0-31, 127 )に,定義された意味は何もないことに注意する。

次の二つの文字は,広く使われている事実上の意味がある。FF(12)は“続きのテキストは新しいページの

先頭から始める”ことをしばしば意味する。TAB 又は HT(9)は,いつもではないけれども,

“初めのカラム

をカラム 0 と数えて,現在のカラムより後の次の可能な 8 の倍数のカラム番号へカーソルを動かす”こと

を意味する。これらの規約とは別に,本体中での制御文字又は DEL の使用は,次のどちらかで生じる。

a) “plain”以外のメディア下位型が,幾つかの追加の意味を具体的に割り当てる場合。

又は

b)  送信者と受信者との間の私的な合意の状況の場合。このような私的な合意は,やめたほうがよく,こ

の規格で規定する他の機能に置き換えたほうがよい。

注記 2 US-ASCII 以外にも多くの異なった文字集合が存在する。部分的又は全体的に重なる文字集合

がたくさんあることはよいことではない。インターネットメールで,世界中の言語のすべて

を表現できて万国共通に使える,単一の文字集合が好ましい。しかし,多くのコミュニティ

での実在の実践は,近い将来の間は複数の文字集合を使い続けることになるだろう。したが

って,この規格では少数の標準的な文字集合を定義する。

定義する charset 値を次に示す。

c)  US-ASCII  ANSI X3.4-1986 [US-ASCII]で定義される文字集合。 
d)  ISO-8859-X  “X”の部分は,ISO/IEC 8859 規格群の各部の番号で置換することが必要である。ISO/IEC 

646 文字集合群を,意図的に,定義する charset 値から省いていることを注記しておく。これはインタ

ーネットメールでの指定は,ISO/IEC 646 文字集合群ではなく,それらの ISO/IEC 8859 規格群の置換

のほうだからである。この規格の原規定の RFC 2046 が公表された時点では,“X”の値として数字の 1

から 10 が合法である。

128-159 の範囲の文字は,ISO-8859-X では,指定された意味をもたない。ISO-8859-X の 128 より小さい


7

X 5810-2:2008

値の文字は,US-ASCII と同じ指定された意味をもつ。

ISO/IEC 8859 規格群の第 6 部(ラテンアルファベット及びアラビアアルファベット)及び第 8 部(ラテ

ンアルファベット及びヘブライアルファベット)は,左から右への普通の筆記方向の文字及び右から左へ

の反対の筆記方向の文字を両方含むが,双方向テキストを表現するための正準的な順序付け方法は定義し

ていない。しかし,“ISO-8859-6”及び“ISO-8859-8”の charset 値は,視覚的な方法が使われることを指定す

る [RFC 1556]。

これらすべての文字集合は,シフト機能又はエスケープ機能なしの,純粋な 7 bit 又は 8 bit 集合として

使う。これら文字集合のシフト及びエスケープシーケンスの意味は定義しない。

上記で規定された文字集合は,MIME の原案作成中比較的議論を呼ばないものであった。この規格は,

US-ASCII 以外の特定のどんな文字集合の使用も支持せず,国際的な文字集合の将来の進化が不明確なまま

であることを認識する。

US-ASCII 以外の文字集合を使用する場合は必ず Content-Type フィールドに明示的に指定されなければ

ならないことに注意する。

上記で定義されていないどんな文字集合名も,公式の仕様の出版及び IANA での登録,又は,私的な合

意によるものでなければならない。私的な合意によって使う場合は,“X-”で始まらなければならない。

注記 3  日本語環境における MIME の使用

この規格では,初期 charset 値として US-ASCII 及び ISO-8859-X [

“X”の部分は ISO/IEC 8859

規格群の各部の番号]だけを定義している。それ以外の文字集合については,RFC 2278 で規定

される登録手続を経たものは,IANA (Internet Assigned Numbers Authority)の登録簿に登録されて

いる。この登録簿は,次のアドレスから入手できる。

http://www.iana.org/assignments/character-sets

日本語を含む charset 値の主なものとして,次のような文字集合が登録されている。

a)  Shift_JIS[現在多くのパソコン上で日本語を表すために使われている文字コード(符号化方

式)である。

b)  EUC-JP(UNIX 上で日本語の文字を扱う場合に最も多く利用されている符号化方式の一つで

ある。

c)  iso-2022-jp[インターネット上(特に電子メール)などで使われる日本の文字用の符号化方

式。JIS X 0202 のエスケープシーケンスを利用して文字集合を切り替える 7 ビットのコード

であることを特徴とする。

d)  UTF-8(Unicode 又は ISO/IEC 10646 の符号化文字集合を符号化する方式の一つ。ASCII の文

字は 1 オクテット,

その他の文字は 2∼6 オクテットで符号化する。

ASCII との互換性は高い。

漢字は 3 オクテット以上で符号化される。

実装者は,絶対的に必要な場合を除き,新しい文字集合を定義しないほうがよい。

“charset”パラメタは,主としてテキストデータのために定義されていて,そのために,この箇条に記述

されている。しかし,何らかの目的で,同じ構文及び値が使われるほうがよいときには,非テキストデー

タでも charset 値を指定したい場合が考えられる。

一般的にいって,文書作成ソフトウェアは,可能な限りいつも“一番小さい共通の”文字集合を使用す

るのがよい。例えば,本体が US-ASCII 文字だけを含む場合,すべての ISO/IEC 8859 規格群と同様に

US-ASCII のスーパセットである ISO-8859-1 とするのではなく,US-ASCII 文字集合として,マーク付けす

るのがよい。もっと一般的にいえば,広く使われている文字集合がもう一つの広く使われている文字集合



X 5810-2:2008

のサブセットであった場合,本体が広く使われているサブセットの文字だけを含むならば,それはサブセ

ットが使われているとラベル付けするのがよい。これは,受信者が結果の実体を正しく見ることができる

機会を,増やすことになる。

4.1.3

plain メディア下位型

最も単純で最も重要な“text”メディア型のメディア下位型は“plain”である。これは,フォーマット命令又

はフォーマット指示を含まない,プレーンテキストを示す。プレーンテキストは,

“そのまま”表示される

ことが意図される。すなわち,適正な表示のために,組み込まれたフォーマット命令,フォント属性指定,

処理命令,解釈指示又は内容マーク付けの解釈を必要としないほうがよい。インターネットメールのため

のデフォルトのメディア型“text/plain; charset=us-ascii”は,既存のインターネット実践を記述する。すなわ

ち,これは RFC 822 で定義される本体の型である。

他の“text”メディア型のメディア下位型は,この規格では,定義されない。

4.1.4

認識されないメディア下位型

“text”メディア型の認識されないメディア下位型は,MIME 実装が charset をどう処理するかを知ってい

る限りは,“plain”メディア下位型として扱うのがよい。認識できないメディア下位型であって,指定して

いる charset も認識できないものは,“application/octet-stream”として扱うのがよい。

4.2

image メディア型

“image”メディア型は,本体が画像を含むことを指示する。メディア下位型は,特定の画像フォーマット

を,名前付けする。これらの名前は,大文字・小文字を区別しない。初期のメディア下位型は,JFIF 符号

化[JPEG]を使った JPEG フォーマットのための,“jpeg”とする。

“image”のメディア下位型の一覧は,排他的でもすべてでもなく,ここで与えられ,これ以上の型は,RFC

2048 に記述されているとおりに,IANA で登録されて,増えていくことが期待される。

“image”の認識されないメディア下位型は,少なくとも“application/octet-stream”として扱うのがよい。実

装は,安全で頑健なはん(汎)用画像表示アプリケーションが利用可能ならば,オプションで“image”のメ

ディア下位型をアプリケーションに渡してもよい。

注記  このようにしてはん(汎)用画像表示アプリケーションは,アプリケーションでサポートする

最も危険なセキュリティ上の問題を受け継ぐ。

4.3

audio メディア型

“audio”メディア型は,本体が音声データを含むことを示す。計算機で使う理想的な音声のフォーマット

については,いまだに合意が得られていないが,相互運用可能な振る舞いを供給することのできるフォー

マットの強い必要性はある。

初期の“basic”メディア下位型は,絶対的に一番小さい共通の音声フォーマットを提供することによって,

この要求に答えるために規定された。より高品質及び/又はより狭帯域音声のためのより高度なフォーマ

ットは,今後の文書で定義されることが期待される。

“audio/basic”メディア下位型の内容は,標本化周波数 8 000 Hz で,8 bit の ISDN の  µ 則[PCM]によって

符号化された,単一チャネル音声とする。

“audio”の認識されないメディア下位型は,最低でも,“application/octet-stream”として扱うのがよい。実

装は,オプションで,明確には認識しない“audio”のメディア下位型を,頑健な一般用途音声再生アプリケ

ーションへ,そのようなアプリケーションが利用可能であれば,渡してよい。

4.4

video メディア型

“video”メディア型は,本体が,時間につれて変動する画像を含むことを示す。用語“video”は,特定の技


9

X 5810-2:2008

術及びフォーマットへの参照ではなく,最も一般的な感覚で使われ,それは小さく符号化されるアニメー

ションの描画のようなメディア下位型を排除することを意味しない。“mpeg”メディア下位型は MPEG 標準

に従って符号化された映像を参照する。

この規格では,一般的には単一の本体に複数のメディアを混ぜることを強く非推奨とするが,多くのい

わゆる映像フォーマットが同期した音声の表現を含むことが認識され,これは“video”のメディア下位型と

して明確に許される。

“video”の認識されないメディア下位型は,少なくとも,“application/octet-stream”として扱うのがよい。

実装は,オプションで,明確には認識しない“video”のメディア下位型を,頑健な一般用途映像再生アプリ

ケーションへ,そのようなアプリケーションが利用可能であれば,渡してよい。

4.5

application メディア型

“application”メディア型は,他の種別には合致しない個別データ,特に幾つかの型のアプリケーションプ

ログラムによって処理されるデータのために使われる。これは,利用者によって見えるようになる前に又

は使えるようになる前に,アプリケーションによって処理されなければならない情報とする。“application”

メディア型の想定される使われ方は,ファイル転送,表計算,メールによるスケジュール管理システムの

データ,“能動的”(計算的)内容の言語を含む。最後のものは,実装者によって理解されなければならな

いセキュリティ上の問題を起こし得,“application/PostScript”メディア型の議論で深く考える。

例えば,会議スケジューラソフトウェアは,提案の会議日程についての情報の標準的な表現を,定義す

るかもしれない。知的な利用者エージェントは,利用者に対話形式で案内するために,この情報を使うか

もしれないし,この対話に基づき追加のデータを送るかもしれない。もっと一般的には,適切に特化した

言語によるプログラムが遠隔地に転送され,受信者の環境上で自動的に実行される,多くの“能動的”メ

ッセージング言語が開発されている。

このようなアプリケーションは,“application”メディア型のメディア下位型として定義されてよい。この

規格では二つのメディア下位型,octet-stream 及び PostScript を定義する。

“application”のメディア下位型は,データを想定する,アプリケーションの名前であるか又は名前の一部

を含むことが多い。しかし,このことは,“application”のメディア下位型として,任意のアプリケーション

プログラムの名前を使ってよいことは,意味しない。

4.5.1

octet-stream メディア下位型

“octet-stream”メディア下位型は,本体が任意の binary データを含むことを示すのに使う。現在定義され

ているパラメタの組は,次の二つである。

a)  TYPE  binary データの一般的な型又は分類。これは,何らかの自動処理のためではなく,人間の受信

者のための情報として意図される。

b)  PADDING  含まれた 8 bit バイト指向のデータを作るために実際の内容を構成するビットストリーム

に付加されたパディングのビット数。これは,ビットの総数が 8 の倍数でないときに,本体中にビッ

トストリームを入れるのに有用である。

これらのいずれのパラメタもオプションとする。

追加のパラメタ“CONVERSIONS”が RFC 1341 で定義されたが,その後削除された。RFC 1341 は,デー

タをファイルに書き込むときに使われる,推奨されるファイル名のために“NAME”パラメタを使うことも

定義している。これは,後続する RFC で定義される,別の“Content-Disposition”ヘッダフィールドを見越し

て,非推奨とした。

“application/octet-stream”実体を受け取ったときに,実装の推奨される動作は,Content-Transfer-Encoding


10 
X 5810-2:2008

を解除して,単純にデータをファイルに書き出すか,又は,多分利用者が指定した処理への入力として使

うことである。

悪意のあるプログラムを転送する危険をなくすために,実装は,次のような経路探索機構を使用しない

ことを強く推奨する。非推奨の経路探索機構とは,プログラム名が Content-Type パラメタ(例えば,

“interpreter=”パラメタ)で指定されていたとき,常にそのプログラムを探索し,発見すればメッセージ本

体を入力として使ってそのプログラムを実行するものである。

4.5.2

PostScript メディア下位型

“application/postscript”メディア型は,PostScript のプログラムを示す。現在,PostScript 言語の二つの種類

が許容される。オリジナルのレベル 1 は[POSTSCRIPT]に記述され,より新しいレベル 2 は[POSTSCRIPT2]

に記述されている。

PostScript は Adobe Systems Inc.の登録商標である。MIME“application/postscript”メディア型の使用は,登

録商標及びそれに伴う一切の権利を認識することを暗示する。

PostScript 言語定義は,与えられたプログラムが使用する,特定の言語の内部的なラベル付けのための機

能を,提供する。この PostScript 文書構造化規約又は DSC( document structuring conventions )と呼ばれるラ

ベル付けは,とても一般的であって,言語レベルだけでない十分に多くの情報を提供する。文書構造化規

約の使用は,要求はされないが,相互運用性のための補助として,強く推奨される。適格な構造化規約を

欠いた文書は,与えられた環境で動作するかどうかを見るための検証ができない。そのことを考慮して,

幾つかのシステムは,最悪を想定し,構造化されていない文書を処理することを拒否することがある。

一般用途の PostScript インタプリタの実行は,深刻なセキュリティ上の危険を伴い,実装者は,単純に

“できあいの”インタプリタに PostScript の本体を送ることは,しないほうがよい。典型的なプリンタ環

境では害を与える可能性が大いに制限されていて,通常は PostScript をプリンタに送ることは安全だが,

実装者は,PostScript 本体の対話的表示を MIME 解読器に追加する前に,次のすべてを考慮したほうがよ

い。

この箇条の残りでは,多分すべてではないけれども,PostScript 実体の転送に伴う,可能性のある問題に

ついての概要を示す。

a) PostScript 言語の危険な操作は,PostScript オペレータ“deletefile”,“renamefile”,“filenameforall”及び“file”

を含むが,これだけとは限らない。“file”は,標準入力又は標準出力以外の何かに適用するときだけ,

危険である。実装は,追加の非標準のファイルオペレータを定義するかもしれず,それらはセキュリ

ティ上の脅威を与えるかもしれない。ワイルドカードファイル検索オペレータの“filenameforall”は,

一見したところでは,無害に見えるかもしれない。しかし,このオペレータは,受信者が,どのファ

イルにアクセスしているかについての情報を暴露する可能性があり,この情報自体が要注意なもので

ある。セキュリティを考慮した PostScript 実装では,危険な可能性があるファイルオペレータを使え

ないであろうから,メッセージの送信者は,これらのオペレータを避けたほうがよい。メッセージを

受信及び表示するソフトウェアは,すべての危険な可能性のあるファイルオペレータを完全に無効に

するか,又はこれらのオペレータの作用に特別な信頼を与えないように,特別の注意をするほうがよ

い。PostScript 文書を解釈するとき,これらのオペレータは,外部で代理実行するものと考えたほうが

よい。このような無効化及び/又は検証は,PostScript 言語自体の及ぶ範囲の外側で,完全に行ったほ

うがよい。これらのオペレータの完全機能版を再有効化するための方法が存在しないことを保証する

ように,特別な注意を払ったほうがよい。

b) PostScript 言語は,通常のインタプリタ又はサーバのループから抜け出す機能を提供している。ループ


11

X 5810-2:2008

を抜け出して“外部の”環境でなされる変更は,通常,文書間でも保存され,場合によっては半永久

的に不揮発性メモリに保持されるかもしれない。インタプリタのループから抜け出すことに関連する

オペレータは,後続の文書処理に干渉する可能性がある。このようにして,これらの抑制されない使

用は,サービス拒絶の脅威の構成要素となる。インタプリタのループを抜け出す PostScript オペレー

タとして,“exitserver”及び“startjob”オペレータがある(これだけには限らない)

。セキュリティを考慮

した PostScript 実装では,インタプリタのループを抜け出す能力は多分利用不可能だから,メッセー

ジ送信ソフトウェアは,

動作するのにインタプリタのループを抜け出すことに依存する PostScript は,

生成しないほうがよい。メッセージを受信し表示するソフトウェアは,“startjob”オペレータ又は

“exitserver”オペレータを排除するか又は無効にすることによって,PostScript 環境へ保持される変更を

行える能力を,完全に無効にしたほうがよい。もし,これらの操作が,排除されるか完全に無効にで

きない場合,少なくとも,これらに関連する想像されにくいパスワード値を設定したほうがよい。

c) PostScript は,システム全体及び機器特有のパラメタを設定するオペレータを提供する。これらのパラ

メタ設定は,ジョブ間で保持されるかもしれず,インタプリタの正しい処理への脅威となる可能性が

ある。システムパラメタ及び機器パラメタを設定する PostScript オペレータは,“setsystemparams”オペ

レータ及び“setdevparams”オペレータである(これらだけには限らない)。メッセージ送信ソフトウェ

アは,正しく動作するためにシステムパラメタ及び機器パラメタを設定することに依存する PostScript

を生成しないほうがよい。これらのパラメタを設定する機能は,セキュリティを考慮した PostScript

実装では,多分利用不可であろう。もし,これらの操作が,排除されるか完全に無効にできない場合,

少なくとも,これらに関連する想像されにくいパスワード値を設定したほうがよい。

d)  幾つかの PostScript 実装は,機械語を直接ロードし実行する,非標準の機能を提供する。このような

機能は,明らかに悪用されやすい。メッセージ送信ソフトウェアは,このような機能の使用を生成し

ないほうがよい。完全にハードウェア固有であるほか,これらも,PostScript のセキュリティを考慮し

た実装では,おそらく使用不可である。メッセージを受信し表示するソフトウェアは,このようなオ

ペレータが存在する場合,それらを使用することを許さないほうがよい。

e) PostScript は拡張性のある言語であって,ほとんどというほどではないにしろその多くの実装は,たく

さんの固有の拡張を提供する。この規格は,このような拡張については,未知の要素を構成するので,

明示的には論じない。メッセージ送信ソフトウェアは,非標準拡張の使用を生成しないほうがよい。

メッセージを受信し表示するソフトウェアは,どの非標準の PostScript オペレータもセキュリティを

考慮されて,どんな種類の脅威も呈さないことを,確認したほうがよい。

f)  幾つものシステム資源を大量に消費する PostScript を書くことができる。無限に繰り返す PostScript を

書くこともできる。いずれのタイプのプログラムも,疑うことのない受信者に送られたならば,障害

を引き起こす可能性がある。メッセージ送信ソフトウェアは,このような反社会的なプログラムの組

立又は拡散を避けたほうがよい。メッセージを受信し表示するソフトウェアは,ある程度の時間が経

過したら,処理を中断する適切な機構を提供したほうがよい。さらに,PostScript インタプリタは,与

えられたシステム資源のある程度の量だけを消費するように制限したほうがよい。

g)  幾つもの形式で PostScript の中に binary の情報を含むことができる。これは,すべての PostScript イン

タプリタでサポートされていないという理由及び MIME Content-Transfer-Encoding の使用を著しく複

雑にするという理由で,インターネットメールでの使用は推奨されない。このような binary 情報がな

ければ,PostScript は,典型的には,行指向データとして見られてよい。binary 及び行指向データが単

一の PostScript データストリームに混ざっていた場合,CRLF 列の振る舞いは非常に問題となる。


12 
X 5810-2:2008

h)  最後に,幾つかの PostScript インタプリタには,受信者のシステムへの認証されないアクセスを得る

ことができるかもしれない,不具合が存在するかもしれない。この可能性とは別に,このような不具

合が発見された場合に,タイムリーに修正することのほかには,これを防ぐためにとる特定の措置は

ない。

4.5.3

その他の application のメディア下位型

将来には,多くの他の“application”のメディア下位型が定義されることが期待される。MIME 実装は,最

低限,認識されないメディア下位型を“application/octet-stream”として取り扱わなければならない。

5

複合メディア型値

七つの初期の Content-Type 値のうち,残る二つは,複合の実体を参照する。複合の実体は,MIME 機構

を使って扱われる。すなわち,典型的には,MIME 処理系が本体を直接扱う。

5.1

multipart メディア型

単一の本体の中に一つ以上の異なるデータの組が結合されるマルチパート実体の場合,実体のヘッダの

中に“multipart”メディア型フィールドが現れなければならない。本体は,一つ以上の本体部分を含まなけ

ればならず,それぞれの部分は境界区切り子行が先行し,最後の部分に終了境界区切り子行が後続してい

る。境界区切り子行の後,それぞれの本体部分は,ヘッダ領域,空白行及び本体領域からなる。そのため,

本体部分は,構文上は RFC 822 メッセージに似ているが,意味は異なる。

本体部分は実体だから,実際に RFC 822 メッセージであるとは,解釈されない。最初に,本体部分には,

ヘッダフィールドは実際には要求されない。したがって,空白行で始まる本体部分は許され,それはすべ

てのデフォルト値が仮定される本体部分になる。このような場合,Content-Type ヘッダフィールドがない

ことは,通常,対応する本体が“text/plain; charset=US-ASCII”の content-type をもつことを示す。

本体部分のために意味を定義したヘッダフィールドは,“Content-”で始まる名前をもつものだけとする。

本体部分中,その他のすべてのフィールドは,無視してよい。それらは,一般的にいって,可能ならば残

しておいたほうがよいが,必要であればゲートウェイによって廃棄されてよい。このような他のフィール

ドは,本体部分に現れることを許すが,依存されてはいけない。“X-”フィールドは,それが含む情報が幾

つかのゲートウェイで失われるかもしれないことを認識の上で,実験目的又は私的目的のために,作成さ

れてもよい。

注記 RFC 822 メッセージと本体部分との区別は付けにくいが,重要である。例えば,インターネッ

トと X.400 メールとのゲートウェイは,画像を含む本体部分と,本体が JPEG 画像であるカプ

セル化されたメッセージを含む本体部分との違いを分からなければならない。後者を表現する

ためには,本体部分は,“Content-Type: message/rfc822”をもたなければならず,空白行の後の本

体は,それ自体が“Content-Type: image/jpeg”ヘッダフィールドをもつカプセル化されたメッセー

ジでなければならない。同様な構文の使用は,本体部分へのメッセージの変換及びその逆変換

を促進するが,その二つの区別を,実装者は理解しなければならない。部分が実際のメッセー

ジである特別な場合のために,“digest”メディア下位型も定義される。

前に宣言したように,それぞれの本体部分は,

境界区切り子を含む境界区切り子行によって先行される。

境界区切り子は,カプセル化された部分,それ自体の行,又はどの行の接頭辞としても,現れてはならな

い。このことは,作成エージェントが,囲まれたマルチパートに境界パラメタ値を接頭辞として含まない,

一意の境界パラメタ値を選んで指定できることが重要であることを示唆する。

すべての現在及び将来の“multipart”型のメディア下位型は,同一の構文を使わなければならない。メデ


13

X 5810-2:2008

ィア下位型は,それらのセマンティクスで異なってよく,構文上追加の制限を課してもよいが,“multipart”

型で要求された構文に適合していなければならない。この要求は,すべての適合した利用者エージェント

が,認識しないメディア下位型であっても,少なくともマルチパート実体の部分を認識し分割できるよう

にすることを保証する。

Content-Transfer-Encoding フィールド[JIS X 5810-1]の定義の中で宣言したとおり,“7 bit”,“8 bit”又は

“binary”以外の符号化は,“multipart”型の実体として,許されない。“multipart”境界区切り子及びヘッダフ

ィールドは,JIS X 5810-3 による非 US-ASCII ヘッダテキストとして符号化してもよいが,どんな場合もい

つも,7 bit US-ASCII として表現され,本体部分中のデータは,それぞれの適切な本体部分のための

Content-Transfer-Encoding フィールドで,部分ごとに符号化することができる。

5.1.1

共通構文

この箇条では,“multipart”のメディア下位型のための共通構文を定義する。すべての“multipart”のメディ

ア下位型は,この構文を使わなければならない。マルチパートメッセージの単純な例も,この箇条で示す。

もっと複雑なマルチパートメッセージの例は,RFC 2049 を原規定とする JIS X 5810-5 で与えられる。

マルチパート実体のための Content-Type フィールドは,一つのパラメタ“boundary”を要求する。境界区

切り子行は,二つのハイフン文字(“-”,10 進値の 45)に後続して Content-Type ヘッダフィールドからの

境界パラメタ値があり,オプションで線形空白があり,終わりの CRLF で構成される行として,定義され

る。

注記 1  ハイフンは,以前のメッセージをカプセル化する RFC 934 の方法との大まかな互換性のため,

及び,幾つかの実装で検索を容易にするためである。しかし,マルチパートメッセージは,

RFC 934 のカプセル化とは,完全には互換性がないこと,特に,ハイフンで始まる埋込み行

のための RFC 934 引用規約には従っていないことに注意したほうがよい。後者は,それぞれ

の引用のレベルで行の成長を引き起こすから,RFC 934 の上にこの機構が選ばれた。SMTP

実装は時々長い行を折り返すという事実,及び行の成長があることを考え合わせると,RFC

934 の機構を深い入れ子のマルチパート構造付けがあるイベントに使用することを不適切に

している。

実装者への警告

Content-Type フィールドのパラメタのための文法は,Content-type 行上の引用で,境界パラメタ

値を囲うのにしばしば必要となる。囲うことはいつも必要というわけではないが,必要でない

ときに囲っても支障はない。実装者は,不正な Content-type フィールドが生成されないように,

注意深く文法を学習したほうがよい。ゆえに,典型的な“multipart” Content-Type ヘッダフィー

ルドは,次のようにするとよい。

 Content-Type:

multipart/mixed;

boundary=gc0p4Jq0M2Yt08j34c0p

しかし,次は,正しくない。

 Content-Type:

multipart/mixed;

boundary=gc0pJq0M:08jU534c0p

なぜならばコロン(:)があるからであり,代わりに,次のように表さなければならない。

 Content-Type:

multipart/mixed;

boundary="gc0pJq0M:08jU534c0p"

この Content-Type 値は,内容が一つ以上の部分からなり,それぞれは,ヘッダ領域が完全に空であるこ

とを許すこと及びそれぞれの部分が次に示す行に先行されること以外は,RFC 822 メッセージと構文上,

同一の構造とする。


14 
X 5810-2:2008

 --gc0pJq0M:08jU534c0p

境界区切り子は,行の先頭,すなわち,CRLF の直後になければならず,最初の CRLF は,先行する部

分の一部ではなく,境界区切り行に付けられたものと考える。境界は,0 文字以上の線形空白に後続され

てよく,別の CRLF 及び次の部分のヘッダフィールドか又は二つの CRLF(この場合,次の部分にヘッダ

フィールドがない。

)のどちらかで終了する。Content-Type フィールドがない場合,“multipart/digest”中の

“message/rfc822”,そうでない場合は,“text/plain”とみなす。

注記 2  境界区切り行に先行する CRLF は,概念的に境界に付いているので,CRLF(改行)で終わら

ない部分をもつことができる。したがって,改行で終わることが想定されなければならない

本体部分は,境界区切り行に先行する二つの CRLF をもたなければならず,1 番目は先行す

る本体部分のもの,2 番目はカプセル化した境界の部分のものである。

境界区切り子は,カプセル化されたデータ中に現れてはならず,二つの先行するハイフンを含まずに,

70 文字より長くてはならない。

最後の本体部分に続く境界区切り子行は,それ以上本体部分が続かないことを示す,区別された区切り

子とする。このような境界行は,それ以前の区切り行と同一のものに,境界パラメタ値の後ろに二つのハ

イフンを加えたものとする。

 --gc0pJq0M:08jU534c0p--

実装者への注記

境界文字列の比較は,それぞれの候補行の始めから境界値を比較しなければならない。候補行

全体の完全な一致は要求されない。CRLF に後続して境界が完全に現れるだけで十分とする。

一番目の境界区切り行の前及び最後の境界区切り行の後に,追加の情報のための場所がある。これらの

領域は,一般的には,空白のままであり,実装者は,一番目の境界区切り行の前及び最後の境界区切り行

の後に現れるどんなものも無視しなければならない。

注記 3  これらの“まえがき”及び“あとがき”の領域は,これらの部分の適切な型付けがないこと

及びゲートウェイ,特に X.400 ゲートウェイにおいてこれらの領域をどう処理するか明確な

セマンティクスがないことから,一般的には使われない。しかし,まえがき領域を空白のま

まにしておくのではなく,MIME 適合のソフトウェアでは無視されるので,多くの MIME 実

装は,MIME 以前のソフトウェアでメッセージを読む受信者に,説明的な注記を挿入する便

利な場所であることが分かる。

注記 4  境界区切り子は,カプセル化された本体部分中には現れてはならないから,利用者エージェ

ントは,一意の境界パラメタ値を注意して選ばなければならない。上記の例で境界パラメタ

値は,データをプレスキャンすることもなくカプセル化されたデータ中に既に存在する可能

性の非常に低い境界区切り子を生成するように設計されたアルゴリズムの結果であり得た。

代替のアルゴリズムは,古い利用者エージェントでの受信者に,もっと“読みやすい”境界

区切り子をもたらし得るが,境界区切り子が組み込まれた部分の,ある行の先頭に現れる可

能性があることに,特に注意する必要がある。最も簡単な境界区切り子行は,“---”のような

ものであり,それの終了の区切り子行は“-----”のようなものである。

とても簡単な例として,次のマルチパートメッセージは二つの部分をもち,両方ともプレーンテキスト

で,一つは明示的に型付けされ,もう一つは暗黙的に型付けされる。

From: Nathaniel Borenstein

To: Ned Freed


15

X 5810-2:2008

Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)

 Subject:

Sample

message

 MIME-Version:

1.0

Content-type: multipart/mixed; boundary="simple boundary"

これはまえがきである。これは作成エージェントが非 MIME 適合リーダへの

説明的注記を含めるための手軽な場所であるが,これは無視される。

 --simple

boundary

この部分に書かれたテキストは暗黙的にプレーン US-ASCII テキストに型付けされる。

この部分に書かれたテキストは行区切りでは終わらない。

 --simple

boundary

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

この部分に書かれたテキストは明示的にプレーン US-ASCII テキストに型付けされる。

この部分に書かれたテキストは行区切りで終わる。

 --simple

boundary--

これはあとがきである。これも無視される。

別の“multipart”実体中の本体部分の中に“multipart”メディア型を使用することは,明示的に許可される。

このような場合,明白な理由で,それぞれの入れ子になった“multipart”実体は異なる境界区切り子を使う

ことを保証するように,注意を払わなければならない。入れ子の“multipart”実体の例は,JIS X 5810-5 を参

照するとよい。

“multipart”メディア型を単一の本体部分だけで使用することは,ある文脈には便利である場合もあり,

明示的に許される。

注記 5 “multipart”メディア型を単一の本体部分で使用することは,非テキストメディア型を送るの

に便利であることを経験が示している。それは,復号の指示を含める場所としてのまえがき

を提供する利点をもつ。さらに,多くの SMTP ゲートウェイは,MIME ヘッダを動かすか又

は取り除き,そして,賢い MIME 復号器は,Content-Type ヘッダがない場合でもマルチパー

ト境界でよい予測をすることができ,そのためメッセージをうまく復号する。

“multipart”メディア型の唯一の必す(須)の大域パラメタは,境界パラメタとし,境界パラメタは,メ

ールゲートウェイを通して非常に耐性のあるものとして知られる文字の組からの,

1 から 70 文字からなり,

空白で終わってはならない。もし,境界区切り子行が空白で終わっている場合,その空白はゲートウェイ

によって加えられたものとみなされ,削除されなければならない。次の拡張 BNF によって,これを形式定

義する。

boundary := 0*69<bchars> bcharsnospace


16 
X 5810-2:2008

bchars := bcharsnospace / " "

bcharsnospace := DIGIT / ALPHA / "’" / "(" / ")" /

"+" / "_" / "," / "-" / "." /

"/" / ":" / "=" / "?"

全般的に,“multipart”実体の本体は,次のように規定してよい。

dash-boundary := "--" boundary

   ;

Content-Type フィールドの境界

   ;

値からとられた境界

   ;

multipart-body := [preamble CRLF]

dash-boundary transport-padding CRLF

   body-part

*encapsulation

   close-delimiter

transport-padding

   [CRLF

epilogue]

 transport-padding

:=

*LWSP-char

   ;

作成者は長さゼロでないトランスポートパディングを

   ;

生成してはならないが,

   ;

受信者はメッセージトランスポートによって

   ;

加えられたパディングを処理できなければならない。

encapsulation := delimiter transport-padding

   CRLF

body-part

delimiter := CRLF dash-boundary

close-delimiter := delimiter "--"

preamble := discard-text

 epilogue

:=

discard-text

discard-text := *(*text CRLF) *text

   ;

無視又は削除されてよい。


17

X 5810-2:2008

body-part := MIME-part-headers [CRLF *OCTET]

   ;

本体部分の行は指定されたダッシュ境界で

   ;

始まってはならず,区切り子は本体部分の

   ;

どこにも現れてはならない。

   ;

文中に記述されているとおり,本体部分の

   ;

セマンティクスは,メッセージの

   ;

セマンティクスと異なる。

   ;

OCTET := <0 から 255 の任意のオクテット値>

注記 6  この拡張 BNF は構造化されたヘッダフィールドを規定しないから,この拡張 BNF に示され

る要素間の線形空白及び RFC 822 コメントの自由な挿入は許されない。

注記 7  特定のトランスポートの領域では,印字可能 US-ASCII 文字に本体を制限することなど RFC

822 の制限が有効でないかもしれない。すなわち,トランスポート領域は,RFC 821 で規定

される標準的なインターネットメールトランスポートに似ていて RFC 822 を想定しているが,

特定の制限がないものが存在するかもしれない。これらの制限の緩和は,これらの拡張がト

ランスポートによってサポートされて Content-Transfer-Encoding ヘッダフィールド中で適切

に文書化されている限りは,局所的に拡張した本体の定義と解釈したほうがよい。しかし,

メッセージヘッダ又は本体部分ヘッダのどちらかでも,US-ASCII 文字以外を含むことは許さ

れない。

注記 8  構造化され,関連する本体部分の概念が,“multipart”型では明白に欠落している。より構造

化され統合化されたマルチパートメッセージング機能を提供したい場合は,構文的には同一

だが,多くの部分間での関連を定義するマルチパートのメディア下位型を定義することが推

奨される。例えば,他の部分との関連を指定するのに使われ,多分それらの Content-ID フィ

ールドを参照する,個別の部分を含む,マルチパートのメディア下位型を定義できる。この

方法が使われる場合,古い実装は新しいメディア下位型を認識しないが,multipart/mixed と

して扱われ,そのため利用者に認識される部分を見せることができる。

5.1.2

入れ子となったメッセージ及びマルチパートの処理

この規格の後続の箇条で定義される“message/rfc822”メディア下位型は,データが尽きること以外に,終

了する条件をもたない。同様に,不正に切られた“multipart”実体が,終了境界のマーカをもたないために,

メールシステムの誤作動を引き起こし,運用を止めることがあり得る。

別の構造の中に埋め込まれる場合,このような実体が正しく処理されることは,本質的である。そのた

め,MIME 実装には,内側の入れ子のすべてのレベルにおいて,そのレベルの境界だけではなく,より外

側のレベルの境界も認識できることが,要求される。次の期待されるマーカを検査する又は他の終了状態

を検査するだけでは十分でない。

5.1.3

mixed メディア下位型

“multipart”の“mixed”メディア下位型は,本体部分が独立であり,特定の順番に束ねられることが必要な

場合での使用が意図されている。実装が認識しない“multipart”のどんなメディア下位型も,“mixed”メディ

ア下位型であるとして,扱わなければならない。


18 
X 5810-2:2008

5.1.4

alternative メディア下位型

“multipart/alternative”メディア下位型は,構文的には“multipart/mixed”と同一であるが,セマンティクスは

異なる。特に,本体部分のそれぞれは,同じ情報の“代替”版とする。

システムは,多くの部分の内容は交換可能であることを,認識したほうがよい。システムは,ある場合

には利用者との対話があるにせよ,局所的な環境及び参照に基づいて,

“最良の”型を選んだほうがよい。

“multipart/mixed”と同様,本体部分の順番には意味がある。この場合,代替は,原内容に忠実さが増す順番

で現れるとする。一般的に,最良の選択は,受信システムの局所環境によってサポートされる型の最後の

部分である。

“multipart/alternative”は,例えば,どこにも簡単に表示できる,装飾的なテキストによるメッセージを送

るのに使われてもよい。

From: Nathaniel Borenstein

To: Ned Freed

Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)

Subject: Formatted text mail

 MIME-Version:

1.0

 Content-Type:

multipart/alternative;

boundary=boundary42

 --boundary42

Content-Type: text/plain; charset=us-ascii

 ...

メッセージのプレーンテキスト版がここにくる ...

 --boundary42

 Content-Type:

text/enriched

 ...

同じメッセージの RFC 1896 text/enriched 版がここにくる ...

 --boundary42

 Content-Type:

application/x-whatever

 ...

同じメッセージの最も装飾的な版がここにくる ...

 --boundary42--

この例では,システムの機能に依存して,フォーマット付き又はプレーンテキストだけしか見られない

利用者もいるし,“application/x-whatever”フォーマットを理解したメールシステムの利用者は,装飾的な版

だけを見る。

一般的に,“multipart/alternative”実体を作成する利用者エージェントは,お勧め度の昇順,すなわちお勧

めのフォーマットを最後に,本体部分を配置しなければならない。装飾的なテキストについては,送った

利用者エージェントは,最もプレーンなフォーマットを先に,最もリッチなフォーマットを最後に置くほ


19

X 5810-2:2008

うがよい。

受信利用者エージェントは,

表示可能な最後のフォーマットを取り出して表示するほうがよい。

一つの代替がそれ自体“multipart”の型の場合で認識されない下位部分を含む場合,利用者エージェントは,

その代替,それより前の代替,又はそれらの両方を選んで表示してもよい。

注記  実装者の観点からは,この順番を逆にし,最もプレーンな代替を最後に置くほうが,より感覚

的 に よ く 見 え る か も し れ な い 。 し か し , 最 も プ レ ー ン な 代 替 を 始 め に 置 く こ と は ,

“multipart/alternative”実体が MIME に適合しないビュアを使って“multipart/alternative”実体を見

るとき,最も親切な可能性がある選択である。この方法は,MIME に適合するビュアに負担を

かけるが,この場合,より古いメールリーダとの相互運用性がより重要であると思われる。

幾つかの利用者エージェントで,それらが一つ以上のフォーマットを認識できるならば,どのフォーマ

ットで見るか利用者に選択を提供することを好む場合があるかもしれない。例えば,メッセージが,きれ

いにフォーマットされた画像版及び簡単に編集できるテキスト版の両方を含む場合などに,

有意義である。

しかし,

最も大事なことは,

自動的に同じデータの複数の版を利用者が見せられるのではないことである。

利用者は最後に認識された版を見せたほうがよいか,又は選択を与えられたほうがよいかである。

multipart/alternate 中 Content-ID のセマンティクス  “multipart/alternative”実体のそれぞれの部分は同じデ

ータを表すが,二つの間の対応付けは,必ずしも情報を失わないとは限らない。例えば,ODA から PostScript

又はプレーンテキストへ変換するときは,情報を失う。二つの部分が同一の情報内容でないときは,それ

ぞれの部分は,異なる Content-ID フィールド値をもつことが推奨される。情報内容が同一のとき,例えば,

“message/external-body”の幾つもの部分が,同一のデータにアクセスする代替の方法を指定する場合,受信

者側にあり得るキャッシュ機構を最適化するため,同じ Content-ID フィールド値が用いられる方がよい。

しかし,部分によって使われる Content-ID フィールド値は,このような Content-ID フィールドがあるなら

ば,“multipart/alternative”全体を記述する Content-ID と同じにしないほうがよい。すなわち,一つ以上の他

の Content-ID フ ィ ー ル ド 値 が 実 体 中 の 部 分 を 参 照 す る が , 一 つ の Content-ID フ ィ ー ル ド 値 が

“multipart/alternative”実体を参照する。

5.1.5

digest メディア下位型

こ の 規 格 は , “multipart”Content-Type の “digest” メ デ ィ ア 下 位 型 を 定 義 す る 。 こ の 型 は , 構 文 的 に

“multipart/mixed”と同一だが,セマンティクスは異なる。特に,ダイジェストでは,本体部分のためのデフ

ォルトの Content-Type 値は,“text/plain”から“message/rfc822”に変更された。これは,引用の規約を除いて,

RFC 934 と互換性の強い,より読みやすいダイジェストのフォーマットを許すために行われた。

注記  ダイジェスト中の本体部分に対して,ダイジェスト中のデータの記述を含む“text/plain”部分な

どのような,“message/rfc822”以外の Content-Type 値を指定することは可能であるが,実際にそ

うすることは望ましくない。

“multipart/digest”Content-Type は,メッセージを集めたものを送

ることを意図する。もし,“text/plain”部分が必要ならば,それは“multipart/mixed”メッセージの

別の部分として含まれたほうがよい。

このフォーマットによるダイジェストは,次のようである。

 From: Moderator-Address

 To:

Recipient-List

Date: Mon, 22 Mar 1994 13:34:51 +0000

Subject: Internet Digest, volume 42

 MIME-Version:

1.0

 Content-Type:

multipart/mixed;


20 
X 5810-2:2008

boundary="---- main boundary ----"

------ main boundary ----

 ...紹介のテキスト又は目次...

------ next message ----

 Content-Type:

multipart/digest;

boundary="---- next message ----"

------ main boundary ----

 From:

someone-else

Date: Fri, 26 Mar 1993 11:13:32 +0200

 Subject:

my

opinion

 ...

本体がここにくる ...

------ next message ----

 From:

someone-else-again

Date: Fri, 26 Mar 1993 10:07:13 -0500

Subject: my different opinion

 ...

もう一つの本体がここにくる ...

------ next message ------

------ main boundary ------

5.1.6

parallel メディア下位型

この規格は,“multipart”Content-Type の“parallel”メディア下位型を定義する。この型は,構文的には

“multipart/mixed”と同一であるが,セマンティクスは異なる。特に,パラレル実体では,本体部分の順番は

意味をもたない。

この型の普通の表現は,ハードウェア及びソフトウェアですることができるならば同時に部分のすべて

を表示する。しかし,作成エージェントは,多くのメールリーダでこの機能がなく,いずれにせよ部分を

直列的に見せることに注意を払ったほうがよい。

5.1.7

その他の multipart のメディア下位型

他の“multipart”メディア下位型は将来的に期待される。MIME 実装は,一般的に,認識しない“multipart”

のメディア下位型を,“multipart/mixed”と同等なものとして,扱わなければならない。

5.2

message メディア型


21

X 5810-2:2008

メールを送るとき,別のメールメッセージにカプセル化することは,頻繁に好まれる。特別の“message”

メディア型はこれを推進するために定義されている。特に,“message”の“rfc822”メディア下位型は,RFC 822

メッセージをカプセル化するのに使われる。

注記  転送メッセージ又は拒絶メッセージのため,“message”のメディア下位型を定義することが提案

されている。しかし,転送メッセージ及び拒絶メッセージは,マルチパートメッセージとして,

取り扱うことができ,そのマルチパートメッセージは,1 番目の部分が制御又は記述的情報を

含み,2 番目の部分が“message/rfc822”型の転送メッセージ又は拒絶メッセージである。このよ

うな拒絶の作成及びメッセージの転送は,原メッセージ上の型情報を保存し,それを受信者が

正しく表現することを許すので,強く推奨される。

“message”のメディア下位型は,どの符号化が許されるかについて制限を課す場合がある。これらの制限

は,それぞれの特定のメディア下位型とともに記述する。

メールゲートウェイ,リレー及び他のメール処理エージェントは,RFC 822 メッセージの最上位ヘッダ

を替えることが一般に知られている。特に,それらは,頻繁にヘッダフィールドを追加,削除又は並び替

えを行う。これらの操作は,“message”型のメッセージの型に組み込まれてカプセル化されたヘッダでは,

明示的に禁止される。

5.2.1

RFC 822 メディア下位型

“message/rfc822”メディア型は,本体が,RFC 822 メッセージの構文でカプセル化されたメッセージを含

むことを示す。しかし,最上位の RFC 822 メッセージとは異なり,それぞれの“message/rfc822”本体が“From”,

“Date”及び少なくとも一つのあて先を含まなければならないという制限が削除され,少なくとも一つの

“From”,“Subject”又は“Date”が現れなければならないという要求に置き換えられる。

しかし,“822”という数字の使用にかかわらず,“message/rfc822”実体は,厳密な RFC 822 への適合性の

データに制限されることはなく,“message/rfc822”オブジェクトのセマンティクスが,RFC 822 で定義され

るセマンティクスに制限されることもない。もっと具体的にいえば,“message/rfc822”メッセージは,ニュ

ース記事又は MIME メッセージである。

“message/rfc822”実体の本体は,“7 bit”,“8 bit”又は“binary”以外の符号化であってはならない。メッセー

ジヘッダフィールドは,どんな場合もいつも US-ASCII でなければならず,本体内のデータは符号化され,

その場合,

カプセル化されたメッセージの Content-Transfer-Encoding ヘッダフィールドはこれを反映する。

カプセル化されたメッセージのヘッダ中の非 US-ASCII テキストは,JIS X 5810-3 に規定する機構を使って,

指定することができる。

5.2.2

partial メディア下位型

“partial”メディア下位型は,大きい実体を,幾つもに分割したメールの部分として配信し,受信する利用

者エージェントによって自動的に再構成することを許容するために定義する。考え方は,基本的な Internet

Protocol における,IP 断片化及び再構成に似ている。この機構は,中間の転送エージェントが,送ること

のできる個別のメッセージの大きさを,制限する場合に使うことができる。“message/partial”メディア型は,

本体がより大きい実体の断片を含んでいることを示す。

“message”型のデータは,base64 又は quoted-printable で符号化されていないかもしれないので,binary 又

は 8 bit のトランスポートをサポートする環境で,“message/partial”実体が組み立てられている場合に問題が

起こる。問題は,binary データが複数の“message/partial”メッセージに分割され,それぞれが binary のトラ

ンスポートを要求することである。7 bit のトランスポートへのゲートウェイで,このようなメッセージに

遭遇したとき,すべての断片を待ち,内部のメッセージを再組立し,そして再組立されたデータを base64


22 
X 5810-2:2008

又は quoted-printable で符号化する場合を除けば,それらを適切に 7 bit の世界に符号化する方法がない。異

なる断片が異なるゲートウェイを通過する場合もあり得るから,再組立する方法でさえも,許容できる解

決 策 で は な い 。 こ の 理 由 か ら , “message/partial” 型 の 実 体 は い つ で も 7 bit ( デ フ ォ ル ト 値 ) の

Content-Transfer-Encoding でなければならないことが規定される。特に,binary 又は 8 bit のトランスポート

をサポートする環境である場合でさえも,“8 bit”又は“binary”の Content-Transfer-Encoding の使用は,

“message/partial”型の MIME 実体には,明示的に禁止される。このことは,順番に内部のメッセージが“8 bit”

又は“binary”符号化を使ってはならないことを意味する。

幾つかのメッセージ転送エージェントは大きいメッセージを自動的に細分化してもよいこと,及びその

ようなエージェントは大きく異なる細分化の範囲を使ってよいことなどから,部分メッセージの断片が,

再組立においてそれら自体が部分メッセージを構成することができることを示すことが可能である。これ

は明示的に許容される。

“message/partial”型の Content-Type フィールドでは,三つのパラメタが指定されなければならない。1 番

目は,“id”であり,これは一意の識別子であり,断片を合わせるために使われるために,できる限り世界

で一意に近い識別子とする。一般に,識別子は本質的には“message-id”であり,二重引用符中に置かれたな

らば,JIS X 5810-1 で与えられる“parameter”のための拡張 BNF に従う,どんな message-id も可能とする。

2 番目は,“number”であり,整数で,断片の番号であり,この断片が断片の列の中でどこに合うかを支持

する。3 番目は,“total”であり,もう一つの整数で,断片の総数とする。この 3 番目の下位フィールドは,

最後の断片では必す(須)とし,それ以前の断片ではオプションとするが,あったほうがよい。これらの

パラメタはどの順番で与えられてもよいことに注意する。

そのため,三つの断片のメッセージの 2 番目の断片は,次のヘッダフィールドのうちいずれであっても

よい。

Content-Type: Message/Partial; number=2; total=3;

   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

 Content-Type:

Message/Partial;

   id="oc=jpbe0M2Yt4s@thumper.bellcore.com";

   number=2

しかし,3 番目の断片は,断片の総数を指定しなければならない。

Content-Type: Message/Partial; number=3; total=3;

   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

細分化番号は,0 でなく,1 で始まることに注意する。

このようにして分けた実体の断片が,一緒にされるとき,結果は,いつも,自体の Content-Type ヘッダ

をもつかもしれず,そして他のデータ型をもつかもしれない,完全な MIME 実体である。

5.2.2.1  メッセージ細分化及び再組立

“message/partial”から再組立されたメッセージのセマンティクスは,細分化されていたメッセージの内部

のセマンティクスでなければならず,それを含んでいたメッセージのセマンティクスではない。例えば,

大きい音声メッセージを幾つもの部分的メッセージとして送るが,受信者に対しては,音声メッセージを

含むカプセル化したメッセージとしてではなく,単純な音声メッセージとして表現することが,このセマ

ンティクスの定義から可能になる。すなわち,メッセージのカプセル化は,

“透過的”であると考えられる。

“message/partial”メッセージの断片の生成及び再構築をする場合,カプセル化されたメッセージのヘッ


23

X 5810-2:2008

ダは,同封の実体のヘッダとマージさせなければならない。この処理では,次の規則に注意を払わなけれ

ばならない。

a)  細分化エージェントはメッセージを行の境界以外の場所で分割してはならない。この制限は,CRLF

で終わらないメッセージのセマンティクスを保存するために課せられた。なぜなら,行の最後以外の

地点での分割は,

メッセージトランスポートに依存してしまうからである。

多くのトランスポートは,

CRLF で終わらないメッセージのセマンティクスを保存することができない。

b) “Content-”で始まるヘッダフィールド並びに特別なヘッダフィールドの“Subject”,“Message-ID”,

“Encrypted”及び“MIME-Version”を除いて,最初の囲まれたメッセージからのすべてのヘッダフィール

ドは新しいメッセージに順番に複写されなければならない。

c) “Content-”,“Subject”,“Message-ID”,“Encrypted”で始まる囲まれたメッセージのヘッダフィールド及

び“MIME-Version”のヘッダフィールドは,新しいメッセージに順番に追加されなければならない。

“Content-” で 始 ま ら な い 囲 ま れ た メ ッ セ ー ジ の , “Subject” , “Message-ID” , “Encrypted” 及 び

“MIME-Version”ではないフィールドは,無視されて,落とされる。

2 番目及び後続の囲まれたメッセージからのすべてのフィールドは,再組立処理によって廃棄される。

5.2.2.2

細分化及び再組立の例

音声メッセージが,二つの部分に分断される場合,最初の断片は,次のようなものであろう。

 X-Weird-Header-1:

Foo

 From:

Bill@host.com

 To:

joe@otherhost.com

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)

Subject: Audio mail (part 1 of 2)

 Message-ID:

<id1@host.com>

 MIME-Version:

1.0

 Content-type:

message/partial;

id="ABC@host.com";

   number=1;

total=2

 X-Weird-Header-1:

Bar

 X-Weird-Header-2:

Hello

 Message-ID:

<anotherid@foo.com>

 Subject:

Audio

mail

 MIME-Version:

1.0

 Content-type:

audio/basic

 Content-Transfer-Encoding:

base64

 ...

符号化された音響データの最初の半分はここにくる ...

そして,後半は,次のようなものであろう。

 From:

Bill@host.com

 To:

joe@otherhost.com

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)

Subject: Audio mail (part 2 of 2)


24 
X 5810-2:2008

 MIME-Version:

1.0

 Message-ID:

<id2@host.com>

 Content-type:

message/partial;

id="ABC@host.com"; number=2; total=2

 ...

符号化された音響データの後半はここにくる ...

そして,細分化されたメッセージが再構成されるとき,利用者に表示される結果のメッセージは次のよ

うなものであろう。

 X-Weird-Header-1:

Foo

 From:

Bill@host.com

 To:

joe@otherhost.com

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)

 Subject:

Audio

mail

 Message-ID:

<anotherid@foo.com>

 MIME-Version:

1.0

 Content-type:

audio/basic

 Content-Transfer-Encoding:

base64

 ...

符号化された音響データの最初の半分はここにくる ...

 ...

符号化された音響データの後半はここにくる ...

前の部分の Message-ID を参照する細分化されたメッセージの 2 番目及び後続の断片のヘッダに

“Reference”フィールドを含めることは,メールリーダが参照を理解し追跡する利点があるかもしれない。

しかし,このような“Reference”フィールドの生成はすべてオプションである。

最後に,“Encrypted”ヘッダフィールドは,Privacy Enhanced Messaging ( PEM ) [RFC 1421,RFC 1422,RFC

1423,RFC 1424]によって,廃止されたが,“message/partial”断片への変換の文脈及び“message/partial”断片

からの変換の文脈において遭遇したとき,上記の規則は,それを取り扱う正しい方法を記述していると信

じられている。

5.2.3

external-body メディア下位型

external-body メディア下位型は,実際の本体データは含まれず,単に参照であることを指示する。この

場合,パラメタは,外部データにアクセスする機構を記述する。

MIME 実体が,型“message/external-body”の実体であるとき,これは,ヘッダ,連続する二つの CRLF 及

びカプセル化されたメッセージのメッセージヘッダからなる。別の連続する二つの CRLF の組が現れたと

き,これはもちろん,カプセル化されたメッセージのメッセージヘッダを終了する。しかし,カプセル化

されたメッセージの本体は,それ自体外部にあるので,それは後続の領域には現れない。例えば,次のメ

ッセージを考える。

 Content-type:

message/external-body;

   access-type=local-file;

   name="/u/nsb/Me.jpeg"


25

X 5810-2:2008

 Content-type:

image/jpeg

 Content-ID:

<id42@guppylake.bellcore.com>

 Content-Transfer-Encoding:

binary

THIS IS NOT REALLY THE BODY!

“見せかけの本体”と呼ばれるかもしれない最後の領域は,ほとんどの external-body メッセージで無視

される。しかし,access-type が“mail-server”である場合などこのような幾つかのメッセージのためには,外

部情報を含むのに用いてよい。この規格で定義される,

“見せかけの本体”を使う access-type は“mail-server”

だけとするが,将来的に,この領域を使う他の仕様によって,他の access-types が定義されてよい。

すべての“message/external-body”実体中のカプセル化されたヘッダは,データを参照するために一意の識

別子を与える Content-ID ヘッダフィールドを含まなければならない。この識別子は,キャッシュ機構のた

め,又は,access-type が“mail-server”であるときデータの受領を認識するために使ってもよい。

ここで規定するように,ファイル名及びメールサーバ命令のような,external-body のデータを記述する

トークンは,US-ASCII 文字集合であることが要求されることに注意する。

実践において問題がある場合,“message/external-body”の新しく定義された access-type 又はその他の機構

によって,将来の MIME の拡張として,新しい機構が必要かもしれない。

“message/partial”と同じように,型“message/external-body”の MIME 実体は,7 bit の Content-Transfer-Encoding

の使用(デフォルト)でなければならない。特に,binary 又は 8 bit トランスポートをサポートする環境に

おいてさえ,“8 bit”又は“binary”の Content-Transfer-Encoding の使用は,型“message/external-body”の実体と

して,明示的に禁止される。

5.2.3.1

一般の external-body パラメタ

“message/external-body”で使ってよいパラメタは,次とする。

a)  ACCESS-TYPE ファイル又はデータが得られる,サポートされるアクセス機構を指示する語とする。

この語は,大文字・小文字を区別しない。値は,“FTP”,“ANON-FTP”,“TFTP”,“LOCAL-FILE”及び

“MAIL-SERVER”を含むが,これらに限定されない。“X-”で始まる実験値を除く将来の値は,RFC 2048

に記述されているように,IANA に登録されなければならない。このパラメタは,無条件に必す(須)

であり,すべての“message/external-body”ごとに存在しなければならない。

b)  EXPIRATION  RFC 822 の“date-time”構文で,RFC 1123 によって年フィールドに 4 数字を許すように

拡張された,外部データの存在が保証されない後の日付。このパラメタはどんな access-type とともに

使ってもよく,いつでもオプションとする。

c)  SIZE  オクテット数によるデータの大きさ。このパラメタの内容は,受信者が,外部データをもって

くるために,必要な資源を拡張するかどうかを決定するのを援助する。これはデータの大きさを正準

形つまり,どの Content-Transfer-Encoding も適用する前又はデータが復号化された後,で記述すること

に注意する。このパラメタはどんな access-type とともに使ってもよく,いつでもオプションとする。

d)  PERMISSION  クライアントがデータを上書きしようとするかもしれないことを期待するかどうか

を指示する,大文字・小文字を区別しないフィールドとする。デフォルトによって又は許可が“read”

の場合,それらが存在しないと仮定して,データが一度とってこられたら,それは再び必要ではない。

PERMISSION が“read-write”の場合,この仮定は不正であり,局所的な複写が,キャッシュ以上でない

ことを考えなければならない。“read”又は“read-write”だけを,許可の値として定義する。このパラメ

タはどんな access-type とともに使ってもよく,いつでもオプションとする。


26 
X 5810-2:2008

ここで定義される access-type の正確なセマンティクスは,後続の箇条に記述される。

5.2.3.2

ftp”及び“tftp access-type

FTP 又は TFTP の access-type は,メッセージ本体が,FTP[RFC 959]プロトコル又は TFTP[RFC 783]プロ

トコルによって,ファイルとしてアクセスできることを指示する。これらの access-type には,次の追加の

パラメタが必す(須)とする。

a)  NAME  実際の本体データを含むファイルの名前。 
b)  SITE  与えられたプロトコルを用いて,ファイルが得られるかもしれない機械。ニックネームでなく,

完全修飾されたドメイン名でなければならない。

c) FTP を用いて,どのようなデータでも引き出すときには,サイトのパラメタによって名付けられた機

械のために,利用者は一般にログイン ID 及びパスワードを尋ねられる必要がある。セキュリティ上

の理由から,このような ID 及びパスワードは content-type パラメタとして指定されないが,利用者か

ら得られなければならない。

加えて,次のパラメタをオプションとする。

d)  DIRECTORY  NAME によって名付けられたデータが取り出されるディレクトリ。 
e)  MODE  情報をとってくるとき,使われるモードを指示する,大文字・小文字を区別しない文字列。

access-type“TFTP”に正当な値は,TFTP プロトコル[RFC 783]で規定されるとおり,“NETASCII”,

“OCTET”及び“MAIL”とする。access-type“FTP”に正当な値は,“ASCII”,“EBCDIC”,“IMAGE”,

“LOCALn”,ここで,“n”は 10 進の整数で典型的には 8,とする。これらは,FTP プロトコル[RFC 959]

で規定されるとおり,

表現の型“A” “E” “I”及び“L n”に対応している。

“BINARY”及び“TENEX”は MODE

の値として正しくなく,代わりに“OCTET”,“IMAGE”又は“LOCAL8”を使ったほうがよいことに注意

する。

MODE が指定されなかった場合,TFTP の場合のデフォルト値は“NETASCII”,それ以外は“ASCII”

とする。

5.2.3.3

anon-ftp access-type

“anon-ftp” access-type は,利用者が,指定のサイトで,名前及びパスワードを提供することを求められる

必要がないことを除いて,“ftp”アクセス型と同一とする。代わりに,ログインが“anonymous”及び利用者の

メールアドレスに対応したパスワードで,ftp プロトコルが使われる。

5.2.3.4

local-file access-type

“local-file”の access-type は,実際の本体が,局所の機械上のファイルとしてアクセス可能であることを

指示する。この access-type のために二つの追加のパラメタが定義される。

a)  NAME  実際の本体データを含むファイルの名前。このパラメタは,“local-file” access-type で必す(須)

とする。

b)  SITE    データファイルへアクセスをもつと知られている機械又は機械の組のための,ドメイン指定

子。このオプションのパラメタは,データ参照が有効な範囲,すなわち,ファイルが視覚化されるこ

とが期待される単数又は複数のサイト,を記述するために使われる。例えば大域ファイルシステム経

由のように,ドメイン名の一部に対するワイルドカードとして,“*.bellcore.com”のような形でアステ

リスクを使用して,そのデータを直接可視化できる計算機の組を指示してもよい。また,単一のアス

テリスクで,そのデータが,全世界的にアクセス可能である(例えば,大域ファイルシステムを経由。

ことを指定してもよい。

5.2.3.5

mail-server access-type

“mail-server” access-type は,実際の本体がメールサーバにあることを指示する。この access-type のため


27

X 5810-2:2008

に,二つの追加のパラメタが定義される。

a)  SERVER 実際の本体データを得ることのできる,メールサーバの addr-spec。このパラメタは

“mail-server” access-type で必す(須)とする。

b)  SUBJECT  データを得るために送られるメールの中で,使われる主題。主題行を使用してメールサー

バを認証することは推奨されないが,このようなメールサーバは存在することが知られている。この

パラメタはオプションとする。

メールサーバは様々な構文を受け入れ,それらの幾つかは複数行なので,メールサーバへ送られる完全

な 命 令 は ,content-type ヘ ッ ダ フ ィ ー ル ド の パ ラ メ タ と し て 含 ま れ な い 。 代 わ り に , メ デ ィ ア 型 が

“message/external-body”であり access-type が mail-server であるとき,“見せかけの本体”として,それは提

供される。

MIME は,メールサーバの構文を定義しないことに注意する。構文を定義する代わりに,見せかけの本

体の中に任意のメールサーバの命令を含むことを許す。実装は,関連のデータを取り出すためにメールサ

ーバアドレスへ送ったメッセージの本体の中に,見せかけの本体を含まなければならない。

他の access-type と異なり,mail-server アクセスは非同期で,将来予想できない時間に起きる。この理由

によって,戻ってきたデータを原“message/external-body”実体とマッチさせることができる機構があること

は重要である。MIME メールサーバは,このようなマッチングを容易にするため,原“message/external-body”

実体に使われた,戻ってきたメッセージと同じ Content-ID を使わなければならない。

5.2.3.6

external-body のセキュリティ上の論点

“message/external-body”実体は,二つの重要なセキュリティ上の論点を起こす。

a) “message/external-body”参照を通したデータへのアクセスは,メッセージ作成者によって指定された操

作をメッセージ受信者が実行するのを,効果的にできる。ゆえに,メッセージ作成者が,受信者をだ

まして,別な方法では実行できないことをさせる可能性がある。例えば,受信者が得ることを承認さ

れていないデータを引き取る動作を指定することができ,受信者は,知らないうちに,あるセキュリ

ティポリシを破ることがある。この理由によって,外部参照を解決できる利用者エージェントは,受

信者のために行う動作について説明し,それを実行する前に明示的な許可を求めるという手順をいつ

もとらなければならない。

“mail-server”という access-type は,受信者に対して,もともとのメッセージ作成者が指定した内容

のデータを送れという新しいメッセージを送らせるので,特に攻撃されやすい。不正の可能性を考慮

して,MIME の“message/external-body”参照を解決しようとして送る要求メッセージには,自動的に構

成されたものであることを示す明確な通知を

(例えば,ヘッダフィールドの注釈内で,

)含むのがよい。

b) MIME は,メッセージの完全性及び真正性に何らかの保証を提供する環境で使われることがある。こ

のような保証が存在するとき,それは,メッセージの実際の直接の内容に対してだけ,あてはまる。

その保証は,MIME の“message/external-body”機構を通してアクセスされるデータにあてはまることも

あるし,あてはまらないこともある。特にメッセージングシステム自体が安全であっても,ある種の

アクセス機構の安全性を弱体化する可能性がある。

MIME 機構を利用する場合と利用しない場合のいずれの場合でも,この問題が存在することに注意

するほうがよい。セキュリティの高いメッセージのテキストの形の参照の場合でさえ,ある文書を含

む FTP サイトについて不用意に参照を行えば同様の問題を起こす。ただ一つの違いは,MIME がこの

ようなデータへの自動的なアクセスを提供することであり,利用者は,このような自動的なアクセス

機構に保障されない信頼を置くかもしれない。


28 
X 5810-2:2008

5.2.3.7  例及び追加説明

external-body 機構が“multipart/alternative”メディア型と結合して使われるとき,同じ実体が同じフォーマ

ットであるが異なったアクセス機構を経由する場合を含むように,“multipart/alternative”の機能を拡張する。

これが行われる場合,メッセージの発信者は,最初,お勧めのフォーマットそしてお勧めのアクセス機構

で,部分を順に配置しなければならない。受信者のビュアは,フォーマット及びアクセス機構の両方によ

って,一覧を評価したほうがよい。

非常に広い領域のファイルシステムが出現するにつれて,そのようなファイルシステムから,あるファ

イルに直接アクセスできる計算機の集合(又は直接アクセスできない計算機の集合)を,前もって知るこ

とは大変難しくなった。それゆえ,直接に試みるファイル名及びファイルがアクセス可能であることが知

られている一つ以上のサイトの名前の両方を提供することは意味があるかもしれない。実装は,FTP 又は

その他のプロトコルを使うか,匿名ファイル検索を使うか,又は,利用者に必要な名前及びパスワードを

入力するように促すことによって,遠隔のファイルを引き出すことを試みることができる。もし,外部本

体が,複数の機構でアクセス可能ならば,送信者は,中に入っている“multipart/alternative”実体の本体部分

の中に,“message/external-body”型の複数の実体を含めることができる。

しかし,external-body 機構は,

“mail-server”access-type に示されるように,ファイル検索に限定するこ

とを想定していない。これを超えて,例えば,ビデオクリップへの外部参照のためのビデオサーバを使う

ことが想像できる。

“message/external-body” デ ー タ が 指 す 外 部 本 体 が プ レ ー ン US-ASCII テ キ ス ト 以 外 で あ っ た ら ,

“message/external-body”データの組込みメッセージヘッダフィールドで,その外部本体のメディア型を宣言

しなければならない。これは,外部本体には,自分自身の型を宣言するためのヘッダ部がないからである。

同様に,“7 bit”以外の Content-Transfer-Encoding も,ここで宣言されなければならない。だから,PostScript

フォーマットでのオブジェクトを参照する,完全な“message/external-body”メッセージは次のようになる。

 From:

Whomever

 To:

Someone

 Date:

Whenever

 Subject:

whatever

 MIME-Version:

1.0

 Message-ID:

<id1@host.com>

 Content-Type:

multipart/alternative;

boundary=42

 Content-ID:

<id001@guppylake.bellcore.com>

 --42

Content-Type: message/external-body; name="BodyFormats.ps";

   site="thumper.bellcore.com";

mode="image";

   access-type=ANON-FTP;

directory="pub";

expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

 Content-type:

application/postscript

 Content-ID:

<id42@guppylake.bellcore.com>


29

X 5810-2:2008

 --42

 Content-Type:

message/external-body;

access-type=local-file;

   name="/u/nsb/writing/rfcs/RFC-MIME.ps";

   site="thumper.bellcore.com";

expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

 Content-type:

application/postscript

 Content-ID:

<id42@guppylake.bellcore.com>

 --42

   Content-Type:

message/external-body;

   access-type=mail-server

   server="listserv@bogus.bitnet";

expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

 Content-type:

application/postscript

 Content-ID:

<id42@guppylake.bellcore.com>

 get

RFC-MIME.DOC

 --42--

上記の例題では,外部 PostScript データのために,デフォルトの Content-Transfer-Encoding の“7 bit”が仮

定される。

“message/partial”型のように,“message/external-body”メディア型が透過的であることが想定される,すな

わち,その型の本体のメッセージを運ぶのではなく,外部本体のデータ型を運ぶことが想定される。した

がって,外側及び内側部分のヘッダは,“message/partial”と同じ規則で,結合されなければならない。特に,

このことは,Content-type フィールド及び Subject フィールドは上書きされるが,From フィールドは保存さ

れることを意味する。

外部本体は,外部本体参照とともには転送されないため,参照自体に適用される転送制限に適合する必

要はないことに注意する。特に,インターネットメールトランスポートは 7 bit 及び行長制限を課すが,こ

れらは,binary の外部本体参照に自動的に適用されることはない。だから,Content-Transfer-Encoding は,

許容されるが,一般に必要ではない。

“message/external-body”型のメッセージの本体は,RFC 822 メッセージのための基本構文が適用されるこ

とに注意する。特に,最初の CRLF が連続した組の前は,ヘッダ情報であり,その後は,多くの access-type

で無視される,本体情報である。

5.2.4

その他のメッセージメディア下位型

MIME 実装は,一般的にいって,認識されない“message”のメディア下位型を,“application/octet-stream”

と同等であるものとして,扱わなければならない。

電子メールで用いることを想定した,将来の“message”のメディア下位型は,“7 bit”符号化に制限するほ


30 
X 5810-2:2008

うがよい。“7 bit”に制限することができない場合は,“message”以外の型を使うほうがよい。

6

実験メディア型値

文字“X-”で始まるメディア型値は,相互の合意の上で同意するシステムによって使われる私的な値とす

る。厳密な公的定義以外のフォーマットは,“X-”接頭辞とともに命名されなければならず,公的に規定さ

れる値は“X-”で始まってはならない。広く使われている Andrew システムの旧版では“X-BE2”という名前を

使っているので,新しいシステムは多分異なる名前を選んだほうがよい。

一般的に,最上位の型で“X-”を使うことは強く非推奨とする。実装者は,可能な限り,存在する型のメ

ディア下位型を作ったほうがよい。多くの場合,新しい最上位の型より,“application”のメディア下位型と

するほうが適切である。

7

要約

五つの個別メディア型は,“audio”,“image”又は多くの他の種類のデータとして,実体をタグ付けするた

めの標準的な機構を提供した。複合メディア型の“multipart”及び“message”は,単一のメッセージ中に,異

なる型の実体の混合及び階層的構造化を可能にした。一つの個別のパラメタ構文は,データフォーマット

の詳細の追加の指定,

特に代替の文字集合の指定を可能にした。

追加のオプションのヘッダフィールドは,

たくさんの実装者に望まれると思われる,信頼できる拡張を提供した。最後に,同意した利用者エージェ

ントによる一般的な使用のため,特に“message/partial”及び“message/external-body”が注目されるが,たくさ

んの便利なメディア型が定義された。

8

セキュリティへの考慮

セキュリティに関する論点は,“application/postscript”型及び“message/external-body”型の箇所並びに RFC

2048 で論じられている。実装者は,受信者の環境でのあらゆる動作の遠隔実行を起こすことができるすべ

てのメディア型のセキュリティとのかかわり合いに特別の注意を払ったほうがよい。このような場合,

“application/postscript”型の議論は,遠隔実行機能をもつ他のメディアについて考えるためのモデルとして

提供されるであろう。


31

X 5810-2:2008

附属書 A

参考)

文法一覧

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

この附属書は,この規格で規定されるすべての構文の,完全な拡張 BNF 文法を含む。

しかし,この文法は,それ自体だけでは不完全である。この文法は,RFC 822 で定義される幾つかの構

文規則を名前によって参照する。これらの定義をここで再び示し,二つの間で意図しない差異を生じる危

険を冒すのではなく,残りの定義については,読者に RFC 822 を参照してもらうことにした。用語(term。

構文の中の終端子又は非終端子。

)が定義されていない場合には,それは,RFC 822 の定義を参照している。

boundary := 0*69<bchars> bcharsnospace

bchars := bcharsnospace / " "

bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /

"+" / "_" / "," / "-" / "." /

"/" / ":" / "=" / "?"

body-part := <RFC 822 で定義されている“message”であって,

すべてのヘッダフィールドがオプションであり,

指定された dash-boundary で始まらず,

本体部分のどこにも区切り子がないもの。

このテキストに記述されているように,

部分のセマンティクスはメッセージの

セマンティクスとは違うことに注意。>

close-delimiter := delimiter "--"

dash-boundary := "--" boundary

   ;

Content-Type フィールドの

   ;

boundary パラメタの値から

   ;

境界。

delimiter := CRLF dash-boundary

discard-text := *(*text CRLF)

   ;

無視又は削除してよい。


32 
X 5810-2:2008

encapsulation := delimiter transport-padding

   CRLF

body-part

 epilogue

:=

discard-text

multipart-body := [preamble CRLF]

dash-boundary transport-padding CRLF

   body-part

*encapsulation

   close-delimiter

transport-padding

   [CRLF

epilogue]

preamble := discard-text

 transport-padding

:=

*LWSP-char

   ;

作成者は長さゼロのトランスポート

   ;

パディングを生成してはならず,

   ;

受信者はメッセージトランスポート

   ;

によって加えられたパディングを

   ;

扱えなければならない。


33

X 5810-2: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 ヘッダの議論から次の文を削除した “しかし,適合ソフトウェアは,版番号を検査し,


34 
X 5810-2:2008

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

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 に固有のセキュリティの課題は,今では細かく示されている。


35

X 5810-2:2008

附属書 C 

参考)

参考文献

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

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

1990

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 1123  Internet Engineering Task Force, R. Braden, Editor "Requirements for Internet Hosts−Application and

Support", October 1989

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


36 
X 5810-2: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