この規格ページの目次
4
X 5810-5 : 2008
のサポートを提供する場合,受信メッセージだけにそれを行うことが,適合利用者エージェントに要
求される。適合利用者エージェントは,US-ASCIIテキスト以外を含む非MIMEメッセージを送って
はならない。
特に,MIME-Versionフィールドなしのメールメッセージにおける非US-ASCIIテキストの使用は,
異なる局所変換の領域間でメッセージを送るときに相互運用性を妨げるので,強く非推奨とする。適
合利用者エージェントは,US-ASCII文字集合でプレーンテキスト以外のものを送るとき,正しい
MIMEラベル付けを含まなければならない。
さらに,非MIME利用者エージェントは,たとえMIME中で他の何もサポートしない場合でも,そ
れが送ったメッセージに適切なMIMEヘッダ情報を含むことが可能なように更新されたほうがよい。
この更新は,あったとしても,ほとんど非MIME受信者に影響を与えず,これらのメッセージを正し
く表示するのにMIMEを援助する。これは,他のMIME機能を将来採用することへの円滑な移行の道
筋をも提供する。
i) 適合利用者エージェントは,“=・”で始まり“・=”で終わる“*text”又は“*ctext”の中にある非空白で印字可
能なUS-ASCII文字のどの文字列も,妥当な符号化語(valid encoded-word)であることを保証しなければ
ならない。ここで,“始まる”は,フィールド本体の先頭又は空白の並び(linear-white-space)の直後を
意味し,“終わる”は,フィールド本体の末尾又は線形空白の直前を意味する。さらに,“=・”で始まり
“・=”で終わる“phrase”の中にあるどんな“word”も,妥当な符号化語でなければならない。
j) 適合利用者エージェントは,符号化語がメッセージヘッダ中の適切な位置に現れたらいつでも,箇条
4に規定する規則に従って,符号化語を“text”,“ctext”又は“word”から区別できなければならない。そ
れは,それがサポートするどの文字集合に対しても,“B”符号化及び“Q”符号化の両方をサポートしな
ければならない。そのプログラムは,符号化されないテキストを,文字集合が“US-ASCII”であれば,
表示できなければならない。ISO-8859-X文字集合に関して,メールを読むプログラムは,少なくとも
US-ASCII集合にも含まれる文字を表示できなければならない。
これらの条件に適合する利用者エージェントは,MIME適合であるといえる。この句の意味は,これら
のメールシステムの利用者に,適切にマーク付けされたどんな種類のデータも事実上送ることが,“安全”
であると想定される。それは,これらのシステムが,少なくともそのデータを区別されないbinaryとして
扱うことができ,疑わない利用者の画面上にそれをまき散らすことはないことによる。
MIME適合のフォーマットでデータを送ることは常に“安全”であるというもう一つ意義がある。それ
は,それらのデータが,壊れることはなく,RFC 821及びRFC 822に適合するどんな既知のシステムによ
っても壊されない。MIME適合の利用者エージェントは,利用者がテキストとして見られることを決して
想定しないデータを見せられないという,追加の保証をもつ。
3 電子メールデータ送信の指針
インターネットメールは,完全で一様なシステムではない。メールは,最終目的地に行く途中の多くの
段階で,壊れてしまうことがある。特に,インターネットを通って送られた電子メールは,多くのネット
ワーク技術を通過し得る。多くのネットワーク技術及びメール技術は,SMTP転送環境で可能な全機能を
サポートするわけではない。これらのシステムを通過するメールは,それが転送され得るように,変更さ
れやすい。
インターネットには,多くの非適合MTA (Message Transfer Agent) がある。これらのMTAは,SMTPプ
ロトコルで交信するときに,それが実装されているホストの内部データ構造を利用して動作中にメッセー
――――― [JIS X 5810-5 pdf 6] ―――――
5
X 5810-5 : 2008
ジを改変するか,又ははっきりと壊される。
次の指針は,最も広範なネットワーク技術及び既知の壊れたMTAで無きずに生き残るために想定され
るデータフォーマット(メディア型)を工夫する人に有用であろう。base64符号化で符号化されるものは,
これらの規則を満たすが,よく知られた機構,とりわけUNIXのuuencode機能はそれを満たさないことに
注意されたい。quoted-printable符号化で符号化されたものは,大部分のゲートウェイで無きずに生き残る
が,EBCDIC文字集合を使うシステムへの幾つかのゲートウェイでは生き残れない可能性がある。
a) 幾つかの状況下では,通常のゲートウェイの一部又は利用者エージェント操作として,データに使わ
れる符号化が変更されることがある。特に,base64からquoted-printableへの変換及びその逆変換は,
避けがたいことがある。これは,テキスト本体中の行区切りで,CRLF列の混乱を起こすかもしれな
い。そうであるから,行区切りではないものとしてのCRLFの保存性は,信頼してはならない。
b) 多くのシステムは,システム固有の改行規約を使って,テキストデータを表示し,保存することを選
択することがある。システム固有の改行規約は,RFC 822のCRLF規約 には一致しないことがある。
例えば,CRだけ,LFだけ,CRLF,又は文字数区切りレコードを使うシステムが知られている。その
結果,孤立したCR文字及びLF文字は,一般には許されない。それらは,あるシステムでは,失われ
るか又は区切り子に変換されるかもしれないので,信頼してはならない。
c) UL(US-ASCII値の0)の転送は,インターネットメールでは問題がある。これは,プログラム言語
Cにおいて多くの標準ランタイムライブラリルーチンによって終端文字として使われているNULの
結果によるところが大きい。終端文字としてのNULの使用の実行は,今では確立されたものだから,
メッセージが保存されることを信じないほうがよい。
d) AB (HT)文字は,誤って解釈され得るか,異なる数のスペースへ自動的に変換されるかもしれない。
これは,ある環境では,特にUS-ASCII文字集合に基づかない環境では,避けられない。これらの変
換は,強く非推奨とするが,もしそれが起きる場合には,メールフォーマットはTAB(HT)文字の保存
性に依存してはならない。
e) 76文字より長い行は,ある環境では,折り返されるか又は切り取られる。メール転送で行われる行の
折返し又は切取りは,強く非推奨とするが,幾つかの場合には避けられない。長い行を要求するアプ
リケーションは,無指定(soft)行区切りと指定(hard)行区切りとを何とかして区別しなければならない。
これを行う簡単な方法に,quoted-printable符号化の使用がある。
f) 行の末尾の“空白”文字[SPACE,TAB (HT) ]は,ある転送エージェントで捨てられるかもしれない。
他の転送エージェントが,これらの文字で行を埋めて,メールファイル中のすべての行を同じ長さに
することもある。したがって,末尾の空白の保存性をあてにしてはならない。
g) 多くのメールドメインは,US-ASCII文字集合での変種を使うか,又はUS-ASCIIの文字の多くを含む
がすべては含んでいないEBCDICなどの文字集合を使う。“不変の”集合にない文字の正しい翻訳は,
文字変換ゲートウェイに頼ることはできない。例えば,この状況は,uuencodeされた情報を,EBCDIC
システムであるBITNETを通して送る場合に問題となる。多くのインターネットのホストは,内部で
はUS-ASCII以外の文字集合を使うので,類似の問題は,ゲートウェイを通さない場合にも起こる。
X.400におけるPrintable String(印字可能文字列)の定義は,ある特定の場合に更に制限を加えている。
特に,すべてのゲートウェイを通して一貫性があると知られている文字は,大文字のAからZまで,
小文字のaからzまで,0から9までの10数字,及び次の11の特別な文字である73文字だけである。
(US-ASCIIの10進値で39)
“'”
“(”(US-ASCIIの10進値で40)
――――― [JIS X 5810-5 pdf 7] ―――――
6
X 5810-5 : 2008
“)”(US-ASCIIの10進値で41)
“+”(US-ASCIIの10進値で43)
(US-ASCIIの10進値で44)
“,”
“-”(US-ASCIIの10進値で45)
(US-ASCIIの10進値で46)
“.”
“/”(US-ASCIIの10進値で47)
(US-ASCIIの10進値で58)
“:”
“=”(US-ASCIIの10進値で61)
“・”(US-ASCIIの10進値で63)
最も大きな可搬性のあるメール表現は,73文字のこの集合から意味のある文字だけを使ったテキス
トの比較的短い行に限ることになる。base64符号化はこの規則に従う。
h) 幾つかのメール転送エージェントは,ある文字列を含むデータを壊す。特に,ピリオド(“.”)だけの行
は,幾つかの(正しくない)SMTP実装によって壊されることが知られており,“From ”の5文字(最
後の文字はSPACE)で始まる行も通常壊される。注意深い作成エージェントは,そのデータを符号化
することによって破壊を防ぐことができる。例えば,quoted-printable符号化において行の先頭にある
“From ”の場所に“=46rom”を使い,行の“.”だけの場所には“=2E”を使う。
上記の一覧は,MTAに関する推奨される実行の一覧ではないことに注意されたい。RFC 821のMTAは,
空白の文字を変更すること又は長い行を折り返すことを禁止している。これらの悪い不正な実行は,設置
されたネットワークで起こることが知られていて,実装は,それらが引き起こし得る悪い影響を扱う場合
に頑健であることが望ましい。
4 正準符号化モデル
MIME規定の初期の版では,混乱があった。それは,どのようなときに電子メールデータが正準形式に
変換し符号化されるか,そして,システムごとに改行の表現が大きく異なるとき,この変換・符号化がCRLF
の振る舞いにどのように影響するかについてのモデルに関する混乱であった。このため,符号化の正準モ
デルを次に示す。
MIME実体を作成する過程は,幾つかの段階で行われるものとしてモデル化できる。これらの段階は,
大雑把にいって,PEM [RFC 1421]で使われる段階と似ていて,それぞれの“最も内側のレベル”の本体に
対して実行される。
a) 局所形式の作成 システムの固有フォーマットで,転送する本体を生成する。固有の文字集合が使わ
れ,適切であれば,同様に局所的な行の終端の変換が行われる。本体は,UNIXスタイルのテキスト
ファイル,Sunのラスタ画像,VMSのインデックス付きファイル,メモリ内だけに保存される形式の
システム依存の音声データ,又は情報のある形式の表現のための局所的なモデルに対応するその他の
ものであってもよい。基本的に,データは,メディア型で指定される型に対応する“固有の”形式で
作成される。
b) 正準形式への変換 レコード長,可能なファイル属性情報などの“out-of-band”情報を含むすべての本
体は,普遍的な正準形式に変換される。本体の特定のメディア型及び関連する属性は,使われる正準
形式の性質を指示する。正しい正準形式への変換は,文字集合の変換,音声データの変換,圧縮,又
は様々なメディア型に固有の多くの他の操作を含んでよい。しかし文字集合の変換を含む場合には,
どんな文字集合の変換にも強い意味をもつであろう,メディア型のセマンティクス(例えば,plain以
――――― [JIS X 5810-5 pdf 8] ―――――
7
X 5810-5 : 2008
外のテキストメディア下位型においては,ある種の文字が構文上の意味をもつ。)について注意を払わ
なければならない。例えば,text/plainデータの場合,テキストはサポートされる文字集合に変換され
なければならず,RFC 822に従ってCRLF区切り子で行を区切らなければならない。ただし,次の段
階でquoted-printable符号化又はbase64符号化のどちらかを用いるならば,RFC 822に伴う行の長さの
制限はなくなる。
c) 内容転送符号化の適用 メッセージの本体に適切なContent-Transfer-Encoding(内容転送符号化)を適
用する。メディア型と内容転送符号化との間には固定的な関係はないことに注意する。特に,base64
かquoted-printableの選択の基礎を,本体の与えられたインスタンスに固有の文字頻度数に置くことは
適切であろう。
d) 実体への挿入 符号化された本体は,MIME実体に適切なヘッダとともに挿入される。それから実体
は,必要に応じてもっと高いレベルの実体(メッセージ又はマルチパート)に挿入される。
実体形式から局所形式への変換は,これらの段階を逆にすることによって達成される。元の形式と最終
的な局所形式とが同じである保証はないので,これらの段階の逆は異なる結果を生成するかもしれないこ
とに注意する。
これらの段階はモデルにすぎないことに注意することは重要である。これらは,実際のシステムがどの
ように構築されるかの青写真では決してない。特にモデルは,次の二つの共通設計を説明できない。
a) 多くの場合,符号化に先立つ正準形式への変換は,局所フォーマットを直接理解できる符号化器その
ものに含まれる。例えば,テキスト本体の局所的な改行の変換は,そのフォーマットが何であるかの
知識に基づいて,符号化器そのものを通して実行されるであろう。
b) 符号化器の出力は,メッセージとして転送される前に,一つ以上の追加の段階を通らなければならな
いかもしれない。したがって,符号化器の出力は,RFC 822に規定されるフォーマットに適合しない
かもしれない。特に,変換器の出力が,標準的なRFC 822のCRLF区切り子を使うのではなく,局所
的な改行変換を使って表現されることが再び適切であるかもしれない。
他の実装上の多様性も同様に考えられる。この議論の重要な点は,要求される段階を崩したり追加処理
を挿入したりする最適化にかかわらず,結果のメッセージはここに示されたモデルによって生成されたも
のと整合していなければならないことである。例えば,次のヘッダファイルをもつメッセージは,始めに
text/foo形式で表現され,それから必要に応じて,“bar”文字集合によって表現され,最後にbase64アルゴ
リズムによってmail-safe形式に変換されなければならない。
Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64
注記 RFC 822のCRLF変換と異なる局所的な改行変換を使うフォーマットでメッセージを表現する
システムによって,ある混乱が起きていた。これらのフォーマットが正準なRFC 822/MIMEで
はないことに注意することは,重要である。これらのフォーマットは,メッセージの正準表現
におけるCRLF列が局所的な改行変換として符号化される,RFC 822の代理“符号化”である。
例えば,CRLF行分離列の部分でないLFオクテットを含むbinaryデータを含むMIMEメッセ
ージを表現できないことに注意。
5 要約
この規格では,MIME適合が何を意味するかを定義した。それは,インターネットの電子メールシステ
ムに存在することが知られている様々な問題,及びこれらを克服するためにMIMEをどのように使うかを
――――― [JIS X 5810-5 pdf 9] ―――――
8
X 5810-5 : 2008
も詳述した。最後に,MIMEの正準符号化モデルを示した。
6 セキュリティへの考慮
セキュリティについては,MIME関連の第2部であるJIS X 5810-2に示されている。
――――― [JIS X 5810-5 pdf 10] ―――――
次のページ PDF 11
JIS X 5810-5:2008の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.110 : 情報通信ネットワーキング
JIS X 5810-5:2008の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JISX5810-1:2008
- 多目的インターネットメール拡張(MIME)―第1部:インターネットメッセージ本体のフォーマット
- JISX5810-2:2008
- 多目的インターネットメール拡張(MIME)―第2部:メディア型