要約
- RFC 3367 は、コモンネームサービスへの照会、能力記述、結果と参照、サービスとデータ集合の出所を扱う最小限の共通手順を定めた。
- サービスの発見と選択、登録、所有、名前の一意性は意図的に範囲外とされた。交換形式が共通でも、誰に回答権があるかをプロトコルだけでは決められない。
1990 年代末、ブラウザのアドレス欄には URL 以外も入力されていた。企業名、人名、書名、場所の呼び名を入れ、ブラウザやポータルが検索や移動へ変換した。専門ディレクトリを組み込むには、しかし個別の接続方法が必要だった。
Common Name Resolution Protocol は、その接続部分を共通化しようとした。2002 年に Proposed Standard として公開された RFC 3367 は、人が使う語句とインターネット資源の既存の結び付きを問い合わせる XML の要求と応答を定義した。世界共通の名前空間を作る規格ではない。
コモンネームには強制された構文がない。URI のような識別構造を持たず、URN のように関連付けの一意性や永続性も要求されない。同じ語句を複数サービスが採用し、別々の記録へ結び付けられることが前提だった。
CNRP が始まるのは、問い合わせ先が選ばれた後である。クライアントはサービス記述を求め、利用できる属性やデータ集合を知り、照会を送る。応答には資源記述、状態、別サービスへの参照が入る。集約プロキシも各結果のサービスとデータ集合の出所を残せた。
必須の核は小さい。コモンネーム、サービス内の識別子、資源 URI、説明である。言語、地理、カテゴリーは絞り込みに使えるが、最善努力のヒントだった。どこまで解釈するかはサービスの差別化要素であり、同じ順位を返す契約ではない。
これは公開ネットワーク上の SQL ではない。条件をすべて満たす完全な集合を保証せず、サービスが基準に最も近いと判断した結果を返す。無視した属性や利用できなかった参照先は、部分成功の状態として表現できた。
RFC 2972 は制度上の境界を明記した。サービスの発見と選択、運営、名前の登録と所有、一意な名前を作る方法は初期範囲に含まれない。選択済みの相手と共通手順で話すことはできても、相手そのものは選ばない。
権威はその選択に入る。商用ディレクトリを設定したブラウザと地域サービスを設定したブラウザは、同じ語句から異なる正当な結び付きを受け取れる。CNRP は出所を示せても、世界で一つの正解を宣言しない。
RFC 2972 が区別した公開名前空間では、人名、地名、作品名などに単一の割当機関がない。サービスごとに分類体系も違う。自由なカテゴリー語で異なる分類を完全に対応させられるかは未証明だと同文書自身が認めていた。
RFC 3368 の go: URI はこの境界を構文にした。特定サーバーを含む形と、サーバーを含まずクライアント設定済みの複数サービスへ送る形があった。同じ URI を二台へコピーしても、設定が違えば回答者と結果が違い得る。
接続の開始点は具体的だった。汎用クライアントとサーバーは 1096 番ポートの HTTP を初回接触に実装し、その後に別の転送方法を知らせられた。既知の相手へ接続する方法は決まっても、その相手をどう発見し、なぜ信頼するかは決まらない。
参照は依存関係を伸ばす。サービスは一部の結果とともに別サービスを示し、クライアントが追跡する。ループ検出には、訪れたホストだけでなくサービスとデータ集合の組を覚える必要がある。参照先が停止していれば、結果は完全成功ではなく部分成功になる。
セキュリティも同じ境界へ戻る。RFC 3367 は中間者攻撃、偽の Service オブジェクト、新しい間接層によるサービス拒否を挙げた。Service オブジェクトへ署名できても、検証には権威ある公開鍵が要る。その鍵の取得はサービス発見に依存するため範囲外だった。
暗号は信頼の起点を選んだ後の発言を守る。起点自体は選ばない。暗号学的な正しさと制度的な権威は接続するが、同じ証明ではない。
現在の IANA 登録簿では go は Permanent とされ RFC 3368 が参照される。RFC 3367 も Proposed Standard のままである。これは登録と標準状態の証拠であって、対応ブラウザ数、稼働サーバー、通信量、利用者数の調査ではない。RFC 2972 の市場予測も導入実績ではない。
RFC 2396 と後継の RFC 3986 は URI の一般構文を扱う。RFC 2276 と RFC 2483 は URN 周辺の解決を論じ、RFC 3401 は別の委任型発見体系を記述した。これらは当時の設計探索を示すが、実運用で一方が他方を置き換えた証拠にはならない。
ここでは Lu Heng の二つの論考を分析枠として明示する。“Minimum Initial Specification” は、共通層を決定的な最小核に留め、その後を実装者へ渡す考え方を示す。CNRP は交換を標準化し、権威を標準化しなかった。“On Reality Layers” は、プロトコル適合、サービス本人性、データ出所、返された結び付き、到達可能性、利用者の意図を別層として扱わせる。
CNRP は複数回答を隠さなかった。出所、部分成功、参照のループを表現した。しかし透明性は配布権力を消さない。最初のサービス一覧を制御する者は、共通形式の要求が出る前から回答候補を形作る。
RFC 3367 の歴史的な意味はこの境界にある。問い方は共有できる。誰に答えさせるかを共有するには別の統治判断が要る。規格はそこを越えず、境界が見えるだけの来歴を残した。
出典
- RFC 3367
- RFC Editor の RFC 3367 記録
- IETF Datatracker の RFC 3367 記録
- IETF Datatracker の RFC 3367 履歴
- RFC 3368
- RFC Editor の RFC 3368 記録
- IETF Datatracker の RFC 3368 記録
- RFC 2972
- RFC Editor の RFC 2972 記録
- RFC 2396
- RFC 2483
- RFC 2276
- RFC 3401
- RFC 3986
- IANA URI スキーム登録簿
- Lu Heng: Minimum Initial Specification
- Lu Heng: On Reality Layers
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
