要約

  • RFC 3981 の IRIS 中核は、それだけでは有用なレジストリ・サービスにならないよう設計された。具体的なクエリ、結果、エンティティ・クラスはレジストリ型のスキーマが、認証とセッションは別のトランスポート層が定めた。
  • 共通 lookup は万能検索ではない。XML が妥当であること、サーバーが対応すること、実行が許されること、結果を受け取る権限があること、クライアントが意味を理解することは別々の条件である。

汎用クライアントが未知の応答を受け取り、要素を一つも取りこぼさず画面に並べたとする。表示は技術的に正しい。それでも、どの欄が識別子で、どの関係が重要で、何が欠けているかを判断できなければ、利用者にとってはほとんど答えにならない。RFC 3981 は、この「読める」と「分かる」の距離を仕様の外へ追いやらず、設計境界として明記した。

RFC 3981 は 2005 年1月、XML を用いる Internet Registry Information Service（IRIS）の中核を Standards Track として定めた。ステータス記録、エラッタ、Datatracker の履歴からは、のちに RFC 4992 が更新を加えたことも確認できる。ただし、これらは配備数、利用率、稼働中のサービスを示す資料ではない。

構造は三層に分かれていた。レジストリ固有層がクエリ、結果、エンティティ・クラスを定義する。共通の IRIS レジストリ層が検索集合、結果集合、参照、継続、レジストリ型の識別方法を提供する。アプリケーション・トランスポート層が認証、メッセージ配送、接続、セッション、トランスポート用 URI を扱う。中央の共通層は橋ではあっても、上下の意味や権限を所有しなかった。

中核スキーマには、基底となるクエリ型が一つ、単独で現れる結果型が二つあるだけで、レジストリ構造は定義されない。仕様自身が、単独では用途が限られると説明する。各レジストリ型は URN で識別され、その値は XML 名前空間とスキーマも示す。サーバーは複数の型を提供できるが、中核が具体的なレジストリや全体を貫く共通ツリーを知るわけではない。

意味は派生仕様に置かれた。RFC 3982 とそのステータスはドメイン・レジストリ型を定め、RFC 4698はアドレス・レジストリ型を定めた。二つが別文書なのは中核の失敗を補うためではなく、異なるデータ・モデルを異なる場所で定義するという約束の実行だった。

lookup と search の区別も重要だ。lookup は一つの離散値を一つの索引に照合する。共通の lookupEntity はレジストリ型、エンティティ・クラス、エンティティ名を指定する。部分一致、複数索引の組み合わせ、同じ索引への複数条件はより広い検索になる。RFC 3981 は全レジストリ型を横断する標準検索言語を置かず、それぞれの型に有効な検索を委ねた。

設計付録が「万能クライアントの誘惑」と呼んだのは、そのためである。汎用ソフトウェアでも lookup と素朴な表示はできる。使いやすい検索を組み立て、結果を適切に見せるには、取得したデータについての固有知識が要る。共通クエリ言語を足しても知識は消えない。利用者の意図を最小公分母へ翻訳する仕事が増え、利用者にも問題領域の理解が残る。

公開レジストリには運用上の理由もあった。複数索引に部分値を組み合わせられる柔軟な検索は、熟練者にも濫用者にも便利である。サービスを守る運用者は高コストの機能を止めるかもしれない。すると、共通言語が提供すると称する機能ほど、各所で利用不能になる。RFC 3707 とそのステータス記録には、IRIS に先立つ CRISP の検索、分散参照、版管理、濫用者に関する要件が残る。これは設計判断の背景であり、攻撃頻度や性能を計測した証拠ではない。

参照も一種類の成功通知ではなかった。entity reference は、別のエンティティについて具体的な知識があることを示す。search continuation は、別の権威が探す先になり得るという手がかりにすぎず、別の情報や何も返さない場合もある。ループを避けるため、クライアントはどちらも一度だけ追うよう求められた。継続先を受け取ったことは、到達、最終権威、結果取得の証明にならない。

エラーも境界を保存する。invalidName は名前の構文、invalidSearch は検索の意味、queryNotSupported は機能、limitExceeded は資源制限、nameNotFound は索引上の不在、permissionDenied は認証情報に対する許可を表す。妥当な XML でも、無意味、未対応、高コスト、無権限のクエリを運べる。

トランスポートも中核から切り離された。RFC 3983 とそのステータスは BEEP への写像を定義した。後年の RFC 4992 は XML を分割してパイプライン化する TCP 転送 XPC で RFC 3981 を更新し、ステータス、エラッタ、Datatracker がその文書状態を記録する。フレーミングやセッション方式が変わっても、検索の意味を決める主体は変わらない。

現在の IANA URI Schemes レジストリには iris と関連方式が、IETF XML Registryには iris1 名前空間が残る。これは登録の持続性を示すだけで、現行サービス、広い採用、成功した問い合わせを保証しない。

RFC 3981 が標準化したのは、異なる世界の中身ではなく、その接合部だった。万能クライアントを約束しなかったからこそ、共通構文とローカルな理解を混同せずに済んだ。不完全さは未完ではなく、責任の所在を見えるままにする仕切りだった。

Sources