要約

  • RFC 1292 は 1992 年 1 月の FYI 11、Informational RFC である。商用および公開された X.500 実装について、可用性と能力の説明を集めたものであり、Internet 標準を定めず、列挙した実装を認証しない。
  • DUA 接続性と DSA 接続性は、パイロットとの関係で異なる役割と向きを表す。どちらの記載も、特定の遠隔相手、経路、認可、時点、検索結果を実測したことにはならない。

RFC 1292 を読むとき、最も重要なのは「接続している」という語を一つの状態として扱わないことである。文書は X.500 の実装を、Directory System Agent（DSA）、Directory User Agent（DUA）、そして DUA と通信するクライアントアプリケーションまで含めて説明する。ここには、ユーザーの要求を出す側、ディレクトリ情報ツリーの一部を担う側、その中間に置かれうる軽量クライアントという、異なる位置がある。

この区別は名称だけの問題ではない。誰が要求を開始するか、どこに情報があるか、どの経路で届くか、誰がアクセスを許可するか、どの応答が返るかは、それぞれ別の問いである。RFC 1292 のカタログは、実装の説明を読者が見つけ、候補を絞るための道具だった。候補を発見できることと、候補がある組織の環境で機能することの間にある接続、設定、スキーマ、権限、運用の仕事まで済ませたわけではない。

DUA と DSA の接続性は同じ矢印ではない

RFC 1292 は「Pilot Connectivity」を一語で済ませず、DUA Connectivity と DSA Connectivity を別に定義する。DUA Connectivity は、DUA がパイロットに接続でき、パイロット上の任意のエントリに関する情報を検索できることを指す。標準属性とオブジェクトクラス、さらに COSINE と Internet Schema で定義されたものを表示できる、と記される。これは要求と表示の側から定義された能力である。

DSA Connectivity は異なる。DSA がディレクトリ情報ツリーに接続され、その DSA 内の情報が任意のパイロット DUA からアクセスできることを指す。こちらは情報を保持または提供する側からの関係である。DUA があるエントリを検索できることは、その DUA がその情報を保有することを意味しない。DSA がアクセス可能と説明されることも、すべての DUA、すべての経路、すべての時点で成功した検索があったことを意味しない。

二つのラベルを「パイロットに接続済み」という一つの事実に圧縮すると、向きが失われる。利用者側の要求能力とサーバー側の情報到達可能性は、同じ操作でも同じ責任でもない。前者にはクライアントの構成、経路、要求の形式、相手の応答が関わる。後者には DSA のツリー上の位置、公開する情報、他の DUA からの到達、運用上の継続性が関わる。カタログはこの差を見えるようにするが、それらの条件が実際に満たされたという証跡にはならない。

ここでさらに一段の区別が必要になる。パイロットのエントリを表示できることは、表示された属性が最新であることを証明しない。DSA の情報がアクセス可能であることは、読み手がその情報を利用する許可を持つことを証明しない。要求が発行されたこと、応答が返ったこと、応答が意味するスキーマを正しく解釈したこと、組織がその応答に依拠してよいと判断したことも、それぞれ別の記録を要する。RFC 1292 はこれらを一つの「接続性」へは変換しない。

軽量クライアントは経路全体を持つとは限らない

文書は DUA クライアントアプリケーションを含め、軽量 DUA クライアントについても説明する。これは非 OSI のアプリケーション層プロトコルを使って DUA に通信し、その DUA がさらに DSA と通信して利用者サービスを支える形態でありうる。この説明が示すのは、X.500 に近づく経路が一つではなかったということである。

しかし、軽量クライアントという名称から end-to-end のサービスを読み取ることはできない。クライアントがローカル DUA に届くか、DUA が適切な DSA を知るか、DSA が必要な情報を持つか、複数のスキーマが一致するか、各段階のアクセス条件が通るかは別である。途中の一段が説明されていることは、後続の段が到達可能であることの代用にはならない。

