URL scheme

[137] URI の構造は、大きく scheme (識別方式), authority (命名権者), path (経路), query (照会), fragment (素片識別子) の5つに分けられます。

このうち、 scheme は authority, path, query の詳細な構文と意味を決定します。

URI では様々な scheme が定義・利用されています。 それぞれの URI scheme はその構文と、 誰が識別子を作ることができるのか、 その識別子がどんな意味を持つのか、 色々なプロトコルや書式でどんな風に使うことができるのかなどを規定しています。

[138] このように URI scheme はそれぞれ独立した識別子の空間を作っています。 この独立性により、新しい資源の識別方法を URI に取り込むことが可能になっています。

素片識別子

[140] URI の5大部品の一つが素片識別子 (fragment) です。素片識別子以外の URI が識別した資源の一部分・一表現を、 素片識別子は更に細かく識別します。

素片識別子は URI の一部ではないなどと呼ばれていた時代もありましたが、 現在では URI の一部分と考えられています。

URL と URI、URN、IRI

[199] 1990年代中頃、それまでのアドレスとしての URL に加えて、 名前である URN が提案され、両者の総称が URI とされました。 URN は scheme が urn の URI で、 URL はそれ以外の URI と決められました。

[200] 2000年前後の頃、 URI には URL としての性質が強い場合と URN としての性質が強い場合があり、一概にどちらであるとは言えないと考えられるようになりました。 例えば http: URI は HTTP でアドレス (URL) としても使えるし、 XML名前空間で名前 (URN) としても使えると解釈されました。 このため技術用語の URL は徐々に URI へと置き換えられていきました。

[202] 2000年代前半、 ASCII文字の URI に対して、 Unicode に拡張された IRI が開発されました。 IRI は URI を拡張した事実上の新バージョンでしたが、 形式的には別の名前で別の仕様書で定義される別の技術とされました。 それまでの URI は IRI に置き換えられていきましたが、 URI を使い続けるものや、 URI という呼称で実態が IRI のものもありました。

[203] 2000年代半ば頃、 HTML5 は一部の専門家コミュニティー内でしか通用しない URI や IRI といった語を排除し、一般の開発者や市民に浸透した URL という呼称を復活させました。 2010年代に入ると、呼称だけでなく技術的にも実態に合っていない URI や IRI の仕様書にかわり、 URL Standard が開発されました。

[204] こうした経緯から、 URL と URN の区別の議論や URI と IRI (やその他のバリエーション) の違いの説明は、 今となっては意味をなさないものです。 (事情が複雑で「公式」見解がころころ変わるので、1990年代から2000年代にかけて書かれた解説記事などは当時としても不正確なことが多いです。)

相対 URL と URL の解決

[142] URI (絶対URI参照) は URI scheme の名前から始まり、一つの資源を識別するべく説明を加えていきます。 例えば http://www.example.com/foo/bar/baz は特定の baz という資源を識別するために、 http: URI scheme を使うこと、 命名権者が www.example.com であること、 その中の foo の中の bar の中の baz が識別したい資源であることを順次説明しています。

しかし、このような説明は冗長なことがあります。 http://www.example.com/foo/bar/hoge が自分と同じ階層に存在する baz を指すためにわざわざ http: からはじめるのは面倒ですし、 不便なことも色々あります。

そこで、 URI の相対参照relative referencesという表現が規定されています。 例えば baz が相対参照です。 ただし、 baz だけでは URI (絶対 URI 参照) ではありません。 http://www.example.com/foo/bar/hoge という文脈の情報 (基底URIbase URI と言います。) があって始めて http://www.example.com/foo/bar/baz という URI (絶対 URI 参照) に解決resolveされます。

URL の一部分の直列化

[160] 次の通り、 URL記録の一部を取り出して直列化する操作が必要になることがあります。

URL の一部分の書き換え

[170] 次の通り、 URL記録の一部を書き換える操作が必要になることがあります。

URL の一部分の取り出し

[181] URL記録の一部から情報を取り出す、次のような操作が使われることがあります。

URL の組み立て

[182] URL を組み立てるための次のような操作が使われることがあります。

RSS における URL の利用

