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

X 5810-1:2008

(1)

目  次

ページ

序文

1

1  総則

1

1.1  適用範囲

1

1.2  概要

2

1A  引用規格

3

2  用語,定義,規約及び共通拡張 BNF 文法

3

3  MIME ヘッダフィールド

6

4  MIME-VersionMIME 版)ヘッダフィールド

6

5  Content-Type(内容型)ヘッダフィールド

7

5.1  Content-Type ヘッダフィールドの構文

8

5.2  Content-Type デフォルト

10

6  Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド

10

6.1  Content-Transfer-Encoding 構文

10

6.2  Content-Transfer-Encoding セマンティクス

11

6.3  新しい Content-Transfer-Encoding

12

6.4  解釈及び使用

12

6.5  符号化の変換

13

6.6  正準符号化モデル

14

6.7  quoted-printable(印字可能引用)Content-Transfer-Encoding 

14

6.8  Base64 Content-Transfer-Encoding

17

7  Content-ID(内容識別子)ヘッダフィールド

19

8  Content-Description(内容記述)ヘッダフィールド

19

9  追加の MIME ヘッダフィールド

19

10  要約

20

11  セキュリティへの考慮

20

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

21

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

24

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

26


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

:2008

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

第 1 部:インターネットメッセージ本体の

フォーマット

Multipurpose Internet Mail Extensions (MIME)−

Part 1: Format of Internet Message Bodies

序文

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

Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies  を基に,技術的内容及び構成を変

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

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

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

であった。

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



X 5810-1:2008

1.2

概要

RFC 822 は,1982 年に出版されて以来,インターネットにおけるテキストのメールメッセージの標準フ

ォーマットを規定してきた。このフォーマットは成功を収め,インターネット及び RFC 821 で定義される

インターネット SMTP トランスポートの範囲外においても,RFC 822 のフォーマットが全部又は一部採択

されるなどしている。このフォーマットは,広範に使えるように見えるが,利用者コミュニティにとって

制約となる,数々の限界があることが,明らかになってきた。

RFC 822 はテキストのメッセージのためのフォーマットを規定することを想定していた。したがって,

音声又は画像を含むかもしれないマルチメディアメッセージなどの,非テキストのメッセージについては

言及していない。テキストの場合であっても,US-ASCII より豊富な文字集合の使用を必要とする言語を使

うメール利用者の必要を満たさない。RFC 822 は,音声,映像及びアジア言語のテキストを含むメールの

ための機構を規定していないばかりでなく,大部分の欧州言語についても,そのテキストを含むメールの

ための機構を規定していないので,追加の規定が必要になる。

RFC 821 及び RFC 822 に基づくメールシステムの顕著な制限の一つは,電子メールメッセージの内容が,

7 bit の US-ASCII の比較的短い行(例えば,1 000 文字以下 [RFC 821])に制限されていることである。こ

のことは,局所的なメールの利用者エージェント(UA,人間の利用者がメールを送信したり受信したりす

るプログラム)を起動する前に,テキストでない送信したいデータを,印字可能な US-ASCII 文字で表現

される 7 bit のバイト列に変換することを,利用者に強いる。インターネットで現在使われているこのよう

な符号化の例には,純粋な 16 進数,uuencode,RFC 1421 で規定される 3-in-4 base 64 方式,Andrew ツール

キット表現 [ATK],及びその他の多くの符号化がある。

RFC 822 ホストと X.400 ホストとの間のメールメッセージの交換を可能にするために,ゲートウェイが

設計されると,RFC 822 メールの制限は更に明らかになった。X.400 [X400]  は,電子メールメッセージ内

にテキストでないデータを含める機構を規定する。X.400 メッセージに RFC 822 メッセージを対応付けす

るための現在の標準的な方法は,テキストでない X.400 のデータを,IA5Text フォーマットに(符号化す

るのではなく)変換するか,又は,RFC 822 利用者に廃棄が起こったことを通知して廃棄するかのどちら

かでなければならないことを規定する。このことは,利用者が受け取ることを望むかもしれない情報を失

うので,明らかに望ましくない。UA がテキストでないデータを処理する能力をもたない場合であっても,

利用者は,データから利用可能な情報を抽出する機構を UA の外部にもっているかもしれない。さらに,

こうした状況は,メッセージが最終的に X.400 メッセージ通信処理システムへゲートウェイによって転送

されて(すなわち,X.400 メッセージがインターネットメールを通り抜けるだけで)

,テキストでない情報

が確かに再び使えるようになる,ということを許容しない。

この規格は,現存する RFC 822 の世界に深刻な非互換性をもたらすことなしに,これらの問題の多くを

解決するために組み合わせて使う,幾つかの機構について記述する。特に,次の四つの事項を記述する。

a)  MIME-VersionMIME 版)ヘッダフィールド  MIME に適合するメッセージを宣言するために版番

号を使用し,MIME に適合するメッセージと,このようなフィールドがないことを仮定した旧式又は

非適合のソフトウェアによって作成されたメッセージとを,メール処理エージェントが区別すること

を可能にする。

b)  Content-Type(内容型)ヘッダフィールド  RFC 1049 から一般化されたもので,メッセージの本体の

データのメディア型及びメディア下位型を指定するため,並びにメッセージ本体のデータの本来の表

現(正準形式)を完全に指定するために使用することができる。

c)  Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド  本体に適用された符号化変換及び


3

X 5810-1:2008

その結果の領域の双方を指定するのに使用することができる。同一(identity)変換以外の符号化変換を

データに適用すると,データ又は文字集合についての制限をもつメール転送機構を通り抜けることが

可能になる。

d)  Content-ID ヘッダフィールド及び Content-Description ヘッダフィールド  本体内のデータを更に記述

するために使うことができる二つの追加のヘッダフィールドである。

この規格で定義されるすべてのヘッダフィールドは,RFC 822 に規定されるヘッダフィールドの一般構

文規則に従っている。特に,Content-Disposition(内容配置)を除くこれらのすべてのフィールドは,意味

的な内容をもたず MIME 処理中には無視することが望ましい RFC 822 注釈を含むことができる。

相互運用性を規定し促進するために,JIS X 5810-5 は,この規格に“適合”する最小限のレベルを定義

する上記機構のサブセットのための,基本的な適用可能性宣言を規定する。

注記  JIS X 5810 規格群に規定する機構の多くは,最初に読むときには,幾分不思議又は風変わりに

思われるかもしれない。既存の規定との互換性及び既存の実践における頑健さは,この一連の

規格群の原規定を作成した作業グループの,最優先事項のうちの二つであった。特に,互換性

が,優雅さよりも,常に支持された。このプロトコルの標準化状況及び状態については,“イ

ンターネット公式プロトコル規定”の現在の版(URL:http://www.rfc-editor.org/rfcxx00.html)を参

照されたい。RFC 822 及び STD 3 である RFC 1123 も,MIME の適合実装はそれらに違反でき

ないため,MIME の本質的な背景を供給している。加えて,他の多くの参考情報(Informational)

RFC 文書,特に,RFC 1344,RFC 1345 及び RFC 1524 は興味深い。

1A

引用規格

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

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

)を適用する。

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

注記  ISO/IEC 2022  Information technology−Character code structure and extension techniques (IDT)

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

注記 RFC

2046  "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", 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 部:適合基準

注記 RFC

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

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

ISO/IEC 8859-1  Information technology−8-bit single-byte coded graphic character sets−Part 1: Latin

alphabet No.1

2

用語,定義,規約及び共通拡張 BNF 文法

JIS X 5810 規格群で規定する機構は,すべて通常の文章で記載されているが,そのほとんどは RFC 822



X 5810-1:2008

の拡張 BNF 記法を用いて形式的にも記述される。実装者は,JIS X 5810 規格群を理解するために,この記

