RFC1630 日本語訳

1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as usedin the World-Wide Web. T. Berners-Lee. June 1994. (Format: TXT=57601 bytes) (Status: INFORMATIONAL)

RFC一覧
英語原文

Network Working Group                                     T. Berners-Lee
Request for Comments: 1630                                          CERN
Category: Informational                                        June 1994


                 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

【この記述の位置付け】

  この記述はインターネットコミュニティのための情報を供給する。この記述は
  どのような種類のインターネット標準も詳述していない。この記述の配布は無
  制限である。

IESG Note:

  この記述に含まれる研究がインターネット標準を説明していない事に注意。
  一般的リソース識別子に対するインターネット標準は IETF への発展の下
  にある。

【イントロダクション】

  このドキュメントはインターネット上のオブジェクトの名前やアドレスをエン
  コードするための World-Wide Web イニシアティブにより使用される構文を定
  義している。ウェブは既にあるプロトコルやウェブ自身のために開発されたプ
  ロトコル、もしくは将来的に開発されるであろうプロトコルを使ってアクセス
  されるオブジェクトを含んでいると考えられる。与えられたプロトコルの下で
  個々のオブジェクトへのアクセス命令はアドレス文字列の形態にエンコードさ
  れる。別のプロトコルはさまざまな形態のオブジェクト名の使用を許可してい
  る。一般的なオブジェクトの抽象的な理念に従い、ウェブではオブジェクトの
  普遍的セットやオブジェクトの名前やアドレスの普遍的セットの概念が要求さ
  れる。

  Universal Resource Identifier (URI) は表されたプロトコルや名前空間を参
  照する示された名前空間やアドレスにおけるこの普遍的セットの一部である。
  他で定義されている Uniform Resource Locator (URL) はネットワークプロト
  コルを使用するアクセスアルゴリズムをマップするアドレスを表す URI の一
  形態である。IETF URL の (まだ改良中の) 概念と一致する既存の URI スキー
  ムはここでリストされている。Uniform Resource Name (URN) 論争は永存可能
  なオブジェクト名のための名前空間 (とおそらくレゾリューションプロトコル)
  の定義を試みている。この領域はこのドキュメントで触れない。それは慣例的
  に存在しているドキュメントにしたがって書かれて、URL と URN ディスカッ
  ションに対する参照ポイントを供給する。

  World-Wide Web プロトコルはメーリングリスト
  www-talk-request@info.cern.ch で論議され、ニュースグループ
  comp.infosystems.www が初心者の質問に望ましい。メーリングリスト
  uri-request@bunyip.com は特に URI 問題について述べている。著者へは
  timbl@info.cern.ch でコンタクトする事ができる。

  このドキュメントは以下においてハイパーテキストて利用可能である:

  http://info.cern.ch/hypertext/WWW/Addressing/URL/URI_Overview.html

【普遍的な構文の必要性】

  この章は URI の概念を示し、仕様書の一部を形成するものではない。

  ドキュメントの検索や探索のための多くのプロトコルとシステムが現在使用さ
  れ、もっと多くのプロトコルや既存のプロトコルの改良版が、爆発的な発展を
  持つ分野において期待されている。

  これらのシステムは異なるコンピュータプラットフォームにまたがるドキュメ
  ントのグローバルな検索や読者層を成し遂げる事に努め、プロトコルとデータ
  フォーマットの過多には関わっていない。プロトコルの発展として、ゲート
  ウェイは可能な遺物へのグローバルなアクセスを可能にする。データフォー
  マットの発展として、フォーマット変換プログラムがグローバルなアクセスを
  維持している。しかしながら、改造を作る事が非現実的であるようなある部分
  が存在し、これはオブジェクトを識別するために使用される名前とアドレスに
  おけるものである。これは、封筒の時代後からハイパーテキストオブジェクト
  時代まで名前やアドレスがさまざまな方法で与えられ、そして多くは長い間使
  用されているからである。

  過去のほとんどすべてのデータモデルのと推奨されるシステムの共通の機能は
  "オブジェクト" の概念とそのオブジェクトに対する何種類かの名前、アドレ
  スもしくは識別子と結び付けられるようなものである。それゆえあるものは存
  在するといえるこれらのオブジェクトにおける名前空間のセットを定義する事
  ができる。

  実際的なシステムは別別に存在しているオブジェクトと推奨されるシステムに
  アクセスし調和させる必要がある。それゆえ、あらゆるの名前空間において、
  すべてのオブジェクトの普遍的なセットの概念と、名前とアドレスの普遍的な
  セットは重要となる。これは、たとえ異なる空間の名前が異なる特徴を持って
  いたとしても、それらが参照しているオブジェクトを行うものとして、共通な
  方法で扱われるための異なる名前空間での名前を認める。

   URIs

    このドキュメントは多くの示される名前空間での名前を含むための方法を
    定義し、名前空間付きで普遍的セットの一部を成しているそれをラベル付
    けする。このセットのそのようにエンコードされラベル付けされた一部は
    Universal Resource Identifier もしくは URI として知られている。

    普遍的な構文は存在するプロトコルを使って利用できるオブジェクトのア
    クセスを認め、技術的な拡張が成されるだろう。

    URI 構文の使用は URI 文字列のセットに対応づけられるさまざまな名前
    空間における名前とアドレスの特性に付いて何も暗に意味しない。この特
    性はプロトコルの仕様とそれぞれのスキームに対する関連した使用習慣に
    伴う。

   URLs

    既存のインターネットアクセスプロトコルのため、ほとんどの場合アクセ
    スアルゴリズムのエンコーディングを、アドレスを表すのに十分な簡潔な
    もので定義する必要がある。既存のプロトコルに関連したオブジェクトを
    参照する URI は "Uniform Resource Locator" (URL) として知られ、そ
    れは WWW で使用されているものとしてここにリストしてあるが、別のド
    キュメントにおいて正式に定義されている。

   URNs

    現在、どんな URL よりももっと恒久的な名前の空間を定義するための活
    動が存在する。これらの "Uniform Resource Names" は IETF ワークグ
    ループのディスカッションの主題である。(非公式に配布された Sollins
    and Masinter, Functional Specifications for URNs 参照。)

    URI 構文と URL 形態はすでに 1990 から World-Wide Web ソフトウェア
    によりひろく使われている。

