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) この文書の現状 このドキュメントはインターネットの標準化過程にあるインターネットコミュ ニティのプロトコルの航跡であり、改良の為議論と提案を求めるものである。 プロトコルの状態と現状については”インターネット公式プロトコル標準” (STD 1)現在の版を参照願いたい。このメモの配布は無制限である。 概要 この文書はUniform Resource Locator (URL)、構文、位置の形式化された情報の 意味とインターネット経由のリソースアクセスの規定をするものである。 1. 紹介 この文書はインターネット経由で利用可能なリソースの簡潔な表現の構文と意味に ついて記している。これらの文字列は"Uniform Resource Locators" (URLs)と呼 ばれる。 この規定はWorld Wide Web global information initiativeから紹介された概 念から得られたが、彼らのオブジェクトの効能は1990年から、"Universal Resource Identifiers in WWW" RFC 1630に記されている。このURLの記述は "Functional Requirements for Internet Resource Locators" [12] で 展開 された要求を満たすように設計されている。 この文書はインターネットタスクフォースのURIワーキンググループによって書か れた。コメントがあれば編集者かURI-WG まで。グループの討 議は にアーカイブされている。 Berners-Lee, Masinter & McCahill [Page 1] RFC 1738 Uniform Resource Locators (URL) December 1994 2. 一般URL構文 リソースにアクセスする異なる手段が幾つもあるので、そのようなリソースの位 置を記述する為にいくつかの体系(schemes)がある。 一般的なURLの構文は、この文書で定義されるもの以外のプロトコルを用いて確立 された新しい体系に枠組を与える。 URLはリソース位置の抽象的な証明を与えることにより、リソースの'位置を特定す る'ために用いられる。リソースの位置が特定されると、システムはリソースに対 して'アクセス'、'更新'、'置換'、'属性調査'などの言葉でいうところの特性で 様々な操作を行う。一般にアクセス方法だけは、あらゆるURL体系で指定される必 要がある。 2.1. URLの主要部分 URL構文の全てのBNF記法は5章にある。 一般的にURLは次の様な書式になる: : URLは、一つのコロンとスキームに依存する解析文字列() が続いた()として用いられる体系の名前を含んでいる。 体系名は文字の連続から構成される。小文字の文字"a"--"z"、数字、文字の("+")、 ピリオド(".")および("-")が続く。その代償としてURLを解析するプログラムは、 体系名(例えば"HTTP"を"http"だと見なす)において大文字を小文字と同等に扱わな ければならない。 2.2. URL文字符号化問題 URLとは文字の連続である。即ち文字、数字および特別な文字である。URLは様々な 方法で表される。例えば紙の上のインクか、またはコード化された文字セットによ る8ビット値の連続によってである。URLの解析は用いられている文字の一致のみに 依存する。 殆どのURL体系で、URLの特別な部分における文字の連続は、インターネットプロト コルで使用される8ビット値の並びを表す為に用いられる。例えば、ftp体系ではホ スト名、ディレクトリ名及びファイル名が8ビット値の連続であり、URLの部分を表 している。これらの部分において、8ビット値はUS-ASCII[20]キャラクタセットで Berners-Lee, Masinter & McCahill [Page 2] RFC 1738 Uniform Resource Locators (URL) December 1994 コード化された8ビット値の文字によって表される。 加えて8ビット値は、文字%に8ビットの16進数値を成す2つの16進数("0123456789 ABCDEF")が続く、3連の文字によってエンコードされる。 8ビット値はUS-ASCIIのキャラクタセットでコード化された文字のうち、目に見え る文字が無い、相当する文字の使い方が安全でない、相当する文字が特別なURL体 系ではある他の解析の為に予約されている場合は符号化されるべきである。 US-ASCIIの表示可能な文字に一致するものは無い： URLはUS-ASCIIコードの文字セットのうち、印字可能な文字でのみ書かれている。 US-ASCIIのうち16進数の8ビット80-FFは使われておらず、8ビットの16進数00-1F と7Fは制御文字を表しているが、これらはエンコードされるべきである。 安全ではない: 文字は幾つかの理由により安全ではなくなる。空白文字が安全でない理由は、ワー プロソフト類の処理によってURLが翻訳・活字化されることにより、重要なスペー スが消えたり、重要でない空白が挿入されるからである。 "<"と">"の文字が安全ではないのは、これらが自由なテキストにおいてURLの区切 りとして用いられるからであり、引用符(""")はあるシステムにおいて区切りとし て用いられているからである。World Wide Webや他のシステムにおいて、"#"文字 はこの後に続くフラグメントやアンカー識別子からURLを区切る為に用いられるの で安全ではなく、常に符号化するべきである。"%"文字は他の文字を符号化するた めに用いられるので安全ではない。他の文字はゲートウェイや転送エージェントに よって時々これらの文字を変更する場合があることが知られているので、安全では ない。その文字は"{"、"}"、"|"、"\"、"^"、"~"、"["、"]"及び"`"である。 全ての安全でない文字はURL内において常に符号化されるべきである。例えば、'#' 文字を通常フラグメントやアンカー識別子として扱わないシステムでも、URLがそ れらの文字を使用する他のシステムにコピーされた場合にURLの符号化を変えずに 済むよう、URL内において符号化されるべきである。 Berners-Lee, Masinter & McCahill [Page 3] RFC 1738 Uniform Resource Locators (URL) December 1994 予約: 多くのURL体系はある文字を特別な目的の為に予約している：URLのscheme- specific部に現れるそれらの文字には意味がある。文字が体系で予約されている8 ビット値に一致するならば、8ビット値は符号化されているはずである。文字のう ち、";"、"/"、"?"、":"、"@"、"="および"&"は体系の中で特別な目的の為に予 約されている。文字のうち、他に体系の中で予約されているものはない。 文字または符号化されて8ビット値が現れる時は、大抵URLは同じ解析結果になる。 これは予約された文字においては正しくない：特別な体系のために予約された文字 の符号化はURLの意味を変える。 このように、予約された目的の為に使用される英数字だけのものと"$-_.+!*'()," の特別文字及び予約された文字は、URL内で符号化せずに用いる。 一方で、符号化を要求されない文字は(英数字を含む)、予約された目的で使用され ない限りは、URLのscheme-specific部分で符号化されるべきである。 2.3 階層体系と相対リンク ある場合において、URLは他のリソースへのポインタを含むリソースの位置を示す 為に用いられることがあり、また別の場合では、これらポインタが相対リンクとし て表される2次リソース位置を"後に続く相対パスを除いた、ここと同じ場所"の表 現に置き換える。この文書では相対リンクについて記さない。いずれにせよ、相対 リンクの使用は、相対リンクが基準となるリンクに対して階層構造を含む元のURL に依存する。 あるURL体系(ftpやhttp、およびfile体系)は、階層化を考慮された名前を含んでい る。階層の要素は"/"で区切られる。 Berners-Lee, Masinter & McCahill [Page 4] RFC 1738 Uniform Resource Locators (URL) December 1994 3. 体系（schemes）の指定 存在する標準かつ試験的なあるプロトコルの写像は、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 他の体系は将来の仕様書で規定されるであろう。この文書の4章では、新しい体系 の登録方法と、ある開発中の体系名のリストが記されている。 3.1. 共通インターネット体系構文 URLの残りの構文は選択された特定の体系に依存して変化すると同時に、URL体系は 体系を指定する(scheme-specific)データに共通な構文を用いて、インターネット 上のホストを指定するIPベースのプロトコルの使い方を直接指定する方法を必要と する： //:@:/ ":@"、":"、":"、及び"/"のこれ らの幾つか、あるいは全ての部分は除外される。ダブルスラッシュ"//"で始まる体 系の規格データは共通のインターネット体系の構文に従うことを示す。異なる要素 は次のルールに従う。 user 任意のユーザ名。ある体系(例えばftp)はユーザ名の指定を許可する。 password 任意のパスワード。もしパスワードが有るならば、ユーザ名の後にコロンで 区切って続ける。 もしあれば、ユーザ名（とパスワード）の後に商業における単価を示す"@"が続く。 ユーザとパスワードフィールドではあらゆる":"や"@"や"/"は符号化される。 Berners-Lee, Masinter & McCahill [Page 5] RFC 1738 Uniform Resource Locators (URL) December 1994 空のユーザー名または空のパスワードは、ユーザ名またはパスワードが無い事とは 異なり、ユーザ名なしにパスワードを指定する方法は無いことに注意する。例えば、 は空のユーザ名でパスワードが無く、 はユーザ名がなく、そして はユーザ名"foo"を持つがパスワードが空である。 host 完全に適合したネットワークホストのドメイン名、または4つの10進数の組で あるそのIPアドレスは"."で区切られて分類される。完全に適合したドメイン 名とはRFC 1034[13]の3.5章とRFC 1123[5]の2.1章で規定された形式である。 "."によって区切られるドメインラベルの連続は、各々のドメインラベルが英 数字あるいは"-"を含んだ文字で開始・終了する。右端のドメインラベルは決 して数字で始まることはないが、全てのドメイン名はIPアドレスから意味的 に区別される。 port 接続先のポート番号。多くの体系はデフォルトのポート番号を持つプロト コルを表している。他のポート番号は任意で供給され、ホスト名からコロ ンで分けられた10進数である。もしポートが省略されるならば、コロンも また省略される。 url-path 位置指定の残りは体系のデータ指定から構成されるが、これは"url-path" として知られている。これは指定されたリソースにアクセスする方法の詳細 を与える。ホスト(またはポート)とurl-pathの間の"/"は、url-pathの一部 ではないことに注意すること。 url-path構文は使用される体系に依存し、そのurl-path構文の様式通りに解析さ れる。 3.2. FTP FTP URL体系は、FTPプロトコル(RFC959)を用いてアクセス可能なインターネッ トホスト上のファイルとディレクトリを表すために用いられる。 FTP URLに従う構文は3.1章に記載されている。もし:が省略されたなら、 ポートのデフォルトは21になる。 Berners-Lee, Masinter & McCahill [Page 6] RFC 1738 Uniform Resource Locators (URL) December 1994 3.2.1. FTP ユーザ名とパスワード ユーザ名とパスワードが与えられるとFTPサーバへ最初のコネクションを張った後、 ftpの"USER"と"PASS"コマンドとして使われる。FTPサーバによって要求されるユー ザ名とパスワードが渡されなければ、慣例に従って次のような"anonymous" FTPと なる： ユーザ名"anonymous"が与えられる。 インターネットEメールアドレスがリソースをアクセスするエンドユーザのパ スワードとして与えられる。 URLがパスワードなしのユーザ名を供給するか、リモートサーバがパスワードを要 求するならば、FTP URLを解析するプログラムはユーザにパスワードを要求すべき である。 3.2.2. FTP url-path FTP URLのrul-pathは次の構文を持つ： //...//;type= からとは(可能なら符号化された)文字列であり、 は文字"a"、"i"、"d"の内の一つである。";type="は省略される。 と部分はあるいは空ある。url-path全体は省略され、ユーザ、パス ワード、ホスト及びポートの接頭辞を含むURLパスから、url-pathを分離する"/" を含む。 url-pathは次のFTPコマンドの系列として解析される： 要素の個々は、連続的にCWE(change working directory)コマンドへの 引数として渡される。 タイプコードが"d"ならば、引数をとしてNLST(name list)コマンドを実 行し、ディレクトリリストの結果を解析する。 一方、引数をとしてTYPEコマンドを実行すると、ファイル名を としてアクセスする。(例えば、RETRコマンドを用いる) nameまたはCWD要素内では、"/"と";"の文字は予約されており、符号化されるべ きである。要素は事前にFTPプロトコルにおけるそれらの用途で復号される。特に、 特別なファイルへアクセスする適切なFTP手順が、CWDやRETRコマンドへの引数の ように"/"を含む文字列の供給を要求するならば、各々の"/"を符号化する必要があ る。 Berners-Lee, Masinter & McCahill [Page 7] RFC 1738 Uniform Resource Locators (URL) December 1994 例えば、URLは"host.dom"へFTPを行 うことにより解析され、"myname"としてログが取られ(要求されたならば、パスワー ドの入力を促す)、"CWD /etc"を実行して、次に"RETR motd"を実行する。"CWD etc" の次に"RETR motd"が実行されるであろう とは異なる意味を持ち、最初に"myname"のデフォルトディレクトリに相対する"CWD" を実行する。一方では、引数を持たな い"CWD"を実行し、次に"CWD etc"、ついで"RETR mod"を行う。 FTP URLもまた他の操作によって使用される。例えば、リモートファイルサーバ上 のファイルの更新を可能にしたり、ディレクトリの一覧からファイルの情報を推論 する。ここではこのような機構について述べない。 3.2.3. FTP Typecodeは任意 FTP URLの完全なtype=部分は任意である。もし省略されたなら、URLを 解析するクライアントプログラムは使用する適切なモードを推測しなければならな い。通常ファイルのデータ内容の種類は、例えば名前の接尾語（訳注：拡張子か？） のように名前から推察されるのみである。ファイルの転送に使用する適切なタイプ コードはファイルのデータ内容から導かれる。 3.2.4 階層 あるファイルシステムにおいて"/"はURLの階層構造を表す印であり、ファイル名 の階層をなすために用いられる区切り符号と一致するので、ファイル名はURLパス に似たものとなる。これはURLがUnixファイルシステムと似ていることを意味して いるわけではない。 3.2.5. 最適化 クライアントによるFTP経由のリソースアクセスは、対話を最適化するために追加 の発見的方法を使用する。あるFTPサーバにおいて、例えば同じサーバから複数の URLによるアクセスを行っている間、制御接続を開いたままにするのは妥当である。 FTPプロトコルには共通の階層的なモデルが無いので、それゆえディレクトリ移動 のコマンドが与えられた場合にパスが異なるのであれば、次の検索のため他のディ レクトリへ移動するためにどのような手順を与えるべきかを推理するのは通常不可 能である。唯一信頼できるアルゴリズムは、制御接続を切断して再度接続を確立す ることである。 Berners-Lee, Masinter & McCahill [Page 8] RFC 1738 Uniform Resource Locators (URL) December 1994 3.3. HTTP HTTP URL体系は、HTTP(HyperText Transfer Protocol)を用いてインターネット のリソースにアクセス可能なよう表される。 HTTPプロトコルは別の場所で規定されている。規定はHTTP URLの構文のみ記し ている。 HTTP URLはこの形式になる： http://:/? とは3.1章に記されている通りである。:が省略されるとポー トはデフォルトの80になる。ユーザ名とパスワードも空欄が許される。は HTTPセレクタで、は検索文字列である。と、これに先行 する"?"も任意であるように、も任意である。やが前に 存在しなければ、"/"もまた省略される。 との要素の中では、"/"、";"、"?"は予約されている。"/"文字 は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://:/ は次のうちの何れか： %09 %09%09 Berners-Lee, Masinter & McCahill [Page 9] RFC 1738 Uniform Resource Locators (URL) December 1994 :が省略されると、デフォルトのポートは70になる。は単一文 字のフィールドで、URLが参照するリソースのGopherタイプを表す。 の全体もまた空であり、この場合区切りの"/"もまた任意で、はデフォ ルトで"1"になる。 はGopherセレクタ文字列である。Gopherプロトコルでは、Gopherセレ クタ文字列は16進数で09(US-ASCIIのHTまたはタブ)、0A(US-ASCII 文字のLF)及 び0D(US-ASCII文字のCR)を除いたあらゆる8ビット値を含む8ビット値の連続であ る。 Gopherクライアントは、Gopherサーバにセレクタ文字列を送ることによって、検 索すべきアイテムを指定する。 に予約されている文字はない。 文字の複製で始まるあるGopher 文字列は、そのような場 合二重の結果を引き起こすことに注意すること。Gopherセレクタ文字列は空の文字 列であり、これはGopherクライアントがいかにしてGopherサーバ上の最上位ディレ クトリを参照するかという手段である。 3.4.2 Gopher検索エンジンのURL指定 Gopher検索エンジンへ送る検索文字を参照するURLは、セレクタの後ろに符号化さ れたタブ(%09)と検索文字列が続いている。Gopher検索エンジンへ検索文字列を送 るには、Gopherクライアントが文字列（復号済み）一つのタブと検索文 字列をGopherサーバへ送る。 3.4.3 Gopher+アイテムのURL構文 Gopher+アイテムのURLは２個目の符号化されたタブ(%09)とGopher+文字列を持っ ている。この場合要素は空の文字列であろうが、%09文字列が与 えられるべきである。 はGopher+アイテムの検索に必要な情報を表すために用いられる。 Gopher+アイテムは任意の属性の組み合わせと、Gopher+アイテムに関する電子形 式の２つのうち、何れかの表示形式を持つ。 Gopher+ URLに関係するデータを検索するために、クライアントはサーバに接続し てGopherセレクタを送り、続いてタブと検索文字列(恐らく空)、その後にタブと Gopher+コマンドが続く。 Berners-Lee, Masinter & McCahill [Page 10] RFC 1738 Uniform Resource Locators (URL) December 1994 3.4.4 デフォルトGopher+データ表現 Gopherサーバがディレクトリのリストをクライアントに返したとき、Gopher+アイ テムは"+"(Gopher+アイテムを表す)と"?"(Gopher+に関連した+ASK形式のGopher+ アイテム)の両方のタグが付けられる。"+"のみで構成されるGopher+文字列を伴う Gopher URLは、"?"だけを含むGopher+文字列が、アイテムとアイテムに関係した Gopher電子形式を参照する間、アイテムのデフォルト表示(データの表示)を参照す る。 3.4.5 電子形式を持つGopher+アイテム +ASKを持つGopher+アイテム(即ち、"?"でタグが付けられたGopher+アイテム)はク ライアントにアイテムの+ASK属性を取り込むことを要求し、それから書式の定義を 得るためにユーザに書式を埋めるように求め、そしてアイテムを検索するためのセ レクタ文字列と一緒にユーザへ応答を返す。Gopher+クライアントはこれをどうや るかを知ってはいるが、何時この問題を扱うかを知るためにGopher+アイテム記述 の"?"タグに依存している。Gopher+文字列中で"?"はGopher+プロトコルにおける このシンボルの使い方に矛盾をなくすために用いられている。 3.4.6 Gopher+ アイテム属性の山 アイテムのGopher+属性を参照するには、Gopher URLのGopher+文字列は"!"または "$"から構成される。"!"はGopher+アイテムの属性全てを参照する。"$"はGopher ディレクトリにある全てのアイテムのアイテム属性を参照する。 3.4.7 指定したGopher+属性の参照 指定した属性を参照するために、URLのGopher+_stringは"!"ま たは"$"となる。例えば、アイテムの概要を含む属性を参照する にはgopher+_stringは"!+ABSTRACT"となるだろう。 ある属性を参照するために、gopher+_stringは符号化されたスペースによって分けら れた属性名から出来ている。例えば"!+ABSTRACT%20+SMELL"はアイテムの +ABSTRACTと+SCELL属性を参照する。 3.4.8 Gopher+オルタネートビューのURL構文 Gopher+はアイテムの任意の別のデータ表現(オルタネートビュー)を用意している。 Gopher+オルタネートビューを検索するために、Gopher+クライアントが適切な表現 と言語識別子(アイテムの+VIEW属性に見られる)を送る。指定のGopher+オルタネー トビューを検索するにはURLのGopher+文字列を次の書式にする。 Berners-Lee, Masinter & McCahill [Page 11] RFC 1738 Uniform Resource Locators (URL) December 1994 +%20 例えば"+application/postscript%20Es_ES"のGopher+文字列は、Gopher+アイテ ムのスペイン語ポストスクリプトのGopher+オルタネートビューを参照している。 3.4.9 Gopher+電子フォームのURL構文 指定した値で満たされたGopher+電子フォーム(ASKブロック)によって参照されたア イテムを参照するULRのgopher+_stringは、クライアントがサーバに送った物の符 号化されたバージョンである。 gopher+_stringの書式は次のようになる： +%091%0D%0A+-1%0D%0A%0D%0A%0D%0A.%0D%0A このアイテムを検索するには, Gopher クライアントは次のようなデータを: +1 +-1 . Gopherサーバに送る. 3.5. MAILTO mailto URL体系は個々のインターネットメールアドレスまたはサービスを表すのに 用いられる。インターネットメールアドレス以外の付加的な情報は表すことも含む ことも無い。 mailto URLの書式: mailto: はRFC 822 [6]に規定された、(符号化された)addr-specであ る。mailto URLには予約された文字はない。 パーセント符号("%")は、RFC 822において一般にアドレスと符号化に使う目的で用 いられると定められている。 多くのURLのように、mailto体系は直接アクセスされるデータオブジェクトを表し ておらず、オブジェクトを表す意味はない。MIME中のmessage/external-bodyとは 異なる使われ方をする。 Berners-Lee, Masinter & McCahill [Page 12] RFC 1738 Uniform Resource Locators (URL) December 1994 3.6. NEWS news URL体系はRFC 1036で規定されているように、USENETニュースのニュースグ ループと個別の記事の両方を参照するために用いられる。 news URLは、次のうち何れかの書式になる: news: news: は"comp.infosystems.www.misc"のようにピリオドで区切られ た階層で分類された名前である。はRFC 1036の2.1.5章 Message-ID に一致しており、囲むための"<"と">"無しに@の書 式をとる。メッセージ識別子は商業の単価を意味する"@"文字の存在によってニュー スグループと区別される。ニュースURLの要素の中に付加的な文字列は予約されて いない。 が"*"(のように)ならば、"全ての利用可能な ニュースグループ"を参照するために用いられる。 ニュースURLは、それらが一つのリソースを示すのに十分な情報を含んでいないと 言うよりも、むしろ位置独立である点が通常とは異なる。 3.7. NNTP nntp URL体系はニュース記事を参照する為の二者択一の手段であり、NNTPサーバ (RFC 977)からのニュース記事を指定するのに便利である。 nntpのURLは次の通り: nntp://:// とは3.1章で規定されている。:が省略されると、ポートはデ フォルトで119になる。 はグループの名前であり、はニュースグルー プ中の記事の数字のIDである。nntp: URLが記事のリソースの一意の位置を指定し ている間、今日のインターネット上にある多くのNNTPサーバは現在ローカルなクラ イアントによるアクセスのみを許すように設定されているので、nntp URLはグロー バルにアクセス可能なリソースを表していないことに注意すること。従って、URL のnews:形式はニュース記事を識別する方法として選ばれている。 Berners-Lee, Masinter & McCahill [Page 13] RFC 1738 Uniform Resource Locators (URL) December 1994 3.8. TELNET Telnet URL体系はTelnetプロトコルによってアクセスされる対話式のサービスを 表すために用いられる。 Telnet URLは次の形式をとる: telnet://:@:/ これは3.1章で規定されている。最後の"/"文字は省略される。もし:が省略 されると、ポートはデフォルトで23になる。:は:部 分全体と同様に省略可能である。 このURLはデータオブジェクトを表しているのではなく、むしろ対話式のサービス を表している。リモートログインを許す手段によって、リモートの対話式サービス は広範囲に変化する。実際問題として、とは状況報告を与える のみである。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://:/ wais://:/? wais://:/// とについては、3.1章に記されている。:が省略されていれば、 デフォルトで210になっている。この最初の書式は検索に使用できるWAISデータベー スを表している。次の書式は詳細な検索を表している。は問い合わせを 受けるWAISデータベースの名前である。 三番目の形式は検索されるべきWAISデータベース中の特定の文書を表している。こ の形式はオブジェクトの種類のWAIS表現である。多くのWAIS実装は、クラ イアントが検索の事前にオブジェクトの"種類"を知っていることが求められ、種類 は、検索の応答における内部のオブジェクト識別子に沿って返される。は クライアントによる適切なURL情報の解析によって、実際に文書を検索することを 許すために、URL中に含まれている Berners-Lee, Masinter & McCahill [Page 14] RFC 1738 Uniform Resource Locators (URL) December 1994 WAIS URLのはWAIS document-idからなり、必要に応じて2.2章に記され た方法によってエンコードされる。WAIS document-idはそれを発行したサーバに よってのみ分解されるよう、不透明に扱われるべきである。 3.10 FILES ファイルURL体系は特定のホストコンピュータ上にあるアクセス可能なファイルを 表すために用いられる。この体系は殆どの他のURL体系と異なり、インターネット を越えてアクセス可能な普遍的リソースを表しているわけではない。 ファイルのURLは次のような形式をとる: file:/// はにアクセス可能なシステムの完全なドメイン名であり、は //.../の書式をした階層的なディレクトリパスで ある。 例えば VMSファイルならば、 DISK$USER:[MY.NOTES]NOTE123456.TXT は次のようになる。 特例としては文字列"localhost"または空の文字列が可能である。これは 'URLを現在解析しているマシン'と解釈される。 ファイルURL体系はインターネットプロトコルやファイルのアクセス手段を指定し ない珍しいURL体系である。そのようなホスト間のネットワークプロトコルの効率 は制限されている。 3.11 プロスペロ(Prospero) プロスペロURLの体系はプロスペロディレクトリサービスを経由してアクセスされ るリソースを表すように設定されていた。プロスペロプロトコルはどこか他所の [14]に記されている。 プロスペロのURLは次のような形式をとる： prospero://:/;= とは3.1章で規定されている。:が省略されると、ポートはデ フォルトで1525になる。空欄のユーザ名とパスワードは許される。 Berners-Lee, Masinter & McCahill [Page 15] RFC 1738 Uniform Resource Locators (URL) December 1994 プロスペロプロトコルのは、相応に符号化されたホスト指定オブジェク ト名である。この名前は不透明であり、プロスペロサーバによって解析される。セ ミコロン";"は予約されており、中では必ず引用符によって囲まれる。 プロスペロURLはリソースにアクセスする適切な手段を決定するために、指定され たホストとポート番号のプロスペロディレクトリサーバと交信することによって解 析され、それ自身は別のURLとして表現される。外部プロスペロリンクは潜在的な アクセス手段として表現され、しかもプロスペロURLとしては表わされない。 スラッシュ"/"はの中に引用符なしで現れ、アプリケーションによって 仮定される意味を持たないことに注意する。スラッシュはサーバの階層構造を表す にも関わらず、この構造は保証されない。多くのはスラッシュで始まる が、このようなホストとポート番号の後には２重のスラッシュが続くことに注意す る。URL構文のスラッシュとの後に続く最初のスラッシュである。(例え ば は"/pros/name"のを表 している) 加えての後は、プロスペロリンクに関連した任意のフィールドと値がURL の一部として指定される。もしこれが存在すれば、各々のフィールド/値のペアは 互いに":"(セミコロン)で区切られており、URLの残りからも同様にセミコロンで区 切られている。フィールドの名前とその値は"="（等号）で区切られている。もし これらのフィールドが存在すれば、URLのターゲットを識別するのに役立つ。例え ば、OBJECT-VERSIONフィールドはオブジェクトの特定のバージョンを識別するた めに指定することが可能である。 4. 新しい体系の登録 新しい体系は、新しい接頭辞を用いてURL構文に準ずる写像を定義することにより 採り入れられる。実験的な体系のURLは当事者の同意の上で使用される。"x-"文字 で始まる体系名は実験目的のために予約されている。 The Internet Assigned Numbers Authority (IANA)はURL体系の登録を保守して いる。新規URL体系のあらゆる提案は、その体系と体系を表す構文の中にリソース のアクセスのためのアルゴリズムの定義を含まなければならない。 URL体系は明らかな有用性と操作性を持たなければならない。このような証明を示 す一つの手段はゲートウェイを経由して既存のプロトコルを用いるクライアントに 対して、新体系の中のオブジェクトを供給する。新たな体系がオブジェクトである Berners-Lee, Masinter & McCahill [Page 16] RFC 1738 Uniform Resource Locators (URL) December 1994 リソースを示さなければ、新しい空間における名前のプロパティは明瞭に定義され るべきである。 新たな体系は、存在する適切な体系と同様の構文の慣習に従うべきである。その上 プロトコルが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 これはUniform Resource Locator構文のBNFに似た記述法であり、RFC822の討議を 用いる。"|"は二者択一を表すことを除いて、角括弧は任意あるいは繰り返しのある 要素を囲む。簡潔に言えば文字は""で囲まれ、任意の要素は[角括弧]で囲まれ、 *が先行する要素は、続く要素のn回またはそれ以上の繰り返しを表している。 nはデフォルトでは0である。 ; URLの一般的な書式: genericurl = scheme ":" schemepart ; Specific predefined schemes are defined here; new schemes ; may be registered with IANA url = httpurl | ftpurl | newsurl | nntpurl | telneturl | gopherurl | waisurl | mailtourl | fileurl | prosperourl | otherurl ; new schemes follow the general syntax otherurl = genericurl ; the scheme is in lower case; interpreters should use case-ignore scheme = 1*[ lowalpha | digit | "+" | "-" | "." ] Berners-Lee, Masinter & McCahill [Page 17] RFC 1738 Uniform Resource Locators (URL) December 1994 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 ; The predefined schemes: ; 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 Berners-Lee, Masinter & McCahill [Page 18] RFC 1738 Uniform Resource Locators (URL) December 1994 ; MAILTO (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" Berners-Lee, Masinter & McCahill [Page 19] RFC 1738 Uniform Resource Locators (URL) December 1994 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 は異なるオブジェクトを指すこともない。 URLに関連したセキュリティの脅威とはしばしばオブジェクトの検索のような悪意 のない操作を等べきに実行しようとする試みが、事実上有害となるリモート操作を 引き起こすURLの構成を可能にすることである。安全でないURLは、典型的に問題の ネットワークプロトコルに予約された以外のポートを指定することによって構成さ れている。クライアントは実際には違うプロトコルで動作しているサーバと知らな いで交信する。URLの内容は他のプロトコルに従って解析された時に予測できない 操作を引き起こす命令を含んでいる。例を挙げると、gopher URLはSMTPサーバを 経由して送られるべき未加工なメッセージを発生させる。あらゆるURLにおいて、 プロトコルにデフォルト以外のポート番号、特に予約済みのポート番号のものを指 定しようとした場合には警告が発せられるべきである。 URLが与えられたプロトコルに埋め込まれ、符号化された区切り符号を含む場合、 (例えば、Telnetプロトコル用のCRとLF文字)は転送の前には複合化されない。特別 な操作またはパラメータを真似るために用いるのは可能であるが、これはプロトコ ル違反である。さらに予期できず、害の有るリモート操作が実行される可能性があ る。 Berners-Lee, Masinter & McCahill [Page 20] RFC 1738 Uniform Resource Locators (URL) December 1994 パスワードを含んだURLの使い方とは、明らかに賢くない秘密に対してである。 7. 感謝 この書類は基本的なWWW設計(RFC 1630)と、ネットワーク上の多くの人々によるこ れらの問題について多くの討議の上に成り立っている。討議は特にClifford Lynch、 Brewster Kahle [10] 及びWengyuk Yeong [18]の記事によって活気付けられた。 John Curran、Clifford Neuman、Ed Vielmettiとより後のIETF URL BOF とURI ワーキンググループが組み込まれた。 このRFCが洗練されるにあたり、つい最近までDan Connolly、Ned Freed、Roy Fielding、Guido van Rossum、Michael Dolan、Bert Bos、John Kunze、Olle Jarnefors、Peter Svanbergと他の多くの人々による慎重な判断とコメントの援助 を受けた。 Berners-Lee, Masinter & McCahill [Page 21] RFC 1738 Uniform Resource Locators (URL) December 1994 付録:推奨する文脈中のURL URLを含むURIは、これらの解析のための文脈を与えるプロトコルを通じて転送され ることを意図されている。 ある場合において、他の可能な構文構造におけるデータ構造とURLを識別する必要 があるだろう。この場合、URLに"URL:"文字で構成される接頭辞が続いていること が推奨される。例えば、この接頭辞はURLをURIの類から識別するのに用いられる。 加えて、URLがテキストの他の形態に含まれる場合に多くの誘因がある。例は電子 メール、USENETニュースメッセージ、または印刷された紙を含んでいる。この様な 場合、URLを区切ってテキストの残りから分離するような別の構文ラッパーを持つ のが便利であり、特に句読点からURLの部分と間違われるであろう。この目的にお いて、URLの境界を区切るため"URL:"接頭辞と一緒にかぎ括弧("<"と">")の使用が 推奨される。このラッパーはURLの一部を形成しておらず、デリミタが既に指定さ れている文脈の中では使用されるべきではない。 ある場合、URL('#'の後に続く)に関係するフラグメント/アンカー識別子は、この 識別子も角括弧の中に位置する。 ある場合では、特別な余白(空白や改行、タブ等)は長いURLを複数行に改行する為 加える必要がある。余白はURLの展開時には無視されるべきである。 余白はハイフン("-")文字の後に続くべきではない。なぜならば、あるタイプセッ タとプリンタは改行されたとき(誤って)行末のハイフンを持ち込むので、ハイフン の後直ちに改行を含むURLの解析者(訳注：ソフトウェア)は、改行の周りにある全 ての符号化されていない余白を無視すべきであり、加えてハイフンが実際にURLの 一部で有ろうと無かろうと注意すべきである。 例: Yes, Jim, I found it under but you can probably pick it up from . Note the warning in . Berners-Lee, Masinter & McCahill [Page 22] RFC 1738 Uniform Resource Locators (URL) December 1994 References [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. [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. [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. [4] Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)", CERN, November 1993. [5] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, IETF, October 1989. [6] Crocker, D. "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, April 1982. [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. [8] Horton, M. and R. Adams, "Standard For Interchange of USENET Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987. [9] Huitema, C., "Naming: Strategies and Techniques", Computer Networks and ISDN Systems 23 (1991) 107-110. Berners-Lee, Masinter & McCahill [Page 23] RFC 1738 Uniform Resource Locators (URL) December 1994 [10] Kahle, B., "Document Identifiers, or International Standard Book Numbers for the Electronic Age", 1991. [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. [12] Kunze, J., "Functional Requirements for Internet Resource Locators", Work in Progress, December 1994. [13] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [14] Neuman, B., and S. Augart, "The Prospero Protocol", USC/Information Sciences Institute, June 1993. [15] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/Information Sciences Institute, October 1985. [16] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, December 1994. [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. [18] Yeong, W. "Towards Networked Information Retrieval", Technical report 91-06-25-01, Performance Systems International, Inc. , June 1991. [19] Yeong, W., "Representing Public Archives in the Directory", Work in Progress, November 1991. Berners-Lee, Masinter & McCahill [Page 24] RFC 1738 Uniform Resource Locators (URL) December 1994 [20] "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4-1986. Editors' Addresses 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 日本語訳：河村直樹(techno01@d4.dion.ne.jp) 2000.2.20 Berners-Lee, Masinter & McCahill [Page 25]