要約

  • RFC 3404 は URI 解決を型付き要求として定義した。I2L、I2R、I2C、I2N はそれぞれ場所、資源インスタンス、説明、永続名を求め、単数形と複数形は結果数も保持した。
  • S、A、U は DDDS の次段階に渡す表現を示した。P は DDDS を離れ、アプリケーション固有処理へ移る。リゾルバーの発見は、相手や返却資源の認証を意味しなかった。

成功の表示が正しい問いへの答えとは限らない。作品の説明を求めた利用者にダウンロード候補の場所だけを返しても、関連情報は得られる。しかし問いは置き換わっている。資源そのものを求めたのに書誌情報を返す場合も同じで、通信の成功と意味の成功は別である。

RFC 3404 は 2002 年 10 月に標準化過程の文書として発行され、DDDS による URI と URN の解決アプリケーションを定めた。RFC 3401 が体系を紹介し、RFC 3402 がアルゴリズム、RFC 3403 が DNS NAPTR 規則データベース、RFC 3404 が解決アプリケーション、RFC 3405 が uri.arpa. と urn.arpa. の管理を担当した。

処理はアプリケーション固有文字列から始まる。一般 URI 解決では絶対 URI を正規化して符号化し、scheme を First Well Known Key として uri.arpa. に連結する。URN では名前空間識別子を使って urn.arpa. を引く。NAPTR 規則は入力を書き換え、または委任し、終端結果か別システムへの引き渡しに到達する。

URI と URN の二つのアプリケーションは技術的には同じだったが、運用上は分離された。URN 解決には既存の短絡経路があり、一般 URI 解決の普及に依存させるべきではなかった。名前空間は、すべての URI scheme が同じ仕組みに加わるのを待たずに、自らの有用な解決機能を展開できた。

Services フィールドが答えの型を保持した。I2L は場所を示す URI を一つ、I2Ls は一つ以上返す。I2R と I2Rs は資源インスタンスを返す。I2C は説明、I2N は URN を返す。最後の場合、二つの URN の同一性判定が単純な文字列比較で済まず、名前空間固有規則を要する可能性も明記された。

場所は資源ではない。取得を試せる地点を示す。資源インスタンスはプロトコルが実際に届ける内容である。説明はその内容についての主張であり、永続名は場所が変わっても同一性を保とうとする。同じ識別子が四つの操作を提供できても、一種類の証拠は他の種類を代替しない。

結果数も契約だった。I2Ls や I2Rs の小文字 s は集合を許す。クライアントが先頭だけを保存すれば、複数回答を単数へ変換し、選択方針を勝手に追加する。監査記録には要求サービス、期待した単複、完全な返却集合、消費者が採用した値を残す必要がある。

Services の前には任意のプロトコル名を置けた。しかし名前だけでは URI 解決契約にならない。RFC 3404 は、要求するサービスをどう符号化し、その応答をどう表現するかを別途定義するよう求めた。「HTTP」と書いても、場所要求と資源要求の違い、説明のメディア型、複数値の直列化は決まらない。

ここに能力発見の限界がある。対応可能と広告する端点を見つけても、転送ラベルからアプリケーションプロトコルは自動的には生まれない。広告、観測可能な要求、型付き応答が同じ意味を共有して初めて相互運用になる。

Flags は別の軸を表した。S、A、U は DDDS 終端フラグである。S は結果のドメイン名を SRV 問い合わせへ、A はアドレス問い合わせへ渡し、U は URI を生成する。終端とは DDDS ループが止まるという意味で、その後の検索、接続、認証、内容検証まで終わるわけではない。

P は意図的に異なる。残りの処理をアプリケーション固有体系へ委ね、DDDS の概念から離れる。DDDS 内部の第四の終端形式ではなく、制御境界である。P を普通の終端として記録すれば、別規則系へ権限が移った事実が消える。

2002 年の四フラグは相互排他的だったが、実装は Flags が永遠に空または一文字だと仮定してはならない。将来は組合せを定義し得る。未知フラグの記録は無視して処理を続ける。この判定は通常の順序より先に必要で、新フラグが他フィールドの読み方を変えるかもしれないからである。

Services が空でも有効だった。委任の早い段階では、発行者が最終リゾルバーのプロトコルやサービスをまだ知らないことがある。空は不正でも万能でもなく、判断を後段へ送る。

RFC 3404 は同じ ORDER の集合内に限り、サービス選択の最適化を認めた。クライアントは自分に適したサービスを探せるが、基礎アルゴリズムと同じ入力と出力を維持しなければならない。別の委任経路へ渡ったり、一致後に高い ORDER を調べたりしてはならない。

この制限はローカル能力と公開された権威を分ける。クライアントは同等な候補から扱えるプロトコルを選べるが、別の権威層にある便利な端点を同等扱いできない。さもなければ最適化が委任の書き換えになる。

Additional セクションの SRV やアドレス情報は往復を減らせたが、必須ではない。権威サーバーが一切添付しなくてもアプリケーションは動く必要がある。次の名前の発見、補助データの同時取得、下流接続の成功は別々の出来事である。

安全性も同じ境界で分かれる。リゾルバーを見つけても、安全な通信方法は決まらない。各解決プロトコルが認証と保護を定義する。uri.arpa. と urn.arpa. の DNS 運用には可用性、偽装、委任のリスクがある。DNS 経路が検証済みでも、アプリケーション相手、返却資源、説明の鮮度までは証明しない。

正規表現には実行前の健全性確認も必要だった。正しく委任された規則でも、強力すぎる環境へ無検査で渡せば危険である。出所の真正性と解釈の安全性は異なる証拠だった。

RFC Editor は三件の編集上の正誤を掲載している。Verified の 282 と 787 は Additional Information 処理の参照先を RFC 3404 から RFC 3403 へ直す。Held for Document Update の 2923 は第 4 節の参照番号を修正する。どれもフラグ、型付きサービス、単複の意味を変えない。

運用上の受領証には、正規入力、scheme または名前空間、第一キー、DNS 問い合わせ、完全な NAPTR 集合、既知/未知フラグ判断、プロトコル、要求サービスと結果数、同一 ORDER 内選択、採用規則、S/A/U/P の引き渡し、次の問い合わせまたは URI、要求符号化、認証済み相手、応答メディア型、返却オブジェクト種別、最終消費結果を保存すべきである。

Lu Heng の最小初期仕様の原則はこの分割を説明する。実装間で共有すべき境界だけを精密に定め、個別プロトコルは局所的に進化できる。動くコード優先なら、同一識別子に場所、資源、説明を別々に求め、Additional を除き、未知フラグを加え、同一 ORDER の能力を変える。契約が許した箇所だけ結果が変わるかを確かめられる。

RFC 3404 は、すべての識別子がすべての答えを返すとは約束しなかった。何を求め、どの境界を越えたかを明示させた。そのため「解決成功」は曖昧な緑の表示ではなく、検証可能な主張になった。

出典