【設計基準と選択】

  この章は仕様書の一部ではない。これは詳述が由来する道のりの簡単な説明
  である。

  設計基準

    構文は以下のように設計されている:

    拡張性                新しく名前付けされたスキームが後から追加でき
                          る。

    完全性                どんな名前付けされたスキームをエンコードする
                          事も可能である。

    印字性                もし必要であれば URI がペンとインクを用いて
                          伝えられるように、どんな URI も 7-bit ASCII
                          を使って表す事が可能である。

  普遍的構文のための選択

    構文自身に対して要素の数値と句読点、それに受け入れられる文字とエス
    ケープ規則を除いて選択の自由はほとんどない。

    拡張性の必要条件はプレフィクスとして使われているような任意の (ただ
    し登録されている) 文字を認めている事によりうまく処理される。プレ
    フィクスは左から右への解析が右から左よりもより一般的であるものとし
    て選ばれた。プレフィクスを URI の残りの部分から分けるコロンの選択
    は独断的なものである。

    文字列の残りのデコードはプレフィクスの機能として定義される。新しく
    プレフィクスがつけられるものは必要に応じて登録当局の同意の元に新し
    いスキームに対して導入される。新しいスキームの登録は名前空間に対し
    て、与えられた名前空間内の URI のデコードの定義、その特徴と適用で
    きる所、レゾリューションプロトコルの定義を明らかに必要とする。

    完全性の必要条件は未知もしくはプレーンバイナリ名を、受け入れられる
    文字を使って base 16 か 64 でエンコードできることで、簡単にうまく
    処理される。

    印字性の必要条件は、基本セットの一部分ではなく、すべてのスキームを
    文字でエンコードする必要がある事によりすでにうまく処理されている。
    たとえば、難解な場合は ISO latin 1 文字列が URL に現われるときで
    あり、ISO Latin-1 を処理できるアプリケーションの中ではそれは完全に
    処理される。しかしながら一般的な転送のため非 ASCII 文字はエスケー
    プ化される必要がある。

    この解決案は文字の安全なセットと "危険" 文字をエンコードするために
    使用される一般エスケープスキームを記述することであった。たとえば、
    この "安全" セットは電子メールにおける使用に対して適当である。これ
    は URI の模範的な形態である。

    許されない文字の描写の導入に対するエスケープ文字の選択も趣味的な事
    である。バックスラッシュ文字 "\" を使っている ANSI 標準が C 言語に
    おいて存在する。しかしながら UNIX コマンドラインでのこの文字の使用
    は多くのシェルプログラムにより中間処理されるため問題となりうるし、
    自分自身がエスケープされなければならないだろう。特定のキーボード上
    で利用できない文字でもある。等価記号は通常 attribute=value ペアを
    持つ名前のエンコーディングに使われている。結局、パーセント記号が適
    当なエスケープ文字として選択された。

    直接 URI の中で空白を含む多くの文字を表す事のできる必要性と、制限
    された文字セットを持つような環境やある文字が欠落する傾向があるよう
    な環境において URI を使う事のできる必要性の間で矛盾が存在する。こ
    の矛盾は与えられたコンテキストにおいて禁止されているどんな文字にも
    適用されるであろう 16 進数エスケープ法の使用で既に解決されている。
    URL がコンテキストの間で移動されるとき、エスケープされる文字のセッ
    トは明らかに増減する。

    空白文字の使用は印刷されたり電子メールにより転送されるため、URI に
    おいては危険であり、複数の空白文字の使用はとても危険である。これは
    メールのようなシステムにより行が折り返されるときの無関係な空白文字
    の常習的導入や、狭い桁幅に必要不可欠な垂直方向への展開によるためで
    あり、アプリケーション間の文字コード変換やテキスト転送の間に発生す
    る空白文字のさまざまな形式の内部変換のためである。これは URI に対
    する模範的な形態がエンコードされたすべての空白を持っている理由であ
    る。

【Reommendations】

  この章は World-Wide Web イニシアティブで使われているような URI に対す
  る構文を詳述している。一般的な構文はまだ定義されていないプロトコルとし
  ての使用を解決するための名前のための新しいスキームに対するフレームワー
  クを提供する。

【URI 構文】

  完全な URI はフォーマットがネーミングスキームの機能であるような文字列
  が続くネーミングスキーム指定子から成り立つ。インターネット上の情報の
  位置指定子のため、共通の構文が IP アドレス部分に対して使用される。URL
  構文の BNF 記述は後の章で与えられる。その構成要素は以下のようになる。
  フラグメント識別子と検索 URI は基本的な URL 定義に含まれない。

   SCHEME

    オブジェクトの URI の中で、最初の要素はコロンで残りの部分を区切っ
    たスキームの名前である。

   PATH

    URI の残りはコロンに続いてスキームに依存するフォーマットが続く。パ
    スは使用されているプロトコルに依存する方法で中間処理される。しかし
    ながら、スラッシュが含まれるなら階層構造を意味しなければならない。

