要約

  • RFC8141では、任意のr、q、f成分をURNの名前としての同一性の比較から除く。それは、どのサービス要求からも除いてよいという規則ではない。
  • q成分は名前の付いた資源、またはサービスを提供するシステムへ渡す情報である。解決器は自らの処理にqの情報を要求してはならない。解決先のURIに既存のクエリがある場合、RFCは一律の結合方法を指定せず、解決器が戦略を文書化することを勧める。
  • r成分の構文を置くことと、利用可能な解決サービスの意味を定義することは別である。RFC8141では後者を将来へ残している。名前、要求、表現、アクセス許可の判断を別々に扱うことが、局所的な責任を見えるようにする。

共通の比較器を、共通の判断機関にしない

ある調達担当者が、名前の重複を減らせるという説明で新しい識別子ライブラリを選ぶ。索引はすっきりし、二つの入力を同じ名前だと認識するようになる。ところが、その比較用の出力をそのまま要求生成にも使ってよいのかは、別の質問である。これは想定上の例であり、本稿が特定製品で見つけた不具合ではない。問題は、便利な共通処理が、本来別の主体に届くはずだった情報まで引き受けてしまう設計にある。

URNはUniform Resource Nameの略で、URIの体系の中で名前を表す。2017年4月のRFC8141は構文と比較の規則を整理し、名前に任意の成分を伴わせる方法も定めた。その文章を「同じURNなら何を要求しても同じ結果」と読んではいけない。ある資源に同じ名前が付いていること、ある解決器が同じ場所を返すこと、その場所から同じ表現が得られることは、同じ命題ではない。

比較の核となるのは名前そのものだ。urnと名前空間識別子であるNIDの大文字小文字をそろえ、名前空間固有文字列NSSのパーセント符号化に現れる16進のAからFを大文字にする。この規則は、NSS全体を小文字にする指示ではない。パーセント符号化を復号してから何でも同じ文字に寄せる手順でもない。汎用の文字列清掃を導入するほど、規格に忠実になるとは限らない。

任意のr、q、f成分は、その名前の同一性を調べる際には含めない。比較器は、資源へ渡す条件やクライアントが使う部分指定まで考慮して、同じ名前を無数に増やす必要はない。一方で、比較に使わない情報が要求処理でも不要だという結論は出ない。比較器の入力から必要な鍵を作ることと、元の要求を永久に書き換えることを分ける必要がある。

名前空間は追加の同一性規則を定められる。ただし、基本規則で同じとされるものを後から別の名前に戻すためではない。基本比較が見落とす同一性を拾い、偽陰性を減らす方向である。この制約は、各名前空間に何でも自由に決めさせるのでも、中央の比較器があらゆる名前空間の事情を知るのでもない。その中間に、共通に維持する最低限の関係を置いている。

qの受け手は、必ずしも解決器ではない

q成分は?=で始まる。RFC8141が想定するのは、名前の付いた資源、または関連サービスを提供するシステムへ伝える情報だ。実際にどの選択肢を意味するかは、そこで使われる規約による。本稿は、違うqなら必ず違う内容になるとは主張しない。処理に影響する場合も、同じ表現へ至る場合もあり得る。重要なのは、同一の名前であるという理由だけで、その情報を削除する一般規則にはできないことだ。

規格は、解決器が自分の処理のためにqの情報を要求することを禁じている。これによって、名前を解決する役割と、その先で要求を解釈する役割を切り離せる。解決器はすべての資源固有の業務条件を理解する承認機関にならなくてよい。「要求してはならない」は「いつでも捨ててよい」とは違う。情報の意味を解読せずに、次の受け手へ運ぶ設計は成り立つ。

特に分かりやすいのが、解決で一つのURIの位置指定子を得る場合である。RFC8141は、その場合にURNのq成分を得られた位置指定子のクエリ部分へコピーする説明をする。比較のときに除かれた成分が、別の段階では仕事を持つ。名前索引の最適化が要求の配達に取って代わってはいけない理由が、ここにある。

ただし、この説明をすべての解決結果へ無条件に広げることもできない。解決の方式や結果の種類には範囲がある。ある事例を支える規則と、すべてのサービスについて断言する規則の距離を保つことが、正しい実装契約の出発点になる。構文上の成分名を並べるだけでは、どこで誰がそれを解釈するのかは明らかにならない。

既存のクエリとの衝突を、見えない既定値にしない

解決器が返そうとする位置指定子に、既にクエリが付いていたらどうなるか。そこには、資源へのアクセスで必要とされる別の情報が入っているかもしれない。元のURNにもqがある。この二つをただつなぐ、どちらかを上書きする、同じ項目名を整理する、といった選択肢は技術的には考えられる。しかし、RFC8141はこの場合の必須の振る舞いを指定しない。

その代わり、解決器が採る戦略を文書化することを勧める。これは、どの結合方法も同じ結果を生むという宣言ではない。利用者と提供者の間で、局所的な処理の選択を説明可能にする責任の置き方である。あるサービスの方針を読んで初めて分かることを、URN構文だけから保証される性質に変えてはいけない。

たとえば試験環境で、既存のクエリを持つ位置指定子と、qを伴う同名の入力を用意することはできる。まず比較結果を確認し、次に作られた位置指定子を観察し、さらに資源側の結果を確認する。この三つを一つの「一致した」という報告に縮めると、どの境界で情報が変わったか分からない。本稿ではその試験を実行していない。提案しているのは、結果の善し悪しを決めつけずに説明を検証する方法だ。