法に親しむ必要がある(拡張 BNF 記法の完全な説明は,RFC 822 にある。

JIS X 5810 規格群における拡張 BNF の幾つかは,RFC 822 で定義される構文規則へ名前付きで参照され

ている。そのため,完全な形式文法は,MIME を規定する規格の文法一覧の附属書と,RFC 822 の拡張 BNF

及び RFC 1123 で定義される RFC 822 の修正(具体的には,“return”,“date”及び“mailbox”の構文の変更)

とを組み合わせることによって得られる。

JIS X 5810 規格群では,すべての数値及びオクテット値は,10 進記法で与えられる。JIS X 5810 規格群

が定義する,すべてのメディア型値,メディア下位型値及びパラメタ名は,大文字・小文字を区別しない。

しかし,パラメタ値は,特定のパラメタで特に指定される場合を除いて,大文字・小文字を区別する。

注記  本質的な事項を失うことなく読み飛ばしてもよい,追加の非本質的な情報は,このような注記

として提供する。これらの非本質的な注記の主な目的は,JIS X 5810 規格群の理論的根拠につ

いての情報を与えること,又は JIS X 5810 規格群を適切な歴史的又は発展的な文脈に位置付け

ることである。この情報は,とりわけ,適合した実装を構築することだけに注目している人々

は読み飛ばしてもよいが,特定の設計上の選択がなぜなされたかを理解したい人々には有用な

ことがある。

2.1

CRLF(復帰改行)

用語“CRLF”は,JIS X 5810 規格群では,CR(10 進の値が 13)及び LF(10 進の値が 10)の二つの

US-ASCII 文字に対応し,この順番で一緒に用いられ,RFC 822 メールでは行区切りを示している,オクテ

ット列とする。

2.2

文字集合,character set  

用語“文字集合”は,MIME では,オクテット列を文字列に変換する方法とする。無条件であいまい性

のない逆方向への変換は要求されないことに注意する。すなわち,一つの与えられた文字集合において,

それで表現できない文字があってもよいし,二つ以上のオクテット列が,同じ文字列を表現していてもよ

い。

この定義は,US-ASCII などの単純な単一の表による対応付けから,JIS X 0202 の技法を使う複雑な表切

換え方法まで,多くの種類の文字符号化を,文字集合として使用するために許すことが意図されている。

しかし,MIME 文字集合の名前に関連する定義は,実行される対応付けを完全に規定しなければならない。

特に,正確な対応付けを決定する外部プロファイル情報を用いてはならない。

注記  用語“文字集合”は,元来は,1 オクテットから 1 文字への単純な 1 対 1 写像(対応付け)を

もつ,US-ASCII 及び ISO-8859-1 といった単純な方式を記述するものであった。複数オクテッ

ト符号化文字集合及び切換え技法は,状況をより複雑にしている。例えば,ある人々は,MIME

でいうところの“文字集合( character set )”に対して,

“文字符号化( character encoding )”という

用語を使う一方,オクテットではない整数から文字への抽象的な対応付けを表すのに語句“符

号化文字集合( coded character set )”を使う。

2.3

メッセージ,message

用語“メッセージ”は,何も修飾句が付かない場合には,ネットワークに転送される(完全又は最上位

の)RFC 822 メッセージを意味するか,又は“message/rfc822”若しくは“message/partial”の型で本体にカプセ


5

X 5810-1:2008

ル化されたメッセージを意味する。

2.4

実体,entity

用語“実体”は,特に,MIME で定義されたヘッダフィールド及び内容とする。ここで,内容とは,メ

ッセージか,又はマルチパート実体の本体における複数の部分の一つか,それらのいずれかとする。これ

ら実体の規定が,MIME の本質になっている。実体の内容は“本体”と呼ばれることが多いので,実体の

本体について語ることは意味がある。

実体のヘッダには,

どのような種類のフィールドも存在してよいが,

実際には,“content-”で始まるフィールドだけが MIME に関係する意味をもつ。このことは,“content-”で

始まらないフィールドが全く意味をもたないことを意味する訳ではない。RFC 822 で意味が定義されてい

る非 MIME ヘッダフィールドをもつメッセージも実体である。

2.5

本体部分  ( body part )

用語“本体部分”は,マルチパート実体の内部の実体とする。

2.6

本体,body

用語“本体”は,更に限定されない場合には,実体の本体の意味とする。すなわち,メッセージ又は本

体部分の本体とする。

注記  2.32.6 の四つの定義は,明らかに循環的である。MIME メッセージ全体の構造は実際に再帰

的なので,このことは避けられない。

2.7

7 bit データ  ( 7 bit data )

“7 bit データ”は,CRLF 行分離シーケンスの間の,998 オクテット以下の相対的に短い行として表現

されるデータとする[RFC 821]。10 進の値が 127 より大きいオクテットがあってはならず,NUL(10 進の

値が 0 のオクテット)があってはならない。CR(10 進の値が 13)及び LF(10 進の値が 10)は,CRLF

行分離シーケンスの一部としてだけ現れる。

2.8

8 bit データ  ( 8 bit data )

“8 bit データ”は,CRLF 行分離シーケンスの間の,998 オクテット以下の相対的に短い行として表現

されるデータとする[RFC 821]。10 進の値が 127 より大きいオクテットを用いてもよい。7 bit データと同

様に,NUL があってはならず,CR(10 進の値が 13)及び LF(10 進の値が 10)は,CRLF 行分離シーケ

ンスとしてだけ現れる。

2.9

binary データ  ( binary data )

“binary データ”は,どのようなオクテットの列も含むことができるデータとする。

2.10

  ( lines )

“行”は,CRLF シーケンスによって分離された,オクテットの列として定義される。この定義は,RFC

821 及び RFC 822 の両方と整合している。“行”は,メッセージの中のデータの単位としてだけ参照され,

UA が実際に表示するものと対応していてもよいし,対応していなくてもよい。



X 5810-1:2008

3

MIME ヘッダフィールド

MIME は,MIME 実体の内容を記述するために使用される多くの新しい RFC 822 ヘッダフィールドを定

義する。これらのヘッダフィールドは,少なくとも次の二つの文脈で出現する。

a)  通常の RFC 822 メッセージヘッダの一部として

b)  マルチパート構成内の MIME 本体部分ヘッダの中で

これらのヘッダフィールドの形式定義は,次のとおりとする。

entity-headers := [ content CRLF ]

[ encoding CRLF ]

[ id CRLF ]

[ description CRLF ]

*( MIME-extension-field CRLF )

MIME-message-headers := entity-headers

   fields

   version

CRLF

   ;

この拡張 BNF 定義が含むヘッダフィールドの順序付けは,

   ;

無視するほうがよい。

 MIME-part-headers

:=

entity-headers

[ fields ]

   ;

“content-”で始まらないすべてのフィールドは,

   ;

定義された意味をもつことはできず,無視してよい。

   ;

この拡張 BNF 定義が含むヘッダフィールドの順序付けは,

   ;

無視するほうがよい。

種々の特定の MIME ヘッダフィールドの構文は,箇条 以降に示す。

4

MIME-VersionMIME 版)ヘッダフィールド

1982 年に RFC 822 が公開されて以来,それがインターネットメッセージのフォーマット規定として唯一

のものであり,使われているフォーマットの規定を宣言する必要性はほとんど認知されていなかった。こ

の規格は,RFC 822 を補完する独立の規定とする。この規格で,拡張は,RFC 822 と互換性のある方法で

定義されてはいるが,そうであっても,新しい規定を用いてメッセージが作成されたかどうかを,メール

処理エージェントが知っていることが望ましいかもしれない状況が存在する。

そのために,この規格は,使われているインターネットメッセージ本体のフォーマット規定の版を宣言

するために使用する,新しいヘッダフィールド“MIME-Version”を定義する。

この規格に従って作成されるメッセージは,このヘッダフィールドを,次のテキストでそのまま,含ま

なければならない。

 MIME-Version:

1.0

このヘッダフィールドがあることは,メッセージがこの規格に従って作成されていることを明言してい

る。