【予約された文字】

  URI におけるパスは特有のスキームにより定義される意味を持つ。典型的には
  与えられた名前空間やオブジェクトにアクセスするためのアルゴリズムでの名
  前をエンコードするために使用される。どちらかの場合、エンコーディングは
  BNF 構文や別の文字の 16 進数エンコーディングによってみとめられる文字が
  使用されるだろう。

  予約された文字の幾つかはここで定義されているように特殊な使用を持つ。

   THE PERCENT SIGN

   パーセント記号 ("%", 16 進数で ASCII 25) はスキームのエンコードにお
   いてのエスケープ文字として使われ、どんな場合でも決して許されない。

   HIERARCHICAL FORMS

   スラッシュ ("/", 16 進数で ASCII 2F) 文字は階層的な関係を持つ部分文
   字列を区切るために予約されている。これは URI の部分的な形態を可能に
   する。シングルドットやダブルドット ("." や "..") の部分文字列は同じ
   く予約されている。

   二つの区分の間のスラッシュの意味は、左側パスの区分が右側パスの区分よ
   りもより重要であるという事である。(この場合における "意味" は階層構
   造のルートに近い事を言い、評価の判断にはなり得ない!)

   注意

        Unix や他のディスクオペレーティングシステムのファイル名の慣例の類
        似点は純粋に一致したものとして捉えるべきであるが、URI がファイル名
        として解釈されるべきであるということを表すと捉えるべきではない。

   HASH FOR FRAGMENT IDENTIFIERS

   ハッシュ ("#", 16 進数で ASCII 23) 文字はフラグメント識別子からオブ
   ジェクトの URI を区切るためのデリミタとして予約されている。

   QUERY STRINGS

   クエスチョンマーク ("?", 16 進数で ASCII 3F) は質問可能なオブジェク
   トの URI とそのオブジェクト上のクエリーを表現するために使用される言
   葉のセットの間の境界を区切るために使用される。この形式が使用されてい
   るとき、組み合わせられた URI はオリジナルオブジェクトに適用されるク
   エリーの結果となるオブジェクトを意味する。

   クエリー文字列の中で、プラス記号は空白の簡略した表記方法として予約さ
   れている。それゆえ、本当のプラス記号はエンコードされなければならない。
   この方法はクエリー URI を空白文字が許されないシステムを通す事をより
   簡単にさせるために使用された。

   クエリー文字列はオブジェクトに適用される幾つかの操作を表すが、この仕
   様書はそれに対する一般的な構文やセマンティクスを与えない。実際、構文
   やセマンティクスはスキームに依存し、基本 URI と互角だろう。

   OTHER RESERVED CHARACTERS

   アスタリスク ("*", 16 進数で ASCII 2A) とエクスクラメーションマーク
   ("!", 16 進数で ASCII 21) は特定のスキーム内で特別な意味を持つように
   使われているため予約されている。

【危険な文字】

  模範的な形式では、空白、制御文字、別国文字バリアント 7 bit セットにお
  いてことなってつかわれているような ASCII コードとなる幾つかの文字、ISO
  Latin-1 セットの DEL (16 進数で 7F) より大きいすべての 8 bit 文字のよ
  うなある文字はエンコードされないで使われるべきではない。これはトラブル
  フリーインターチェンジのために推奨され、下に示されるように、エンコード
  されたセットは増減する。

【エンコーディング予約文字】

  システムがローカルアドレスのスキームを使用しているとき、焦点を当ててい
  るスキームの中のオブジェクトへの参照がグローバルに参照され、可能であれ
  ばゲートウェイサーバを通してアクセスされるかもしれないので、ローカルア
  ドレスからのマッピングを URI の中に用意するのは有用である。

  新しいネーミングスキームに対して、それが明確で可逆的であり正当な URI
  を供給するならばどのようなマッピングスキームも定義されるであろう。ロー
  カルネーミングスキームへの階層的な容貌が存在するところで、それらは使用
  されるための部分的な形態を認めるために階層的な URL パス構文でマッピン
  グされることが勧められる。

  慣習的なスキームの下でテキストに対するバイナリデータをエンコードするよ
  うなどんなスキームをも除いてすべての場合において使用される事が勧められ
  る。そのような場合、純粋な 16進数や base 64 のようによりコンパクトなエ
  ンコーディングはより適切であろう。たとえば、慣習的な URI エンコーディ
  ング方法は URI 仕様書で WAIS, FTP, Prospero や Gopher アドレスのマッピ
  ングのために使用される。

   慣習的な URI エンコーディングスキーム

   ローカルネーミングスキームが URI で許されていない ASCII 文字をつかう
   場面で、ISO Latin 1 コードで与えられるその文字に対する二つの 16 進数
   値 (0-9, A-F) が直後に続く一つのパーセント記号 "%" によって URL の中
   で表される。構文によって許されたそれらのほかの文字は URI の中ではエ
   ンコードされないで使われるべきではない。

   増減した安全な文字セット

   URI では技術的に許されているが、同じエンコーディング方法は、不完全な
   ゲートウェイによる欠落や、バリアント文字または与えられた環境において
   単純に都合の悪い文字セットの使用による文字化けの問題のため、使うのが
   賢明でないエンコーディング文字のために使われるであろう。既にエンコー
   ドしておいた文字をさらにエンコードするが、% 記号はすでに一つのエン
   コードされた文字を表すため、URI は安全でないと思われるどんな文字もエ
   ンコードする事により簡単に "より安全な" ものにされるだろう。同様に、
   文字のより大きなセットが受け入れられる場合、% 記号は選択的に可逆的に
   展開される。

   それゆえ二つの URI を比較する前にそれらを同じエンコーディングレベル
   にしておく必要がある。

   しかしながら、上記で述べられた戻された文字はエンコードされるとき全く
   異なる重要性を持ち、決してこの方法でエンコードや復元を行ってはならな
   い。

   
      The percent sign intended as such must always be encoded, as its
      presence otherwise always indicates an encoding.  Sequences which
      start with a percent sign but are not followed by two hexadecimal
      characters are reserved for future extension.  (See Example 3.)

   Example 1

   以下の二つの URI は:

                http://info.cern.ch/albert/bertram/marie-claude

                http://info.cern.ch/albert/bertram/marie%2Dclaude

   %2D がハイフンのエンコードであるために同一である。

   Example 2

   以下の二つの URI は:

                http://info.cern.ch/albert/bertram/marie-claude

                http://info.cern.ch/albert/bertram%2Fmarie-claude

   二つ目の場合においてエンコードされたスラッシュが階層的な意味を持たない
   ため同一ではない。

   Example 3

   以下の二つの URI は:

                fxqn:/us/va/reston/cnri/ietf/24/asdf%*.fred

                news:12345667123%asdghfh@info.cern.ch

   すべての % 文字がエンコーディングを意味し、この勧告において "%*" や
   "%as" のデコードは定義されていないため不正である。