これは階層を多く持つ古いシステムだけの教訓ではない。中間の代理、ゲートウェイ、クライアント、サービスを表す言葉は、しばしば一つの滑らかな利用体験にまとめられる。だが、ある局所的なインターフェースが見えることと、遠隔の情報源が権威を持ち、利用可能で、応答し、利用者が求める意味を持つことは、別々の条件である。RFC 1292 の DUA/DSA の分け方は、その条件の鎖を歴史資料の中に残している。

カタログの行は説明の出所を持っていた

DISI は実装の説明を自らの試験によって書いたのではない。RFC 1292 は、いくつかの Internet メーリングリストを通じて X.500 コミュニティから入力を募ったと説明する。実装記述は実装者とベンダーが書き、DISI は読みやすさを確保するために協力したが、記述の有効性や実装の価値を保証しない。ここで文書が管理するのは、説明の集約と表示であって、説明の内容に対する試験機関としての保証ではない。

したがって、一行のカタログ情報には少なくとも異なる行為が重なっている。実装者またはベンダーが能力を述べる。編集者がその記述を受け取り、あるキーワードの下に置く。独立の技術者が特定の版と構成を相手実装に対して試す。組織が費用、技能、既存システム、セキュリティ、運用責任を考えて採用する。RFC 1292 が直接保存するのは前の二つである。後の二つを読み手のために済ませる権限も証拠も持たない。

この出所は、カタログを軽視する理由ではない。むしろ何を信頼できるかを正確にする理由である。文書は、1992 年初めにどの実装がどのような特徴を自称し、コミュニティがどの分類でそれを比較可能にしようとしたかの証拠になる。特定製品の動作、互換性、支援、または今日の可用性の証拠にはならない。

明示的なキーワードは実行済みの機能ではない

RFC 1292 のキーワードは、実装説明から導かれた略属性である。ある実装をキーワードで索引化するのは、説明本文がその能力に明示的に、暗示ではなく、言及している場合、または説明の著者が入力した場合である。このルールは編集者が周辺情報から能力を推測してしまうことを防ぐ。例えば、ある転送環境の近くにあるからといって、その環境を使うと勝手に分類しない。

ただし、明示性が保証するのは説明と索引の対応であり、プログラムの実行結果ではない。ある機能は特定の版、特定のプラットフォーム、追加モジュール、設定、許可の下でだけ成立するかもしれない。設計上の予定として書かれ、実地の運用として観察されていないかもしれない。キーワードのあるセルは、記述にその語があったという強い手掛かりであって、読み手がその能力を実行し、期待した相手と相互運用できたという記録ではない。

実装種別の用語も同じ範囲にとどまる。API はライブラリと include ファイルが付属すること、DSA Only は DSA だけで DUA を含まないこと、DUA Only はその逆、DSA/DUA は両方を含むことを表す。これらはソフトウェアの形を混同しないための有益な分類である。一方で API が特定の利用者環境で安定すること、DSA が必要な枝を持つこと、DUA が許可されること、両者が同じ属性意味を共有することは示さない。

空欄にも同じ注意が要る。能力がないのか、説明に明示されなかったのか、入力されなかったのか、編集上の分類に入らなかったのかは、カタログの空欄だけでは決まらない。有るキーワードを試験済みと読み、無いキーワードを能力欠如と読む両方の近道は、RFC 1292 の索引規則を越えている。

共通の転送名は一回の関連を作らない

RFC 1292 は Internetworking Environment に CLNP、OSI Transport、RFC 1006、X.25 を並べる。RFC 1006 の項目は、記述が TCP/IP の転送サービスを使うと述べたことを示す。CLNP の項目も、OSI ネットワークプロトコルの使用を示す。これは候補比較を始めるうえで重要な前提である。