将来の規格がメッセージフォーマットの規定を再び拡張するかもしれないことを可能とするので,


7

X 5810-1:2008

MIME-Version ヘッダフィールドの内容のための形式拡張 BNF は,次による。

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

そこで,“1.0”を置き換える又は拡張するかもしれない,将来のフォーマット指定子は,ピリオドで分離

された二つの整数フィールドに制限される。“MIME-Version”の値が“1.0”以外のメッセージを受け取る場合,

この規格に適合するとみなすことはできない。

MIME-Version ヘッダフィールドは,メッセージの最上位にあることが要求されることに注意する。マル

チパート実体のそれぞれの本体部分には要求されない。“message/rfc822”型又は“message/partial”型の本体に

組み込まれたヘッダに対しては,組み込まれたメッセージそれ自体が MIME 適合になっていると主張され

る場合に限り,要求される。

この規格で定義されるとおりに MIME と適合するメールリーダが,将来到着するかもしれない“1.0”以外

の MIME-Version の値をもつメッセージをどう扱うのがよいかを,完全に規定することは可能ではない。

特定のメディア型の版管理は,MIME-Version 機構を使っては,達成されないことに注意する。特に,

application/postscript といった幾つかのフォーマットは,メディアフォーマット内部に版番号付け規約をも

つ。これら規約が存在する場合には,MIME はそれにとって代わることはしない。これら規約が存在しな

い場合には,必要があれば,MIME メディア型は,内容型フィールドの中で“version”パラメタを使うかも

しれない。

注記 MIME-Version の値を検査するとき,RFC 822 注釈文字列がある場合には,それらを無視する。

特に,次の四つの MIME-Version ヘッダフィールドは等価とする。

 MIME-Version:

1.0

MIME-Version: 1.0 (produced by MetaSend Vx.x)

MIME-Version: (produced by MetaSend Vx.x) 1.0

MIME-Version: 1.(produced by MetaSend Vx.x)0

MIME-Version ヘッダフィールドがなかった場合,受信側のメール UA は,MIME 要件に適合していても

していなくても,局所的な規約に基づき,メッセージの本体を解釈することを選んでよい。多くのこれら

規約は現在使われており,実際には非 MIME メッセージが,ほとんど何でも含むことができることに注意

したほうがよい。

非 MIME メールメッセージが,実際に US-ASCII 文字集合を用いたプレーンテキストであるかは,確実

ではない。これは,MIME 以前の非標準の局所的な規約の集合を使って,他の文字集合を用いたテキスト,

又は例えば圧縮( compress )されて uuencode された UNIX tar ファイルなどの,自動的には認識できない方

法によって表現されたテキストでないデータを含むメッセージであるかもしれないことによる。

5

Content-Type(内容型)ヘッダフィールド

Content-Type フィールドは,受信側の UA が,利用者にデータを表示するために,適切なエージェント

若しくは機構を選ぶこと,又は適切な方法でデータを扱うことができるほど十分に,本体に含まれるデー

タを記述することを目的としている。このフィールドに含まれる値は,メディア型と呼ばれる。

注記 Content-Type ヘッダフィールドは,最初,RFC 1049 で定義された。RFC 1049 では,より単純

で強力ではない構文を使っていたが,その多くは,この規格(及び原規定の RFC 2045)で与え

る機構と大部分は互換性がある。

Content-Type ヘッダフィールドは,メディア型及びメディア下位型の識別子を与えること,及びある種

のメディア型が要求することのある補助情報を提供することによって,実体の本体中のデータの性質を指



X 5810-1:2008

定する。メディア型及びメディア下位型の名前の後の,ヘッダフィールドの残りは,単に,“属性=値”の記

法で指定されたパラメタの集合とする。パラメタの順番は意味をもたない。

一般に,最上位のメディア型は,データの一般的な型を指定し,メディア下位型は,そのデータの型に

対する特定のフォーマットを指定する。そこで,メディア型“image/xyz”は,UA が“xyz”という特定の画像

フォーマットを知らなかったとしても,データが画像であることを知らせるのに十分である。このような

情報は,例えば,認識されないメディア下位型からの生データを利用者に見せるかどうかを決定するため

に利用できる。テキストの場合には,認識されないメディア下位型の生データを利用者に見せるのが妥当

であっても,画像又は音声の場合には妥当でないことがあるので,最上位のメディア型を使うことが必要

となる。このように,認識されないメディア下位型の処理の問題があるので,テキスト,画像,音声及び

映像の登録されたメディア下位型は,より下位において認識できない型への分化を生むような組込み情報

を含まないほうがよい。これら複合フォーマットは,“multipart”型又は“application”型を用いて表したほう

がよい。

パラメタは,メディア下位型の修飾子であって,内容の性質には,基本的には影響しない。意味のある

パラメタの集合は,メディア型及びメディア下位型に依存する。ほとんどのパラメタは,単一の特定のメ

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

適用可能なパラメタを定義してもよい。内容型又はメディア下位型の定義によって,パラメタは必す(須)

であってもよいし,オプションであってもよい。MIME 実装は,認識しない名前のパラメタを無視しなけ

ればならない。

例えば,“charset”パラメタは,“text”のあらゆるメディア下位型に適用でき,“boundary”パラメタは,

“multipart”メディア型のあらゆるメディア下位型に要求される。

すべてのメディア型に適用される大域的に意味のあるパラメタは存在しない。真に大域的な機構は,

MIME モデルでは,付加的な Content-*ヘッダフィールドの定義によって,最もよく言及される。

七つの最上位メディア型の初期集合は,JIS X 5810-2 で定義される。そのうち五つは,MIME 処理が関

係する限りにおいては,本質的に不透明な内容をもつ別々の型とする。残りの二つは,MIME 処理系によ

って追加の処理が必要な内容の複合型とする。

最上位メディア型のこの集合は,実質的に,完全となることを意図している。一般に,サポートされる

型のより大きな集合への追加は,これら初期の型の新しいメディア下位型を作ることによって,達成され

る。将来,この規格への標準化手続の拡張によってだけ,より多くの最上位の型を定義してよい。何らか

の理由によって他の最上位型を使うことが望ましい場合,非標準の状況を示すため,及び将来の公式の名

前と衝突する可能性を避けるために,その型には,“X-”で開始する名前を与えなければならない。

5.1

Content-Type ヘッダフィールドの構文

Content-Type ヘッダフィールドの値は,RFC 822 の拡張 BNF 記法を用いて,次のとおりに定義される。

content := "Content-Type" ":" type "/" subtype

   *(";"

parameter)

   ;

メディア型及びメディア下位型の合致は,

   ;

常に大文字・小文字を区別しない。

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" /


9

X 5810-1:2008

"application" / extension-token

composite-type := "message" / "multipart" / extension-token

extension-token := ietf-token / x-token

ietf-token := <標準化手続の RFC によって定義され,IANA で登録された拡張トークン>

x-token := <“X-”又は“x-”の 2 文字で始まり,空白を含まない,任意のトークン。>

subtype := extension-token / iana-token

iana-token := <公式に定義された拡張トークン。

この形式のトークンは,RFC 2048 で規定されるとおりに

   IANA に登録されなければならない。>

parameter := attribute "=" value

 attribute

:=

token

   ;

属性の合致は,

   ;

常に大文字・小文字を区別しない。

value := token / quoted-string

 token

:=

1*<SPACE,CTL,tspecials を除く,任意の(US-ASCII) CHAR>

tspecials := "(" / ")" / "<" / ">" / "@" /

"," / ";" / ":" / "\" / <">

"/" / "[" / "]" / "?" / "="

   ;

パラメタ値内で使うため,

   ;

quoted-string でなければならない。

tspecials の定義は,“/”,“?”及び“=”の 3 文字を追加したこと,並びに“.”を削除したこと以外は,RFC 822

の special の定義と同じであることに注意する。

メディア下位型の指定は必す(須)であることにも注意する。すなわち,メディア下位型の指定は,