【部分的 (相対的) な形式】

  明確に定義された URI を持つオブジェクトの中で、別のオブジェクトの URI
  が短縮形式で与えられるかもしれない。ここで二つの URI の部分は同じであ
  る。これはグループ内のオブジェクトが完全な参照のための空間を必要としな
  い互いを参照できるようにし、ついでにオブジェクトのグループがどんな参照
  も変更する事なく移動されるようにする。参照が十分に制御されていないコン
  テキストで渡されるとき、完全な形式が常に使用されなければならないと言う
  事を強調しなければならない。

  World-Wide Web アプリケーションにおいて、コンテキスト URI は参照を含む
  ドキュメントやオブジェクトのそれである。この場合、階層的ネーミングシス
  テムのより高い順位の部分が変更されるなら、部分的な URI は劇的な変更の
  必要なく仮想オブジェクトにおいて生成されるか実在オブジェクトにおいて保
  存される。説明的に述べると、これはシステム構成要素の間を隠して情報を可
  能にする事により、実際のシステムにより高い強靭さを与える。

  部分的な形式は、特別な文字 ("/") と特別なパス要素 ("..", ".") が階層空
  間を表すために予約された意味を持ち、クライアントとサーバの両方によって
  そのように認識されなければならない URI 構文の特性を当てにしている。

  絶対形式がコロンを持たなければならず、コロンはすべてのスラッシュ文字の
  前に現れなければならないと言う点で部分的な形式は絶対形式と区別できる。
  部分的な形式を必要としないシステムはそれらの名前付けされたスキームにお
  いてどんなエンコードされていないスラッシュも使うべきではない。もしそれ
  らがそうするなら、絶対 URI はまだ機能するが、混乱が発生するだろう
  (以下の Gopher の注意参照)。

  コンテキストの URI に関連する部分的な名前の使用に対するルールは:

   もしスキーム部分が異なるなら、絶対 URI の全体が与えられなければなら
   ない。もしそうでなければ、そのスキームは除外され、そして:

   もし部分的な URI がゼロでない連続したスラッシュで開始しているなら、
   コンテキスト URI からのすべては
   その右側のどこかに
   それ以下の数の連続したスラッシュを持つ
   正確に同じ数の連続したスラッシュの最初の存在
   まで (しかし含んでいない)
   は
   同じであると思われ
   
      If the partial URI starts with a non-zero number of consecutive
      slashes, then everything from the context URI up to (but not
      including) the first occurrence of exactly the same number of
      consecutive slashes which has no greater number of consecutive
      slashes anywhere to the right of it is taken to be the same and
      so prepended to the partial URL to form the full URL. Otherwise:

   コンテキスト URI のパスの最後の部分 (もっとも右側のスラッシュ以降の
   すべて) は削除され、与えられた部分的な URI をその位置に追加し、この
   時:

   結果として、"xxx/../" や "/." のすべての存在は適当に削除される。ここ
   で xxx, "..", "." は完全なパス要素である。

   注意: 終端のスラッシュ

  もしコンテキストロケータのパスがスラッシュで終了しているなら、部分的な
  URI は同じパスでスラッシュで終了していない URI とは異なって扱われる。
  終端のスラッシュはパスの空のセグメントを示す。

   注意: Gopher

  Gopher システムは相対的な URI の概念を持たず、Gopher コミュニティは現
  在スラッシュを %2F にエスケープしない Gopher URI におけるデータ文字と
  して / を認めている。相対的な形式は一般的に Gopher サーバによって支給
  されるドキュメントに対して使う事ができない。もしそれらが使われるなら、
  実際それらが階層的な重要性を悪意の設計書にするという事を WWW ソフトウェ
  アは -- 通常は正しく -- 仮定する。しかしながら、Gopher プロトコル以外
  の HTTP の使用が奨励される。

  例

  以下の URI のコンテキストにおいて

                        magic://a/b/c//d/e/f

  部分的な URI は以下のように発展するだろう:

   g                       magic://a/b/c//d/e/g

   /g                      magic://a/g

   //g                     magic://g

   ../g                    magic://a/b/c//d/g

   g:h                     g:h

  そして以下の URI のコンテキストにおいて

                           magic://a/b/c//d/e/

  結果は正確に一致するだろう。