しかし、二つの実装が同じ RFC 1006 ラベルを持つからといって、二者間で DUA と DSA の関連が成功するわけではない。プロトコルの版、名前の表現、ディレクトリスキーマ、オブジェクトクラス、参照、経路、相手の認証、アクセス方針、エラー処理が異なりうる。同じソフトウェアであっても、異なる OS や局所設定で別の振る舞いになる。転送ラベルは互換性仮説の一つの材料であり、相互運用試験の結果ではない。

歴史の文章で「X.500 は TCP/IP で接続された」と短く書く場合にも同じ警戒がいる。RFC 1292 が支えるのは、1992 年のカタログが一部の説明を RFC 1006 という分類に置いた、という主張である。特定の接続を主張するには、端点、構成、時刻、操作、応答が必要になる。カタログはその情報を提供するために作られていない。

推薦しないことは責任を曖昧にしたことではない

RFC 1292 の範囲は、実装のインストール、実行、管理の手順を提供しないと明示する。また、組織ごとに必要性と計算環境が大きく異なるため、推薦を行わない。この不在は有用性の放棄ではなく、誰が最終判断を持つかを認める設計である。

推薦には、比較項目を選び、重み付けし、結果の責任を引き受けることが必要である。ある組織では既存の転送スタック、職員の技能、スキーマ、ライセンス、支援、移行費用が決定的かもしれない。別の組織では利用者層、データ責任、セキュリティ、継続性が優先される。同じカタログ行が二つの組織で異なる結論を支えるのは、カタログが弱いからではなく、決定がその外側の条件を含むからである。

整然とした索引は順位表のように見えることがある。だが、記載があることは推奨順位を示さず、記載がないことも否定的評価を示さない。提出がなかった、編集対象にならなかった、時期が合わなかったという可能性が残る。DISI が行ったのは比較の言語をつくることであって、どの組織にどの実装を採用させるかを決めることではない。

改訂の間隔は情報の一部だった

RFC 1292 は、コメント、批評、新規または更新された記述の提出を求める。DISI は十分な数の変更を受け取ったときに新しい版を出し、その十分性は DISI 主席が主観的に決める。ここには、リストの鮮度がソフトウェアの状態だけでなく、提出、編集、判断、配布という人間の流れに依存することが示されている。

一版と次版の間に、実装は変わり、配布先は消え、新製品は出現し、能力の説明は古くなりうる。旧版がそのために虚偽になるのではない。旧版は、その版が作られた時に誰が何を記述し、編集者が何を表示したかの記録として残る。現在の導入判断に十分でないことと、歴史資料として正確であることは両立する。

セキュリティと利用者成果は別の証拠を要する

RFC 1292 は可用性と能力のカタログであり、認証、機密性、完全性、脆弱性、運用実務を保証する資料ではない。記載された実装が許可を得たこと、ホストに到達したこと、パイロットの情報が正しかったこと、組織が導入に成功したこと、利用者が有用な検索結果を得たことも示さない。

この限界を保つことで、文書の歴史的な成果が明瞭になる。RFC 1292 は、X.500 の周辺に散らばった自己記述を候補として発見し、比較を始められる形に置いた。カタログは判断の入口を整えたが、接続の観察、相互運用の試験、組織による採用、サービスの結果を引き受けたわけではない。

出典と証拠の限界

本稿は RFC 1292 — A Catalog of Available X.500 Implementations を用いる。出典は、1992 年 1 月の FYI/Informational の地位、DISI カタログの目的、DSA/DUA/クライアントの区別、メーリングリストを通じた募集、実装者・ベンダーによる記述、保証しないという声明、明示的主張によるキーワード化、可用性・転送・パイロットの分類、インストール手順と推薦を提供しない範囲、主観的な改訂しきい値を支える。導入、後日の可用性、現在の支援、ライセンス、構築成功、到達可能なホスト、パイロット接続、相互運用性、セキュリティ、組織への適合、推薦、完了した検索、利用者の成果を支えるものではない。