要約

  • RFC 1862は検索、索引作成、対象取得を別の操作として整理した。最終的なアクセス制御は対象で行う一方、存在の漏えいを防ぐため、制限情報を索引にも伝える必要があった。
  • 誰に対しても同じ答えを返すDNS型の発想と、権限のない者には記録の存在も隠す企業文書型の発想は、ワークショップ内でも一致しなかった。
  • 検索結果が証明するのは、特定の索引が特定時点・範囲・方針の下で返した内容だけであり、普遍的な存在、許可、現在地、内容の同一性、真偽、完全性ではない。

空欄は一つの意味を持たない

内部調査の名称を社員が検索したとする。本文サーバーは正しく設定され、権限のない社員には取得を拒否する。しかし一覧に案件名、担当者、日付が出れば、サーバーが拒否する前に調査の存在は伝わっている。守られたのは本文であって、情報全体ではない。

RFC 1862 は、アクセス制御を対象そのもので実施すべきだとしながら、その情報を索引へ伝播させる必要も指摘した。索引は、利用者が対象を取得しようとする前に「その質問は許されない」と答えられるべきだという。

索引が対象の権限を奪うわけではない。対象サーバーは表現を渡すかを決め、索引は質問者が名称、説明、所在への手掛かりを知ってよいかを決める。同じ方針を共有しても、二つの判断は別の責任である。

標準ではなく、未解決問題の記録

IABは1994年10月12日から14日まで、バージニア州Tysons CornerのMCIでワークショップを開いた。参加者は34人、三つの分科会に分かれ、Web、Gopher、WAIS、命名、検索、索引、図書館サービスなどの経験を持っていた。IABの構成員と関係するIESGのエリアディレクターも加わった。

報告は1995年11月に公表された。RFC Editorの記録 はInformationalに分類し、本文もInternet Standardを定めるものではないと明記する。会場と運営上の制約から参加できなかった専門家もいた。

したがって、この文書は後の仕組みが採用したことの証拠ではない。全参加者の完全な合意でも、全世界への命令でもない。価値はむしろ、ネットワーク上の情報を一体として扱おうとした時点で、どの衝突がすでに見えていたかを保存した点にある。

検索は参照先の一覧を調べることだった

報告の定義では、検索とは情報を指すディレクトリを調べることであり、索引作成とは情報を走査してディレクトリを作ることである。複数の索引を組み合わせれば統合ディレクトリになる。この整理では、結果は対象そのものではなく、対象についてのポインターである。

ここから証拠の限界が分かる。記録を見つけても取得許可は得られない。場所を得ても、そこに以前と同じ内容があるとは限らない。結果がなくても、対象が存在しないとは限らない。範囲外、未更新、障害、別名、方針による非表示が同じ空欄を作り得る。

人が作る索引は品質を高めやすいが費用がかかり、機械による索引は広げやすいが判断の質は同じとは限らない、と報告は論じた。索引を組み合わせるにはURNのような共通形式が必要だとも考えた。これは相互運用への要求であり、単一で完全な世界索引が存在したという記述ではない。

ロボットを歩かせる費用は誰が負うのか

ワークショップは概して、情報提供者が索引作成を制御すべきだと考えた。ロボットがネットワークを巡回する代わりに、提供者がローカルな要約を作り、索引へ送る方法が望ましいとされた。帯域とサーバー負荷を抑え、提供者が公開範囲と記述を管理できるからである。

これは提案であり、実装済みの普遍的慣行ではない。それでも費用と権限のずれを示す。集約の便益を索引側が得る一方、走査、計算、更新、漏えいの費用は提供者が負い得る。提供者発の要約は、そのずれを調整する制御面だった。

ただし提供者自身も中立ではない。要約を省略し、更新を遅らせ、都合よく見せるかもしれない。外部索引はより広く見つけられる代わりに、古い記録や望まれない発見を増やす。RFC 1862は選択を消さず、誰がどの費用と誤りを引き受けるかを見えるようにした。

検索対象は「インターネット全体」ではなかった

報告は「Internetを検索する」という言い方を不適切とみなした。実際に検索するのは、特定の公開情報空間である。公開空間と私的空間の区別も、なお研究課題だった。索引の境界を省略すれば、その回答は世界全体についての断言に見えてしまう。

運用上は、どの空間を収集し、誰が要約を供給し、いつ更新し、どの質問者に何を返したかを付けなければならない。境界を書かないゼロ件は、もっとも強く、もっとも誤って読まれやすい結果である。

同じ名前には同じ答えか、存在も秘密か

一方の参加者は、索引がDNSのように質問者の身元に左右されず同じ結果を返すことを望んだ。これはキャッシュ、再現性、共通の名前空間に向く。別の参加者は、企業の記録管理では、権限のない者に文書の存在さえ知らせてはならないと指摘した。

身元ごとに回答を変えれば、認証が必要になり、問い合わせ履歴と人物を結び付け、キャッシュも監査も複雑にする。報告は匿名利用の価値にも触れていたから、秘密を守る仕組みが同時に新しいプライバシー負担を作ることも見逃せない。逆に全員へ同じ回答を返せば、秘匿すべき関係がメタデータから現れる。文書はこの対立を一方的に解決しなかった。

名前と場所と権限を混ぜない

RFC 1737 は、URNを永続的な識別、URLを場所、URCをアクセス制限や費用を含み得るメタデータとして整理した。資源には場所がない場合も、一つまたは複数ある場合もある。したがって名前の解決は許可でも、内容の保証でもない。

RFC 1738 はURLが後日も同じ対象を指す保証をしないと述べ、NNTP URLの対象がローカルにしか利用できない場合も示した。RFC 1630 の共通構文も、すべての名前やアドレスが同じ性質を持つという意味ではなく、安全性はそこで論じられていなかった。

四文書を重ねると、名前、索引記録、場所、対象取得が別々の証拠段階として見える。一段の成功から、次の段の成功を推論してはならない。

更新されない解決は半分の基盤である

RFC 1862はURN基盤に検索と更新の両方が必要だとした。古い場所や撤回済みの要約、変更前の制限が残れば、検索結果は過去の状態を現在の事実として示す。更新は補助作業ではなく、回答の時間的意味を決める機能である。

結果を証拠として残すなら、時刻、索引、範囲、認証状態も保存すべきだ。後で結果が変わっても、対象の消滅だけが原因とは限らない。索引、マッピング、方針、サービス状態のどれが変わったかを分離して確認する必要がある。

結果に言わせてよいこと

安全な表現は限定的である。「この時点、この索引、この問い合わせ条件で、この記録が返った」。危険な表現は境界を飛び越える。「世界中で存在する」「閲覧できる」「同じURLは同じ内容を保つ」「表示されなければ存在しない」。

RFC 1862は現代の検索サービスを予言した文書ではない。だが、発見と取得を分離したため、どこで何が漏れ、どの証拠で何を主張できるかを明確にした。文書の扉より手前にある索引の門は、補助的な一覧ではなく、独自の開示判断を行う場所だった。

出典