要約

  • RFC 3305が記録したのは、URI空間をURLとURNに分ける考え方から、拡張可能な単位として各スキームを見る考え方への移行だった。「URL」は便利な説明語として残っても、形式的な別区画である必要はない。
  • 2002年の報告はInformationalであり、実装を命じる標準ではない。RFC 3986は後にRFC 3305を引用して一般語「URI」の使用を勧めた。これは文書上の採用例であって、唯一の原因や全員の遵守を証明するものではない。

分類が説明の邪魔をする

初期のウェブ識別子は、分かりやすい仕分けに見えた。Uniform Resource Locator（URL）は主なアクセス手段を示して資源の場所をたどれるようにし、Uniform Resource Name（URN）は位置とは別に資源を識別する、と説明された。古典的な理解ではURIはURLかURNのどちらかだった。ところが仕様書が「URLスキーム」「URIスキーム」「URNスキーム」を交互に使い始めると、用語は異なる階層を指すように読めてしまう。

RFC 3305は、その混線を解きほぐそうとした記録である。W3Cは2000年10月、URI分野で今後取り組むべき作業を検討する計画グループを設置した。W3Cのメンバーに加え、IETFの専門家も招かれた。2002年8月の報告は、「古典的」な分割モデルと「現代的」な見方を対置する。後者では、識別子の方式は原則としてURIスキームであり、各スキームが独自の下位空間を定義できる。http:はURIスキームであり、urn:もURIスキームで、その下に名前空間を持つ。

この見方では「URL」はURI空間の正式な区画ではない。主たるアクセス手段によって資源の所在を示すURIを表す、便利だが非公式な語として残る。違いは小さく見えるが、問いを変える。ある方式が本質的にロケーターかネームかを決めるのではなく、個々の識別子と割当主体が何を可能にしているかを見る。同じスキームでも、名前付け、位置特定、またはその両方に使われうる。

これは文書間の摩擦に対する対応であり、利用者すべてが同じ混乱を経験したという調査結果ではない。RFC 3305は、汎用URI構文を定めたRFC 2396や、題名に「URLスキーム登録手続き」と掲げたRFC 2717など、既存文書の用語のずれを例に挙げた。隣接する標準が同じ種類の拡張を別の名で呼べば、著者、実装者、登録簿の管理者は、拡張の中身を議論する前に用語を読み替えなければならない。

勧告は命令ではない

報告は、W3CとIETFがURI・URL・URNのモデルを共同で整えること、RFC 2717とRFC 2718の「URLスキーム」を「URIスキーム」に直すこと、代替登録ツリーの規則を明確にすること、公開・廃止・申請中のスキームに関するIANA情報を改善することを提案した。2002年当時の登録状況も記録している。公式一覧の34スキーム、正式なURN名前空間識別子が10件という数字は、その時点の観測であり、現在の件数ではない。

文書の区分は重要だ。RFC 3305はInformationalで、インターネットコミュニティへの情報提供である。Standards Trackのプロトコルでも、W3Cのプロジェクト、IETFの著者、各スキームの管理者にコードや用語の変更を命じる決議でもない。共通の調整課題を言語化し、進み方を提案したにすぎない。実際の制御は、スキームを定義する仕様、登録申請者、IANAが管理する一覧、識別子を解析・割当する実装者に分散していた。

3年後のRFC 3986は、用語提案がより正式な文書に届いた証拠を残す。そこではURLは、主たるアクセス手段を与えるURIの一種とされる。個々のスキームは名前かロケーターのどちらか一方に限られないとも説明し、将来の仕様では、より限定的な「URL」「URN」より一般的な「URI」を使うよう勧める際、RFC 3305を明示的に引用した。これは後続のStandards Track文書における直接の採用例である。一方で、RFC 3305だけが原因だったこと、すべての著者が従ったこと、日常語から「URL」が消えたことまでは示さない。

登録手続きは関連しつつも別の線で続いた。RFC 7595は後にURIスキームの指針と登録手続きをBest Current Practiceとして定めた。RFC 8820は別の角度からスキームの権限を論じる。URIの内部構造はスキームが定め、外部仕様がその構造を細かく指定することには問題がある、という指摘だ。用語の整理だけでは所有権、構文、登録のすべては決まらない。

記録から言える範囲

RFC 3305は、W3C/IETFの計画グループが用語の衝突を見つけ、共通語彙と登録情報を提案し、その実行を後続の仕様と参加者に委ねた小さな標準史として読むのがよい。RFC 3986の明示的引用によって、一つの提案が後の標準文書に移った経路は追える。ただし、混乱がどれだけ解消されたか、全コミュニティが採用したか、現在のURIの考え方をRFC 3305だけに帰せるかは、この記録からは分からない。

この慎重さも制度設計の一部だ。調整用の文書は共通の問題を見えるようにできても、その答えを強制する権限を持つとは限らない。公開された文書は採用可能な参照点を作るが、実際に何が変わるかは、後続の規格、登録手続き、実装が決める。