【Fragment-id】

  これはあるオブジェクトの一部、フラグメント、もしくはサブ機能を表す。こ
  の構文とセマンティクスはオブジェクトの原因となるアプリケーション、もし
  くはオブジェクトの内容タイプの詳述によって定義される。ここでは URL で
  表されるものによって認められる文字のみの定義をする。
   This represents a part of, fragment of, or a sub-function within, an
   object.  Its syntax and semantics are defined by the application
   responsible for the object, or the specification of the content type
   of the object.  The only definition here is of the allowed characters
   by which it may be represented in a URL.

  行や文字の範囲によるテキストドキュメント、座標によるグラフィックス、
  ladder を使う構造化ドキュメントにおけるフラグメントを表すための具体的
  な構文は標準化のためにふさわしいがここでは定義しない。

  fragment-id はオブジェクト全体の URL に続くハッシュ記号 (#) によって区
  切られたものである。もし fragment-id が空なら、ハッシュ記号は省略する
  事ができる。ハッシュ記号を伴うか伴わない空の fragment-id は URL がオブ
  ジェクト全体を参照すると言う意味となる。

  このフックはフラグメントの確認に対して行う事ができるが、オブジェクトの
  部分のアドレッシングの疑問やオブジェクトのグルーピングの疑問、続けられ
  含んでいるオブジェクト間の関係はこのドキュメントで言及されない。

  フラグメント識別子は "現行の" オブジェクトの異なるバージョンであるオブジェクトや
  異なるバージョンと現行のバージョンのオブジェクトの間の関係を表す事の疑問を申し入れない。
   Fragment identifiers do NOT address the question of objects which are
   different versions of a "living" object, nor of expressing the
   relationships between different versions and the living object.

  フラグメント識別子がそれ自身の正当性においてオブジェクトとして抜粋され
  る何かを参照していることとの関係はない。
   There is no implication that a fragment identifier refers to anything
   which can be extracted as an object in its own right.  It may, for
   example, refer to an indivisible point within an object.

【具体的なスキーム】

  いくつかの既存の標準的で実験的なプロトコルにおける URI に対するマッピ
  ングは BNF 構文定義で概略される。個別のプロトコルに関する注釈は以下の
  ようになる。これらの URI は URL として頻繁に参照されるが、URL と言う用
  語の正確な定義はまだ論議中 (March 1993) である。補われるスキームは:

   http                    Hypertext Transfer Protocol (examples)

   ftp                     File Transfer protocol

   gopher                  Gopher protocol

   mailto                  Electronic mail address

   news                    Usenet news

   telnet, rlogin and tn3270
                           Reference to interactive sessions

   wais                    Wide Area Information Servers

   file                    Local file access

  以下のスキームは電子メールのウェブの統合にとって極めて重要なものとして
  提案されているが、現在 (著者の知るところでは) 実装されていない:

   mid                     Message identifiers for electronic mail

   cid                     Content identifiers for MIME body part

  X.500 -- ネットワーク管理データベース-- や Whois++ はまだ詳述されてい
  なく将来の研究の課題である。Prespero や制限された NNTP スキームの使用
  は著者が知る限り現在実装されていない。

  "urn" プレフィクスは IETF ワークグループによって開発されているとき
  Uniform Resource Name のエンコードでの使用のために予約されている。

  新しいスキームは後々予約される事ができる。

【HTTP】

   The HTTP protocol specifies that the path is handled transparently by
   those who handle URLs, except for the servers which de-reference
   them.  The path is passed by the client to the server with any
   request, but is not otherwise understood by the client.

   The host details are not passed on to the client when the URL is an
   HTTP URL which refers to the server in question.  In this case the
   string sent starts with the slash which follows the host details.
   However, when an HTTP server is being used as a gateway (or "proxy")
   then the entire URI, whether HTTP or some other scheme, is passed on
   the HTTP command line.  The search part, if present, is sent as part
   of the HTTP command, and may in this respect be treated as part of
   the path.  No fragmentid part of a WWW URI (the hash sign and
   following) is sent with the request.  Spaces and control characters
   in URLs must be escaped for transmission in HTTP, as must other
   disallowed characters.

   EXAMPLES

      These examples are not part of the specification: they are
      provided as illustations only.  The URI of the "welcome" page to a
      server is conventionally

         http://www.my.work.com/

         As the rest of the URL (after the hostname an port) is opaque
         to the client, it shows great variety but the following are all
         fairly typical.

http://www.my.uni.edu/info/matriculation/enroling.html

http://info.my.org/AboutUs/Phonebook

http://www.library.my.town.va.us/Catalogue/76523471236%2Fwen44--4.98

http://www.my.org/462F4F2D4241522A314159265358979323846

   A URL for a server on a different port to 80 looks like

        http://info.cern.ch:8000/imaginary/test

   A reference to a particular part of a document may, including the
   fragment identifier, look like

        http://www.myu.edu/org/admin/people#andy

   in which case the string "#andy" is not sent to the server, but is
   retained by the client and used when the whole object had been
   retrieved.

    A search on a text database might look like

        http://info.my.org/AboutUs/Index/Phonebook?dobbins

   and on another database

        http://info.cern.ch/RDB/EMP?*%20where%20name%%3Ddobbins

   In all cases the client passes the path string to the server
   uninterpreted, and for the client to deduce anything from

【FTP】

   The ftp: prefix indicates that the FTP protocol is used, as defined
   in STD 9, RFC 959 or any successor.  The port number, if present,
   gives the port of the FTP server if not the FTP default.

   User name and password

      The syntax allows for the inclusion of a user name and even a
      password for those systems which do not use the anonymous FTP
      convention. The default, however, if no user or password is
      supplied, will be to use that convention, viz. that the user name
      is "anonymous" and the password the user's Internet-style mail
      address.

      Where possible, this mail address should correspond to a usable
      mail address for the user, and preferably give a DNS host name
      which resolves to the IP address of the client.  Note that servers
      currently vary in their treatment of the anonymous password.

   Path

      The FTP protocol allows for a sequence of CWD commands (change
      working directory) and a TYPE command prior to service commands
      such as RETR (retrieve) or NLIST (etc.) which actually access a
      file.

      The arguments of any CWD commands are successive segment parts of
      the URL delimited by slash, and the final segment is suitable as
      the filename argument to the RETR command for retrieval or the
      directory argument to NLIST.

      For some file systems (Unix in particular), the "/" used to denote
      the hierarchical structure of the URL corresponds to the delimiter
      used to construct a file name hierarchy, and thus, the filename
      will look the same as the URL path.  This does NOT mean that the
      URL is a Unix filename.

         Note: Retrieving subsequent URLs from the same host

      There is no common hierarchical model to the FTP protocol, so if a
      directory change command has been given, it is impossible in
      general to deduce what sequence should be given to navigate to
      another directory for a second retrieval, if the paths are
      different.  The only reliable algorithm is to disconnect and
      reestablish the control connection.

   Data type

      The data content type of a file can only, in the general FTP case,
      be deduced from the name, normally the suffix of the name.  This
      is not standardized. An alternative is for it to be transferred in
      information outside the URL.  A suitable FTP transfer type (for
      example binary "I" or text "A") must in turn be deduced from the
      data content type.  It is recommended that conventions for
      suffixes of public archives be established, but it is outside the
      scope of this standard.

      An FTP URL may optionally specify the FTP data transfer type by
      which an object is to be retrieved. Most of the methods correspond
      to the FTP "Data Types" ASCII and IMAGE for the retrieval of a
      document, as specified in FTP by the TYPE command.  One method
      indicates directory access.

      The data type is specified by a suffix to the URL.  Possible
      suffixes are:

       ;type =      Use FTP type as given to perform data
                               transfer.

       /                       Use FTP directory list commands to read
                               directory

      The type code is in the format defined in RFC 959 except that THE
      SPACE IS OMITTED FROM THE URL.

   Transfer Mode

      Stream Mode is always used.

【Gopher】

   The gopher URL specifies the host and optionally the port to which
   the client should connect. This is followed by a slash and a single
   gopher type code. This type code is used by the client to determine
   how to interpret the server's reply and is is not for sending to
   server.  The command string to be sent to the server immediately
   follows the gopher type character.  It consists of the gopher
   selector string followed by any "Gopher plus" syntax, but always
   omitting the trainling CR LF pair.

   When the gopher command string contains characters (such a embedded
   CR LF and HT characters) not allowed in a URL, these are encoded
   using the conventional encoding.

   Note that some gopher selector strings begin with a copy of the
   gopher type character, in which case that character will occur twice
   consecutively.  Also note that the gopher selector string may be an
   empty string since this is how gopher clients refer to the top-level
   directory on a gopher server.

   If the encoded command string (with trailing CR LF stripped) would be
   void then the gopher type character may be omiited and "1" (ASCII 31
   hex) is assumed.

   Note that slash "/" in gopher selector strings may not correspond to
   a level in a hierarchical structure.

【Mailto】

  これは URL が RFC822 addr-spec メールアドレスを記述できるようにする。
  % の使用は URL で %25 に変換する必要がある事に注意。たとえばゲートウェ
  イに通されるメールアドレスをなすところで使用されるようなものかもしれな
  い。

【News】

   The news locators refer to either news group names or article message
   identifiers which must conform to the rules for a Message-Id of RFC
   1036 (Horton 1987).  A message identifier may be distinguished from a
   news group name by the presence of the commercial at "@" character.
   These rules imply that within an article, a reference to a news group
   or to another article will be a valid URL (in the partial form).

   A news URL may be dereferenced using NNTP (RFC 977, Kantor 1986)
   (The ARTICLE by message-id command ) or using any other protocol for
   the conveyance of usenet news articles, or by reference to a body of
   news articles already received.

   Note 1:

      Among URLs the "news" URLs are anomalous in that they are
      location-independent. They are unsuitable as URN candidates
      because the NNTP architecture relies on the expiry of articles and
      therefore a small number of articles being available at any time.
      When a news: URL is quoted, the assumption is that the reader will
      fetch the article or group from his or her local news host.  News
      host names are NOT part of news URLs.

   Note 2:

      An outstanding problem is that the message identifier is
      insufficient to allow the retrieval of an expired article, as no
      algorithm exists for deriving an archive site and file name.  The
      addition of the date and news group set to the article's URL would
      allow this if a directory existed of archive sites by news group.

      Suggested subject of study in conjunction with NNTP working group.
      Further extension possible may be to allow the naming of subject
      threads as addressable objects.

【Telnet, rlogin, tn3270】

  相互セッションを表すための URL の使用はオブジェクトへのそれらの使用を
  拡張するのに便利である。
   The use of URLs to represent interactive sessions is a convenient
   extension to their uses for objects.  This allows access to
   information systems which only provide an interactive service, and no
   information server.  As information within the service cannot be
   addressed individually or, in general, automatically retrieved, this
   is a less desirable, though currently common, solution.

【URN】

   The "Universal Resource Name" is currently (March 1993) under
   development in the IETF.  A requirements specification is in
   preparation. It currently looks as though it will be a short string
   suitable for encoding in URI syntax, for which case the "urn:" prefix
   is reserved.  The URN shall be encoded precisely as defined in the
   (future) URN standard, except in that:

      If the official description of the URN syntax includes any
      constant wrapper characters, then they shall not be omitted from
      the URI encoding of the URN;

      If the URN has a hierarchical nature, then the slash delimiter
      shall be used in the URI encoding;

      If the URN has a hierarchical nature, the most significant part
      shall be encoded on the left in the URI encoding;

      Any characters with reserved meanings in the URI syntax shall be
      escape encoded

   These rules of course apply to any URI scheme.  It is of course
   possible that the URN syntax will be chosen such that the URI
   encoding will be a 1-1 transcription.

   An example might be a name such as

         urn:/iana/dns/ch/cern/cn/techdoc/94/1642-3

   but the reader should refer to the latest URN drafts or
   specifications.

【WAIS】

   The current WAIS implementation public domain requires that a client
   know the "type" of a object prior to retrieval. This value is
   returned along with the internal object identifier in the search
   response. It has been encoded into the path part of the URL in order
   to make the URL sufficient for the retrieval of the object.

   Within the WAIS world, names do not of course need to be prefixed by
   "wais:" (by the partial form rules).
   The wpath of a WAIS URL consists of encoded fields of the WAIS
   identifier, in the same order as inthe WAIS identifier. For each
   field, the identifier field number is the digits before the equals
   sign, and the field contents follow, encoded in the conventional
   encoding, terminated by ";".

【file】

   The other URI schemes (except nntp) share the property that they are
   equally valid at any geographical place.

   There is however a real practical requirement to be able to generate
   a URL for an object in a machine's local file system.

   The syntax is similar to the ftp syntax, but in this case the slash
   is used to donate boundaries between directory levels of a
   hierarchical file system is used.  The "client" software converts the
   file URL into a file name in the local file name conventions.  This
   allows local files to be treated just as network objects without any
   necessity to use a network server for access.  This may be used for
   example for defining a user's "home" document in WWW.

   There is clearly a danger of confusion that a link made to a local
   file should be followed by someone on a different system, with
   unexpected and possibly harmful results.  Therefore, the convention
   is that even a "file" URL is provided with a host part.  This allows
   a client on another system to know that it cannot access the file
   system, or perhaps to use some other local mecahnism to access the
   file.

   The special value "localhost" is used in the host field to indicate
   that the filename should really be used on whatever host one is.
   This for example allows links to be made to files which are
   distribted on many machines, or to "your unix local password file"
   subject of course to consistency across the users of the data.

   A void host field is equivalent to "localhost".

【Message-Id】

   For systems which include information transferred using mail
   protocols, there is a need to be able to make cross-references
   between different items of information, even though, by the nature of
   mail, those items are only available to a restricted set of people.

   Two schemes are defined.  The first, "mid:", refers to the STD 11,
   RFC 822 Message-Id of a mail message.  This Identifier is already
   used in RFC 822 in for example the References and In-Reply-to field.
   The rest of the URL after the "mid:" is the RFC822 msg-id with the
   constant <> wrapper removed, leaving an identifier whose format in
   fact happens to be the same as addr-spec format for mailboxes (though
   the semantics are different).

   The use of a "mid" URL implies access to a body of mail already
   received. If a message has been distributed using NNTP or other
   usenet protocols over the news system, then the "news:" form should
   be used.

【Content-Id】

   The second scheme, "cid:", is similar to "mid:", but makes reference
   to a body part of a MIME message by the value of its content-id
   field.  This allows, for example, a master document being the first
   part of a multipart/related MIME message to refer to component parts
   which are transferred in the same message.

   Note

      Beware however, that content identifiers are only required to be
      unique within the context of a given MIME message, and so the cid:
      URL is only meaningful with the context the same MIME message. For
      a reference outside the message, it would need to be appended to
      the message-id of the whole message.  A syntax for this has not
      been defined.

【さらなる研究のためのスキーム】

   X500

      The mapping of x500 names onto URLs is not defined here.  A
      decision is required as to whether "distinguished names" or "user
      friendly names" (ufn), or both, should be allowed.  If any
      punctuation conversions are needed from the adopted x500
      representation (such as the use of slashes between parts of a ufn)
      they must be defined.  This is a subject for study.

   WHOIS

      This prefix describes the access using the "whois++" scheme in the
      process of definition.  The host name part is the same as for
      other IP based schemes.  The path part can be either a whois
      handle for a whois object, or it can be a valid whois query
      string. This is a subject for further study.

   NETWORK MANAGEMENT DATABASE

      This is a subject for study.

   NNTP

      This is an alternative form of reference for news articles,
      specifically to be used with NNTP servers, and particularly those
      incomplete server implementations which do not allow retrieval by
      message identifier.  In all other cases the "news" scheme should
      be used.

      The news server name, newsgroup name, and index number of an
      article within the newsgroup on that particular server are given.
      The NNTP protocol must be used.

      Note 1.

         This form of URL is not of global accessability, as typically
         NNTP servers only allow access from local clients.   Note that
         the article numbers within groups vary from server to server.

         This form or URL should not be quoted outside this local area.
         It should not be used within news articles for wider
         circulation than the one server.  This is a local identifier
         for a resource which is often available globally, and so is not
         recommended except in the case in which incomplete NNTP
         implementations on the local server force its adoption.

【Prospero】

   The Prospero (Neuman, 1991) directory service is used to resolve the
   URL yielding an access method for the object (which can then itself
   be represented as a URL if translated).  The host part contains a
   host name or internet address.  The port part is optional.

   The path part contains a host specific object name and an optional
   version number. If present, the version number is separated from the
   host specific object name by the characters "%00" (percent zero
   zero), this being an escaped string terminator (null).  External
   Prospero links are represented as URLs of the underlying access
   method and are not represented as Prospero URLs.

【ネーミングスキームの登録】

   A new naming scheme may be introduced by defining a mapping onto a
   conforming URL syntax, using a new prefix.  Experimental prefixes may
   be used by mutual agreement between parties, and must start with the
   characters "x-".  The scheme name "urn:" is reserved for the work in
   progress on a scheme for more persistent names.

   It is proposed that the Internet Assigned Numbers Authority (IANA)
   perform the function of registration of new schemes. Any submission
   of a new URI scheme must include a definition of an algorithm for the
   retrieval of any object within that scheme. The algorithm must take
   the URI and produce either a set of URL(s) which will lead to the
   desired object, or the object itself, in a well-defined or
   determinable format.

   It is recommended that those proposing a new scheme demonstrate its
   utility and operability by the provision of a gateway which will
   provide images of objects in the new scheme for clients using an
   existing protocol. If the new scheme is not a locator scheme, then
   the properties of names in the new space should be clearly defined.
   It is likewise recommended that, where a protocol allows for
   retrieval by URL, that the client software have provision for being
   configured to use specific gateway locators for indirect access
   through new naming schemes.

【一般的な URI 構文の BNF】

   This is a BNF-like description of the URI syntax. at the level at
   which specific schemes are not considered.

   A vertical line "|" indicates alternatives, and [brackets] indicate
   optional parts.  Spaces are represented by the word "space", and the
   vertical line character by "vline".  Single letters stand for single
   letters.  All words of more than one letter below are entities
   described somewhere in this description.

   The "generic" production gives a higher level parsing of the same
   URIs as the other productions.  The "national" and "punctuation"
   characters do not appear in any productions and therefore may not
   appear in URIs.

     fragmentaddress        uri [ # fragmentid ]

     uri                    scheme :  path [ ? search ]

     scheme                 ialpha

     path                   void |  xpalphas  [  / path ]

     search                 xalphas [ + search ]

     fragmentid             xalphas

     xalpha                 alpha | digit | safe | extra | escape

     xalphas                xalpha [ xalphas ]

     xpalpha                xalpha | +

     xpalphas               xpalpha [ xpalpha ]

     ialpha                 alpha [ xalphas ]

     alpha                  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 | 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                  ! | * | " |  ' | ( | ) | ,

     reserved               = | ; | / | # | ? | : | space

     escape                 % hex hex

     hex                    digit | a | b | c | d | e | f | A | B | C |
                            D | E | F

     national               { | } | vline | [ | ] | \ | ^ | ~

     punctuation            < | >

     void

      (end of URI BNF)

【具体的な URL スキームのための BNF】

   This is a BNF-like description of the Uniform Resource Locator
   syntax.  A vertical line "|" indicates alternatives, and [brackets]
   indicate optional parts.  Spaces are represented by the word "space",
   and the vertical line character by "vline".  Single letters stand for
   single letters.  All words of more than one letter below are entities
   described somewhere in this description.

   The current IETF URI Working Group preference is for the prefixedurl
   production. (Nov 1993. July 93: url).

   The "national" and "punctuation" characters do not appear in any
   productions and therefore may not appear in URLs.

   The "afsaddress" is left in as historical note, but is not a url
   production.

  prefixedurl            u r l : url

  url                    httpaddress | ftpaddress | newsaddress |
                         nntpaddress | prosperoaddress | telnetaddress
                         | gopheraddress | waisaddress |
                         mailtoaddress  | midaddress | cidaddress

  scheme                 ialpha

  httpaddress            h t t p :   / / hostport [  / path ] [ ?
                         search ]

  ftpaddress             f t p : / / login / path [  ftptype ]

  afsaddress             a f s : / / cellname / path

  newsaddress            n e w s : groupart

  nntpaddress            n n t p : group /  digits

  midaddress             m i d  :  addr-spec

  cidaddress             c i d : content-identifier

  mailtoaddress          m a i l t o : xalphas @ hostname

  waisaddress            waisindex | waisdoc

  waisindex              w a i s : / / hostport / database [ ? search
                         ]

  waisdoc                w a i s : / / hostport / database / wtype  /
                         wpath

  wpath                  digits = path ;  [ wpath ]

  groupart               * | group | article

  group                  ialpha [ . group ]

  article                xalphas @ host

  database               xalphas

  wtype                  xalphas

  prosperoaddress        prosperolink

  prosperolink           p r o s p e r o : / / hostport / hsoname [ %
                         0 0 version [ attributes ] ]

  hsoname                path

  version                digits

  attributes             attribute [ attributes ]

  attribute              alphanums

  telnetaddress          t e l n e t : / / login

  gopheraddress          g o p h e r : / / hostport [/ gtype  [
                         gcommand ] ]

  login                  [ user [ : password ] @ ] hostport

  hostport               host [ : port ]

  host                   hostname | hostnumber

  ftptype                A formcode | E formcode | I | L digits

  formcode               N | T | C

  cellname               hostname

  hostname               ialpha [  .  hostname ]

  hostnumber             digits . digits . digits . digits

  port                   digits

  gcommand               path

  path                   void |  segment  [  / path ]

  segment                xpalphas

  search                 xalphas [ + search ]

  user                   alphanum2 [ user ]

  password               alphanum2 [ password ]

  fragmentid             xalphas

  gtype                  xalpha

  alphanum2              alpha | digit | - | _ | . | +

  xalpha                 alpha | digit | safe | extra | escape

  xalphas                xalpha [ xalphas ]

  xpalpha                xalpha | +

  xpalphas               xpalpha [ xpalphas ]

  ialpha                 alpha [ xalphas ]

  alpha                  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 | 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                  ! | * |  " |  ' | ( | )  | ,

  reserved               =  |  ;  |  /  |  #  | ? |  : | space

  escape                 % hex hex

  hex                    digit | a | b | c | d | e | f | A | B | C |
                         D | E | F

  national               { | } | vline | [ | ] | \ | ^ | ~

  punctuation            < | >

  digits                 digit [ digits ]

  alphanum               alpha | digit

  alphanums              alphanum [ alphanums ]

  void

   (end of URL BNF)

【参照】

  Alberti, R., et.al., "Notes on the Internet Gopher Protocol",
     University of Minnesota, December 1991,
     . See also
     

  Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)", CERN, December
     1991, as updated from time to time,
     

  Crocker, D., "Standard for ARPA Internet Text Messages" STD 11, RFC
     822, UDel, August 1982.

  Davis, F, et  al., "WAIS Interface Protocol: Prototype Functional
     Specification", Thinking Machines Corporation, April 23, 1990.
     

  International Standards Organization, Information and Documentation -
     Search and Retrieve Application Protocol Specification for open
     Systems Interconnection, ISO-10163.

  Horton, M., and R. Adams, "Standard for Interchange of USENET
     messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
     Studies, December 1987.

  Huitema, C., "Naming: strategies and techniques", Computer Networks
     and ISDN Systems 23 (1991) 107-110.

  Kahle, B., "Document Identifiers, or International Standard Book
     Numbers for the Electronic Age", 

  Kantor, B., and P. Lapsley, Kantor, B., and P. Lapsley, "Network News
     Transfer Protocol", RFC 977, UC San Diego & UC Berkeley, February
     1986.  

  Kunze, J., "Requirements for URLs", Work in Progress.

  Lynch, C., Coalition for Networked Information: "Workshop on ID and
     Reference Structures for Networked Information", November 1991. See
     

  Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC
     1034, USC/Information Sciences Institute, November 1987,
     

  Neuman, B. Clifford, "Prospero: A Tool for Organizing Internet
     Resources", Electronic Networking: Research, Applications and
     Policy, Vol 1 No 2, Meckler Westport CT USA, 1992.  See also
     

  Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9,
     RFC 959, USC/Information Sciences Institute, October 1985.
     

  Sollins, K., and L. Masinter, "Requiremnets for URNs", Work in
     Progress.

  Yeong, W., "Towards Networked Information Retrieval", Technical report
     91-06-25-01, June 1991, Performance Systems International, Inc.
     

  Yeong, W., "Representing Public Archives in the Directory", Work in
     Progress, November 1991, now expired.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   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

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

REVOKE 権限を剥奪する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る