要約

  • RFC 1431では、対象を発見したか、ほかのエントリがいくつ混じったか、基盤のディレクトリ処理がどれほど必要だったかは別々の成果だった。
  • SearchStonesはBind、Read、List、Searchを重み付けしたが、その値にはQuipuの複製方式、DITの形、DSA実装という試験環境が入り込んでいた。
  • 実運用する組織数と、開発者・提供者の外部による公開評価は別項目であり、検索の点数から採用や総合的優位を推測することはできなかった。

答えが出た後に残るもの

Paul Barkerのエントリが画面に現れる。白ページを使う人にとっては、これが成功である。しかし評価者には、まだ二つの見えない問題がある。目的の人物以外に何件を返したのか。そして、その画面を作るために分散ディレクトリは何をしたのか。

1993年2月のRFC 1431は「DUA Metrics」と題され、Directory User Agentと利用者向けインターフェースの評価基準を示した。主な場面は人物を探す白ページである。プロトコル機構が正しく動くことを前提に、利用者が触れる道具の性質に焦点を合わせた。

文書は最初から万能順位を警戒する。異なる道具は異なる利用者と仕事を対象にする。「どちらが優れているか」は、誰が、何を、どのデータから、どこを起点に探すかを示さなければ成立しない。

検索結果は三つに分解された。対象エントリを発見したか。ほかのエントリを何件返したか。下層でどれだけのディレクトリ処理を行ったか。第一は命中、第二は絞り込み、第三は見えない仕事量である。正しい一件だけを示す検索と、正しい一件を大勢の候補に埋める検索は同じではない。

操作に値段を付ける

第三の観測単位がSearchStoneだった。Bindは5、Readは1、Listは2、一階層のSearchは3、部分木全体のSearchは5と数える。操作履歴を重み付き合計にすれば、滑らかな画面の裏でクライアントが共有基盤に要求した仕事が見える。

対象を発見できなかった場合も合計を表示すべきだとされた。失敗は、それまでのBindやSearchを消さない。少ない手順で合理的に停止した失敗と、多くの処理を費やして空振りした失敗を区別できる。

ただし、重みは自然法則ではない。RFC 1431自身が、一階層検索の値にはQuipu実装で兄弟間の複製が広く使われていた事情が反映されると説明している。実装文化が単位の内部にある。

SearchStoneは秒数でも利用者満足度でもない。低い値は短い応答時間とおおむね相関するが、常にではない。数値は選択した重みによる操作構成を表し、時間や品質の原因をすべて含むわけではない。

一人を探す十の問い

試験には、容易なものから難しいものまで十種類の問い合わせが用意された。すべて作者Paul Barker自身のエントリを探す。さらに、対象DSA cn=Vicuna,c=GBへ直接接続するよう提案された。

既知の対象なら正解を確認できる。同じ人物について手掛かりを変えれば、不完全な入力をクライアントがどう扱うか比較できる。接続点を固定すれば、試行間のばらつきを一つ減らせる。

同時に、ここが推論の境界になる。一人の名前は、あらゆる言語、文字体系、組織、木の位置を代表しない。対象DSAへの直結は、すべての利用者の経路ではない。十の問いは精密な探針であって、人口調査ではない。

表から表へ数値だけを移すと、この境界が消える。点数の意味には、対象人物、問い合わせ表現、フィルター、出発点、対象DSA、データ配置、複製状態が付着している。短い数字だからといって、原因まで持ち運べるわけではない。

物差しの下で変わる地形

Directory Information Treeの深さは一様でない。DSA実装ごとに性能特性が異なり、その組み合わせも変化する。ドメインごとに複製戦略が違い、性能への影響は大きい。フィルターの複雑さや論理結合は重みに含まれない。

木の深さは移動距離を変える。実装は同名操作の内部コストを変える。複製はデータとの距離を変える。フィルターは操作ラベルを変えずに計算量を変える。ネットワーク遅延は操作数の外側から作用する。

同じSearchStoneでも時間は違い得る。小さい合計が遅い場合もある。強い複製を前提に磨いた戦略は、別の配置では利点を失う。責任ある説明は、「このクライアントが、この条件で、この操作列を作った」となる。

採用は別の証拠だった

RFC 1431は、製品を実運用する組織数を別に尋ねた。開発者または提供者の共同体の外で評価されたか、その評価が公開されているかも別に尋ねた。

これは証拠の飛躍を防ぐ。試験成績がよくても採用されるとは限らない。広く導入されても効率的とは限らない。提供者の詳細な自己評価は独立評価ではない。外部評価があっても、方法が非公開なら検証可能性は異なる。

隣接するRFC 1430は、世界規模のX.500ディレクトリを構想し、短期的に白ページ、X.509支援、試行運用を重視した。一方、既存データを整合した枠組みに写す作業は、サーバーや利用者エージェントを設置する以上の運用労力を要すると認めた。導入とは、ソフトウェアの起動だけでなく、組織がデータを分類し、委任し、保守することだった。

RFC 1202の文字ベースのDirectory Assistance ServiceとRFC 1249のDIXIEは異なる接続形態を示し、RFC 1274はスキーマの背景を与える。DUAは、プロトコル、データ、DSA、複製、運用組織からなる系の、人に見える端だった。

証拠を一段ずつ置く

評価者が人物と問い合わせを選ぶ。クライアントが指定点から始まり、フィルターを構成する。DSAと複製が操作を実行する。対象が現れるか外れ、余分な結果が入るか除かれる。操作が数えられ、時間が観測される。人が使いやすさを判断し、組織が導入を決め、外部者が評価し、報告を公開するかもしれない。

下段は上段を証明しない。Paul Barkerを一度見つけたことは、その試行で彼が返ったことだけを示す。絞り込み、低コスト、速度、別の利用者への適合、採用、独立検証までは示さない。

RFC 1431の歴史的な強さは、共通単位を作りながら、単位の縫い目を隠さなかった点にある。重みには由来があり、試験には固有名があり、接続先には位置があり、測らない項目には結果がある。

限定された測定は役に立つ。問い合わせ、接続点、操作履歴、重み、失敗、トポロジーを合計と一緒に保存すれば、局所比較と診断が可能になる。合計だけなら、一つのディレクトリの事情が世界の法則に見えてしまう。

RFC 1431はセキュリティを論じず、製品の勝者も、その後のX.500の成否も報告しなかった。残したのはより確かな原則である。仕事を数えるなら、何を仕事と決めた者も見えるようにしなければならない。

情報源