[5] RSS 2.0 は url 要素、 link 要素、url 属性、 docs 要素、comments 要素、 guid 要素で URL を値として使っています。ただし、「URL」の定義は明記されておらず、 どの仕様も引用されていません。

[6] このうち、なぜか url 要素と link 要素については URL scheme に関する制限があります。

仕様書:

• RSS 2.0 Specification (version 2.0.10) (2008-11-21 18:10:17 +09:00 版) http://www.rssboard.org/rss-specification#comments
• RSS Best Practices Profile (2008-11-21 15:11:45 +09:00 版) http://www.rssboard.org/rss-profile#data-types-url

識別子としての利用

[16] 次の場面では URL がアドレスとしてではなく、 識別子として使われています。

[17] 次の場面では URL がアドレスとしての側面と識別子としての側面の両方を持っています。

[216] 元来プロトコルと結びつかない URL (例えば urn: URL scheme の URN) がこうした場面で使われることもありますが、 そうでない URL (例えば http: URL) もよく使われています。 後者が用いられる場合は、 URL の本来の意味 (例えば http: の場合 HTTP でアクセスできる資源という意味) が失われている場合が多いです。

[20] Semantic Web 界では http: URL を識別子として使っているため、 HTTP から HTTPS への移行が難しいという人もいます >>19。 マイクロデータ界では実際に HTTPS 化時に識別子である URL を https: URL に書き換えようとした例 >>21 もあり、 URL を識別子として用いることの問題が浮き彫りになっています。 元来プロトコルのアドレスだったものを、 不透明な識別子に目的外利用してしまったがために、 認知と理論に齟齬が生じてしまっているのです。

[220] 長くて面倒なので、URLの省略の仕組みが導入されていることがあります。

[221] URL を識別子として使うという行為のバッドノウハウ感が否めないですが、 他によい代案がないこともあります。

[214] これらの場面のほとんどでは、URLの単純文字列比較が用いられています。

[28] >>27 の source と target は application/x-www-form-urlencoded のキーなんだけど、このURLは何の役に立つんですかね・・・?

URL とプログラミング言語

[118] プログラム言語EではURIが言語の構文に組み込まれている。

URI Expressions http://www.erights.org/elang/io/uri-exprs.html

[119] 他にURIを積極的に言語そのものに取り入れたプログラム言語といえばWMLScriptがある。

URL の前後の区切り文字

URLの表示, URLの印刷, URLの省略, URL自動リンク

    return 302 https://example.com/path;

scheme のない URL

URLの省略

URL を組み込んだ構文

• url-or-path

[233] 関連: ange-ftp address

URL に使えない文字

[238] LBRY

URL 内の秘密情報

[146] URL には、漏洩するべきでない情報が含まれることがあります。 そのようなURLの決め方は好ましくありませんが、 現に存在しますし、避けられないこともあります。

[112] 認証鍵付きURLや capability URL などと称して、 bearer を URL に付加することがよくあります。 簡易的な認証機能としたり、利用者の確認のために電子メールで URL を送信する際に用いたりします。

[151] URL の userinfo 部分は、元々利用者名と合言葉を記述する欄として用意されました。 現在では好ましくないと考えられています。しかし利便性が高いため、 しばしば用いられます。

構成する文字に関わる問題

[217] 文字のセキュリティー、URLにおける文字も参照。

著作権

[103] あまり意識されることはありませんが、 URI である文字列に対して著作権が主張される可能性があります。 単に資源の位置を表すに過ぎない URL 的な URI の類が著作物足る要件を満たすとは考えにくいですが、 ほとんどあらゆる種類のものが URI として表現し得ます。 特に、

[105] URI が著作物足り得るかどうかの議論は、 ハイパーテキストにおけるリンクの自由性にも関わってきます。

[106] URI に著作権は及ばないという主張の例:

[107] URI に著作権が及ぶという主張の例:

[110] 葉っぱ日記 - ぼくはまちちゃん!(Hatena) - urlのポエム化 (2007-01-17 09:25:44 +09:00 版) http://d.hatena.ne.jp/hasegawayosuke/20070117/p1 (名無しさん 2007-01-17 00:28:09 +00:00)

商標権

[111] URI として使用する文字列の一部が商標としてみなされることがあります。 特に URI に一部としてよく使われるドメイン名は頻繁に商標に関する係争が発生しています。 ドメイン名に限らず、商標を根拠に商標権者が URI の使用者に使用しないように主張する可能性があります。

