Network Working Group R. Fielding Request for Comments: 1808 UC Irvine Category: Standards Track June 1995 相対 Uniform Resource Locators この文書の現状 このドキュメントはインターネットの標準化過程にあるインターネット コミュニティのプロトコルの航跡であり、改良の為議論と提案を求める ものである。プロトコルの状態と現状については”インターネット公式 プロトコル標準”(STD 1)現在の版を参照願いたい。このメモの配布は無 制限である。 概要 Uniform Resource Locator (URL) はインターネット経由で利用可能な資 源位置とアクセス手法の簡潔な表現である。基本となる文書の中に埋め 込まれたとき、既に基本文書の修正文脈から得られた絶対形式のURLは、 構造やネットワーク上の位置、uri-pathの一部を含む多くの情報を含ん でいる。十分定義され、解析者にも（人間または機械に）公表された基 本URLの場所であるならば、文書中にURL参照の埋め込みを可能にして元 の文脈を受け継ぐようにすれば、あらゆる文書に文脈を再度記入するよ りも有益である。この文書はこのような相対URLの文法と意味を定義す る。 1. 入門 この文書は絶対基本URLへ相対するリソース位置の簡潔な表現である"相対" URL(相対URLs)の文法と意味を記したものである。この文書は絶対の文法 と意味を指定したRFC1738"Uniform Resource Locators (URL)"[2]の姉妹 編である。 URLの共通の使い方は、他のインターネットアクセスが可能なリソースと 区別する目的で、これを文書（"基本"文書として参照される）に埋め込 むことである。 絶対URLは基本文書を検索して得られた文脈から既に得られていて、構造 や、ネットワーク上の位置、URLパスの一部を含む多くの情報を含んでい る。よく定義され公表された基本URLの場合、文書中にURL参照の埋め込 みを可能にして元の文脈を受け継ぐようにすれば、あらゆる文書中に文 Fielding Standards Track [Page 1] RFC 1808 相対 Uniform Resource Locators June 1995 脈を再度記入するよりも有益である。相対URLはデータ登録ダイアログ中で用 られ、位置の表現に必要な文字数を減らすことが可能である。 加えて、グループまたは文書の"木"が共通の目的を提供する為に構築されてい る場合、これら文書中の膨大な大多数のURLはしばしば外部ではなく、木内部 の位置を指している。同様に特定のインターネットサイトに位置する文書はリ モートサイトの資源よりも、同一サイト内の他の資源を参照していることが多 い。 相対的なURLアドレスは文書木(Document trees)に、これらの位置とアクセス 機構の部分的な独立を許す。例えば、文書が各々相対URLを用いて参照し合う のであれば、単一のハイパーテキスト文書をそれぞれの"FILE"や"HTTP"、 "FTP"の体系を経由して、一斉にアクセス可能かつ、交差可能なものにできる。 その上、文書木は全体としては、埋め込まれたURLを何も変更することなく移 動が可能である。 2. 相対的なURL構文 相対URLの構文は絶対URL[2]の縮められた形態であり、あるURLの前置詞 が失われ、相対パスを翻訳する際に特定のパス構成要素("."と"..")が特 別の意味を持つものである。即ち相対URLは、絶対URLを保持可能なあら ゆる文脈中に存在するが、相対URLを処理できるシステムはこれらをURL 解析処理の一部として解読可能でなければならない。 この文書は、相対URL解析の記述をする目的の避けがたい議論であるにも 関わらず、全てのURL構文の定義を求めていない。特に基本文書は、唯一 それらの基本URLが次に示す一般的なRL構文記述に適合する場合のみ相対 URLを利用可能である。あるURL体系はこの一般的なRL構文を必要としな いにも関わらず、相対参照を含むあらゆる文書は構文に従う基本URLを持 つ、と仮定される。 2.1 URL構文構成要素 URL構文は体系に依存している。ある体系は"?"や";"のように予約された 文字を他者がちょうどそれらをパスの一部だと見なせるよう、特別な要 素を指定するために用いる。なんであれ解析者に、単一で一般的なRL構 文を元にした相対URLを解決することを許す十分なURL用法の統一性があ る。この一般RL構文は6つの要素から成り立っている： Fielding Standards Track [Page 2] RFC 1808 　　相対 Uniform Resource Locators June 1995 :///;?# を除いて、各々は特定のURLから欠けている。これらの要素は 次のように定義されている（完全なBNFは2.2章で規定）： scheme ":" ::= スキーム名、RFC 1738 [2]の2.2章通り "//" net_loc ::= ネットワークロケーションとログイン イン フォーメーション、RFC 1738 [2]の3.1章通り "/" path ::= URLパス RFC 1738 [2] 3.1章通り ";" params ::= オブジェクトパラメータ (e.g., ";type=a" とは RFC 1738 [2] 3.2.2章通り). "?" query ::= 問い合わせる情報, RFC 1738 [2] 3.3章 "#" fragment ::= フラグメント識別子 フラグメント識別子（と、先行する#）はURLの一部とは見倣されないことに 注意。何であれフラグメントは、URLとして同じ文字列の文脈中において一般 に用いられるので、フラグメントが存在した場合解析者はフラグメントを判 別できなければならないし、解析処理の一部として取っておかなければなら ない。 要素の順番は重要である。もし両方のとが存在したならば、 情報はの後に現れなければならない。 2.2 相対URLのBNF これはBNFに似た相対Uniform Resource Locator 構文の解説であり、RFC 822 [5]の議論を用いている。例外的に"|"は二者択一を示すために用いられる。 簡潔に言えば、文字は""によって囲まれ、"("と")"の括弧は要素を分類し、 任意の要素は[角括弧]で囲まれ、*が先行する要素はn個かより以上の続く 要素の繰り返しを表していて、nはデフォルトで0である。 このBNFもまた、有効な基本URLの一般RL構文を規定する。注意すべき点は、 RFC 1738 [2]で定義されているURL構文との違って、全ての体系で単一の予約 された文字セットを用いることと、かつ主要なURL要素において矛盾無くこれ らを使用することである。 Fielding Standards Track [Page 3] RFC 1808 相対 Uniform Resource Locators June 1995 URL = ( absoluteURL | relativeURL ) [ "#" fragment ] 絶対URL = generic-RL | ( scheme ":" *( uchar | reserved ) ) generic-RL = scheme ":" 相対URL 相対URL = net_path | abs_path | rel_path net_path = "//" net_loc [ abs_path ] abs_path = "/" rel_path rel_path = [ path ] [ ";" params ] [ "?" query ] path = fsegment *( "/" segment ) fsegment = 1*pchar segment = *pchar params = param *( ";" param ) param = *( pchar | "/" ) scheme = 1*( alpha | digit | "+" | "-" | "." ) net_loc = *( pchar | ";" | "?" ) query = *( uchar | reserved ) fragment = *( uchar | reserved ) pchar = uchar | ":" | "@" | "&" | "=" uchar = unreserved | escape unreserved = alpha | digit | safe | extra escape = "%" hex hex hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" alpha = lowalpha | hialpha 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" digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" safe = "$" | "-" | "_" | "." | "+" extra = "!" | "*" | "'" | "(" | ")" | "," national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`" reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" punctuation = "<" | ">" | "#" | "%" | <"> Fielding Standards Track [Page 4] RFC 1808 相対 Uniform Resource Locators June 1995 2.3. 体系指定と構文上のカテゴリ 各々のURL体系は、それ自身の存在、または構文成分の欠落ルールが2.1章と 2.2章において解説されている。加えて、ある体系は相対URLと共に使用する には向かない。何であれ、相対URLはそれらが役に立つ場合のみ文脈の中だけ で用いられ、解析処理ではこれら体系指定の違いは無視される。 この章中では、RFC 1738 [2]で定義されたURL構文を持っているそれらの体系 のみを例として含めた。次の体系は決して相対URLと一緒に用いられることは ない。 mailto 電子メール news USENET news telnet TELNET Protocol for Interactive Sessions あるURL体系は予約された文字を上記の様な一般RL構文以外の目的で使用する 事を許している。相対URLは、適切な基本URLが一般的なRL構文の後に続くと き、いつでもこれらの体系と共に用いることができる。 gopher Gopher と Gopher+ Protocol prospero Prospero Directory Service wais Wide Area Information Servers Protocol gopher URLのユーザーは、gopher-type情報が殆ど常に一般RLパスの最初に含 まれることに注意すべきである。もしgopher-typeが存在すれば、この種類の 情報は異なるgopher-typesを持つ文書への相対パス参照を妨害する。 最終的には、次の体系を用いることによって一般RL構文を用いて解析できる。 この文書は、相対URLがこれらの体系にとって有効であることを必ずしも示し ているわけではない。−この決定はシステムの実現と基本文書の著作の為に 残された。 file Host-specific Files ftp File Transfer Protocol http Hypertext Transfer Protocol nntp USENET news using NNTP access 注意： RFC 1738 の5章は疑問符文字("?")がftpまたはファイルパスの部分で許 すことを規定している。なんであれ実際問題として正しくなく、RFCのエ ラーだと信じられている。同様に、RFC 1738はHTTPパスの部分に予約文字 のセミコロン(";")を許している。しかし意味上の定義は為されておらず、 正しい意味はこの文書のにて定義されている。 Fielding Standards Track [Page 5] RFC 1808 相対 Uniform Resource Locators June 1995 もし相対URLを利用するつもりがあるならば、一般RLを経由して解析可能な新 しい体系が設計されているので、そちらを推奨する。新たな体系が登録され たとき、相対形式を許す記述はRFC 1738[2]の4章に従って含まれるべきであ る。 2.4. URL解析 解析するURLを受け付けたメソッドは、2.2章の一般RL構文を明らかにし、 4章で提示されている相対URLの解決アルゴリズムを述べるのに役立つ。こ の章ではURL（相対または絶対）を2.1章に記した構成要素の部分に分解する 解析ルールを記している。解析の規則は、URLが既に周りを取り囲むテキス トから分離され"解析文字列"としてコピーされているもの、と仮定する。 解析規則は、解析者によって適用される順番で掲げられている。 2.4.1. 断片（フラグメント）識別子の解析 もし解析文字列がクロスハッチ"#"文字を含む場合、部分文字列の最初の (最も左)のクロスハッチ"#"と解析文字列の最後尾は識別子であ る。クロスハッチが最後の文字であるか、クロスハッチが存在しないなら ば、フラグメント識別子は空である。クロスハッチ文字を含む、合致した 部分文字列は連続する前に解析文字列から取り除かれる。 フラグメント識別子はURLの一部とは見なされないことに注意。なんであれ、 フラグメント識別子はしばしばURLに付加されるので、解析者は処理の際に これを認識し、無視する。 2.4.2. 体系(scheme)の解析 解析文字列が最初の文字以降と、体系名の部分として許されない文字（例え ば非英数字、プラス"+"、ピリオド"."、またはハイフン"-"）の前にコロン ":"を含むのならば、URLのは最初のコロンを含まない文字の部分文 字列である。これらの文字とコロンは連続する前に解析文字列から取り除か れる。 2.4.3. ネットワーク位置/ログインの解析 解析文字列が二つのスラッシュ"//"で始まる場合、ダブルスラッシュに続く 文字から、次のスラッシュ"/"文字を含まない最後の文字までの部分文字列は、 ネットワーク位置/ログイン()のURLである。 続くスラッシュ"/"が 存在しなければ、残った解析文字の全体はに割り当てられている。 二つのスラッシュとは連続する前に解析文字列から取り除かれる。 Fielding Standards Track [Page 6] RFC 1808 相対 Uniform Resource Locators June 1995 2.4.4. 質問(query)情報の解析 解析文字列が疑問符"?"文字を含んでいるならば、最初の(最左端)疑問符"?" 以降の部分文字列と解析文字列の最後までが情報である。もし疑問符 が最後の文字であるか、疑問符が全く無ければ質問情報は空である。疑問符 文字を含み、合致する部分文字列は連続する前に解析文字列から取り除かれ る。 2.4.5. パラメータの解析 解析文字列がセミコロン";"文字を含んでいるならば、最初(最も左)のセミコ ロン";"以降の部分文字列と、解析文字列の最後までがパラメータ() である。セミコロンが最後の文字であるか、セミコロンが存在しなければ、 空である。セミコロン文字を含む、マッチした部分文字列は、連続す る前に部分文字列から取り除かれる。 2.4.6. パスの解析 以上のステップの後、残ったものは解析文字URL と先行するスラッ シュ"/"である。たとえ初期のスラッシュがURLパスの一部でなかったとして も、解析者は後の処理が相対と絶対パスの区別を処理できるスラッシュが存 在するしないに関わらず、このことを忘れてはいけない。 3. 基本URLの確立 "相対URL"という用語は、相対的な参照が適用されるある絶対的な"基本URL" の存在を示している。実際、基本URLは埋め込まれたあらゆる相対URLの意味 を定義する為に必要であり、絶対URLが無ければ相対参照は意味がない。文書 中の相対URLが有用である故、文書は解析者に識別されている必要がある。 Fielding Standards Track [Page 7] RFC 1808 相対 Uniform Resource Locators June 1995 文書の基本URLは、次に挙げる4通りの優先順位のうちの一つに確定できる。 優先順位の順番は層に置き換えて考えることができるが、最も内側で定義さ れた基本URLは高い優先順位を持っている。これは次のような図になる。 .----------------------------------------------------------. | .----------------------------------------------------. | | | .----------------------------------------------. | | | | | .----------------------------------------. | | | | | | | (3.1) 文書の内容に含まれる基本URL | | | | | | | | | | | | | | | `----------------------------------------' | | | | | | (3.2) カプセル化された実体の基本URL | | | | | | (message, document, or none). | | | | | `----------------------------------------------' | | | | (3.3) 実体を取得するために用いられるURL | | | `----------------------------------------------------' | | (3.4) 基本 URL = "" (未定義) | `----------------------------------------------------------' 3.1. 文書の内容に含まれる基本URL ある文書のメディアタイプの中には、文書の基本URLは容易に解析者が得るこ とができるので、その文書自体の文脈に埋め込むことが可能である。これは よく文脈を検索するような（例えば、E-mailやUSENETニュース）プロトコル 以外の方法によって他へ転送される内容の表のような文書の記述に役立つ。 埋め込み可能な基本URLを、各々のメディアタイプによってどのようにして指 定するかについては、この文書の範疇を超える。ユーザエージェントがメディ アタイプを操作することは、メディアタイプの仕様から適切な構文を得るこ とを可能にするであろう。例として、どのようにすれば基本URLをハイパーテ キストマークアップランゲージ中に埋め込めるかを、付録(10章)で規定した。 メッセージは合成した文書だと考えられる。メッセージの基本URLはメッセー ジのメッセージヘッダ（若しくはタグが付けられたメタ情報と同等）の中で 指定することが出来る。RFC 822 [5]に記されているようなメッセージヘッダ の使い方をしているプロトコルにとって、次のようなヘッダのフォーマット がお勧めである： base-header = "Base" ":" "" "Base"は大文字や小文字の違いに無関係であり、かぎ括弧の隣にある様々な 空白(行の折り返しに使われるものを含む)ものは無視される。例えば、ヘッ ダフィールド： Fielding Standards Track [Page 8] RFC 1808 相対 Uniform Resource Locators June 1995 Base: >URL:http://www.ics.uci.edu/Test/a/b/c> は、メッセージの基本URLが文字列"http://www.ics.uci.edu/Test/a/b/c"で あることを示している。メッセージの基本URLは次の章で記されているように、 メッセージヘッダ中のあらゆる相対URLとメッセージ中に含まれる文書のデフォ ルトの基本URLの両方を提供している。 RFC 822メッセージヘッダ構文を用いないが、メッセージ中にあるタグがつ けられたメタ情報の形態の内包を許すプロトコルは、基本URLを定義するそ れら自身の構文をメッセージの一部として定義するであろう。 3.2. Base URL from the Encapsulating Entity 基本URLが埋め込まれていなければ、文書の基本URLは文書の検索文脈によっ て定義されている。他の実体(メッセージや他の文書)の中に内包された文書 にとって、検索する文脈はその実体であり、従って文書のデフォルトの基本 URLは文書が封入された実体の基本URLである。 MIME (RFC 1521, [4])で定義された"multipart/*"や"message/*"等のメディ アタイプのように複合化したメディアタイプは、それらの封入された文書の 検索文脈の階層化を定義している。言い換えれば、複合化部分の検索文脈は その一部の複合化した実体の基本URLである。このように複合化した実体は ベースヘッダの内包を経由して検索文脈の再定義を可能にしており、この再 定義は再起的に複合化部分の階層に適用される。これらは構成要素の基本URL を変更するのではなく、各々の構成要素が埋め込まれた基本URLを含むか、 検索文脈に優先するベースヘッダを含んでいることに注意すること。 3.3. 相対URLから取り出す基本URL もし基本URLが埋め込まれておらず、文書が他の実体に内包されていない場合 (例えば、最上位レベルの複合した実体？)や、URLが基本文書を検索するため に用いられているのであれば、そのURLは基本URLであると考えられる。もし 検索が書き換えられた要求の結果であれば、最後のURL（実際の文書の検索に 用いられた結果で生じた）は基本URLである。 3.4. デフォルトの基本URL もし、3.1〜3.3章が適用される状況がない場合、基本URLは空の文字列であ り、文書中の全ての埋め込まれたURLは絶対URLであるべきだと仮定される。 Fielding Standards Track [Page 9] RFC 1808 相対 Uniform Resource Locators June 1995 文書が確立できる基本URLを保証するのは、相対URLを含む文章のディストリ ビュータの責任である。文書の基本URLが十分に定義されていない状況では、 相対URLは信頼して使用出来ないことを強調すべきである。 4. 相対URLの解析 この節では、相対URLが常に結果が絶対形式のURLとなるURL解析のアルゴリズ ム例について記す。このアルゴリズムには結果のURLが元の著者が意図した URLと同一になるという保証がないにも関わらず、あらゆる有効なURL(相対か 絶対)が、有効な基本URLが与えられた絶対形式へと矛盾無く変形できること を保証している。 解析は次のステップで実行される。 Step 1: 基本URLは3章の規則によって確立されている。基本URLが空文字列 (未知)ならば、埋め込まれたURLは絶対URLとして解釈される。 Step 2: 基本URLと埋め込まれたURLは両方共、2.4章に記述されている要素 の部分だと解析される。 a) 埋め込まれたURLが全く空であるならば、完全に基本URLを受け 継いでいる。（例えば、基本URLと等しく設定されている）つ まり既に絶対URLである。 b) 埋め込まれたURLが体系の名前で始まっているのならば、絶対 URLだと解釈できる。つまり既に絶対URLである。 c) さもなければ、埋め込まれたURLは基本URLの体系を受け継いで いる。 Step 3: 埋め込まれたURLが空でなければ7へ飛ぶ。さもなければ 埋め込まれたURLは基本URLの(もしあれば)を受け継いで いる。 Step 4: 埋め込まれたURLパスがスラッシュ"/"で始まるのならば、パスは相 対ではないので7へ飛ぶ。 Fielding Standards Track [Page 10] RFC 1808 相対 Uniform Resource Locators June 1995 Step 5: もし、埋め込まれたURLパスが空であれば、(スラッシュが先行して いなければ)埋め込まれたURLは基本URLパスを引き継いでおり、 a) もし埋め込まれたURL が空でなければ、7へ飛ぶ。さも なくば基本URL（もしあれば）の を引き継いでいるの で、 b) 埋め込まれたURLの が空でなければ、7へ飛ぶ。さもな ければ、基本URL（もしあれば）の を引き継ぐので7へ 飛ぶ。 Step 6: 最後の基本URLパス(右端にあるスラッシュ"/"の後に続く全てか、ス ラッシュがなければパス全体)の文節が取り除かれて、埋め込まれた URLパスがその場所に加えられる。新しいパスには適切な作業が行わ れるが、その作業は次の通りである。 a) "."が完全なパス文節で"./"にある全てのものは取り除かれる。 b) 完全なパスの文節としてパスの最後が"."であるならば、その"." は取り除かれる。 c) "/../"の出現は、が".."とは異なる完全なパ ス文節であれば、全て削除される。これらのパス文節の削除は反 復的だが、反復の際には最も左にあってパターンマッチングする 全てのものを取り除き、パターンマッチングするものが無くなる まで行われる。 d) パスが"/.."で終わる場合、が".."とは異な る完全なパス文節ならば、その"/.."は取り除かれる。 Step 7: 残ったURLの成分は基本URLからさまざまな要素を引き継いでいるが、 埋め込まれたURLの絶対形式を与えるために再結合される。 パラメータはそれ自身の目的にも関わらず、URLパス部を形成することはない。 従って相対パスを解析する作用がない。特に、ftpのURLにおけるその存在と ";type=d"パラメータの不足はそのURLに相対する パスの解釈に影響しない。 フラグメント識別子は埋め込まれたURL全体が空の場合のみ、基本URLのみを 受け継ぐ。 Fielding Standards Track [Page 11] RFC 1808 Relative Uniform Resource Locators June 1995 上記のアルゴリズムは試験可能な実装の出力による例を与えることを意図し ているが、アルゴリズムの実装そのものは要求されていない。例えばあるシ ステムは文字列パターンマッチの連続よりも、効率の良いステップ6のように、 併合された一対の文節スタックの実装を見つけるだろう。 5. 見本と推奨例 よく定義された基本URLのオブジェクトの中では、次のようになる。 Base: 相対URLは次のように解析される： 5.1. 通常の見本 g:h = g = ./g = g/ = /g = //g = ?y = g?y = g?y/./x = #s = g#s = g#s/./x = g?y#s = ;x = g;x = g;x?y#s = . = ./ = .. = ../ = ../g = ../.. = ../../ = ../../g = 5.2. 例外 次に示す例外は通常の稼動では起こりえず、全てのURL解析者はこれらを矛盾 することなく解決出来なければならない。各々の例は、上記と同じベースを 用いている。 Fielding Standards Track [Page 12] RFC 1808 Relative Uniform Resource Locators June 1995 空の参照は、次のような完全な基本URLへ解決される： <> = 解析者は、階層を持つレベル基本URLパスがある場合よりも、".."以上の相対 パスの部分がある場合は注意深く扱わなければならない。".."構文はURLの を変えるために用い ることはできないことに注意すること。 ../../../g = ../../../../g = 同様に、解析者は"."や".."が相対パスの完全な要素でなければ、これを特別 扱いしてはならない。 /./g = /../g = g. = .g = g.. = ..g = 滅多にない例では、相対URLの必要がなく、かつ意味のない"."の形態を使い、 ".."でパス文節を完成する場合がある。 用いる場合がある。 ./../g = ./g/. = g/./h = g/../h = 結果的には、基本URLの体系と同じであったとしても、ある古い解析者（訳注: ソフトウェア）は、相対URLの中に体系名が存在することを許している。これ は先の部分URL[1]の仕様における欠陥だと見なされているので、将来の解析者 では避けるべきである。 http:g = http: = 5.3. 推奨例 著者はコロン":"文字を含むパス名が、相対URLパス(例えば"this:that")の最 初の成分として使用できないことに注意しなければならない。なぜならば、 それらは体系名の不整合を起こすからである。故に、他の成分(例えば "./this:that")が先行したり、コロン文字を避ける為(例えば"this%3Athat") であったとしても、これらは正しく解析されるべきである。先の解析法はURL の絶対形式には影響しないため、むしろ好ましい。 Fielding Standards Track [Page 13] RFC 1808 Relative Uniform Resource Locators June 1995 スラッシュ("/")文字を引き擦っていたり、ftpディレクトリであるリソース への";type=d"パラメータと見倣されるftp URL体系の使い方には、意味上の 曖昧さがある。検索の結果、ディレクトリが埋め込まれた相対URLを含んでい るのであれば、結果の基本URLパスは、スラッシュの後の結果を含む必要があ る。この理由により":type=d"パラメータ値を、相対URLを許した文脈内で使 用しないことを推奨する。 6. 機密性の考慮 相対URLでは、その使用や解析について機密性は一切考慮されていない。何で あれ一旦相対URLが絶対URL形式に還元されたならば、RFC 1738 [2]に記され たような機密性の考慮が適用される。 7. 謝辞 この文書はTim Berners-LeeとWorld-Wide Web global information initiative によって紹介された概念から作られた。相対URLはRFC 1630 [1]に"部分的なURL" として記されている。この記述はRFC1738 ""Uniform Resource Locators (URL)" [2] の初期草案用の付録として含まれていたものを拡張したものである。そ の後の進んだ議論では、URI-WGは相対URLを初期URLの草案から分離すること を明記する、と決定した。 この文書は、[6]で示されたインターネットリソースロケータの推奨を満たすこ とを意図している。これは全てのURI-WGに携わる人々のコメントによる恩恵で ある。特にLarry Masinter、Michael A. Dolan、Guido van Rossum、 Dave Kristol、David Robinson、そしてBrad Barbeは、初期の草案における問 題と欠陥について明らかにしてくれた故に感謝するものである。 8. 参考文献 [1] 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. [2] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994. [3] Berners-Lee T., and D. Connolly, "HyperText Markup Language Specification -- 2.0", Work in Progress, MIT, HaL Computer Systems, February 1995. Fielding Standards Track [Page 14] RFC 1808 Relative Uniform Resource Locators June 1995 [4] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. [5] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [6] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, IS&T, UC Berkeley, February 1995. 9. 著作者の連絡先 Roy T. Fielding Department of Information and Computer Science University of California Irvine, CA 92717-3425 U.S.A. Tel: +1 (714) 824-4049 Fax: +1 (714) 824-4056 EMail: fielding@ics.uci.edu 10. 付録 - HTML文書中の基本URL埋め込み これらは、どのようにすれば文書の基本URLを文書の内容に埋め込むことがで きるかの例を考慮するのに役立つ。この付録では埋め込まれた基本URLを含む 文章がハイパーテキストマークアップランゲージ(HTML) [3]でどのように書か れているかを記している。この付録は相対URLの規定の形態を成しておらず、 記された例以上の配慮をされているわけでもない。 HTMLでは特別な要素として"BASE"を定義しているが、文書の"HEAD"部の中に "BASE"が存在するとき、解析者は"BASE"を合図に、あらゆる相対URLを解析す るための基本URLとして"BASE"要素の"HREF"属性を用いなければならない。 "HREF"属性は絶対URLでなければならない。注意すべきことは、HTMLにおいて 要素と属性名は大文字小文字を問わない。例えば： ... a hypertext anchor ... Fielding Standards Track [Page 15] RFC 1808 相対 Uniform Resource Locators June 1995 例題の文書を読み込んだ解析者は、与えられた相対URL "../x"が絶対URLを意味するように解析 しなければならない。 入手した文書例の内容は考慮されない。 日本語訳：河村直樹(techno01@d4.dion.ne.jp) 2000.1.30 Fielding Standards Track [Page 16]