Uniform Resource Locators (URL)
Takami Torao
Network Working Group T. Berners-Lee
Request for Comments: 1738 CERN
Category: Standards Track L. Masinter
Xerox Corporation
M. McCahill
University of Minnesota
Editors
December 1994
Uniform Resource Locators (URL)
この記述について
このドキュメントはインターネットコミュニティにおいてインターネットの標
準的なトラックプロトコルを記述し、改善のための論議と提案をリクエストす
るものです。このプロトコルの標準化の状態のため、新しい "Internet
Official Protocol Standards" (STD 1) を参照してください。この記述の配
布は無制限です。
概要
このドキュメントは Uniform Resource Locatior (URL)、インターネットでの
リソースの位置の特定とアクセスのための定型化された情報構文を記述してい
る。
1. イントロダクション
このドキュメントはインターネット経由で利用可能なりソースに対するコンパ
クトな文字列表現のための構文と記号論を示している。これらの文字列は
"Uniform Resource Locators" (URLs) と呼ばれている。
この記述は World-Wide Web グローバルインフォメーションイニシアティブに
由来する。そのような目的の使用は 1990 から続き、"Universal Resource
Identifiers in WWW", RFC 1630 に記述されている。URL の記述は
"Functional Requirements for Internet Resource Locators" [12] において
整えられた必要条件に合意するように設計されている。
このドキュメントは Internet Engineering Task Force の URI ワーキンググ
ループによって書かれている。コメントは編集者か URL-WG <uri@bunyip.com>
に送られる。このグループの論議は
<URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html> に
アーカイブされている。
2. 一般的な URL 構文
リソースへのアクセスの異なった方法はたくさん存在する。そのようなリソー
スへのロケーションを記述するためにいくつかのスキーム (構成) が存在する。
URL のための一般的な構文は、このドキュメントにおけるそれらの定義のほか
に、プロトコルの使用を確立するための新しいスキームに対する骨組みを可能
にする。
URL はリソース位置の抽象的 ID を供給する事により、`locate' リソースと
して使われる。位置を特定されたリソースを持つ事でシステムはリソースに対
して、`access', `update', `replace', `find attributes' といった言葉に
よって特徴づけられるさまざまな種類の操作を実行できるだろう。一般的には
どのような URL スキームに対しても `access' 方法を記述する必要がある。
2.1. URLs の主要部分
URL 構文の完全な BNF 表記は Section 5 で与えられる。
一般的には、URL は以下のように表記される。
<scheme>:<scheme-specific-part>
URL は使われているスキーム (<scheme>) とその後ろに続くセミコロンおよび
スキームに依存する解釈の文字列 (<scheme-specific-part>) からなる。
スキーム名は文字の連続から成り立っている。小文字 "a"--"z"、数字、そし
てプラス記号 ("+")、ピリオド (".")、ハイフン ("-") が許されている。た
だし、URL を処理するプログラムはスキーム名において大文字を小文字と同等
に扱うべきである ("HTTP" は "http" と同じになる)。
2.2. URL 文字エンコーディングの問題
URL は英字、数字、特殊文字などの文字の連続である。URL はインクと紙、も
しくはコード化された文字セットにおける8ビット文字の連続のように、さま
ざまな方法で記述される。URL の解釈は使われている文字の特定にのみ依存す
る。
ほとんどの URL スキームにおいて、URL の別々の部分の文字の連続は、イン
ターネットプロトコルで使われている 8ビット文字の連続に当てはまる。ftp
スキームでは、ホスト名、ディレクトリ名およびファイル名はそのような URL
の一部として表す事のできる 8ビット文字の連続である。これらの部分の中で
は、8ビット文字は US-ASCII [20] コードの文字セット内の 8ビット文字とし
て表す事ができる。
付加的に、8ビット文字は文字 "%" に続く 8ビット文字の 16進数値となる 2
つの 16進数 ("0123456789ABCDEF") の 3文字により符号化される。(文字
"abcdef" も 16進数符号化で使われるだろう。)
8ビット文字は、もしそれらが US-ASCII コード文字セット内の印字可能な文
字でない場合、その文字の使用が安全でない場合、もしくはそれが特殊な URL
スキーム内で何か別の処理のために予約されている場合に符号化されなければ
ならない。
印字可能な文字でないとは:
URL は US-ASCII コード文字セットの印字可能な文字でのみ記述される。8
ビット文字の 80-FF は US-ASCII で使われていない。そして 8ビット文字
00-1F と 7F は制御文字に相当する。これらは符号化されなければならない。
安全でないとは:
文字はいくつかの理由で安全でなくなる。URL が転記されたりタイプされた
り、ワードプロセッシングプログラムによって扱われる時、大切な空白が消え
るかもしれないし、意味のない空白が追加されるかもしれないため、空白 (ス
ペース) は安全でない。文字 "<" と ">" はテキストを URL と区切るのに使
われるため安全ではない。クォートマーク (""") はいくつかのシステムにお
いて URL を区切るのに使われる。文字 "#" は安全でなく、World Wide Web
や別のシステムで URL とそれに続くフラグメント/アンカーを区切るのに使わ
れるため、常に符号化されるべきである。文字 "%" は他の文字の符号化に使
われるので安全でない。他の記号はゲートウェイや他のトランスポートエー
ジェントが時々置き換えてしまう事が知られているので安全ではない。このよ
うな記号は "{", "}", "|", "\", "^", "~", "[", "]" そして "`" である。
すべての安全でない文字はフラグメントやアンカー識別子として普通に扱われ
ないシステムにおいて URL のようなものの中では符号化されなければならな
い。そういうわけで、もしその URL が、それらの文字を使っている別のシス
テムにコピーされるなら、URL 符号化を変換する必要はないだろう。
予約されているとは:
多くの URL スキームはある複数の文字を特別な意味として予約している。URL
のスキーム記述部分でのこれらの出現は、指定されたセマンティクスを持って
いる。もし 8ビット文字に相当する文字がスキーム内で予約されているなら、
その 8ビット文字は符号化されなければならない。文字 ";", "/", "?", ":",
"@", "=" そして "&" はスキームにおいて特別な意味のために予約されている
と思われる文字である。スキームにおいて別の文字は予約されていないだろう。
たいていの場合 8ビット文字が文字により振り替え表現され、そして符号化さ
れているとき、URL は同じ解釈を持っている。しかしながら、これは予約され
た文字に対しては真意ではない。特別なスキームに対して予約されている文字
を符号化する事は、URL のセマンティクスを変えるだろう
したがって、英数文字、特殊文字 "$-_.+!*'(),"、そしてそれらの予約されて
いる意図で使われている予約された文字のみ URL の中で符号化しないで使う
事ができる。
他方では、符号化が必要でない (英数文字を含む) 文字は、それらが予約され
た意図で使われない限り、URL のスキーム記述部分の中で符号化されるかもし
れない。
2.3 階層的なスキームと相対的リンク
いくつかの場合において、URL は別のリソースへのポインタを含むロケートリ
ソースとして使われる。いくつかの場合、これらのポインタは、二次的なリ
ソースのロケーションの表現が "続く相対パス以外のものと同じ場所" に関す
る場合の相対的リンクの結果となる。相対的リンクはこのドキュメントにおい
て示されない。しかしながら、相対的リンクの使用は、相対的リンクの元とな
る階層構造を含んでいるオリジナル URL に依存している。
(ftp, http, file スキームのような) いくつかの URL スキームは階層的とみ
なせる名前を含んでいる。これら階層的な部分は "/" により分割される。
3. 具体的なスキーム
既存のいくつかの標準的、実験的なプロトコルに対するマッピングは BNF 構
文定義で概略化される。特有なプロトコルは以下に記述する。カバーされるス
キームは:
ftp File Transfer protocol
http Hypertext Transfer Protocol
gopher The Gopher protocol
mailto Electronic mail address
news USENET news
nntp USENET news using NNTP access
telnet Reference to interactive sessions
wais Wide Area Information Servers
file Host-specific file names
prospero Prospero Directory Service
その他のスキームは将来的な仕様書により記述されるだろう。このドキュメン
トの Section 4 では新しいスキームがどの様に登録されるかと、開発途上の
いくつかのスキーム名のリストを示している。
3.1. 一般的なインターネットスキームの構文
URL の残りの構文全体は、選択された特殊なスキームや、インターネット上で
具体的なスキーマデータに対して同じ構文を使うホストへの IP ベースプロト
コルの使用方法を含んでいる URL スキームに強く依存している。
//<user>:<password>@<host>:<port>/<url-path>
"<user>:<password>@", ":<password>", ":<port>", "/<url-path>" のいくつ
かもしくは全部は除外される可能性がある。scheme specific data は共通の
インターネット構文に対応していることを示すためダブルスラッシュ "//" で
始まる。その他の部分は以下のルールに準ずる。
user
オプション的なユーザの名前。(ftp のような) いくつかのスキームでは
ユーザ名の記述を許可している。
password
オプション的なパスワード。これが与えられるとき、それは一つのコロン
で区切られたユーザ名に続く。
ユーザ名 (とパスワード) が存在するなら、それらは単価記号 "@" が後ろに
続く。user と password フィールド内では ":", "@" もしくは "/" のいずれ
も符号化されなければならない。
空のユーザ名もしくはパスワードはユーザ名もしくはパスワードがないと言う
意味とは異なる事に注意。ユーザ名を省略してパスワードを記述する方法はな
い。たとえば <URL:ftp://@host.com/> は空のユーザ名と無指定のパスワード
を持っている。<URL:ftp://host.com/> はユーザ名を持たない。
<URL:ftp://foo:@host.com/> は "foo" のユーザ名と空のパスワードを持つ。
host
ネットワークホストの十分なドメイン名、もしくは "." で区切られた 4
個の 10進数のグループのセットとなる、そのホストの IP アドレス。十
分なドメイン名は RFC 1034 [13] の Section 3.5 と RFC 1123 [5] に示
されているような形態を取る。ドメインラベルの文字列は "." で区切ら
れ、それぞれのドメインラベルは英数文字と、ひょっとすると "-" を含
む文字群で構成されている。もっとも右側に位置するドメインラベルは決
して数字で始まらないが、構文上 IP アドレスからすべてのドメイン名を
区別している。
port
接続するためのポート番号。ほとんどのスキームはデフォルトポート番号
を持っているプロトコルに定義されている。別のポート番号がオプション
的に、10進数で、コロンを用いて host と区切って供給されうる。port
が省略されるならほとんどの場合コロンも省略される。
url-path
locator の残りはスキームへの data specific で成り立っている。これ
は "url-path" として良く知られている。それは記述されたリソースがど
のようにアクセスする事ができるかの詳細を供給する。ホスト (もしくは
ポート) とこの url-path の間の "/" は url-path の一部 *ではない*
事に注意。
url-path 構文は処理における方法を行うものとして、使用されているスキー
ムに依存する。
3.2. FTP
FTP URL スキームは FTP プロトコル (RFC959) を使う事ができるインターネッ
トホスト上で、ファイルやディレクトリを示すのに使用される。
FTP URL は Section 3.1 で示された構文に適応する。もし :<port> が省略さ
れたら、そのポートはデフォルトの 21 である。
3.2.1. FTP 名とパスワード
ユーザ名とパスワードが供給される事がある。これらは最初に FTP サーバに
接続を確立した後 FTP の "USER" と "PASS" コマンドにおいて使われる。も
しユーザ名とパスワードが省略されたり片方が FTP サーバから要求を受けた
ら、以下のような慣例的な "anonymous" FTP が使われる。
The user name "anonymous" is supplied.
The password is supplied as the Internet e-mail address
of the end user accessing the resource.
もし URL にユーザ名が指定されてパスワードがない場合や、リモートサーバ
がパスワードを要求した場合、FTP URL を処理しているプログラムはユーザか
らその要求をリクエストするべきである。
3.2.2. FTP url-path
FTP URL の url-path は以下のような構文になる。
<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
ここで <cwd1> から <cwdN> と <name> は (符号化されているかもしれない)
文字列であり、<typecode> は文字 "a", "i", "d" の一つである。
";type=<typecode>" の部分は省略されるかもしれない。<cwdx> と <name> 部
分は空かもしれない。user, password, host, port を含むプレフィクスから
url-path を区切る "/" を含めて url-path 全体が省略されるかもしれない。
この url-path は以下のように FTP コマンドの連続として処理される。
<cwd> 要素のそれぞれが指定されているなら CWD (change working directory)
コマンドへの引数として続ける。
もし typecode が "d" なら、引数を <name> とした NLST (name list) コ
マンドを実行し、ファイルディレクトリリストとしての結果を処理する。
そうでなければ引数を <typecode> とした TYPE コマンドを実行し、
<name> を名前としたファイルにアクセスする。(例: RETR コマンドの使用)
Otherwise, perform a TYPE command with <typecode> as the argument,
name や CWD 要素内では文字 "/" や ";" は予約され、符号化されなければな
らない。要素は FTP プロトコルでのそれらの使用に先駆けて複合かされる。
特に、特定のファイルにアクセスする適切な FTP シーケンスは CWD や RETR
コマンドへの引数として "/" を含んでいる文字列が供給される事が必要であ
り、この事はそれぞれの "/" を符号化する必要がある。
たとえば、URL <URL:ftp://myname@host.dom/%2Fetc/motd> は "host.dom"
に FTP 接続て "myname" でログインし (パスワードが必要ならプロンプトを
出して)、それから "CWD /etc" と "RETR motd" を処理する。これは
"CWD etc" と "RETR motd" を行う <URL:ftp://myname@host.dom/etc/motd>
とは異なる意味を持つ。その最初の "CWD" は "myname" に対するデフォルト
ディレクトリに相対的に実行されるだろう。さらに
<URL:ftp://myname@host.dom//etc/motd> は null 引数を持つような "CWD "
を行い、それから "CWD etc" を行い、"RETR motd" を行う。
FTP URL は別の操作のためにも使用される。たとえばリモートファイルサーバ
上でのファイルの更新やディレクトリリストから更新についての情報を推測す
る事も可能である。そのような事を行うためのメカニズムはここでは述べない。
3.2.3. オプション的な FTP Typecode
FTP URL の ;type=<typecode> 全体はオプションである。もしこれが省略され
れば URL を処理しているクライアントプログラムは使用への適切なモードを
推測しなければならない。一般的にはファイルのデータ content type は(ファ
イルのサフィックスの様に)名前からのみ推測する事ができる。。このときファ
イルの転送のために使用される適切なタイプコードはファイルのデータ内容か
ら推定される。
3.2.4 階層構造
同じファイルシステムに対して、URL の階層構造を示すのに使われる "/" は
ファイル名階層を構造化するために使われるデリミタに相当する。したがって
ファイル名は URL パスに類似しているように見えるだろう。これは URL が
Unix ファイル名であると言う事を *意味しない*。
3.2.5. 最適化
FTP 経由でリソースにアクセスしているクライアントは相互の動作を最適に行
える事を追加の発見的に採用するだろう。たとえば、いくつかの FTP サーバ
に対して同じサーバからの重複した URL をアクセスしている間、コントロー
ル接続を開いたままにしておくことは合理的である。しかしながら FTP プロ
トコルに一般的な発見的モデルは存在しない。もしディレクトリ移動コマンド
が与えられたときそのパスが異なるなら、二次的な訂正に対して別のディレク
トリへ移動するために与えられたシーケンスを推定する事は不可能である。信
頼できるアルゴリズムはコントロール接続を切断して際確立する事だけである。
3.3. HTTP
HTTP URL スキームは HTTP(HyperText Transfer Protocol) を使ってアクセス
できるインターネットリソースを示すのに使用される。
この HTTP プロトコルは他に記述される。この記述は HTTP URL の構文を示す
だけである。
HTTP URL は以下のような形態を取る
http://<host>:<port>/<path>?<searchpart>
ここで <host> と <port> は Section 3.1 に示してある。もし :<port> が省
略されたらポートはデフォルトの 80となる。ユーザ名もしくはパスワードは
許されていない。<path> は HTTP セレクタであり、そして <searchpart> は
クエリー文字列である。この <path> は <searchpart> とその前の "?" とと
もに省略可能である。もし <path> も <searchpart> も与えられていなければ
"/" も省略されるかもしれない。
<path> と <searchpart> 部分の中では "/", ";", "?" が予約されている。文
字 "/" は階層構造を示すために HTTP 内で使われている。
3.4. GOPHER
Gopher URL スキームは Gopher プロトコルを使用してアクセス可能なインター
ネットリソースを示している。
ベース Gopher プロトコルは RFC 1436 に記述され、アイテムとアイテムのコ
レクション (ディレクトリ) をサポートしている。Gopher+ プロトコルは
ベース Gopher プロトコルの上位互換拡張セットであり、[2] に記述されてい
る。Gopher+ は Gopher アイテムの属性と相互的なデータ表現の任意のセット
統合をサポートしている。Gopher URL は Gopher と Gopher+ 両方のアイテム
とアイテム属性に適応している。
3.4.1. Gopher URL 構文
Gopher URL は以下の形態を取る:
gopher://<host>:<port>/<gopher-path>
ここで <gopher-path> は以下の一つである。
<gophertype><selector>
<gophertype><selector>%09<search>
<gophertype><selector>%09<search>%09<gopher+_string>
もし :<port> が省略されたらデフォルトポート 70となる。<gophertype> は
URL が参照しているリソースの Gopher タイプを示す単一文字フィールドであ
る。区切っている "/" がオプションで <gophertype> がデフォルトの "1" の
場合、エンティティ <gopher-path> は省略されるかもしれない。
<selector> は Gopher セレクタ文字列である。Gopher プロトコルにおいて、
Gopher セレクタ文字列は 16進数 09 (US-ASCII HT もしくはタブ)、0A
(US-ASCII 文字 LF)、0D (US-ASCII 文字 CR) を除くすべての 8ビット文字を
含む可能性のある 8ビット文字の連続である。
Gopher クライアントは Gopher サーバに Gopher セレクタ文字列を送る事に
より取り出すアイテムを記述する。
<gopher-path> 内ではどんな文字も予約されていない。
文字が 2回連続して現れる場合、いくつかの Gopher <selector> 文字列が
<gophertype> 文字のコピーで始まる事に注意。Gopher セレクタ文字列は空で
あるかもしれない。これは Gopher クライアントが Gopher サーバ上でトップ
レベルディレクトリを参照する方法である。
3.4.2 Gopher サーチエンジンに対する URL 記述
もし URL が Gopher サーチエンジンに提出される検索を参照しているとき、
セレクタには符号化されたタブ (%09) と検索文字列が続く。Gopher サーチエ
ンジンに検索を要求する事は、Gopher クライアントが (複合化された後の)
<selector>、一つのタブ、そして検索文字列を Gopher サーバにを送る。
3.4.3 Gopher+ アイテムに対する URL 構文
Gopher+ アイテムは第 2の符号化されたタブ (%09) と Gopher+ 文字列を持っ
ている。この場合、%09<search> 文字列が供給されなければならない事に注意。
とはいえ <search> 要素は空かもしれない。
<gopher+_string> は Gopher+ アイテムの検索のために必要とされる情報の結
果として使用される。Gopher+ アイテムは、属性の任意のセットの平行した見
方を持ち、それらの連なった電子的形態を持つ可能性がある。
Gopher+ URL に提携したデータ検索のため、クライアントはサーバに接続して、
タブと (空かもしれない) 検索文字列、それに続くタブと Gopher+ コマンド
の Gopher セレクタを送るだろう。
3.4.4 デフォルトの Gopher+ データ表現
Gopher サーバがクライアントにディレクトリリストを送るとき、Gopher+ ア
イテムは "+" (Gopher+ アイテムを示す) か "?" (それらに準じた +ASK 形態
を持つ Gopher+ アイテムを示す) のどちらかがつけられる。"?" のみとみな
される Gopher+ 文字列がそれに準じた Gopher 電子的形態のアイテムを参照
している一方、"+" のみとみなされる Gopher+ 文字列がついた Gopher URL
はアイテムのデフォルトビュー (データ表現) を参照している。
3.4.5 電子的形態付き Gopher+ アイテム
("?" がついた Gopher+ アイテムのような) それらに準
ずる +ASK を持っている Gopher+ アイテムは、形態の定義を得るためのアイ
テムの +ASK 属性を取り寄せる、形態のすべてをユーザに問い合わせ、アイテ
ム検索のためのセレクタ文字列をつけたユーザの対応を返すクライアントが必
要となる。Gopher+ クライアントはこのやり方を知っているが、いつこの場合
をハンドルするかを知るための Gopher+ アイテム記述における "?" タグに依
存している。この "?" はこの記号の Gopher+ プロトコルの使用と一致する
Gopher+ 文字列で使用される。
3.4.6 Gopher+ アイテム属性の収集
アイテムの Gopher+ 属性を参照するために、Gopher URL の Gopher+ 文字列
が "!" もしくは "$" から成り立ってる。"!" はすべての Gopher+ アイテム
の属性を参照している。"$" は Gopher ディレクトリにおけるすべてのアイテ
ムのアイテム属性を参照している。
3.4.7 Gopher+ 属性記述の参照
記述属性を参照するために、URL の gopher+_string は "!<attribute_name>
もしくは "$<attribute_name>" である。たとえば、あるアイテムの概要と一
致する属性を参照するために、gopher+_string は "!+ABSTRACT" となるだろ
う。
いくつかの属性を参照するため、gopher+_string は符号化された空白文字に
より分けられた拡張名からなる。たとえば "!+ABSTRACT%20+SMELL" はアイテ
ムの +ABSTRACT と +SMELL 属性を参照している。
3.4.8 Gopher+ 振り替えビューに対する URL
Gopher+ はオプション的なアイテムの振り替えデータ表現 (交互ビュー) を許
可している。Gopher+ 交互ビューの検索のため、Gopher+ クライアントは適切
なビューと言語識別 (アイテムの +VIEW 属性から見つかる) を送る。Gopher+
振り替え属性ビューを記述するため、URL の Gopher+ 文字列は以下のような
形態になる。
+<view_name>%20<language_name>
たとえば、"+application/postscript%20Es_ES" の Gopher+ 文字列は
Gopher+ アイテムのスペイン語追伸振り替えビューを参照している。
3.4.9 Gopher+ 電子形態に対する URL 構文
記述された値で膨らんだ Gopher+ 電子形態 (ASK ブロック) により参照され
るアイテムを参照する URL の gopher+_string はクライアントがサーバに
送ったもののコード化されたバージョンである。gopher+_string は以下のよ
うになる。
+%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A
このアイテムを検索するため、Gopher クライアントは以下のものを Gopher
サーバに送る:
<a_gopher_selector><tab>+<tab>1<cr><lf>
+-1<cr><lf>
<ask_item1_value><cr><lf>
<ask_item2_value><cr><lf>
.<cr><lf>
3.5. MAILTO
mailto URL スキームはここのインターネットメールアドレスやサービスを示
すために使用される。インターネットメールアドレス以外のいかなる付加的な
情報も与えられず意味しない。
mailto URL は以下のような形を取る:
mailto:<rfc822-addr-spec>
ここで <rfc822-addr-spec> は RFC 822[6] に記述されている addr-spec (も
しくはそれが符号化されたもの) である。mailto URL の中では予約されている
文字はない。
パーセント記号 ("%") は RFC 822 アドレス内で共通して使われるため符号化
しなければならない。
他の URL と異なり、mailto スキームは直接アクセスされたデータオブジェク
トの結果ではない。あるオブジェクトを示すような意味はない。これは MIME
における message/external-body タイプとは違った使用を持つ。
3.6. NEWS
news URL スキームはニュースグループや RFC 1036 に記述されている USENET
ニュースの個々の記事のどちらかを参照するのに使用される。
news URL は以下の 2つの形態を取る:
news:<newsgroup-name>
news:<message-id>
<newsgroup-name> は "comp.infosystems.www.misc" のようにピリオド区切ら
れた階層構造名である。<message-id> は "<" と ">" で囲まれているもの以
外の RFC 1036 の section 2.1.5 の Message-ID に相当する。これは
<unique>@<fill_domain_name> の形態を取る。メッセージ識別子はニュースグ
ループ名を単価記号 "@" 文字の存在で区別される。どのような追加的な文字
も news URL 部分内で予約されていない
news URL はこの中ではそれ自体珍しい。これらは単一のリソースへの十分な
情報を含んでいるわけではなく、むしろ場所に独立している
(location-independent) ものである。
3.7. NNTP
nntp URL スキームは NNTP サービス (RFC 977) からのニュース記事を記述す
るために有用な、ニュース記事参照の振り替えとなるものである。
nntp URL は以下の形態を取る:
nntp://<host>:<port>/<newsgroup-name>/<article-number>
ここで <host> と <port> は Section 3.1 で示されている。もし :<port> が
省略されたらデフォルトポート 119 となる。
<newsgroup-name> はグループの名前であり、<article-number> はニュースグ
ループ内の記事の ID 番号である。
nntp: URL は記事リソースに対するユニークなロケーションを記述している事
に注意。現在のインターネット上のほとんどの NNTP サーバはローカルクライ
アントからのアクセスのみを許可するように設定されている。したがって
nntp URL グローバルにアクセス可能なリソースを示さない。したがって、URL
の news: 形態はニュース記事特定の方法として好まれる。
3.8. TELNET
Telnet URL スキームは Telnet プロトコルによりアクセスされるような相互
サービスを示している。
Telnet URL は Section 3.1 で記述されているように以下の形を取る:
telnet://<user>:<password>@<host>:<port>/
最後の文字 "/" は省略されるだろう。もし :<port> が省略されたらポートは
デフォルトの 23 となる。<user>:<password> 全体部分や :<password> は省
略可能である。
この URL はデータオブジェクトではなくむしろ相互サービスを示している。
リモート相互サービスはリモートログインを許しているようなものによって大
きく意味が異なる。特に与えられた <user> と <password> はアドバイス的な
ものでしかない。telnet URL にアクセスしているクライアントは、提示され
たユーザ名とパスワードのユーザに単にアドバイスする。
3.9. WAIS
WAIS URL スキームは WAIS データベースの指定、検索もしくは WAIS データ
ベースから利用できるここのドキュメントを使うためである。WAIS は [7] に
記述されている。WAIS プロトコルは RFC 1625 [17] に記述されているが、
WAIS プロトコルは Z39.50-1988 を基にし、WAIS URL スキームは任意の
Z39.50 サービスに対する使用のための目的を持っているわけではない。
WAIS URL は以下のような形態となる:
wais://<host>:<port>/<database>
wais://<host>:<port>/<database>?<search>
wais://<host>:<port>/<database>/<wtype>/<wpath>
ここで <host> と <port> は Section 3.1 に記述されている。もし :<port>
が省略されたらデフォルトのポート 210 となる。最初の形態は検索が利用で
きる WAIS データベースを示している。第 2の形態は特定の検索を示している。
<database> は要求された WAIS データベースの名前である。
第 3の形態は WAIS データベースから特定のドキュメントを取り出すため指示
である。この形態における <wtype> はオブジェクトタイプの指示である。多
くの WAIS 実装では検索先オブジェクトの "型" をクライアントが知っている
必要がある。この型は内部的オブジェクト識別を伴う検索応答において返され
る。<wtype> は実際にドキュメントを検索するための十分な情報の URL を処
理しているクライアントに許されるふさわしい URL に含まれる。
WAIS URL の <wpath> は必要により Section 2.2 で記述されている方法を用
いて符号化された WAIS ドキュメント ID とみなされる。WAIS ドキュメント
ID は不透明に扱われる。これは、それを配給するサーバによってのみ分解さ
れる。
3.10 FILES
file URL スキームは特にホストコンピュータ上でアクセス可能なファイルを
示す。他のほとんどの URL スキームと異なるこのスキームは、インターネッ
ト上でアクセス可能な普遍的なリソースを示しているのではない。
file URL は以下のような形態を取る:
file://<host>/<path>
ここで <host> は <path> がアクセス可能なそのシステムのフルドメイン名で
あり、<path> は <directory>/<directory>/.../<name> 形式の階層的ディレ
クトリパスである。
たとえば VMS ファイル
DISK$USER:[MY.NOTES]NOTE123456.TXT
は以下のようになる。
<URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>
特殊な例として <host> は "localhost" もしくは空の文字列にできる。これ
は `URL が処理されているマシーンから' として処理される。
この file URL は、ホスト間のネットワークプロトコルにおける利便性に制限
があるように、ファイルに対してインターネットプロトコルやアクセス方法を
記述していない場合においてまれである。
3.11 PROSPERO
prospero URL スキームは Prospero ディレクトリサービス経由でアクセスさ
れるリソースを示すのに使用される。Prospero プロトコルは [14] などに記
述されている。
prospero URL は以下のような形態を取る:
prospero://<host>:<port>/<hsoname>;<field>=<value>
ここで <host> と <port> は Section 3.1 に記述してある。もし :<port>
が省略されたらデフォルトポート 1525となる。ユーザ名およびパスワードは
許されていない。
<hostname> は適切に符号化された Prosperio プロトコルにおけるホストを記
述するためのオブジェクトの名前である。この名前は不透明であり、Prospero
サーバにより処理される。セミコロン ";" は予約され <hsoname> において引
用する以外に現れないだろう。
Prospero URL は、それ自身別の URL で表されているかもしれないリソースへ
の適切なアクセスを決定するため、記述されたホストとポートの接続している
Prospero ディレクトリサーバによって処理される。外部的な Prospero リン
クは潜在的なアクセス方法の URL として表されるし、Prospero URL として表
されない。
スラッシュ "/" が引用以外に <hsoname> に現れる可能性があり、アプリケー
ションによりどんな重要性も仮定されない事に注意。しかしスラッシュはサー
バ上での階層構造 (そのような構造は保証されない) を示すかもしれない。
多くの <hsoname> はスラッシュで始まり、場合によってホストもしくはポー
トがダブルスラッシュに続けられるであろうことに注意。URL 構文からのス
ラッシュは <hsoname> からの初めのスラッシュが続けられる
(<URL:prospero://host.com//pros/ame> が "/pros/name" の <hsoname> を示
すように)。
追加的に、<hsoname> の後の、Prospero リンクに準ずるフィールドと値は
URL の部分として記述されるかもしれない。これが与えられるとき、それぞれ
のフィールド/値のペアはお互い ";" (セミコロン) により URL の残り部分か
ら分けられる。もし与えられるなら、これらのフィールドは URL のターゲッ
トを識別するのに対応する。たとえば、OBJECT-VERSION フィールドはあるオ
ブジェクトの記述されたバージョンを識別するのに示す事ができる。
4. 新しいスキームの登録
新しいスキームは新しいプレフィクスを使った URL 構文に従う定義された
マッピングにより導入される。実験的な URL スキームはパーティ間の相互の
同意により使われるだろう。文字 "x-" で始まるスキーム名は実験的な目的の
ために予約されている。
Internet Assigned Numbers Authority (IANA) は URL スキームの登録整備を
行うだろう。新しい URL スキームのどんな提案も、スキームとそのスキーム
の表現に対する構文の中で、リソースのアクセスに対するアルゴリズムの定義
が含まれなければならない。
URL スキームは論証できる便利さと操作しやすさを持っていなければならない。
そのような論証を示す一つの方法は、既存のプロトコルを使うクライアントに
対する新しいスキームにおけるオブジェクトを備えたゲートウェイ経由である。
もし新しいスキームがデータオブジェクトとなるリソースの位置を示さないな
ら、新しい領域における名前の特性は明確に定義されなければならない。
新しいスキームは適切な既存のスキームの同じセマンティクス互換性を伴うよ
うに志すべきである。プロトコルが URL により検索を許される場合に、クラ
イアントソフトウェアは新しい名前がつけられたスキームを通しての間接的ア
クセスに対する記述されたゲートウェイロケーターを使うために設定されるよ
うな準備を持つ事を推奨する。
以下のスキームはいろいろなときに提案されているが、今回このドキュメント
はそれらの構文定義もしくは使い方を定義していない。将来的な定義のためこ
れらのスキーム名を IANA が予約する事を提案する。
afs Andrew File System global file names.
mid Message identifiers for electronic mail.
cid Content identifiers for MIME body parts.
nfs Network File System (NFS) file names.
tn3270 Interactive 3270 emulation sessions.
mailserver Access to data available from mail servers.
z39.50 Access to ANSI Z39.50 services.
5. URL スキームを記述するための BNF
"|" が代わりに指定するために使われ、ブラケット [] がオプション的もしく
は繰り返される要素の前後に使われている以外、これは RFC822 互換で使われ
ている Uniform Resource Locator 構文のBNF-like な記述である。簡潔に言
うと、リテラルは "" で引用され、オプション的な要素は [ブラケット] で囲
まれて、要素は続く要素の n回もしくはそれ以上の繰り返しを示すために <n>*
を先頭に持つ。nのデフォルトは 0である。
; URL の一般形式は:
genericurl = scheme ":" schemepart
: 示された定義済みのスキームはここで定義される。新スキームは
; IANA に登録されるだろう。
url = httpurl | ftpurl | newsurl |
nntpurl | telneturl | gopherurl |
waisurl | mailtourl | fileurl |
prosperourl | otherurl
; 新しいスキームの一般構文は以下のようになる。
otherurl = genericurl
; このスキームは小文字である。処理時には大文字小文字を区別しない
scheme = 1*[ lowalpha | digit | "+" | "-" | "." ]
schemepart = *xchar | ip-schemepart
; IP ベースのプロトコルに対する URL スキーム部分:
ip-schemepart = "//" login [ "/" urlpath ]
login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname | hostnumber
hostname = *[ domainlabel "." ] toplabel
domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
alphadigit = alpha | digit
hostnumber = digits "." digits "." digits "." digits
port = digits
user = *[ uchar | ";" | "?" | "&" | "=" ]
password = *[ uchar | ";" | "?" | "&" | "=" ]
urlpath = *xchar ; depends on protocol see section 3.1
: 定義済みのスキーム
; FTP (RFC959 参照)
ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]]
fpath = fsegment *[ "/" fsegment ]
fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
ftptype = "A" | "I" | "D" | "a" | "i" | "d"
; FILE
fileurl = "file://" [ host | "localhost" ] "/" fpath
; HTTP
httpurl = "http://" hostport [ "/" hpath [ "?" search ]]
hpath = hsegment *[ "/" hsegment ]
hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
; GOPHER (RFC1436 参照)
gopherurl = "gopher://" hostport [ / [ gtype [ selector
[ "%09" search [ "%09" gopher+_string ] ] ] ] ]
gtype = xchar
selector = *xchar
gopher+_string = *xchar
; MAILTO (see also RFC822)
mailtourl = "mailto:" encoded822addr
encoded822addr = 1*xchar ; further defined in RFC822
; NEWS (RFC1036 参照)
newsurl = "news:" grouppart
grouppart = "*" | group | article
group = alpha *[ alpha | digit | "-" | "." | "+" | "_" ]
article = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host
; NNTP (RFC977 参照)
nntpurl = "nntp://" hostport "/" group [ "/" digits ]
; TELNET
telneturl = "telnet://" login [ "/" ]
; WAIS (RFC1625 参照)
waisurl = waisdatabase | waisindex | waisdoc
waisdatabase = "wais://" hostport "/" database
waisindex = "wais://" hostport "/" database "?" search
waisdoc = "wais://" hostport "/" database "/" wtype "/" wpath
database = *uchar
wtype = *uchar
wpath = *uchar
; PROSPERO
prosperourl = "prospero://" hostport "/" ppath *[ fieldspec ]
ppath = psegment *[ "/" psegment ]
psegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
fieldspec = ";" fieldname "=" fieldvalue
fieldname = *[ uchar | "?" | ":" | "@" | "&" ]
fieldvalue = *[ uchar | "?" | ":" | "@" | "&" ]
; その他の定義
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z"
hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
alpha = lowalpha | hialpha
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
safe = "$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
punctuation = "<" | ">" | "#" | "%" | <">
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
escape = "%" hex hex
unreserved = alpha | digit | safe | extra
uchar = unreserved | escape
xchar = unreserved | reserved | escape
digits = 1*digit
6. セキュリティ考察
URL スキームはそれ自身セキュリティ的脅威を引き起こすものではない。ユー
ザは、与えられたオブジェクトに対する一時的なポイントとなる URL を続け
てそうであると言う一般的な保証はないし、それがもっと後にサーバ上でオブ
ジェクトの移動のため別のオブジェクトを指し示すことはない一般的な保証も
ない事に注意すべきである。
URL に関連するセキュリティ的脅威は、オブジェクトの検索が実際にリモート
オペレーションを害する可能性を引き起こすかもしれないような、無害の
idempotent オペレーションを実行する試みとなる URL を構築する可能性がし
ばしばあるという事である。この問題において、安全でない URL がネット
ワークプロトコルのために予約されている以外のポート番号指定により典型的
に構築される。クライアントは無意識に実際に別のプロトコルで動作している
サーバに接続する。この別のプロトコルにしたがって解釈された時の指示を含
んでいる URL の内容は意外な操作を引き起こす。例として SMTP サーバ経由
で送られる間違ったメッセージを引き起こすための gopher URL の使用がある。
警告はプロトコルに対するデフォルト以外のポート番号、特に予約された領域
内の番号のとき、を記述しているすべての URL を使うときに使われるべきで
ある。
URL が与えられたプロトコルに対して埋め込まれた符号化されたデリミタ (た
とえば telnet プロトコルでの CR と LF 文字) は転送前に複合化されないた
め、これらを含んでいるときに注意すべきである。これはプロトコルを壊すか
もしれないが、実行される意外で有害なリモートオペレーションを再び引き起
こす、拡張的な操作やパラメータのシミュレートのために使うこともできる。
秘密とされるべきパスワードを含んでいる URL の使用は明らかに懸命ではな
い。
7. 謝辞
This paper builds on the basic WWW design (RFC 1630) and much
discussion of these issues by many people on the network. The
discussion was particularly stimulated by articles by Clifford Lynch,
Brewster Kahle [10] and Wengyik Yeong [18]. Contributions from John
Curran, Clifford Neuman, Ed Vielmetti and later the IETF URL BOF and
URI working group were incorporated.
Most recently, careful readings and comments by Dan Connolly, Ned
Freed, Roy Fielding, Guido van Rossum, Michael Dolan, Bert Bos, John
Kunze, Olle Jarnefors, Peter Svanberg and many others have helped
refine this RFC.
付録: コンテキストにおける URL に対する推奨
URL を含む URI はそれらの処理のためのコンテキストを与えるプロトコルを
通して転送される目的を持つ。
いくつかの場合、セマンティクス構造における別の可能なデータ構造から URL
を見分ける事が必要となるだろう。この場合、URL は文字 "URL:" で成り立つ
プレフィクスに preceed される事を薦める。たとえば、このプレフィクスは
URL と別の種類の URI とを区別するために使用されるだろう。
付加的に URL が別の種類のテキストを含む多くの場合がある。たとえば電子
メール、USENET ニュースメッセージもしくは紙面上にプリントされたものを
含む場合である。このような場合、URL を分割し、それを残りのテキスト、特
に URL の一部として誤りとされる句読点から分ける分割セマンティクスラッ
パーを持つことが便利である。このような目的のため、プレフィクス ("URL:")
といっしょの角括弧 ("<" と ">") が URL の境界線として区切るために使わ
れる事を薦める。このラッパーは URL をなす部分ではなく、このデリミタが
常に記述されるようなコンテキストで使われるべきではない。
フラグメント/アンカー識別子が URL("#" に続く) と関連付けられている場合、
この識別子はよくブラケット内に置き換えられるであろう。
いくつかの場合、余分なホワイトスペース (空白、改行、タブなど) は行をま
たいで長い URL を割るために付け加える必要があるだろう。ホワイトスペー
スは URL を抜粋するときに無視される。
どのようなホワイトスペースもハイフン文字 ("-") の後に差し入れられるべ
きではない。なぜならいくつかのタイプセッタやプリンタはハイフンを改行時
の行の終わりに (誤って) 挿入するからである。ハイフンのすぐ後に改行を含
む URL を処理するものは、改行の周囲のすべての符号化されていないホワイ
トスペースを無視すべきであり、ハイフンが実際に URL の部分であろうがあ
るまいが意図されるべきである。
たとえば:
ハイ、Jim、私はそれを <URL:ftp://info.cern.ch/pub/www/doc;
type=d> で見つけましたが、多分あなたは <URL:ftp://ds.inter
nic.net/rfc> から取り出すでしょう。<URL:http://ds.internic.
net/instructions/overview.html#WARNING> にも注意してください。
参照
[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Alberti, "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, University of Minnesota, March 1993.
<URL:ftp://ds.internic.net/rfc/rfc1436.txt;type=a>
[2] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D.,
Johnson, D., and B. Alberti, "Gopher+: Upward compatible
enhancements to the Internet Gopher protocol",
University of Minnesota, July 1993.
<URL:ftp://boombox.micro.umn.edu/pub/gopher/gopher_protocol
/Gopher+/Gopher+.txt>
[3] Berners-Lee, T., "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", RFC
1630, CERN, June 1994.
<URL:ftp://ds.internic.net/rfc/rfc1630.txt>
[4] Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)",
CERN, November 1993.
<URL:ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z>
[5] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, IETF, October 1989.
<URL:ftp://ds.internic.net/rfc/rfc1123.txt>
[6] Crocker, D. "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, April 1982.
<URL:ftp://ds.internic.net/rfc/rfc822.txt>
[7] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
Functional Specification", (v1.5), Thinking Machines
Corporation, April 1990.
<URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>
[8] Horton, M. and R. Adams, "Standard For Interchange of USENET
Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
Studies, December 1987.
<URL:ftp://ds.internic.net/rfc/rfc1036.txt>
[9] Huitema, C., "Naming: Strategies and Techniques", Computer
Networks and ISDN Systems 23 (1991) 107-110.
[10] Kahle, B., "Document Identifiers, or International Standard
Book Numbers for the Electronic Age", 1991.
<URL:ftp://quake.think.com/pub/wais/doc/doc-ids.txt>
[11] Kantor, B. and P. Lapsley, "Network News Transfer Protocol:
A Proposed Standard for the Stream-Based Transmission of News",
RFC 977, UC San Diego & UC Berkeley, February 1986.
<URL:ftp://ds.internic.net/rfc/rfc977.txt>
[12] Kunze, J., "Functional Requirements for Internet Resource
Locators", Work in Progress, December 1994.
<URL:ftp://ds.internic.net/internet-drafts
/draft-ietf-uri-irl-fun-req-02.txt>
[13] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, USC/Information Sciences Institute,
November 1987.
<URL:ftp://ds.internic.net/rfc/rfc1034.txt>
[14] Neuman, B., and S. Augart, "The Prospero Protocol",
USC/Information Sciences Institute, June 1993.
<URL:ftp://prospero.isi.edu/pub/prospero/doc
/prospero-protocol.PS.Z>
[15] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, USC/Information Sciences Institute,
October 1985.
<URL:ftp://ds.internic.net/rfc/rfc959.txt>
[16] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
December 1994.
<URL:ftp://ds.internic.net/rfc/rfc1737.txt>
[17] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B.,
Kunze, J., Morris, H., and F. Schiettecatte, "WAIS over
Z39.50-1988", RFC 1625, WAIS, Inc., CNIDR, Thinking Machines
Corp., UC Berkeley, FS Consulting, June 1994.
<URL:ftp://ds.internic.net/rfc/rfc1625.txt>
[18] Yeong, W. "Towards Networked Information Retrieval", Technical
report 91-06-25-01, Performance Systems International, Inc.
<URL:ftp://uu.psi.com/wp/nir.txt>, June 1991.
[19] Yeong, W., "Representing Public Archives in the Directory",
Work in Progress, November 1991.
[20] "Coded Character Set -- 7-bit American Standard Code for
Information Interchange", ANSI X3.4-1986.
著者のアドレス
Tim Berners-Lee
World-Wide Web project
CERN,
1211 Geneva 23,
Switzerland
Phone: +41 (22)767 3755
Fax: +41 (22)767 7155
EMail: timbl@info.cern.ch
Larry Masinter
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94034
Phone: (415) 812-4365
Fax: (415) 812-4333
EMail: masinter@parc.xerox.com
Mark McCahill
Computer and Information Services,
University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: mpm@boombox.micro.umn.edu