X 5810-2：2008
（1）
2019年7月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）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法第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部：適合基準
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格 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の改正で
あった。附属書Bに，過去の版との違い及び変更について記載する。
1.2
概要
JIS X 5810の規格群の最初であって，RFC 2045を原規定とするJIS X 5810-1では，Content-Typeを含む
多くのフィールドを定義している。Content-Typeフィールドは，メディア型及びメディア下位型の識別子
2
X 5810-2：2008
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
を与えること並びに特定のメディア型で要求してよい外部情報を提供することによって，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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 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”の使用法には，表計
4
X 5810-2：2008
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
算，メールを利用したスケジュール管理システムのデータ，“能動的”（計算的）メッセージングのた
めの言語，直接は読むことのできないワードプロセッサのフォーマットを含む。幾つかの型のアプリ
ケーションデータ，特に“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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ばならない。同様に，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”ヘッダフィールドのメディア型のパラメタと
6
X 5810-2：2008
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
して，明示的に文字集合を指定することを強く推奨する。“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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
値の文字は，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文字集合として，マーク付けす
るのがよい。もっと一般的にいえば，広く使われている文字集合がもう一つの広く使われている文字集合
8
X 5810-2：2008
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
のサブセットであった場合，本体が広く使われているサブセットの文字だけを含むならば，それはサブセ
ットが使われているとラベル付けするのがよい。これは，受信者が結果の実体を正しく見ることができる
機会を，増やすことになる。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
術及びフォーマットへの参照ではなく，最も一般的な感覚で使われ，それは小さく符号化されるアニメー
ションの描画のようなメディア下位型を排除することを意味しない。“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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
を解除して，単純にデータをファイルに書き出すか，又は，多分利用者が指定した処理への入力として使
うことである。
悪意のあるプログラムを転送する危険をなくすために，実装は，次のような経路探索機構を使用しない
ことを強く推奨する。非推奨の経路探索機構とは，プログラム名が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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
を抜け出して“外部の”環境でなされる変更は，通常，文書間でも保存され，場合によっては半永久
的に不揮発性メモリに保持されるかもしれない。インタプリタのループから抜け出すことに関連する
オペレータは，後続の文書処理に干渉する可能性がある。このようにして，これらの抑制されない使
用は，サービス拒絶の脅威の構成要素となる。インタプリタのループを抜け出す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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ィア下位型は，それらのセマンティクスで異なってよく，構文上追加の制限を課してもよいが，“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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
--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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
うがよい。受信利用者エージェントは，表示可能な最後のフォーマットを取り出して表示するほうがよい。
一つの代替がそれ自体“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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
メールを送るとき，別のメールメッセージにカプセル化することは，頻繁に好まれる。特別の“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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
又は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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ダは，同封の実体のヘッダとマージさせなければならない。この処理では，次の規則に注意を払わなけれ
ばならない。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ここで定義される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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
に，二つの追加のパラメタが定義される。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
--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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
うがよい。“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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
認識できない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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書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
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
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