Content-Type ヘッダフィールドから省いてはならない。このように,デフォルトのメディア下位型は存在

しない。

メディア型名,メディア下位型名及びパラメタ名は,大文字・小文字を区別しない。例えば,TEXT,

Text 及び TeXt は,等価な最上位のメディア型とする。パラメタ値は,通常,大文字・小文字を区別するが,

意図される使用によっては,大文字・小文字を区別しないように解釈されることがある。例えば,マルチ

パート境界は大文字・小文字を区別するが,message/External-body の“access-type”パラメタは大文字・小文


10 
X 5810-1:2008

字を区別しない。

引用文字列( quoted-string )パラメタの値は引用符を含まないことに注意する。すなわち,quoted-string の

中の引用符はパラメタ値の一部ではなく,単にパラメタ値を区切るのに使われる。さらに,構造化ヘッダ

フィールドに関する RFC 822 規則に従う注釈は許される。そこで,次の二つの形式は完全に等価とする。

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

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

この構文以外の,メディア下位型名の定義における構文上の唯一の制約は,それらの使用は重複しては

ならないという要求とする。すなわち,二つの異なる意味の“Content-Type: application/foobar”を使う,二つ

の異なるコミュニティがあることは望ましくない。そこで,新しいメディア下位型を定義する過程は,制

限を課すための機構を意図しているのでなく,単純にそれらの定義及び使い方を公にする機構とする。そ

のために,新しいメディア下位型を定義するための受入可能な次の二つの機構が存在する。

a) “X-”で始まる私的な値は,外部での登録又は標準化なしに二つの協力的エージェントの間で双方で(合

意して)定義してよい。これらの値は,登録又は標準化することはできない。

b)  新しい標準の値は,RFC 2048 に記述されるとおりに IANA に登録することが望ましい。

MIME を規定する 2 番目の規格( JIS X 5810-2 )では,MIME のメディア型の初期集合を定義する。

5.2

Content-Type デフォルト

MIME の Content-Type ヘッダなしのデフォルトの RFC 822 メッセージは,このプロトコルによって,

US-ASCII 文字集合によるプレーンテキストとされ,明示的に次のとおりに指定できる。

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

このデフォルトは,Content-Type ヘッダフィールドが指定されなかった場合を想定している。構文的に

有効でない Content-Type ヘッダフィールドに遭遇したときにも,このデフォルトを想定することが望まし

い。MIME-Version ヘッダフィールドが存在し,Content-Type ヘッダフィールドが存在しない場合,受信側

の UA は,プレーン US-ASCII テキストが送信者の意図であったと想定することもできる。MIME-Version

が存在しない,又は構文上有効でない Content-Type ヘッダフィールドが存在する場合であって,送信者の

意図によらず,プレーン US-ASCII テキストを想定してもよい。

6

Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド

電子メールによって便利に転送できる多くのメディア型は,8 bit 文字又は binary データとして,“自然

な”フォーマットで表現される。これらのデータは,幾つかの転送プロトコルでは転送することができな

い。例えば,RFC 821 ( SMTP )  は,メールメッセージを,末尾の CRLF 行分離子を含む 1 000 文字以下の

行をもった 7 bitUS-ASCII データに制限する。

したがって,これらデータを 7 bit の短い行のフォーマットに符号化する標準的な機構を定義する必要が

ある。制限の少ないトランスポート上での直接使用のために,制限の少ないフォーマットの中での符号化

されていないデータを適切にラベル付けすることも望まれる。この規格は,これら符号化が新しい

“Content-Transfer-Encoding”ヘッダフィールドによって指示されることを規定する。このフィールドは,今

までのいかなる規定によっても定義されていない。

6.1

Content-Transfer-Encoding 構文

Content-Transfer-Encoding フィールド値は,次に列挙されるとおり,符号化の型を指定する単一トークン

とする。形式文法は次による。

encoding := "Content-Transfer-Encoding" ":" mechanism


11

X 5810-1:2008

mechanism := "7bit" / "8bit" / "binary" /

"quoted-printable" / "base64" /

ietf-token / x-token

これらの値は大文字・小文字を区別しない。Base64,BASE64 及び bAsE64 はすべて等価とする。7 bit

の符号化型は,本体が既に 7 bit メールに使える表現であることを要求する。これは,デフォルト値とする。

すなわち,Content-Transfer-Encoding フィールドがない場合は,“Content-Transfer-Encoding: 7bit”が仮定され

る。

6.2

Content-Transfer-Encoding セマンティクス

この単一の Content-Transfer-Encoding トークンは,実際には,二つの情報を提供する。これは,本体がど

んな種類の符号化変換に従っているか(そのために,それを元の形式に戻すためにどの復号操作を使わな

ければならないか)及び結果の領域が何になるかを指定する。

Content-Transfer-Encoding の提供する二つの情報のうちの変換に関する部分は,単一の明確に定義された

復号アルゴリズムを,明示的に又は暗黙的に,指定する。このアルゴリズムは,符号化されたオクテット

のすべての列に対して,符号化される前の元のオクテット列に変換するか,又は符号化列として不正であ

ることを示すかのいずれかを行う。Content-Transfer-Encoding は,適切な操作のために追加される外部プロ

ファイル情報に依存することはない。復号器は,有効な符号化に対して,単一の明確に定義された出力を

生成しなければならないが,符号化器にはこのような制限はないことに注意する。すなわち,与えられた

同じオクテット列を,場合によって異なる等価な符号化列へと符号化することは完全に正しい。

同一(符号化変換),“quoted-printable”(印字可能引用)符号化及び“base64”符号化の三つの変換が,現

在定義されている。その(変換)領域は,“binary”,“8 bit”及び“7 bit”とする。

Content-Transfer-Encoding 値の“7 bit”,“8 bit”及び“binary”は,すべて同一符号化変換がなされること,す

なわち,いかなる符号化変換もなされないことを意味する。このように,それらは単に本体データの領域

の指示子として役に立ち,与えられたトランスポートシステムにおいて転送のために必要かもしれない符

号化の種類についての有用な情報を提供する。用語“7 bit データ”

“8 bit データ”及び“binary データ”

は,すべて箇条 で定義されている。

quoted-printable 符号化及び base64 符号化は,任意の領域からの入力を“7 bit”範囲のデータへと変換する

ので,制限のあるトランスポートシステムで運ぶことを安全にする。変換の特定の定義は,後に示す。

正しい Content-Transfer-Encoding ラベルが常に使われなければならない。8 bit 文字を含む符号化されて

いないデータを“7 bit”とラベル付けしてはならず,行に基づかない符号化されていないデータを“binary”以

外にラベル付けしてはならない。

メディア下位型と違って,Content-Transfer-Encoding 値の増加は望ましくないし不必要でもある。しかし,

“7 bit”領域への単一の変換だけを制定する訳にはいかない。多くの binary データの小規模で効率的な符号

化に対する要望と,ほとんどが 7 bit だがすべてではないデータのある程度可読性のある符号化に対する要

望との間にはトレードオフが存在する。この理由によって,少なくとも二つの符号化機構,すなわち,多

かれ少なかれ可読性のある符号化(quoted-printable)及び“密な”又は“一様な”符号化( base64 )が,必要で

あった。

符号化されていない 8 bit データのメールトランスポートは,RFC 1652 で定義されている。この規格の

原規定の初期の公開のときには,メール本体に符号化されていない binary データを含めるのに適正な,標

準化されたインターネットメールトランスポートは存在しなかった。そこで,インターネットメールにお


12 
X 5810-1:2008

いて“binary”Content-Transfer-Encoding が実際に有効である状況は存在しなかった。しかし,binary メールト

ランスポートがインターネットメールで現実のものとなるか,又は MIME が他の binary 可能なメールトラ

ンスポート機構と一緒に使われる場合には,binary の本体は,この機構を使うものとしてラベル付けされ

なければならない。

