要約

  • RFC 2157 における mapping は一方向の変換であり、equivalence には二つの mapping を通した無損失の往復が必要だった。
  • カプセル化は原形式への復元可能性を保てても、中間のメールシステムが本文を解釈・表示できるとは保証しなかった。
  • 同じバイト列、妥当そうなファイル名、一回の変換成功は一つの受領証にすぎず、逆変換、メタデータ復元、利用可能性、配送結果は別に確認すべきだった。

等号は往復の後に置かれた

1998 年 1 月に公開された RFC 2157 は、X.400 と RFC 822/MIME を結ぶ MIXER の本文変換を担った。RFC 2156 がメールシステム全体の相互接続を扱う一方、RFC 2157 はテキスト、添付、multipart、転送メッセージ、署名・暗号化コンテンツの表現に踏み込んだ。

冒頭の用語集は検証方法まで定めている。mapping は X.400 本文を MIME 本文へ、またはその逆へ変える方法の記述である。equivalence は二つの mapping の組であり、両者を続けて適用したときに損失なく変換できることを指す。

したがって、MIME 入力から有効な X.400 本文を作れたという試験は片道の証明でしかない。帰路を担当するゲートウェイが別の規則を選ぶかもしれず、逆規則を実装していないかもしれない。最初の変換で捨てられたパラメータを戻す場所がない場合もある。構文受理は往復同一性の証明書ではない。

カプセル化が守るのは意味ではなく帰還可能性

RFC 2157 はカプセル化を、片方のメールシステムのオブジェクトを他方の中で運べるよう包む処理と定義した。中間システムが本文を合理的に理解できるとは期待しない。その代わり、元のシステムに戻すゲートウェイが原形式を損失なく復元できることを狙う。

FTBP や BP15 の容器は MIME の種別、パラメータ、ヘッダー、正規化された本文オクテットを保持できた。逆方向では application/x400-bp が X.400 の拡張本文を MIME 内に通せた。これは将来のデカプセル化装置に向けた保管であり、途中の利用者が閲覧・編集・安全な実行を行えるという宣言ではない。

同じ章には BP14 の content passing もあるが、RFC 自身が損失のある変換と呼ぶ。ヘッダーと transfer encoding を外し、オクテット列だけを残すため、元の MIME type を復元する逆変換はない。戻ったオブジェクトは application/octet-stream になる。内容の材料は残っても、型の履歴は失われる。

ファイル名は判断材料であって型の権威ではない

当時の MIME と X.400 は非テキスト情報の扱いを変え続けていた。RFC は、受信者の能力、送信者の希望、次ホップの制約、内容やファイル名から得るヒントを使って変換を選ぶ余地を認めた。BP14、一般的な FTAM file、application/octet-stream では、拡張子を見る実装も許容された。

しかし、ヒントが事実になるわけではない。Content-Disposition の filename を FTBP の pathname に移す規則では、/ や \ を特別扱いせず、ローカルファイルシステムで通常の安全対策を取るよう求めた。例に /etc/passwd を置いたのは、送られた名前が保存先を認可しないことを鮮明にする。

application/octet-stream には二つの必須経路があった。MIXER 適合製品は X.400 の BilaterallyDefined と FTBP Unknown Attachment の両方、および選択可能な設定を持たなければならない。BP14 は MIME パラメータを除去する。FTBP はより多くのファイル属性を運び、本文バイトを両方向にコピーする。

どちらも仕様上の出力を作れるが、保持する不変条件は同じではない。padding を捨てれば最後のバイトの解釈が変わり得る。disposition は無視され、帰路では attachment に固定される。新しい MIME ヘッダーを格納できない本文型なら情報は消える。局所的に正しい変換が、別の経路との同値性を自動的に作ることはない。

レジストリは変換対を記述しただけだった

同値関係の登録には MIME type と X.400 body part の名前だけでなく、必要な OID、ASN.1 構造、変換アルゴリズム、conversion prohibited と conversion with loss prohibited の効果を記す必要があった。独立した実装者が再現できる粒度が求められた。

目的はゲートウェイ間の一貫性を高めることだったが、RFC は登録を強制実装の一覧にはしなかった。すべての登録変換を各ゲートウェイが持つ必要はなく、ローカル変換のすべてを登録する必要もない。登録行は公開された合意を示す。特定製品の実装、稼働設定による選択、受信側の利用まで証明するものではない。

表には IA5Text、GeneralText、画像、転送メッセージ、汎用添付に対応する規則が並ぶ一方、音声、動画、いくつかの X.400 本文はカプセル化へ送られる。署名や暗号化 multipart を不用意に「読める形」へ変換すれば、保持すべき暗号学的性質そのものが壊れるため、特別な保存経路が選ばれた。

往復が成功しても利用結果は別である

監査可能な試験では、入力バイト、ヘッダー、パラメータ、入れ子位置を固定する。変換表の版、受信者能力、送信者指示、ヒューリスティック入力を記録し、出力で何を保持・移動・削除したかを残す。その後、名指しした逆 mapping を実行して原本と比較する。

表現上の往復が完全でも、受信者の利用を代弁できない。ユーザーエージェントに handler がない場合がある。ファイル名はローカル規則に反するかもしれない。暗号化本文は意図どおり不透明かもしれない。配送、安全な処理、表示、人の理解は後段の観測である。

Lu Heng のランニングコード優先は、表とアルゴリズムを可能性、実行した往復と比較を運用事実として読む視点を与える。最小初期仕様は、共通層を可逆な対に絞り、受信ポリシーまで中央化しない。現実の層は、登録、実装、選択、保存されたバイト、利用可能な対象、最終結果を別々の証拠として扱う。

RFC 2157 は、あらゆる本文がどこでも理解されると約束しなかった。片道を mapping、無損失の往復を equivalence、途中で理解されなくても帰路を残す方法を encapsulation と呼ぶことで、相互運用性の主張を検査可能にした。

情報源