公開された方針がない場合も、直ちに一つの正解を外から押し付けることはできない。規格の要求水準と、調達で求める説明の水準を分けて考えるべきだ。規格のSHOULDに対応した説明を求めることは合理的である。一方、特定の上書き優先順位を規格そのものの命令として売り込むなら、その追加の根拠が要る。説明不足を補う行為が、新しい普遍規則の発明になってはならない。

予約されたrは、出来上がったサービスではない

r成分は?+から始まり、解決サービスへ向けた情報を置く場所として用意されている。ここでも構文と意味を分ける必要がある。RFC8141は、その意味を将来の標準化へ残し、意味が標準化される前に使うべきではないとする。予約された文字列をパーサーが受け取れることは、解決器が相互運用可能な命令を受け取ったことを意味しない。

この限定は当該RFCの読み方についてのものだ。本稿は、その後の全規格を調べてrの意味が一切定められていないと証明したわけではない。現在の特定サービスでrが使えるかどうかも試していない。将来の拡張を見込んだ構文を、現に動く汎用の解決制御プロトコルとして説明する根拠が、この資料にはないということだ。

f成分は#の後にあり、資源内の位置や領域をクライアントが指定する役割を持つ。表現を取得する対象場面では、その意味は取得した表現のメディア型に従う。したがって、解決器がすべての片段指定を理解する必要があるという設計にはならない。逆に、名前比較から外すからといって、クライアントへ届く前に削ってよいともいえない。

日本語の説明では、三つをひとまとめに「付加パラメータ」と呼ぶと簡単に見える。しかし、受け手も標準化の状態も同じではない。rは解決サービス、qは資源またはサービスを提供するシステム、fは対象場面のクライアント側の表現解釈というように、役割を切り分ける必要がある。任意であることは、自由なアクセス権を与えることでも、自由な情報削除を認めることでもない。

ISSNの具体例が示す、段階ごとの規則

IANAのURN名前空間登録簿と、保存されているISBN、ISSNの登録文書は、名前の有効性が構文だけでは決まらないことも示す。NIDを書けるだけで、その名前空間の割り当て権限や有効な識別子を手に入れるわけではない。登録された名前空間の規則と、そこでの割り当ての仕組みを見る必要がある。名前の同一性が確認できたとしても、サービスへのアクセス許可まで確認したことにはならない。

保存されたISSNの文書では、同一性に関して中央のハイフンを省略でき、QとRの成分を比較から除く扱いが示される。他方、解決の文脈ではチェックディジットと中央のハイフンを考慮し、局所的に欠けているハイフンを補う説明がある。比較と解決を別に記すことで、同じ文字列の特徴が異なる仕事を持てる。これは、実在するISSNを本稿で解決して確かめた結果ではない。

RFC8254は2017年にISBN、ISSNのURN登録を移行し、RFC3044とRFC3187を廃止した。関連するISOの識別子の実務が進展するたび、登録文書について同じ形式承認を繰り返さなくてもよい方向を示す。だからこそ、保存された文書を最新のISO実務の完全な記述として使うべきではない。歴史的な登録の証拠と、現行サービスの振る舞いの証拠を分ける必要がある。

RFC3401のDDDSは、名前解決を考える歴史的な背景として役立つ。ただし、すべてのURN解決器が同じDDDS手順を必ず採るという根拠にはならない。RFC6963のexample名前空間も、説明や実例用の枠であって、実在する識別子が配備済みサービスへつながる証明ではない。説明用の資料から運用済みの性質へ進むときには、もう一段の証拠が必要だ。

HTTPのキャッシュは、名前の索引ではない

URNの解決の後にHTTPで表現を取得する経路を考えると、比較の違いはさらに明確になる。RFC9111によるHTTPキャッシュの鍵は、少なくとも要求のメソッドと対象URIから成る。Varyは、保存された応答の選択で考慮すべき要求ヘッダーの違いに関わる。名前空間の索引で同じと認識したURNを、そのままHTTP応答の同一性の鍵にしてよいという説明ではない。

この話はHTTPの段階に限る。すべてのURN解決器がHTTPキャッシュを使うという主張でも、URIが違えば常に応答内容が違うという主張でもない。名前の関係、HTTPの対象、表現の選択という三つの対象に別々の規則がある。その区別を維持しなければ、索引の統合で得た効率が、別段階の誤った再利用の理由に化ける。

RFC8820は、URIの構造を定める仕様の作者がどこまで制御を及ぼすべきかを考えるための指針を示す。W3CのWebアーキテクチャも、識別、相互作用、表現を分け、URIの所有を技術的な関係として扱う。いずれも、識別子を使えることから法律上の許諾やアクセス権を導く資料ではない。技術的な境界を守る議論を、法的な権限の根拠へ飛躍させるべきではない。

Lu Hengが示す最小の初期仕様、将来の判断の局所化、自発的な採用という考え方は、この問題を整理する参照になる。共通層は名前を認識するための規則を置く。解決器は自分の処理戦略を説明する。資源サービスとクライアントは、それぞれの段階の情報を解釈する。採用者はそれらの説明と観察に基づいて選ぶ。すべての要求を中央に戻して毎回許可を得る方式を付け加える必要はない。

それでも、局所化は責任を曖昧にする口実ではない。「名前は永続する」「標準に従う」という大きな約束だけで、既存クエリをどう扱うかが分かるわけではない。共通仕様が意図的に決めていないところは、提供者の説明が重要になる。良い境界とは、細部を一か所に集める境界ではなく、何が保証され、誰の選択が残るのかを読める境界だ。

同じ名前を認めることは、サービス要求を交換可能にする命令ではない。比較のための省略は比較の中にとどめ、他の段階で必要な情報の経路を残す。それだけで、中央の追加承認なしに、より明確なサービス契約を作れる。

参照資料