注記 Content-Transfer-Encoding フィールドのために定義される五つの値は,そのフィールドが符号化

されたアルゴリズム,又は符号化されない場合にはトランスポートシステム要件以外は,メデ

ィア型について何も示唆しない。

6.3

新しい Content-Transfer-Encoding

実装者は,必要ならば,私的 Content-Transfer-Encoding 値を定義してよいが,非標準の状態を示す“X-”

で始まる名前の,x-token を使わなければならない(例えば,“Content-Transfer-Encoding: x-my-new-encoding”)

標準として追加する Content-Transfer-Encoding 値は標準化手続の RFC によって規定されなければならない。

これら規定が満たさなければならない要件は,RFC 2048 で与えられる。このようにして,“X-”で始まるも

のを除き,すべての内容転送符号化の名前空間は,IETF で将来の使用のために明示的に予約されている。

注記 Content-Transfer-Encoding 値は大文字・小文字を区別しないので,“X-”と“x-”とは同等である。

メディア型及びメディア下位型と異なり,新しい Content-Transfer-Encoding 値の生成は,ほとんど可能性

のない利益のために互換性を妨げることが多いと考えられるので,強く非推奨とする。

6.4

解釈及び使用

Content-Transfer-Encoding ヘッダフィールドが,メッセージヘッダの一部として現れる場合,そのメッセ

ージの本体全体に適用される。Content-Transfer-Encoding ヘッダフィールドが,実体ヘッダの一部として現

れる場合,その実体全体に適用される。実体が“multipart”の型である場合,Content-Transfer-Encoding は,“7

bit”,“8 bit”又は“binary”以外の値をもってはならない。“message”型の幾つかのメディア下位型へは,更に

厳しい制限を適用する。

ほとんどのメディア型は,bit でなくオクテットを用いて定義されていて,ここで示される機構は,ビッ

トストリームではなく,任意のオクテットストリームを符号化するための機構となっていることに注意す

るほうがよい。これらの機構のうちの一つを通してビットストリームが符号化される場合,ネットワーク

で標準のビット順(ビッグエンディアン)

,すなわち,ストリームの中で最初のほうのビットが,8 bit バ

イトの中の高位ビットになるように,まず最初にビットストリームが 8 bit バイトストリームに変換されな

ければならない。8 bit 境界で終わらないビットストリームは,0 を用いてパディングされなければならな

い。JIS X 5810-2 は,“padding”パラメタをもつ application/octet-stream メディア型の場合に,それらパディ

ングの追加に言及する機構を提供する。

ここで定義する符号化機構は,US-ASCII のすべてのデータを明示的に符号化する。そこで,例えば,次

のヘッダフィールドをもつ実体を想定する。

Content-Type: text/plain; charset=ISO-8859-1

 Content-Transfer-Encoding:

base64

これは,本体が,元は ISO-8859-1 だったデータの base64 US-ASCII 符号化であって,復号後は,その文

字集合になることを意味すると,解釈されなければならない。

ある Content-Transfer-Encoding 値は,あるメディア型だけに使われ,他のメディア型には使えないことが

ある。特に,“7 bit”,“8 bit”又は“binary”以外の符号化を複合的なメディア型(他の Content-Type フィール

ドを再帰的に含むメディア型。

)に使用することは,明確に禁止される。現在,複合的なメディア型は,

“multipart”及び“message”だけである。multipart 型又は message 型の本体の符号化は,すべて,最も内側の


13

X 5810-1:2008

レベル,すなわち符号化されることが必要な実際の本体のところでなされなければならない。

複合的な実体が“7 bit”になる内容転送符号化値をもつが,それに取り囲まれた実体の一つが“8 bit”といっ

たより制限のゆるい値をもつ場合,内側に実際に 8 bit データが含まれていて,外側の“7 bit”というラベル

付けが,エラーであるか,又は内側に実際に含まれているデータが実は 7 bit 安全なデータであって,内側

の“8 bit”というラベル付けが,トランスポートシステムに不必要な高い要求を課しているのか,そのいず

れかであることが明らかだということを注意しておく。

注記 1  複合的な本体データに内容転送符号化( Content-Transfer-Encoding )を使うことを禁止するの

は過度に制限的と思われるかもしれないが,これは,データが一つの符号化アルゴリズムを

複数回通過し,適切に見るために複数回復号をしなければならないという,入れ子になった

符号化を防ぐために必要とする。入れ子になった符号化は,UA に相当な複雑さを加える。

これら複数回符号化の明白な効率の問題とは別に,入れ子になった符号化は,メッセージの

基本構造を不明りょうにすることがある。特に,入れ子になった符号化は,メッセージがど

んな型の本体を含むかを単に見付けるために,何回もの復号操作が必要になることを示唆す

る。入れ子になった符号化を禁止することは,特定のメールゲートウェイの仕事を複雑にす

るかもしれないが,入れ子になった符号化が UA へ及ぼす影響に比べれば,問題が少ないよ

うに思われる。

認識されない Content-Transfer-Encoding をもつ実体は,Content-Type ヘッダフィールドに実際に何と書い

てあるかにかかわらず,“application/octet-stream”の Content-Type をもつものとして取り扱われなければな

らない。

注記 2 Content-Transfer-Encoding は,符号化されるメディアの特質から推測できるか,又は少なくと

もある Content-Transfer-Encoding を特定のメディア型とともに使用するのが必す(須)となる

ものと思われるかもしれない。これが事実でない幾つもの理由がある。まず,メールに使わ

れるトランスポートの様々な型を与えた場合,ある符号化はメディア型とトランスポートと

のある組合せに対して適切だが,他の組合せには適切でなくともよい。例えば,8 bit トラン

スポートでは,特定の文字集合によるテキストに対して符号化は必要でないが,7 bitSMTP

では,それら符号化が明白に必要とされる。

次に,特定のメディア型は,異なる状況では異なる型の内容転送符号化を要求することがあ

る。例えば,多くの PostScript の本体は,全体的には 7 bit データの短い行から構成されるかも

しれないので,その場合,符号化は必要でない。他の PostScript の本体,特に,レベル 2 PostScript

の binary 符号化機構を使った本体は,binary トランスポート符号化を使った場合にだけ適切に

表現されてよい。最後に,Content-Type フィールドは拡張可能な指定機構となることを意図し

ているので,メディア型と符号化との間の関連の厳密な指定が,応用プロトコルの指定と特定

の下位トランスポートとを効果的に結び付けることになる。このことは,メディア型の開発者

が,使われているすべてのトランスポート及びそれらの制限について意識しなければならない

ので,望ましくない。

6.5

符号化の変換

quoted-printable 符号化及び base64 符号化は,それらの間の変換が可能なように設計されている。これら

変換において生じる唯一の課題は,quoted-printable 符号化出力での原文内( hard )行区切りの扱いである。

quoted-printable から base64 に変換するとき,quoted-printable 形式の原文内( hard )行区切りは,データの正

準形式の CRLF 列で表現される。そこで,その行区切りは,データの base64 形式での対応する符号化され


14 
X 5810-1:2008

た CRLF へ変換されなければならない。同様に,base64 復号後に得られるデータの正準形式での CRLF 列

は,テキストデータを変換するときにだけ,quoted-printable での原文内( hard )行区切りに変換されなけれ

ばならない。

6.6

正準符号化モデル

この規格の原規定である RFC の以前の版では,電子メールデータが正準形式に変換され符号化されると

きのモデルについて,特に,システムごとに改行の表現が非常に異なっているときに,この(変換)処理

が,CRLF の振る舞いにどう影響するか,及び内容転送符号化と文字集合との間の関係にどう影響するか

について,多少の混乱があった。この理由から,符号化のための正準モデルが,JIS X 5810-5 で提示され

る。

6.7

quoted-printable(印字可能引用)Content-Transfer-Encoding

quoted-printable 符号化は,大部分が US-ASCII 文字集合の中の印字可能文字に対応するオクテットから