呼称

[15] URL の一部または全部を指して、歴史的に様々な呼称が用いられてきました。

[88] IETF は RFC を改版する度に用語やその定義を少しずつ変えていました。 更に、実際に普及した用語や DOM 等の API で使われている用語とも一致していませんでした。 そのため、色々な仕様書や実装で似たような異なるような概念が交錯し、 大混乱していました。

[89] 加えて W3C は、 XML 関連仕様を新たに出版する度に、 新しい「URI のようなもの」を定義していました。その定義も少しずつ異なるものでした。

[42] URI 関係の古い定義:

• 逃避, escape, URI符号化 → 百分率符号化
• 素片識別子は URI の一部ではない → 素片識別子も URI の一部分
• scheme の後が // の URI でしか相対URI は使えない → どんな URI でも相対参照は使える

[82] fragment identifiers from Roy T. Fielding on 2002-07-23 (www-tag@w3.org from July 2002) http://lists.w3.org/Archives/Public/www-tag/2002Jul/0253.html

[83] URI の標準化はかなりいい加減で混乱気味の上に W3C/Martin Durest は IRI を進めていて、それも SP を認めるとか # もどうとか無茶苦茶なこと言ってたし、混乱は当分収まりそうにない。

[84] RFC 2396 は、絶対 URI だけを URI としており、相対 URI や素片識別子がついた URI も含めた名称を URI 参照としています。 (旧版の RFC 1808 も含めて) 旧来の仕様や慣習では絶対 URI と相対 URI の両方を URI と言っていましたし、素片識別子も仕様書には URI の一部ではないと書いてあるけど実際には曖昧に使われていた (古い URI 仕様書まで遡るとこちらも曖昧だった) という歴史的経緯がありまして、単に URI とだけ言われると厳密には何を指しているのだかわかったものではありません。たまに論争の火種になります(w

[85] XML 関連仕様書は URI という名前で IRI を指していたり、「URI と解釈されるもの」というわけのわからんのがでてきたりしますから混迷極まり (XML//URI 参照)。

[86] あと目立たないけど注意しておきたいのは、空文字列。 RFC 2396 的には URI 参照の一種ですが URI じゃないですし、相対 URI でもないかもしれません。 RFC 1808 から意味が変更されたものですから解釈は実装依存になってしまう。その上使えるかどうかは採用する規格に依存。 (URI 参照を使うと書かれている規格でも、よく見ると字数制限1文字以上で使えなかったりする。)

[87] 2396bis ではまた変わるみたいです。。。

拡張

[205] 歴史的にいくつも URL の拡張が提案されていますが、広く採用されたものはありません。

URI

[36] URI (Uniform Resource Identifiers, 統一資源識別子) は、資源を識別するための統一的な仕組みとして提案されていました。 簡単に言えば、色々なものに名前を付けるための仕組みでした。 あるいは、その仕組みによる識別子をも URI と呼んでいました。 また、文脈で意味が曖昧でない場合には、識別子によって参照される資源のことすらも URI と呼ぶことがありました。

[37] 従来の情報システム・計算機システムは、 それぞれで資源を識別する仕組みや番地付けの仕組みを持っていました。 しかし、それらはあくまでそれぞれのシステムの範囲内でのみ有効な識別子システムでした。

ところが、1990年頃 TimBL が発明した WWW では、番地付けのために URI を採用しました。 URI は URI scheme によって命名システムを識別し、 URI scheme ごとにその中で更に具体的な資源を識別するという構造を持っています。 そのため、従来の情報システムの識別子を URI scheme として再定義することによってあらゆる資源を統一的に扱うことに成功したのです。

参考: そのような設計が採用された背景には、 当時様々な情報システムが提案されて割拠していたことがあります。 WWW は HTTP だけではなく、それら他のシステムも URI によって取り込むことで魅力的な情報システムになったのです。

[38] URI で識別される資源は、何も計算機で表現できるものに限りません。 urn:isbn: URI を使えば ISBN によって書籍を識別することができます。 物理的に存在するもの以外でも、 言葉や抽象概念などありとあらゆる資源を識別することが可能です。

[39] URI が元々 HTTP と HTML で番地付けのために使われてきたことから、 単にネットワーク資源の位置を表す住所のようなものと考えられることがよくあります。 しかし、 >>38 のように URI はネットワークで取出すことができないものであっても識別できます。 Webブラウザで画面に表示することはできないかもしれませんが、 それだけが URI の役割ではないのです。

[223] Univeral Resource Identifiers -- Axioms of Web architecture, 2009-08-27T21:38:06.000Z, 2021-04-12T12:07:39.763Z https://www.w3.org/DesignIssues/Axioms.html

既存の識別子との関係

[125] URI は URI を意識せずに作られた識別子体系でもそのまま取り込んでしまうことができます (もちろん相性のようなものはありますが)。 既に色々な識別子を URI として使う方法が定義されています。

[126] 色々な識別子の体系を URI 1つにまとめると、 何かしたいときに各識別子体系それぞれに対してその方法を考える必要がなくなります。 例えば引用文献を記述する時に、引用する文献が Web頁 (URI) でも紙の書籍 (ISBN) でも両方 URI として扱えると便利になることがあります。 あるいは連絡先がインターネットの電子メイル (電子メイル・アドレス) でも従来の電話 (電話番号) でも統一して扱えたりもします。

[131] 既存の識別子と URI の対応

既存の識別子体系	URI	備考
出版物
ISBN	urn:isbn:
ISSN	urn:issn:
公開識別子	urn:publicid:
RFC	urn:ietf:rfc:
ネットワーク番地
電話番号	tel:
FTP	ftp:
インターネットの電子メイル	mailto:
ニュース組	news:
チャットのチャンネル	irc:
言語・文化
言語札	urn:x-suika-fam-cx:lang:
その他
UUID	urn:uuid:

RFC 1630 (第1世代)

[46]

• RFC1630 『Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web (WWW における普遍資源識別子 : World Wide Web で使われているネットワーク上の物体の 名前と番地の表現の統一構文)』,
  • T. Berners-Lee, 1994 年6月, Informational RFC。
  • この文書は、 WWW でインターネット上の物体の名前と番地を符号化するのに使われている構文を定義します。 Web は、既存のプロトコル, web 自体のために新しく開発されたプロトコル, 将来発明されるプロトコルを含めた拡張可能な数のプロトコルを使って接続可能な物体を含むと考えられます。 特定のプロトコルによる個々の物体への接続指示は、 番地文字列の形式に符号化されます。 他のプロトコルは種々の形式の物体名の使用を認めています。 一般物体の抽象的考えのために、 web は物体の普遍的集合の概念及び物体の名前及び番地の普遍的概念を必要としているのです。

[33]

• 『A Framework for Identifying, Locating, and Describing Networked Information Resources (ネットワーク情報資源の識別, 位置付け, 記述の枠組み)』
  • http://www.apache.org/~fielding/uri/rfc/lynch93.txt
  • Clifford Lynch, 1993年3月。
  • インターネット上のネットワーク情報資源の増加につれ、 この資源の体系的で標準的な識別・位置付け・記述手段が益々必要となっています。 そのような方式の開発の動機は様々ですが、 開発を進めるに当たって少なくても3つの大きな応用があります。 1つには、図書館界では伝統的な型録記述をネットワーク資源に拡張する必要があります。 本質的には、 (in the sense that libraries are shifting from collections to access, and increasingly view their catalogs and other databases as bibliographies of materials to which they are prepared to provide, and perhaps subsidize, access) 書誌記述及び統一的に図書館蔵書と協調させるためのネットワーク情報資源の管理を可能とし、 これらへの接続を向上させる必要があります。 As networked information resources become critical to scholarship and research, and come to represent significant investments by institutions, it also becomes essential to apply the practices of information management to this new class of resources.

RFC 1738 (第2世代)

[34]

• RFC1736
  • 『Functional Recommendations for Internet Resource Locators (インターネット資源位置子の機能的要件)』
  • J. Kunze, 1995年2月。 Informational RFC。
  • この文書は、位置と資源の接続情報を伝達するインターネット資源位置子の要件の最小集合を規定します。 資源の典型的な例には、ネットワークで接続可能な文書, WAIS データベース, FTP サーバー, Telnet 終点を含みます。

[35]

• RFC1737
  • 『Functional Requirements for Uniform Resource Names (統一資源名の機能的要件)』
  • K. Sollins, L. Masinter, 1994年12月。 Informational RFC。
  • この文書は、統一資源名 (URN) として知られるある種のインターネット資源識別子の要件の最小集合を規定します。 URN は、統一資源特性 (URC), 統一資源位置子 (URL) を加えて構成される上位のインターネット情報体系内に fit します。 URN は識別に使用され、 URC はめた情報を含めるのに使用され、 URL は資源の位置付けや探索に用いられます。 この文書は URN の規格を評価する基礎として提供します。 議論はメイリング・リスト MAIL:uri@bunyip.com 及び IETF の URI 作業部会の部で行われます。

[40]

• RFC1738
  • 『Uniform Resource Locators (URL) (統一資源位置子 URL)』
  • T. Berners-Lee, L. Masinter, M. McCahill, 1994年12月。 提案標準。
  • RFC 1808, RFC 2368, RFC 2396 が更新。
  • この文書は、位置及びインターネットを介した資源への接続の形式化された情報の構文及び意味である統一資源位置子 (URL) を規定します。

[92] RFC 1630 (URI) と RFC 1738 は、内容的に大体同じですが、文章としては全然違います。

RFC 1808 (第2世代の相対URL)

[41]

• RFC1808
  • 『Relative Uniform Resource Locators (相対統一資源位置子)』
  • R. Fielding, 1995年6月。提案標準。
  • RFC 1738 を更新。
  • RFC 2368, RFC 2396 が更新。
  • 統一資源位置子 (URL) は、インターネットを介して入手可能な資源の位置及び接続方法の短小な表現です。 URL を基底分書中に埋め込む時には、 絶対形式だと基底文書の取り出しの文脈で、 方式, ネットワーク位置, url-path の一部のように非常に多くの既知の情報を含んでいます。 基底 URL が良く定義されていて解析器 (人間又は機械) がそれを知っている時には、その文脈を実現値毎に際して慰するのではなく、継承した URL 参照を埋め込むことが出来ると便利です。 この文書ではこのような相対統一資源位置子の構文と意味を定義します。

• [1] URL = ( absoluteURL | relativeURL ) [ "#" fragment ] RFC 1808

RFC 2396 (第3世代)

[43]

• RFC2396
  • 『Uniform Resource Identifiers (URI): Generic Syntax (統一資源識別子 (URI): 一般的構文)』
  • T. Berners-Lee, R. Fielding, L. Masinter, 1998年8月。原案標準。
  • RFC 1808, RFC 1738 を更新。
  • 統一資源識別子 (URI) は、抽象資源又は物理資源を識別する短小な文字の列です。 この文書は、絶対形及び相対形の双方を含む、 URI の一般的構文とこれらの使用の指針を定義します。 この文書は RFC 1738 及び RFC 1808 の一般的定義を改訂・置換します。
  • この文書は全ての妥当な URI の超集合である文法を定義します。従って、実装は方式規定の可能な識別型毎の要件を知ること無しに URI 参照の共通の部品を解析することが出来ます。 この文書は URI の生成文法は定義しません。 その作業は各 URI 方式の個々の仕様書が行うことでしょう。

[91] RFC 1738 (URL) と RFC 2396 (URI) は、ほとんど別の文章です。扱う対象はほぼ同じであるにもかかわらず、 2396 は概念的にもかなり整理されていて、 diff が役に立つ立たない以前の問題です。それ程違います。

[90] RFC 1808 (相対 URI) と RFC 2396 は、多くの部分が共通しています。節単位で diff を取ったら違いは URL→URI ばっかり、みたいな。それでも、 2396 の包括的な定義に比較すると 1738 的古臭さ(謎)を感じる部分があって、その辺は 2396 にそのまま入ってはいません。

[93] >>92、>>91、>>90 というわけで、 URI の仕様書は毎回全然違う内容で出てくるのであって、同じ WWW でも HTTP の仕様書 (RFC1945, RFC2068, RFC2616) が追記的に成長していっているのに比べると、中々興味深いところであります。

[94] >>93 比較的早くまとまった (それでも随分かかってるけど。) HTTP の仕様に比べて、 URI は色々ありましたからねぇ。概念的に成熟するまでが長かったし、未だに不安定な部分も多々あるし・・・。

[95] >>94 HTTP みたいな転送プロトコルは前例が一杯あるからかも。 URI のような規模の番地付けってインターネットでは初めての試みだったと思うし。

[96] WWW のもう一つの要素, HTML は、リッチテキスト的構成要素は爆発的に進歩したよね。仕様の安定性って話とはちょっと違うけど、今までの文書処理の経験がやっぱり効いてると思う。一方で単純参照リンク以上のリンクとか、メタ情報とか、そっちの方向は全然進まなくて、今になってようやく SemanticWeb とか大々的に表に出てきた。っていう二面性があって又興味深い。リンクもメタ情報も、やっぱり十分な経験がなかったから。

[97] >>95-96 そういう意味では、 HTTP でも、リンクやメタ情報って蔑ろにされがち。リンクなんてほとんどなかったことにされてるし。。。

[44]

• RFC2717 = BCP35
  • 『Registration Procedures for URL Scheme Names (URL 方式名の登録手続き)』
  • R. Petke, I. King, 1999年11月。現状の最善の運用。
  • この文書は、新しい URL 方式を登録する過程を定義します。

[45]

• RFC2718
  • 『Guidelines for new URL Schemes (新しい URL 方式の指針)』
  • L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, 1999年11月。情報提供 RFC。
  • 統一資源位置子 (URL) はインターネットを介して入手可能な資源の位置の短小な文字列表現です。 この文書は新しい URL 方式の定義の指針を提供します。

[47]

• URIs, URLs, and URNs: Clarifications and Recommendations 1.0 http://www.w3.org/TR/uri-clarification/ IETF/W3C 合同 URI 特別部会の報告。

RFC 2373 (IPv6 拡張)

[48]

• RFC2732
  • 『Preferred Format for Literal IPv6 Addresses in URL's (URL 中の生 IPv6 番地の好ましい書式)』
  • R. Hinden, B. Carpenter, L. Masinter, 1999年12月。
  • この文書は、 World Wide Web ブラウザの実装での URL 中に生 IPv6 番地の書式を定義します。 この書式は Microsoft Internet Explorer, Mozilla, Lynz を含む幾つかの広く用いられているブラウザの IPv6 版で実装されています。 この書式はサービス位置プロトコルの IPv6 版でも使用される見込みです。
  • この文書は RFC 2396 で定義された統一資源識別子の一般的構文の更新を含みます。 この文書は IPv6 番地の構文を定義し、 この予約目的のために陽に URI 中に [ 及び ] の使用を認めます。

RFC 1738 の廃止

[98] RFC 4248 (telnet: URI scheme) が発行されて、遂に RFC 1738 が廃止されました。

ftp:, news:, nntp:, gopher: は改訂版が出てないけどいいのかね? gopher: は RFC編集者の待ち行列にいるからいいとして・・・。 (名無しさん 2005-11-10 10:47:05 +00:00)

[99] あ、 file: も結局放置されたままじゃん?

[100] しかし RFC 4248 は全くやる気がないな。 telnet: を標準化過程に残すためにとか書いてあったけど、 もう要らないんじゃないのか? それよりも ftp:, news:, file: が一時的にせよ標準化過程から離れることの方がむしろ問題かと。 (名無しさん 2005-11-10 10:52:16 +00:00)

RFC 4395

[101] RFC 2717, RFC 2718は廃止されてBCP 115 RFC 4395になりました。 (名無しさん 2006-02-14 14:11:09 +00:00)

90年代-00年代の応用仕様における URL

[75]

• RFC1727
  • 『A Vision of an Integrated Internet Information Service (統合インターネット情報サービスの展望)』
  • C. Weider, P. Deutsch, 1994年12月。
  • この論文は、今後数年間でインターネット情報サービスがいかに統合されるかの展望を示し、 統合を実現するためにどのような手順が必要かの詳細を幾らか議論します。
• RFC1728
  • 『Resource Transponders (資源配送路)』
  • C. Weider, 1994年12月16日。
  • ここ数年で資源の位置とインターネット上の誘導を提供する数多のシステムが作られてきましたが、 これらのシステムに含まれる情報は手動で管理・更新しなければなりません。 この論文では、資源位置情報を維持するために、 自動化機構と資源配送路を記述します。
• RFC2016
  • 『Uniform Resource Agents (URAs) (統一資源エージェント URA)』
  • L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan, 1996年10月。実験的 RFC。

[50] >>49 について、この定義ではURNはURIに含まれていないのではないかと指摘する人がいますが、単にURLがURIに含まれていることを述べているに過ぎず、URN (やURCやその他の何か) については何も言及していないと解釈するのが適当だと思います。

[3] >>2 なにこの定義、ふざけてるの?

[76]

• 2168 Resolution of Uniform Resource Identifiers using the Domain Name System. R. Daniel, M. Mealling. June 1997. (Format: TXT=46528 bytes) (Updated by RFC2915) (Status: EXPERIMENTAL)
• 2169 A Trivial Convention for using HTTP in URN Resolution. R. Daniel. June 1997. (Format: TXT=17763 bytes) (Status: EXPERIMENTAL)
• 2276 Architectural Principles of Uniform Resource Name Resolution. K. Sollins. January 1998. (Format: TXT=64811 bytes) (Status: INFORMATIONAL)
• RFC2483
  • 『URI Resolution Services Necessary for URN Resolution (URN 解決に必要な URI 解決サービス)』
  • M. Mealling, R. Daniel, 1999年1月。実験的 RFC。
  • 統一資源識別子 (URI) によって識別される資源の取り出しは、 URI について施せる処理の1つに過ぎません。 元の URI から、例えばその別名である他の識別子の一覧やその URI が示す資源の書誌的記述を尋ねたり入手したりもするかもしれません。 これは統一資源名 (URN) に対しても統一資源位置子 (URL) に対しても適用されます。 統一資源特性 (URC) はこの文書中で議論しますが、 識別子というよりは資源の記述に過ぎません。
• 2972 Context and Goals for Common Name Resolution. N. Popp, M. Mealling, L. Masinter, K. Sollins. October 2000. (Format: TXT=26252 bytes) (Status: INFORMATIONAL)

[77]

• RFC2017
  • 『Definition of the URL MIME External-Body Access-Type (URL MIME 外部本体接続型の定義)』
  • N. Freed, K. Moore, A. Cargille, 1996年10月。提案標準。
• 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. G. Neufeld, J. Baer. July 1998. (Format: TXT=30853 bytes) (Status: PROPOSED STANDARD)
• 3087 Control of Service Context using SIP Request-URI. B. Campbell, R. Sparks. April 2001. (Format: TXT=83612 bytes) (Status: INFORMATIONAL)

• [224] RFC 3305 - Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations, 2021-04-11T09:04:54.000Z, 2021-04-22T09:17:33.809Z https://tools.ietf.org/html/rfc3305
• [225] RFC Errata Report » RFC Editor, 2021-04-22T09:17:48.000Z https://www.rfc-editor.org/errata_search.php?rfc=3305

URI もどき

[133] URI が使われる文脈で使われる、 URI でない (又はなさそうな, あってほしくない) ものたち, および URL っぽいが URL だとは明言されていないものたち

• emacs-w3m で
  • eiwa:, kokugo:, CODE[waei: に続けて語句を指定すると、その語句を辞書で検索する。
• IRI ・・・URI の多文字拡張
• SuikaWiki の URI もどき
  • IMG: (case-sensitive) 画像参照。
  • IW: (case-sensitive) InterWiki の接頭辞。 See IW:SuikaWiki:InterWiki
  • MAIL: (case-sensitive) 電子メイルの宛先。
  • 詳細は SuikaWiki/0.9 仕様書を参照。 これらは URI ではありません。
• URL: URL の前につける。例: <URL:http://foo.example/>
• MRL
• QRコード
• gid:

[136] ResourceUtils (Spring Framework) http://www.springframework.org/docs/api/org/springframework/util/ResourceUtils.html

Javaのパッケージを表すclasspath: pseudo URLがある。

[198] Oracle の DBURIType は URI を名乗っていますが、 実際には XPath です。

HTML5 と URL Standard

[145] HTML5 で Web における URL が規定されました。紆余曲折を経て、 単独の仕様書 URL Standard となりました。

[239] Karasuma::URL