要約

  • RFC 2156 の MIXER 適合性は、適合設定が可能なソフトウェア一般ではなく、X.400 と RFC 822/MIME を結ぶ一つの稼働インスタンスに適用された。
  • 閉じた共同体向けのローカル・ゲートウェイでも、配布リストや域外 X.400 利用者との交換によってグローバル経路の一部になり得た。
  • 証拠は製品機能から、実設定、MCGAM、各境界通過、変換記録、サービス保持、配達結果へ段階的につなぐ必要がある。

箱を替えずに役割が変わる

一通の試験メールが変換できたとしても、その結果が後日、本番の配布リストを通るメールにそのまま当てはまるとは限らない。1998 年1月の RFC 2156 は、X.400 と RFC 822/MIME の間に複数のゲートウェイが存在する世界を前提に、まさにこの差を明文化した。

グローバル・シナリオでは二つのメール網が複数ゲートウェイで接続され、メッセージは境界を何度も越える。そのため各ゲートウェイには一貫した動作が必要になる。ローカル・シナリオは閉じた共同体を世界のメール網へ接続し、接続性や認可方針で範囲を絞る。後者なら MIXER に似た限定機能でも目的を果たせる場合があり、完全なグローバル写像には追加の実装・配備コストがかかる。

しかし RFC は、ローカルのまま固定されるとは考えなかった。ADMD の顧客向けに導入されたゲートウェイが、配布リストと非顧客の X.400 利用者との通信によってグローバル運用へ入り込む例を挙げる。筐体も製品名も同じで、経路だけが責任を拡張する。

そこで適合性の対象は「実装」だけではなく、ゲートウェイの「インスタンス」だとされた。機能を実装していることは必要条件だが、稼働設定の証明ではない。

配布リストは境界を反復させる

X.400 利用者が RFC 822 側の配布リストに送信し、そのリストに自身や別の X.400 宛先が含まれていれば、アドレスと本文は再び境界を越える。単一変換と思われた処理が、別々の管理者、写像表、バージョン、本文方針を通る連鎖になる。

RFC 2156 は反復写像を、とくに配布リストで不可欠と位置付けた。アドレスを二重符号化せず、返信が経路を逆にたどれるよう、対称性と可逆性を設計した。ただし複数回の通過で得られるサービスは、おおむね RFC 822 の最低共通部分まで下がるとも述べる。標準 RFC 822 に対応項目がない X.400 サービスは、往復後に保持されると期待できない。

可逆な返信経路は、意味の完全保存ではない。重要度、通知、trace、変換禁止、本文の解釈、受信者の行動まで同一だったとは証明しない。単一ゲートウェイ内部の再帰と、複数ゲートウェイを通る source route も分けて考える必要がある。

適合付録は設定表でもあった

Appendix G は、必須機能を欠く場合に適合を名乗れないとした。フィールド形式、MCGAM、trace、三種のグローバル写像へのアクセス、RFC 2157 の本文写像、MIME 生成時の RFC 2045 が含まれる。また、対応するメール転送プロトコルと X.400 バージョン、グローバル写像の取得方法を明示しなければならない。SMTP を使うなら附属書 A も必須になる。

これらは稼働インスタンスの属性である。DNS と X.500 のコードが製品内にあっても、プロセスが古いローカル表を参照していれば同じではない。trace 機能が存在しても、対象経路で無効なら証拠は残らない。

必須の伴走文書 RFC 2157 は、製品で設定可能なら機能は「実装済み」と数える一方、その設定だけで運用するよう製品を拘束しない。つまり製品能力の定義自体が、RFC 2156 のインスタンス適合と別である。

RFC 2157 では受信者能力、送信者指示、内容の推測、次ホップ制限に応じた選択も許される。未知本文を拒否、欠落表示、カプセル化のどれにするかで、能力が同じ二台でも見かけ上異なるサービスになる。監査すべきなのは、どの選択肢が存在したかだけでなく、そのメールで何が選ばれたかである。

成功した変換は一枚の受領書

RFC 2156 が単一通過について「サービスをサポートする」と言うとき、意味の対応、重大な情報損失がないこと、必要な動作の実行まで含む。構文上の出力だけを見て、その強い言葉を借りることはできない。

検証記録には、製品版と必須機能、インスタンスと有効設定、MCGAM の出所・ハッシュ・参照結果、配布リスト展開、各通過の入出力指紋、写像規則、カプセル化・欠落、trace を残す。そこからサービスを評価し、宛先受理、メールボックス配達、表示、人の受領を別々に観測する。

Lu Heng の Running-Code Primacy は、ここでは編集上の視座であって RFC の要件ではない。標準とバイナリは互換性の可能性を示し、稼働設定と実経路が現実を示す。Minimum Initial Specification は主張を局所検証可能な単位に分け、Reality Layers はラベルという象徴を実行証拠と混同しないための補助線になる。

RFC 2156 は特定製品の失敗や現在の普及率を報告していない。その歴史的価値は、証明対象を「ソフトウェアができること」から「その経路のインスタンスが実際にしたこと」へ移した点にある。

出典