構成されるデータを表現することを意図している。この符号化は,結果として生じるオクテットがメール

トランスポートによって変更されることはまずないといった方法で,データを符号化する。符号化される

データがほとんど US-ASCII テキストの場合,データの符号化された形式は,人によって大部分認識可能

なままになっている。全体が US-ASCII である本体も,文字変換及び/又は行折返しを行うゲートウェイ

をメッセージが通過する場合に,データの完全性を保証するために,quoted-printable によって符号化して

もよい。

この符号化では,オクテットは,次の規則によって決定されるとおりに表現されるのが望ましい。

a)  一般 8 bit 表現  符号化されるデータの正準形式(標準形式)の CRLF 行区切りの一部である CR 又は

LF を除くあらゆるオクテットは,一つの“=”にそのオクテットの値の 16 進表現の二つの数字(2 けた

の 16 進数)を続けたもので表してよい。この目的のために使う 16 進の数字は,“0123456789ABCDEF”

とする。大文字を使わなければならず,小文字は使ってはならない。例えば,10 進の値が 12( US-ASCII

form feed )は“=0C”で表現でき,10 進の値が 61( US-ASCII EQUAL SIGN )は“=3D”で表現できる。後続

の規則が代替の符号化を許す場合を除き,この規則には従わなければならない。

b)  文字表現  10 進の値が 33 以上 60 以下及び 62 以上 126 以下のオクテットは,それらのオクテットに

対応する US-ASCII 文字,それぞれ,EXCLAMATION POINT から LESS THAN まで及び GREATER

THAN から TILDE まで,として表現してよい。

c)  空白  10 進の値が 9 及び 32 のオクテットは,US-ASCII の TAB( HT )文字及び SPACE 文字として表現

してよいが,符号化された行の末尾で表現してはならない。符号化された行の TAB( HT )文字及び

SPACE 文字には,印字可能文字がその行で後続しなければならない。符号化された行の末尾の“=”は,

無指定( soft )行区切り[規則 e)を参照]を示しているが,一つ以上の TAB( HT )文字又は SPACE 文字

に続いてもよい。これは,符号化された行の末尾で 10 進の値が 9 又は 32 のオクテットは,1 番目の

規則によって表現されなければならないことに従っている。MTA[Message Transport Agent(メッセー

ジ転送エージェント)

,すなわち,一人の利用者から他の利用者へのメッセージを転送する,又はそれ

ら転送の一部を実行するプログラム]の中には,テキストの行を SPACE でパディングするものがあ

ることが知られていて,更に行末から“空白”文字を取り除くものも知られているので,この規則が必

要になる。そのために,中間の転送エージェントによって空白が加えられることが避けがたいので,

quoted-printable 本体を復号するとき,行の末尾に付いているすべての空白を削除しなければならない。

d)  改行  テキストの正準形式では CRLF 列として表現される,テキスト本体中の行区切りは,

quoted-printable 符号化では,やはり CRLF 列である RFC 822 の行区切りによって表現されなければな


15

X 5810-1:2008

らない。テキスト以外のメディア型の正準表現は一般には CRLF 列としての行区切りの表現を含まな

いので,原文内( hard )行区切り(すなわち,意味があり,利用者に表示されることを意図している行

区切り)は,これらの型の quoted-printable には出現できない。もちろん,quoted-printable で表現され

たテキストでないデータには,“=0D”,“=0A”,“=0A=0D”及び“=0D=0A”といった列は,機械的に現れ

ることがある。

多くの実装は,まず正準形式に変換し,符号化し,それから局所的な表現に戻すのではなく,直接

に様々な内容型の局所的な表現を符号化することを選んでもよいことに注意する。

特に,

このことを,

CRLF 終端子列ではない改行規約を使うシステムで,プレーンテキストのデータに適用してもよい。

このような実装の最適化は許されるが,

(それと)組み合わされた正準化符号化の段階が,三つの段階

を別々に実施するのと等価な場合だけに限る。

e)  符号化時(soft)行区切り  quoted-printable 符号化では,符号化された行が 76 文字を超えてはならない。

quoted-printable 符号化でそれより長い行が符号化される場合,“符号化時( soft )”行区切りが使われな

ければならない。符号化された行の最後の文字としての等号は,符号化されたテキストの中で意味が

ない“符号化時( soft )”行区切りを示す。

そこで,行の“元の( raw )”形式が,次の符号化されていない単一の行の場合を考える。

Now's the time for all folk to come to the aid of their country.

quoted-printable 符号化では,これを次のとおりに表せる。

Now's the time =

  for all folk to come=

  to the aid of their country.

これは,UA によって元に戻されるといった方法で,長い行を符号化する機構を提供する。76 文字制限

は,末尾の CRLF を数えないが,等号を含めた他のすべての文字を数える。

ハイフン文字(“-”)は,それ自体,quoted-printable 符号化で表現してよいので,一つ以上のマルチパート

実体の内部に quoted-printable で符号化された本体をカプセル化するときには,その境界区切り子

1)

が,符

号化された本体のどこにも現れないことを保証するために,注意をしなければならない。よい戦略として

は,quoted-printable(で符号化された)本体には現れることのない“=_”  といった文字列を境界に選ぶこと

がある。JIS X 5810-2 のマルチパートメッセージの定義を参照

1)

注記 1 quoted-printable 符号化は,可読性と転送における信頼性との折衷的なものを表現している。

quoted-printable 符号化で符号化された本体は,ほとんどのメールゲートウェイにおいて高い

信頼性で動作するが,少数のゲートウェイ,特に,EBCDIC への変換を伴うものでは完全に

は動かないかもしれない。より高いレベルの信頼性は,base64 Content-Transfer-Encoding によ

って提供される。EBCDIC ゲートウェイを通る妥当な信頼性のある転送を得る方法は,次の

US-ASCII 文字も,前の 1 番目の規則で示した 16 進表現にすることである。

!"#$@[\]^`{|}~

quoted-printable データは一般に行に基づくことを仮定しているので,改行規約の異なるシス

テム間で渡されるとき,インターネットメールにおいてプレーンテキストメールが常に変更

されてきたのと同じように,quoted-printable データの行の間の区切りの表現は,転送中に変

更されるかもしれないと予想される。これら変更が,データの変造を引き起こす可能性があ

る場合,quoted-printable 符号化ではなく,base64 符号化を使うことがおそらくより賢明とい

える。


16 
X 5810-1:2008

注記 2 quoted-printable 内容転送符号化のための符号化規則に従って,ある種の部分文字列を生成す

ることはできない。したがって,quoted-printable 符号化器の出力にそれらが出現する場合は,

形式的には不正とする。この注記は,これらの場合を列挙し,復号される quoted-printable デ

ータの中で次のどれかに出会う場合,それら不正な部分文字列を取り扱う方法を示す。

a)  一つ又は両方が“abcdef”のうちのいずれかの小文字となっている二つの 16 進数字に後続

される“=”は,形式的には不正とする。頑健な実装は,それらを対応する大文字として認

識するとよいかもしれない。

b) “abcdef”の場合を含む 16 進の数字でなく,CRLF 対の CR 文字でもない文字に後続され

る“=”は,不正とする。この場合は,それ自体が quoted-printable 符号化に従っていない,

メッセージの quoted-printable 部分に含まれている,US-ASCII テキストの結果の可能性

がある。頑健な実装による理にかなった方針は,復号されたデータに,“=”文字及びそれ

に後続する(一つの)文字を変換せずに含ませ,可能な場合には,利用者に,データの

この箇所で適切な復号ができなかったことを示すことかもしれない。

c) “=”は,符号化されたオブジェクトの中で最後又は最後から 2 番目の文字となることはで

きない。これは,前項の場合として取り扱ってよい。

d) TAB,又は CRLF 対の一部としての CR 及び LF,以外の制御文字は現れてはならない。

10 進の値が 126 より大きい値のオクテットに対しても同じとする。それらの文字が,復

号器によって,到着した quoted-printable データの中に発見された場合,頑健な実装は,

復号されたデータからそれら文字を除外し,利用者に不正文字が発見されたことを警告

するとよいかもしれない。

e)  符号化した行は,末尾の CRLF を数えずに,76 文字より長くてはならない。より長い行

が到着した符号化されたデータの中に発見された場合,頑健な実装は,エラーではある

がその行を復号し,利用者にエラーのある符号化であることを報告するとよいかもしれ

ない。

注記 3 binary データが quoted-printable で符号化される場合,CR 文字及び LF 文字をそれぞれ“=0D”

及び“=0A”として符号化することに注意しなければならない。特に,binary データでの CRLF

列は,“=0D=0A”と符号化するのがよい。そうでない場合であって,CRLF が指定( hard )行区

切りとして表現される場合,異なった行区切り規約をもつプラットホームでは,正しく復号

されないかもしれない。

1)

  JIS X 5810-2 において,境界区切り子は,ハイフン文字を使って定義されている。

quoted-printable データの構文は,次の形式文法で記述される。

quoted-printable := qp-line *(CRLF qp-line)

qp-line := *(qp-segment transport-padding CRLF)

 qp-part

transport-padding

qp-part := qp-section

   ;

最大長 76 文字。

qp-segment := qp-section *(SPACE / TAB) "="


17

X 5810-1:2008

   ;

最大長 76 文字。

qp-section := [*(ptext / SPACE / TAB) ptext]

ptext := hex-octet / safe-char

safe-char := <10 進の値が 33∼60 及び 62∼126 をもつ任意のオクテット>

   ;

更に,JIS X 5810-5 の“mail-safe”の一覧にない

   ;

文字も推奨しない。

hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

   ;

127 より大きな文字,=,又は行末の SPACE 若しくは TAB には

   ;

hex-octet が使われなければならず,

   ;

JIS X 5810-5 で“mail-safe”の一覧にない文字のためには

   ;

hex-octet が推奨される。

 transport-padding

:=

*LWSP-char

   ;

送信者は,長さが 0 ではないトランスポート

   ;

パディングを生成してはならないが,

   ;

受信者は,メッセージトランスポート

   ;

によって追加されたパディングを

   ;

処理できなければならない。

この拡張 BNF では構造化ヘッダフィールドを規定していないので,この拡張 BNF に示される要素間で

の LWSP(空白の並び)の追加は許されない。このことは,重要である。

6.8

Base64 Content-Transfer-Encoding

Base64 Content-Transfer-Encoding は,任意のオクテット列を,人が読めなくともよい形式で,表現するた

めに設計された。符号化及び復号のアルゴリズムは単純だが,符号化されたデータは,符号化されていな

いデータに比べ,一貫しておよそ 33 パーセントほど大きい。この符号化は,実質的に,RFC 1421 で定義

されている,Privacy Enhanced Mail ( PEM )  アプリケーションと同等になっている。

US-ASCII の 65 文字の部分集合を使用し,印字可能な一つの文字ごとに 6 bit を表現可能とする。65 番

目の文字“=”は,特別な処理機能を意味するために使用する。

注記 1  この部分集合は,US-ASCII を含む ISO/IEC 646 のすべての版で同一に表現されるという,重

要な特性をもち,このすべての文字は,EBCDIC のすべての版でも,同一に表現される。

uuencode ユティリティ,Macintosh の binhex 4.0 [RFC 1741]及びレベル 2 PostScript の一部と

して規定される base85 符号化といった,

他のよく利用される符号化は,

この特性を共有せず,

そのために,メール用の binary 内容転送符号化が満たさなければならない可搬性要件を満足

しない。

符号化処理は,四つの符号化文字の出力列として,入力ビットの 24 bit(単位の)群( 24-bit group )を表

現する。左から右へと進めて,一つの 24 bit の入力群が,三つの 8 bit 入力群を連結することによって,形


18 
X 5810-1:2008

成される。次に,これらの 24 bit を,四つの連結された 6 bit 群として取り扱い,それぞれを base64 アルフ

ァベット(base64 の構成単位)における単一の数字へと変換する。base64 符号化を通じてビットストリー

ムを符号化する場合,ビットストリームは,最上位ビットが先になる順番と仮定されていなければならな

い。すなわち,ビットストリームの最初のビットは,最初の 8 bit(単位の)バイトの中の上位ビットとな

り,8 番目のビットは,最初の 8 bit(単位の)バイトの中の下位ビットとなる,など,以下同様とする。

それぞれの 6 bit 群は,64 個の印字可能文字の配列へのインデクスとして使われる。インデクスによっ

て参照される文字が,出力列の中に置かれる。次の

表 で識別されるこれらの文字は,広い範囲で表現可

能なように選ばれ,例えば,“.”,CR,LF などの,SMTP に対して特定の意味をもつ文字,及び例えば“-”

などの JIS X 5810-2 で定義されるマルチパート境界区切り子に対して特定の意味をもつ文字を除外してあ

る。

表 1Base64 アルファベット

符号

符号

符号

符号

0  A  17 R  34 i  51 z 
1  B  18 S  35 j  52 0 
2  C  19 T  36 k  53 1 
3  D 20 U 37 l  54 2 
4  E  21 V  38 m  55 3 
5  F  22 W 39 n  56 4 
6  G  23 X  40 o  57 5 
7  H 24 Y 41 p  58 6 
8  I  25 Z  42 q  59 7 
9  J  26 a  43 r  60 8 
10 K  27 b  44 s  61 9 
11 L  28 c  45 t  62 + 
12 M  29 d  46 u  63 / 
13 N  30 e  47 v     
14 O  31 f  48 w  (pad)

=

15 P  32 g  49 x     
16 Q  33 h  50 y

符号化された出力ストリームは,それぞれ 76 文字を超えない行で表現されなければならない。すべての

行区切り又は

表 にない他の文字は,復号ソフトウェアによって,無視されなければならない。base64 デ

ータの中の,

表 以外の文字,行区切り及びその他の空白は,おそらく,ある状況では警告メッセージ又

はメッセージ拒否が適切かもしれない,転送誤りを示す。

符号化されるデータの末尾において,24 bit に満たない場合には,特別な処理が実行される。本体の末

尾では常に欠けることのない符号化の分量で完結する。入力群の中で,24 よりも少ない入力ビットが存在

する場合,値 0 のビットが右に追加され,6 bit 群を単位とする整数倍の数へと整形される。データの末尾

へのパディングは“=”文字を使って実行される。すべての base64 入力はオクテットの整数倍の数なので,

次の場合だけが発生する。

a)  符号化入力の最後の分量が,24 bit の整数倍になっている。この場合,符号化出力の最後の単位(か

たまり)は,“=”パディングなしで 4 文字の整数倍となる。

b)  符号化入力の最後の分量が,ちょうど 8 bit になっている。この場合,符号化出力の最後の単位(かた

まり)は,二つの文字に,二つの“=”パディング文字が後続したものとなる。


19

X 5810-1:2008

c)  符号化入力の最後の分量が,ちょうど 16 bit になっている。この場合,符号化出力の最後の単位(か

たまり)は,三つの文字に,一つの“=”パディング文字が後続したものとなる。

“=”文字はデータの最後のパディングのためだけに用いられるので,途中で切り取られなかった場合には,

“=”文字の出現はデータの最後に到達した証拠とみなしてもよい。しかし,転送されたオクテットの数が 3

の倍数であって“=”文字が存在しないときは,このような保証は可能ではない。

base64 アルファベット以外の文字は,base64 符号化データの中では,無視するのが望ましい。

正準形式に変換されていないテキストデータに対して base64 符号化を直接に適用する場合には,行区切

りのために適切なオクテットを使うように注意しなければならない。特に,テキストの行区切りは,base64

符号化の前に,CRLF 列に変換されなければならない。実装の中には,この変換を,先行する正準化段階

ではなく,符号化器によって直接に行うものもあるという点に注意することが重要である。

注記 2  マルチパート実体の内部の base64 符号化本体内で,存在する可能性のある境界区切り子を引

用する( quote )ことについては,心配する必要はない。これは,base64 符号化では“-”(ハイ

フン)文字は使用されないことによる。

7

Content-ID(内容識別子)ヘッダフィールド

高機能の UA を作成するとき,ある本体が他の本体への参照を行うのを可能にすることが望まれる場合

がある。それに従って,本体は,構文的には Message-ID ヘッダフィールドと同一の,Content-ID ヘッダフ

ィールドを使ってラベル付けしてよい。

id := "Content-ID" ":" msg-id

Message-ID 値と同様に,Content-ID 値は,世界で一意となるように生成されなければならない。

注記  世界で一意とする方法については,この規格では規定しない。

Content-ID 値は,幾つかの文脈において MIME 実体を一意に識別するために,特に,message/external-body

機構によって参照されるデータをキャッシュするために使ってよい。Content-ID は一般にオプションだが,

オプションの MIME メディア型である“message/external-body”のデータを生成する実装では,その使用は必

す(須)とする。すなわち,それぞれの message/external-body 実体は,これらデータのキャッシュ化を許

すために Content-ID フィールドをもたなければならない。

Content-ID 値は,multipart/alternative メディア型の場合には特別なセマンティクスをもつことに注意する

ことも重要である。このことは,JIS X 5810-2 において,multipart/alternative について扱う箇条で示される。

8

Content-Description(内容記述)ヘッダフィールド

説明的な情報を与えられた本体と関連付ける能力が,望まれることが多い。例えば,“image”本体に“ス

ペースシャトルエンデバーの写真”といった印を付けることは役に立つかもしれない。

それらテキストは,

Content-Description ヘッダフィールドの中に置いてよい。このヘッダフィールドは,常にオプションとする。

description := "Content-Description" ":" *text

この記述( description )は,US-ASCII 文字集合で与えられることを想定する。ただし,JIS X 5810-3 で規

定される機構を使って,非 US-ASCII 文字を Content-Description フィールドの値としてもよい。

9

追加の MIME ヘッダフィールド

将来の規定では,

種々の目的のために追加の MIME ヘッダフィールドを定義することを決定してもよい。

メッセージの内容を更に記述する新しいヘッダフィールドは,メッセージヘッダに現れるそれらフィール


20 
X 5810-1:2008

ドを通常の RFC 822 ヘッダフィールドと区別するために,文字列“Content-”で始めることが望ましい。

MIME-extension-field := <文字列“Content-”で始まる任意の RFC 822 ヘッダフィールド>

10  要約

MIME-Version ヘッダフィールド,Content-Type ヘッダフィールド及び Content-Transfer-Encoding ヘッダ

フィールドを使って,標準化された方法で,RFC 822 に適合するメールメッセージに任意の型のデータを

含ませることが可能になる。RFC 821 又は RFC 822 のどちらかによって課される制約に違反しない。幾つ

かのインターネットメール転送機構の特徴によって追加的に課される制約が引き起こす問題を避けるため

の注意が行われた。これについては,JIS X 5810-5 に記す。

JIS X 5810-2 では,これらのヘッダを使ってラベル付け及び転送ができるメディア型の初期集合を規定

する。

11  セキュリティへの考慮

セキュリティに関しては,JIS X 5810-2 で論じられる。


21

X 5810-1:2008

附属書 A

参考)

文法一覧

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

この附属書は,この規格で規定されるすべての構文の,完全な拡張 BNF 文法を示す。

しかし,この文法は,それ自体だけでは不完全である。この文法は,RFC 822 で定義される幾つかの構

文規則を名前によって参照する。これらの定義をここで再び示し,二つの間で意図しない差異を生じる危

険を冒すのではなく,残りの定義については,読者に RFC 822 を参照してもらうことにした。用語(term。

構文の中の終端子又は非終端子。

)が定義されていない場合には,それは,RFC 822 の定義を参照している。

 attribute

:=

token

   ;

属性の合致は,

   ;

常に大文字・小文字を区別しない。

composite-type := "message" / "multipart" / extension-token

content := "Content-Type" ":" type "/" subtype

   *(";"

parameter)

   ;

メディア型及びメディア下位型の合致は,

   ;

常に大文字・小文字を区別しない。

description := "Content-Description" ":" *text

discrete-type := "text" / "image" / "audio" / "video" /

"application" / extension-token

encoding := "Content-Transfer-Encoding" ":" mechanism

entity-headers := [ content CRLF ]

[ encoding CRLF ]

[ id CRLF ]

[ description CRLF ]

*( MIME-extension-field CRLF )

extension-token := ietf-token / x-token

hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

   ;

127 より大きな文字,=,又は行末の SPACE 若しくは TAB には


22 
X 5810-1:2008

   ;

オクテットが使われなければならず,

   ;

JIS X 5810-5 で“mail-safe”の一覧にない文字のためには

   ;

オクテットが推奨される。

iana-token := <公式に定義された拡張トークン。

この形式のトークンは,RFC 2048 で規定されるとおりに

   IANA に登録されなければならない。>

ietf-token := <標準化手続の RFC によって定義され,IANA で登録された拡張トークン>

id := "Content-ID" ":" msg-id

mechanism := "7bit" / "8bit" / "binary" /

"quoted-printable" / "base64" /

ietf-token / x-token

MIME-extension-field := <文字列“Content-”で始まる

任意の RFC 822 ヘッダフィールド。>

MIME-message-headers := entity-headers

   fields

   version

CRLF

   ;

この拡張 BNF 定義が含むヘッダフィールドの順序付けは,

   ;

無視するほうがよい。

 MIME-part-headers

:=

entity-headers

[ fields ]

   ;“content-”で始まらないすべてのフィールドは,

   ;

定義された意味をもつことはできず,無視してよい。

   ;

この拡張 BNF 定義が含むヘッダフィールドの順序付けは,

   ;

無視するほうがよい。

parameter := attribute "=" value

ptext := hex-octet / safe-char

qp-line := *(qp-segment transport-padding CRLF)

   qp-part

transport-padding

qp-part := qp-section


23

X 5810-1:2008

   ;

最大長は 76 文字。

qp-section := [*(ptext / SPACE / TAB) ptext]

qp-segment := qp-section *(SPACE / TAB) "="

   ;

最大長は 76 文字。

quoted-printable := qp-line *(CRLF qp-line)

safe-char := <10 進の値が 33∼60 及び 62∼126 をもつ任意のオクテット>

   ;

更に,JIS X 5810-5 の“mail-safe”の一覧にない

   ;

文字も推奨しない。

subtype := extension-token / iana-token

 token

:=

1*<SPACE,CTL,tspecials を除く,任意の(US-ASCII) CHAR>

 transport-padding

:=

*LWSP-char

   ;

送信者は,長さが 0 ではないトランスポート

   ;

パディングを生成してはならないが,

   ;

受信者は,メッセージトランスポート

   ;

によって追加されたパディングを

   ;

処理できなければならない。

tspecials :=    "(" / ")" / "<" / ">" / "@" /

"," / ";" / ":" / "\" / <">

"/" / "[" / "]" / "?" / "="

   ;

パラメタ値内で使うため,

   ;

quoted-string でなければならない。

type := discrete-type / composite-type

value := token / quoted-string

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

x-token := <“X-”又は“x-”の 2 文字で始まり,空白を含まない,任意のトークン。>


24 
X 5810-1: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 ヘッダの議論から次の文を削除した “しかし,適合ソフトウェアは,版番号を検査し,


25

X 5810-1: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 に固有のセキュリティの課題は,今では細かく示されている。


26 
X 5810-1:2008

附属書 C 

参考)

参考文献

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

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

1990

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

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

ISO/IEC 8859( Part 2∼Part 10 )  Information technology  −8-bit single-byte coded graphic character sets

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 Braden,R., 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


27

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