原文：ftp://ftp.rfc-editor.org/in-notes/rfc1630.txt
訳注：本文中で「開発中」とされている資源識別子のインターネット標準は、RFC3986(Uniform Resource Identifier (URI): Generic Syntax) だと思います。
A Unifying Syntax for the Expression of
Names and Addresses of Objects on the Network
as used in the World-Wide Web
ワールドワイドウェブで使用される
ネットワーク上のオブジェクトのアドレス・名前を
表現するための統一構文
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. この文書はインターネットコミュニティのための情報を提供する。この文書はいかなる種類のインターネット標準も規定しない。この文書の配布に制限はない。
Note that the work contained in this memo does not describe an Internet standard. An Internet standard for general Resource Identifiers is under development within the IETF. この文書の内容はインターネット標準ではないことに注意してほしい。一般的な資源識別子(Resource Identifiers)のインターネット標準は IETF において開発中である。
This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. The web is considered to include objects accessed using an extendable number of protocols, existing, invented for the web itself, or to be invented in the future. Access instructions for an individual object under a given protocol are encoded into forms of address string. Other protocols allow the use of object names of various forms. In order to abstract the idea of a generic object, the web needs the concepts of the universal set of objects, and of the universal set of names or addresses of objects. この文書は、ワールドワイドウェブイニシアチブがインターネット上のオブジェクトの名前とアドレスとをエンコードするために使用する構文を定義する。ウェブは、既存、またはウェブ自身のために発案された、または将来発明されるであろう、拡張可能な数のプロトコルを使用してアクセスされるオブジェクトを含むと考えられる。特定のプロトコルの下での個々のオブジェクトへのアクセスコマンドは、アドレス文字列の形にエンコードされる。その他のプロトコルは様々な形式のオブジェクト名の使用を許可する。ウェブは、一般的なオブジェクトの考え方を抽象化するために、オブジェクトの汎用集合の概念、および、オブジェクトのアドレスまたは名前の汎用集合の概念を必要とする。
A Universal Resource Identifier (URI) is a member of this universal set of names in registered name spaces and addresses referring to registered protocols or name spaces. A Uniform Resource Locator (URL), defined elsewhere, is a form of URI which expresses an address which maps onto an access algorithm using network protocols. Existing URI schemes which correspond to the (still mutating) concept of IETF URLs are listed here. The Uniform Resource Name (URN) debate attempts to define a name space (and presumably resolution protocols) for persistent object names. This area is not addressed by this document, which is written in order to document existing practice and provide a reference point for URL and URN discussions. 統一資源識別子(URI)は、登録済みの名前空間とアドレスとにおける名前の汎用集合のメンバーであり、登録済みのプロトコルまたは名前空間を参照する。他で定義されている統一資源位置指定子(Uniform Resource Locator)(URL)は、ネットワークプロトコルを使用するアクセスアルゴリズムにマップされたアドレスを表現する URI の一形式である。IETF URL の(今なお改変中の)概念に対応する既存の URI のスキームは、この文書に記載されている。統一資源名(Uniform Resource Name)(URN)に関する議論は、持続性のあるオブジェクト名の名前空間(および、おそらく解決プロトコル)の定義を試みている。この文書ではその分野に触れていないが、既存の慣例を記述したり、URL や URN の議論への参照を提供したりするためには書かれている。
The world-wide web protocols are discussed on the mailing list www- talk-request@info.cern.ch and the newsgroup comp.infosystems.www is preferable for beginner's questions. The mailing list uri- request@bunyip.com has discussion related particularly to the URI issue. The author may be contacted as timbl@info.cern.ch. ワールドワイドウェブのプロトコルはメーリングリスト www-talk-request@info.cern.ch で議論されている。初心者の質問にはニュースグループ comp.infosystems.www が好ましい。メーリングリスト uri-request@bunyip.com は、URI の問題に特化した議論を行っている。著者の連絡先は timbl@info.cern.ch である。
This document is available in hypertext form at: この文書はハイパーテキスト形式でも利用可能である：
http://info.cern.ch/hypertext/WWW/Addressing/URL/URI_Overview.html
(訳注：リンク切れです。多分 http://www.w3.org/Addressing/URL/URI_Overview.html ですが、この RFC と整合性が取れているかどうかは未確認)
This section describes the concept of the URI and does not form part of the specification. このセクションは URI の概念を説明するものであり、仕様の一部を構成するものではない。
Many protocols and systems for document search and retrieval are currently in use, and many more protocols or refinements of existing protocols are to be expected in a field whose expansion is explosive. 現在、ドキュメントの検索・取得のための多くのプロトコルとシステムとが使用されている。爆発的に拡張する分野においては、さらに多くのプロトコルや既存のプロトコルの改良が予想される。
These systems are aiming to achieve global search and readership of documents across differing computing platforms, and despite a plethora of protocols and data formats. As protocols evolve, gateways can allow global access to remain possible. As data formats evolve, format conversion programs can preserve global access. There is one area, however, in which it is impractical to make conversions, and that is in the names and addresses used to identify objects. This is because names and addresses of objects are passed on in so many ways, from the backs of envelopes to hypertext objects, and may have a long life. 大量のプロトコルとデータフォーマットが存在するにもかかわらず、これらのシステムは異なるコンピューティングプラットフォームにまたがる全世界的なドキュメントの検索と読者数とを達成することを目的としている。プロトコルの発展によりゲートウェイによる全世界的なアクセスが可能な状態を維持することができ、データフォーマットの発展によりフォーマット変換プログラムによる全世界的なアクセスを維持できている。しかしながら、変換するのが実用的ではない分野が存在する。それは、オブジェクトの識別に使用される名前とアドレスである。その理由は、オブジェクトの名前とアドレスは非常に多くの方法(封筒の裏からハイパーテキストオブジェクトまで)により伝えられ、そして長い生存期間を持つ可能性があるためである。
A common feature of almost all the data models of past and proposed systems is something which can be mapped onto a concept of "object" and some kind of name, address, or identifier for that object. One can therefore define a set of name spaces in which these objects can be said to exist. 過去および提案中のシステムにおけるほとんど全てのデータモデルに共通の特徴は、"オブジェクト(object)" の概念にマップできる何か、そして、そのオブジェクトのための何らかの名前、またはアドレス、または識別子である。ゆえに、これらのオブジェクトが存在すると言える名前空間の集合を定義することができる。
Practical systems need to access and mix objects which are part of different existing and proposed systems. Therefore, the concept of the universal set of all objects, and hence the universal set of names and addresses, in all name spaces, becomes important. This allows names in different spaces to be treated in a common way, even though names in different spaces have differing characteristics, as do the objects to which they refer. 実用的なシステムでは、既存および提案中の異なるシステムの一部であるオブジェクトにアクセスし、混在させる必要がある。そのため、すべての名前空間におけるすべてのオブジェクトの汎用集合(したがって、名前とアドレスの汎用集合)の概念が重要となる。これにより、たとえ異なる空間の名前が異なる特徴を持っていたとしても、その異なる空間における名前を、それらが参照するオブジェクトと同じように共通の方法で扱える。
This section is not part of the specification: it is simply an explanation of the way in which the specification was derived. このセクションは仕様の一部ではない。これはこの規約が生まれた過程の簡単な説明である。
Design criteria 設計基準
The syntax was designed to be: この構文は以下のような目的で設計されている：
Choices for a universal syntax 汎用構文のための選択
For the syntax itself there is little choice except for the order and punctuation of the elements, and the acceptable characters and escaping rules. 要素の順序と句読法・受入可能な文字・エスケープの規則を除き、構文自体に選択肢はほとんどない。
The extensibility requirement is met by allowing an arbitrary (but registered) string to be used as a prefix. A prefix is chosen as left to right parsing is more common than right to left. The choice of a colon as separator of the prefix from the rest of the URI was arbitrary. プレフィクスとして任意の(ただし登録済みの)文字列の使用を許可することで、拡張性の要求が満たされている。左から右への解析が右から左への解析よりも一般的であることから、プレフィクスが選択されている。プレフィクスと URI の残りの部分とを区切るコロンの選択は独断的なものであった。
The decoding of the rest of the string is defined as a function of the prefix. New prefixed are introduced for new schemes as necessary, in agreement with the registration authority. The registration of a new scheme clearly requires the definition of the decoding of the URI into a given name space, and a definition of the properties and, where applicable, resolution protocols, for the name space. 文字列の残りの部分の解析は、そのプレフィクスにより決まる機能ごとに定義される。新しいプレフィクスは、新しいスキームのために必要に応じて(登録認定機関の合意の下で)導入される。明らかに新しいスキームの登録は、与えられた名前空間にその URI を変換する方法の定義と、その名前空間のための属性と(適用できる場合には)解決プロトコルの定義とを必要とする。
The completeness requirement is easily met by allowing particularly strange or plain binary names to be encoded in base 16 or 64 using the acceptable characters. 完全性の要求は、特に未知の名前や完全にバイナリの名前を、受入可能な文字を用いた base16 や base64 にエンコード可能にすることで、容易に満たされている。
The printability requirement could have been met by requiring all schemes to encode characters not part of a basic set. This led to many discussions of what the basic set should be. A difficult case, for example, is when an ISO latin 1 string appears in a URL, and within an application with ISO Latin-1 capability, it can be handled intact. However, for transport in general, the non-ASCII characters need to be escaped. 印字可能の要求は、基本集合の一部ではない文字がエンコードできることを全てのスキームに要求することで満たされている。これは、何が基本集合であるべきかという多くの議論を招いた。例えば複雑なケースとして、URL 中に ISO latin 1 文字列が現れた場合、ISO Latin-1 を処理する能力のあるアプリケーションはそれをそのまま処理することが可能だろう。しかしながら一般に転送のためには、非 ASCII 文字をエスケープする必要がある。
The solution to this was to specify a safe set of characters, and a general escaping scheme which may be used for encoding "unsafe" characters. This "safe" set is suitable, for example, for use in electronic mail. This is the canonical form of a URI. これを解決する対策は、文字の安全な集合と、"安全でない(unsafe)" 文字をエンコードするために使用することのできる一般的なエスケープの仕組みとを規定することである。この "安全な(safe)" 集合とは、例えば電子メールでの使用に適切なものである。これはURI の正統な形式である。
The choice of escape character for introducing representations of non-allowed characters also tends to be a matter of taste. An ANSI standard exists in the C language, using the back-slash character "\". The use of this character on unix command lines, however, can be a problem as it is interpreted by many shell programs, and would have itself to be escaped. It is also a character which is not available on certain keyboards. The equals sign is commonly used in the encoding of names having attribute=value pairs. The percent sign was eventually chosen as a suitable escape character. 許可されない文字を表現するためのエスケープ文字の選択もまた、どちらかといえば趣味の問題である。C 言語には ANSI 標準があり、バックスラッシュ文字 "\" が使用されているが、UNIX のコマンドラインでこの文字を使用すると、それが多くのシェルプログラムによって解釈されてしまうため、それ自身をエスケープしなければならないという問題となり得る。その上、この文字は特定のキーボードでは利用できない文字でもある。等号("=")は一般に 属性=値 の組を持つ名前のエンコードにおいて使用されている。最終的に適当なエスケープ文字として、パーセント記号が選択された。
There is a conflict between the need to be able to represent many characters including spaces within a URI directly, and the need to be able to use a URI in environments which have limited character sets or in which certain characters are prone to corruption. This conflict has been resolved by use of an hexadecimal escaping method which may be applied to any characters forbidden in a given context. When URLs are moved between contexts, the set of characters escaped may be enlarged or reduced unambiguously. 空白を含む多くの文字群を URI に直接表現できるようにすることと、限られた文字セットしか持たない環境や特定の文字が崩れる傾向にある環境で URI を使用できるようにする要求との間には衝突がある。この衝突は、与えられたコンテキストで禁止されている任意の文字に適用可能な 16 進エスケープ法の使用により解決されている。URL をコンテキスト間で移動する場合、エスケープされた文字の集合を、あいまいでない方法で伸張または圧縮してよい。
The use of white space characters is risky in URIs to be printed or sent by electronic mail, and the use of multiple white space characters is very risky. This is because of the frequent introduction of extraneous white space when lines are wrapped by systems such as mail, or sheer necessity of narrow column width, and because of the inter-conversion of various forms of white space which occurs during character code conversion and the transfer of text between applications. This is why the canonical form for URIs has all white spaces encoded. URI を印刷したり電子メールで送信したりする場合、空白文字の使用は危険である。複数の空白文字の使用はさらに危険である。これはメールのようなシステムや、単純に狭いカラム幅のためにラップされるシステムの場合に、余分な空白文字が頻繁に導入されることによるものであり、また文字コード変換や、アプリケーション間でのテキスト移動時に起こる様々な形式の空白文字の相互変換によるものでもある。URI の正統な形式においてすべての空白文字をエンコードするのは、このためである。
This section describes the syntax for URIs as used in the WorldWide Web initiative. The generic syntax provides a framework for new schemes for names to be resolved using as yet undefined protocols. このセクションでは、ワールドワイドウェブで使用される URI のための構文を説明する。汎用(generic)構文は、まだ定義されていないプロトコルを使用して解決される名前のための、新しいスキームに関する枠組みを提供する。
A complete URI consists of a naming scheme specifier followed by a string whose format is a function of the naming scheme. For locators of information on the Internet, a common syntax is used for the IP address part. A BNF description of the URL syntax is given in an a later section. The components are as follows. Fragment identifiers and relative URIs are not involved in the basic URL definition. 完全な URI は、名前付けスキーム指定子の後に、その名前付けスキームの機能の形式を持つ文字列を続けることで構成される。インターネット上の情報の位置を指定するために、IP アドレス部には共通の構文が使用される。URL 構文の BNF 記法は後のセクションで示される。構成要素は以下の通り。フラグメント識別子(fragment identifiers)と相対 URI は、基本 URL 定義には含まれない。
The path in the URI has a significance defined by the particular scheme. Typically, it is used to encode a name in a given name space, or an algorithm for accessing an object. In either case, the encoding may use those characters allowed by the BNF syntax, or hexadecimal encoding of other characters. URI 中のパスは、個々のスキームが定義する意味を持つ。一般的には、与えられた名前空間における名前、あるいは、オブジェクトにアクセスするためのアルゴリズムなどをエンコードするために使用される。どちらの場合もそのエンコードは、BNF 構文によって許される文字か、それ以外の文字の 16 進エンコードを使用することが許される。
Some of the reserved characters have special uses as defined here. いくつかの予約済み文字は、以下で定義されるような特別な用途を持つ。
In canonical form, certain characters such as spaces, control characters, some characters whose ASCII code is used differently in different national character variant 7 bit sets, and all 8bit characters beyond DEL (7F hex) of the ISO Latin-1 set, shall not be used unencoded. This is a recommendation for trouble-free interchange, and as indicated below, the encoded set may be extended or reduced. 空白・制御文字・各国の 7 ビット文字セットの亜種において異なった使い方をされる ASCII コードの一部の文字・ISO Latin-1 文字セットの DEL(16 進 7F)を越える全ての 8 ビット文字を、正統な形式においてエンコードせずに使用するべきではない。これは円滑な相互交換のための推奨事項であり、以下で示すように、エンコードされた文字セットは拡張されたり縮小されたりしてもよい。
When a system uses a local addressing scheme, it is useful to provide a mapping from local addresses into URIs so that references to objects within the addressing scheme may be referred to globally, and possibly accessed through gateway servers. システムがローカルなアドレス指定スキームを使用する場合、そのアドレス指定スキーム中のオブジェクトへの参照がグローバルに参照されたり、おそらくゲートウェイサーバーを通してアクセスされたり出来るように、ローカルアドレスから URI へのマッピングを提供することは有用である。
For a new naming scheme, any mapping scheme may be defined provided it is unambiguous, reversible, and provides valid URIs. It is recommended that where hierarchical aspects to the local naming scheme exist, they be mapped onto the hierarchical URL path syntax in order to allow the partial form to be used. 新しい名前付けスキームに対して、それが明確かつ可逆であり、妥当な URI を提供するという条件の下、どのようなマッピング方法が定義されてもよい。ローカルの名前付けスキームの外見的特長として階層構造がある場合、部分形式を利用できるように、階層 URL パスの構文にマップされることが推奨される。
It is also recommended that the conventional scheme below be used in all cases except for any scheme which encodes binary data as opposed to text, in which case a more compact encoding such as pure hexadecimal or base 64 might be more appropriate. For example, the conventional URI encoding method is used for mapping WAIS, FTP, Prospero and Gopher addresses in the URI specification. 以下の習慣的なスキームは、テキストではなくバイナリデータをエンコードするスキームの場合を除き(そのような場合には、純粋な 16 進や base64 のようなより簡潔なエンコードが適切だろう)、すべての場合に使用されることが推奨される。例えば習慣的な URI エンコード方法は、URI 仕様において WAIS・FTP・Prospero・Gopher の各アドレスのマッピングに使用される。
http://info.cern.ch/albert/bertram/marie-claude
and
と
http://info.cern.ch/albert/bertram/marie%2Dclaude
are identical, as the %2D encodes a hyphen character.
は、%2D がハイフンにエンコードされるため同一である。
http://info.cern.ch/albert/bertram/marie-claude
and
と
http://info.cern.ch/albert/bertram%2Fmarie-claude
are NOT identical, as in the second case the encoded slash does not
have hierarchical significance.
は、後者のエンコードされたスラッシュが階層の意味を持たないため、同一ではない。
fxqn:/us/va/reston/cnri/ietf/24/asdf%*.fred
and
と
news:12345667123%asdghfh@info.cern.ch
are illegal, as all % characters imply encodings, and there is no
decoding defined for "%*" or "%as" in this recommendation.
は、すべての % 文字がエンコードを必要とされ、この推奨では "%*" や "%as" のために定義されたエンコード方法が存在しないため、違反である。
Within a object whose URI is well defined, the URI of another object may be given in abbreviated form, where parts of the two URIs are the same. This allows objects within a group to refer to each other without requiring the space for a complete reference, and it incidentally allows the group of objects to be moved without changing any references. It must be emphasized that when a reference is passed in anything other than a well controlled context, the full form must always be used. URI が明確に定義されているオブジェクトの中に別のオブジェクトの URI が書かれており、その 2 つの URI の一部が同じ場合、内側のオブジェクトの URI を省略形で与えることができる。これはあるグループ内のオブジェクト同士が完全な領域を必要とすること無く相互参照することを可能にし、また偶然にも、オブジェクトのグループをいかなる参照も変更すること無く移動することを可能にする。参照がうまく制御されないコンテキストを通過する場合、常に完全形式が使用されなければならないことを強調しておく。
In the World-Wide Web applications, the context URI is that of the document or object containing a reference. In this case partial URIs can be generated in virtual objects or stored in real objects, without the need for dramatic change if the higher-order parts of a hierarchical naming system are modified. Apart from terseness, this gives greater robustness to practical systems, by enabling information hiding between system components. ワールドワイドウェブアプリケーションにおけるコンテキスト URI は、参照を含むオブジェクトまたは文書のそれである。この場合、部分 URI は、階層名前付けシステムの上位部分が変更された場合の劇的な変更の必要なしに、仮想オブジェクト内に生成されたり、実在のオブジェクト内に保存されたりすることができる。簡潔さとは別に、これはシステム構成要素間の情報隠蔽を可能にすることで、実用的システムにより優れた堅牢性を与える。
The partial form relies on a property of the URI syntax that certain characters ("/") and certain path elements ("..", ".") have a significance reserved for representing a hierarchical space, and must be recognized as such by both clients and servers. 部分形式は、特定の文字("/")と特定のパス要素("..", ".")とが階層空間を表現するために予約された意味を持ち、クライアントとサーバーの両方にその通りに認識されなければならないという URI 構文の特性に依存する。
A partial form can be distinguished from an absolute form in that the latter must have a colon and that colon must occur before any slash characters. Systems not requiring partial forms should not use any unencoded slashes in their naming schemes. If they do, absolute URIs will still work, but confusion may result. (See note on Gopher below.) 部分形式と完全形式は、後者がコロンを持たなければならず、そのコロンがどのスラッシュよりも前に現れなければならないという点で区別できる。部分形式を要求しないシステムは、その名前付けスキームにおいて、エンコードされないスラッシュを使用するべきではない。もし使用した場合、それでも絶対 URI はうまく動作するだろうが、混乱を引き起こす可能性がある。(後述の Gopher の注記を参照)
The rules for the use of a partial name relative to the URI of the context are: コンテキストの URI に対する相対的な部分名の使用規則は以下の通り：
If the scheme parts are different, the whole absolute URI must be given. Otherwise, the scheme is omitted, and: スキーム部分が異なる場合、完全な絶対 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 が 1 個以上の断続するスラッシュから始まる場合、そのコンテキスト URI から、断続するスラッシュの数より多くない、断続するスラッシュと正確に同じ数の最初の出現まで(ただしそれ自体は含まない)はすべて同じであると見なされ、完全な URL を形成するためにその部分 URL の先頭に追加される。そうでなければ：
The last part of the path of the context URI (anything following the rightmost slash) is removed, and the given partial URI appended in its place, and then: コンテキスト URI のパスの最後の部分(もっとも右のスラッシュに続くすべて)が取り除かれ、与えられた URI がそこに追加される、そして：
Within the result, all occurrences of "xxx/../" or "/." are recursively removed, where xxx, ".." and "." are complete path elements. 結果の中の、すべての "xxx/../" または "/." が再帰的に取り除かれる。xxx、 ".."、 "." は完結したパス要素である。
Note: Trailing slashes 注記：末尾のスラッシュ
If a path of the context locator ends in slash, partial URIs are treated differently to the URI with the same path but without a trailing slash. The trailing slash indicates a void segment of the path. コンテキストのパスがスラッシュで終わる場合、部分 URI は、同じパスで最後にスラッシュが付かない URI とは異なる扱いを受ける。最後のスラッシュはそのパスの空のセグメントを表す。
Note: Gopher 注記：ゴーファー(Gopher)
The gopher system does not have the concept of relative URIs, and the gopher community currently allows / as data characters in gopher URIs without escaping them to %2F. Relative forms may not in general be used for documents served by gopher servers. If they are used, then WWW software assumes, normally correctly, that in fact they do have hierarchical significance despite the specifications. The use of HTTP rather than gopher protocol is however recommended. ゴーファーシステムは相対 URI の概念を持たない。現在ゴーファーのコミュニティは / を %2F にエスケープせず、ゴーファー URI の中のデータ文字として許可している。一般に、ゴーファーサーバーの提供するドキュメントに対して相対形式を使用することは許されない。もし使用された場合、その仕様にもかかわらず WWW ソフトウェアは、実はそれが階層の意味を持っていると(普通に正しく)仮定する。ゴーファープロトコルより、むしろ HTTP の使用が推奨される。
Examples 例
In the context of URI 次の URI コンテキストにおいて、
magic://a/b/c//d/e/f
the partial URIs would expand as follows: 以下の部分 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
and in the context of the URI また、次の URI コンテキストにおいて、
magic://a/b/c//d/e/
the results would be exactly the same. その結果はまったく同じである。
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. これはオブジェクトの一部、または断片、または下位機能を表す。その構文とセマンティクスは、そのオブジェクトに責任を持つアプリケーション、またはそのオブジェクトの内容の型の仕様によって定義される。ここでの唯一の定義は、URL に現れることの許される文字の定義のみである。
Specific syntaxes for representing fragments in text documents by line and character range, or in graphics by coordinates, or in structured documents using ladders, are suitable for standardization but not defined here. 行や文字の範囲によるテキスト文書内、または座標による図形内、またはラダー(ladders)を使用した構造化文書内において、フラグメントを表すための具体的な構文は標準化するのに適しているが、ここでは定義しない。
The fragment-id follows the URL of the whole object from which it is separated by a hash sign (#). If the fragment-id is void, the hash sign may be omitted: A void fragment-id with or without the hash sign means that the URL refers to the whole object. fragment-id はオブジェクト全体の URL の後に続き、ハッシュ記号(#)で区切られる。fragment-id が空の場合、ハッシュ記号は省略されてもよい。ハッシュ記号の有無に関わらず、fragment-id が空の場合、その URL がオブジェクト全体を参照することを意味する。
While this hook is allowed for identification of fragments, the question of addressing of parts of objects, or of the grouping of objects and relationship between continued and containing objects, is not addressed by this document. この仕組み(hook)はフラグメントを識別するために許されているものだが、この文書では、オブジェクトの一部やオブジェクトのグループ化を表すことに付いての疑問や、継続オブジェクトと包含オブジェクトとの関係に付いての疑問には触れない。
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. フラグメント識別子は、"現在の(living)" オブジェクトの異なるバージョンのオブジェクトの問題に付いても、異なるバージョンと現在のオブジェクトとの間の関係の表現に付いても解決しない。
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. フラグメント識別子には、それ自体でオブジェクトとして展開できる何かを参照しているという意味はない。例えばフラグメント識別子は、オブジェクト内の分割できない位置を参照してもよい。
The mapping for URIs onto some existing standard and experimental protocols is outlined in the BNF syntax definition. Notes on particular protocols follow. These URIs are frequently referred to as URLs, though the exact definition of the term URL is still under discussion (March 1993). The schemes covered are: URI から既存の標準や実験的プロトコルへのマッピングは、BNF による構文定義で説明される。以下の個々のプロトコルに注目してほしい。URL という用語の正確な定義はいまだ議論中ではあるが、これらの URI はしばしば URL として言及される。対象となるスキームは以下の通り：
The following schemes are proposed as essential to the unification of the web with electronic mail, but not currently (to the author's knowledge) implemented: 以下のスキームはウェブと電子メールとの統合に不可欠なものとして提案されているが、(著者の知る限りでは)今のところ実装されていない：
The schemes for X.500, network management database, and Whois++ have not been specified and may be the subject of further study. Schemes for Prospero, and restricted NNTP use are not currently implemented as far as the author is aware. X.500、ネットワーク管理データベース、Whois++ のためのスキームは規定されておらず、さらなる研究課題となるだろう。Prospero、限定された NNTP 利用のためのスキームは、著者の知る限り今のところ実装されていない。
The "urn" prefix is reserved for use in encoding a Uniform Resource Name when that has been developed by the IETF working group. プレフィクス "urn" は、IETF ワーキンググループが統一資源名(Uniform Resource Name)のエンコードを開発したときのために予約済みである。
New schemes may be registered at a later time. 将来、新しいスキームが登録されてもよい。
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. HTTP プロトコルは、そのパスが URL を扱うもの(それらを逆参照するサーバーを除く)によって透過的に扱われると規定する。すべてのリクエストにおいてパスはクライアントからサーバーに渡され、他の方法でクライアントが解釈することはない。
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. URL が当のサーバーを参照する HTTP URL の場合、そのホストの詳細がクライアントへ渡されることはない。この場合に送られる文字列は、そのホストの詳細の後に続くスラッシュから始まる。しかしながら、HTTP サーバーがゲートウェイ(または"プロキシ(proxy)")として使用されている場合、URI 全体は(HTTP であろうと他のスキームであろうと)HTTP コマンドラインに渡される。(もしあれば)検索部は、HTTP コマンドの一部として送信され、その点ではパスの一部として扱われる。WWW URI の fragmentid 部分(ハッシュ記号とその後続)がリクエストと共に送られることはない。URL 中の空白と制御文字は、他の禁止文字と同様、HTTP による転送のためにはエスケープされなければならない。
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 これらの例は説明のために提供されているだけであり、仕様の一部ではない。サーバーの "ようこそ(welcome)" ページの URI は通常以下のようになる：
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. URL の残りの部分(ホスト名およびポート番号の後)はクライアントにとって不透明であるため非常に多様であるが、以下の URL はすべて極めて一般的なものである。
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 80 以外のポートのサーバーへの URL は次のようになる：
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. この場合、文字列 "#andy" はサーバーに送信されず、クライアントによって保持され、オブジェクト全体が取得されたときに使用される。
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 どちらの場合も、クライアントは何も解釈せず、何も推論せずにサーバーへとパス文字列を渡す。
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. プレフィクス ftp: は FTP プロトコルが使用されることを表す。FTP プロトコルは STD9, RFC 959、またはその後継で定義される。ポート番号は(もしあれば)、FTP のデフォルトではない FTP サーバーポートを表す。
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. ゴーファーの URL は、ホストと、任意でクライアントが接続するべきポートとを指定する。その後にスラッシュと単独のゴーファーの型コードが続く。この型コードは、サーバーの応答を解釈する方法を決定するためにクライアントが使用するものであり、サーバーに送信するためのものではない。サーバーに送られるコマンド文字列はゴーファーの型の文字の直後に続く。それは、"ゴーファープラス(Gopher plus)" 構文に従うゴーファーセレクタ文字列から成るが、末尾の CR LF は常に取り除かれる。
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. ゴーファーのコマンド文字列が URL で許されない文字(埋め込まれた CR LF や HT など)を含む場合、それらは習慣的なエンコード方法を使用してエンコードされる。
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. 一部のゴーファーセレクタ文字列はゴーファーの型の文字のコピーから始まり、その場合その文字が 2 個連続して現れることに注意してほしい。ゴーファークライアントがゴーファーサーバー上のトップレベルのディレクトリを参照する場合、ゴーファーセレクタ文字列に空文字列が許されることにも注意してほしい。
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. エンコードされた(末尾の CR LF を取り除かれた)コマンド文字列が空の場合、そのゴーファーの型の文字は省略されてもよく、"1"(ASCII 31(16進)) と仮定される。
Note that slash "/" in gopher selector strings may not correspond to a level in a hierarchical structure. ゴーファーセレクタ文字列中のスラッシュ "/" は、階層構造のレベルと無関係でもよいことに注意してほしい。
This allows a URL to specify an RFC822 addr-spec mail address. Note that use of % , for example as used in forming a gatewayed mail address, requires conversion to %25 in a URL. これにより、URL が RFC822 addr-spec メールアドレスを特定することが可能になる。% を使用する場合、URL の中では %25 に変換する必要があることに注意してほしい(これは例えば、ゲートウェイを通過させるメールアドレスを構築するときに使用される)。
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). ニュース位置指定子は、ニュースグループ名、または RFC 1036(Horton 1987) の Message-Id の規則に従わなければならない記事メッセージ識別子(article message identifiers)のどちらかを参照する。アット "@" 文字を用いることで、メッセージ識別子をニュースグループ名から分離することができる。これらの規則は、記事の中のニュースグループや別の記事への参照が、有効な URL(の部分形式)であることを必要とする。
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. ニュースの URL は、NNTP(RFC977, Kantor 1986)(message-id コマンドによる記事)か usenet ニュース記事の伝達のための他のプロトコルかを使用して、または受信済みニュース記事の本文への参照によって、逆参照されてもよい。
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. 対話的セッションを表現するために URL を使用することは、オブジェクトの用途に対する都合のよい拡張である。これにより、対話サービスだけを提供し、情報サーバーではない情報システムへのアクセスが可能になる。このサービス内の情報は個々にアドレス付けすることができないか、一般に自動的に取得することができないため、これはあまり魅力のない解決策である(しかし現状では一般的である)。
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: "統一資源名(Universal Resource Name)" は 現在(1993 年 3 月) IETF によって研究開発中であり、その要求仕様は準備中である。現時点で URN は、URI 構文におけるエンコードに適した短い文字列になるように思える。そのためにプレフィクス "urn:" が予約されている。以下の点を除いて、URN は(将来の)URN 標準の定義通りにエンコードされるべきである：
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. 当然ながら、これらの規則はすべての URI スキームに適用される。もちろん、URN 構文は URI エンコードが 1 対 1 に対応するような選択をされる可能性もある。
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. しかしながら読者は、最新の URN のドラフトか仕様を参照するべきである。
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. 現在の WAIS 実装のパブリックドメインは、クライアントが取得に先立ってオブジェクトの "型(type)" を知っていることを要求する。この値は検索応答内の内部オブジェクト識別子と共に返される。これは URL がオブジェクトの取得のために十分であるように、URL のパス部分の中にエンコードされるようになった。
Within the WAIS world, names do not of course need to be prefixed by "wais:" (by the partial form rules). WAIS の世界の内側では、当然ながら名前の頭に "wais:" を付ける必要はない(部分形式の規則による)。
The wpath of a WAIS URL consists of encoded fields of the WAIS identifier, in the same order as in the 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 ";". WAIS の URL の wpath は、WAIS 識別子を WAIS 識別子と同じ順序でエンコードしたフィールド群から成る。それぞれのフィールドは、等号(=)の前の数字が識別子フィールド番号、習慣的なエンコード方法に従ってエンコードされたフィールドがその後に続き、";" で終わる。
The other URI schemes (except nntp) share the property that they are equally valid at any geographical place. 他の URI のスキーム(nntp を除く)は、地理的位置に関わらず、等しく有効であるという性質を持つ。
There is however a real practical requirement to be able to generate a URL for an object in a machine's local file system. しかしながら、マシンのローカルファイルシステム内のオブジェクトの URL を生成したいという、極めて実用的な要望がある。
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. その構文は ftp のそれに似ているが、この場合のスラッシュは、階層型ファイルシステムの使用するディレクトリ階層間の境界を表すために使用される。"クライアント(client)" ソフトウェアは、file URL をローカルのファイル名の規則へと変換する。これによりローカルファイルを、アクセスのためにネットワークサーバーを使用する必要のないネットワークオブジェクトとして扱うことが可能になる。これは例えば、WWW においてユーザーの "ホーム(home)" ドキュメントを定義するために使用できる。
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. 明らかに、ローカルファイルのために作られたリンクを、別のシステム上の誰かが (予期せず、場合によっては有害な結果を伴って) たどるという混乱の危険性がある。そのため "file" URL でも、習慣的にホスト部分を伴って提供される。これにより別のシステム上のクライアントは、そのファイルシステムにアクセスできないことを知るか、そのファイルにアクセスするために何らかの別のローカルメカニズムを使用することが可能となる。
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. 特別な値 "localhost" はホストフィールドで使用され、そのファイル名がどのホスト上でも実際に使われているはずであることを表すために使用される。これにより例えば、多くのマシン上に配布されているファイルや、(もちろんそのデータのユーザー群全体に渡る一貫性の支配下にある) "あなたの unix ローカルパスワードファイル(your unix local password file)" のためのリンクを作成することが可能となる。
A void host field is equivalent to "localhost". 空のホストフィールドは "localhost" と同等である。
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). 2 つのスキームが定義されている。ひとつ目は "mid:" で、これはメールメッセージの STD 11, RFC 822 Message-Id を参照する。この識別子は、例えば RFC 822 の References フィールドと In-Reply-to フィールドですでに使用されている。"mid:" の後ろの残りの URL は、(そのセマンティクスは異なるが)メールボックスの addr-spec とたまたま同じフォーマットを持つ識別子を残して、定数の囲い文字 <> を取り除いた RFC822 の msg-id である。
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. "mid" URL を使用するということは、受信済みメールの本文にアクセスすることを意味する。メッセージが NNTP やその他の usenet プロトコルを使用して配布されている場合は、"news:" を使用するべきである。
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. 二つ目のスキーム "cid:" は "mid:" に似ているが、その content-id フィールドの値により MIME メッセージのボディ部への参照を構成する。これにより例えば、multipart/related MIME メッセージの最初の部分である最上位文書が、同じメッセージ内で送信された構成部分を参照することが可能となる。
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. しかしながら、内容識別子(content identifiers)は与えられた MIME メッセージのコンテキスト内においてのみユニークであることを要求されるため、cid: URL は同じ MIME メッセージのコンテキストにおいてのみ意味を持つことに注意してほしい。メッセージの外部を参照するには、メッセージ全体を表す message-id を追加する必要がある。そのための構文は定義されていない。
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. Prospero(Neuman, 1991) ディレクトリサービスは、オブジェクトへのアクセス方法を与える URL を解決するために使用される(変換された場合、そのオブジェクトはその後、それ自身 URL として表される)。ホスト部分はホスト名またはインターネットアドレスを含む。ポート部分はオプションである。
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. パス部分はホスト固有のオブジェクト名と、オプションのバージョン番号を含む。バージョン番号が提示される場合、"%00"(パーセント ゼロ ゼロ)文字(これは文字列終端文字(null)のエスケープされたものである)によって、ホスト固有のオブジェクト名と分離される。外部の Prospero へのリンクは下層のアクセス方法の URL として表現され、Prospero URL としては表現されない。
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. 新しいプレフィクスを使用して URL 構文に従うマッピングを定義することで、新しい名前付けスキームを導入してもよい。参加者相互の合意の下で実験的なプレフィクスが使用されてもよく、その場合、プレフィクスは文字 "x-" で始まらなければならない。スキーム名 "urn:" は、より永続性を持つ名前のためのスキーム用に予約されている。
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. Internet Assigned Numbers Authority (IANA) が新しいスキームの登録の役割を果たすことが提案されている。いかなる新しい URI スキームの提出にも、そのスキーム内で任意のオブジェクトを取得するためのアルゴリズム定義を含まなければならない。そのアルゴリズムは URI を受け取り、目的のオブジェクトへと導く URL の集合、または目的のオブジェクト自身を、明確な、あるいは決定できる形式で提供しなければならない。
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. このような新しいスキームの提案は、既存のプロトコルを使用してクライアントに新しいスキームにおけるオブジェクトの像を提供するゲートウェイを準備することで、その利便性と操作性とを実証することが推奨される。新しいスキームが位置を示すスキームではない場合、その新しい空間における名前の属性は明確に定義されるべきである。プロトコルが URL による取得を許可する場合、クライアントソフトウェアは、新しい名前付けスキームを通して間接的にアクセスするための、特別なゲートウェイ位置子を使用する設定を提供することも同様に推奨される。
This is a BNF-like description of the URI syntax. at the level at which specific schemes are not considered. これは特定スキームを考慮しないレベルにおける URI 構文の、BNF に似た記述である。
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. 縦線 "|" は選択を表し、[ ブラケット ] は任意部分を表す。空白は "space" で表され、縦線は "vline" で表されている。単独の文字は単独の文字を表す。以下の 2 文字以上のすべての単語は、この説明のどこかで記述されているエンティティである。
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. "generic" の生成物は、他の生成物と同じ URI の、より高い水準の構文解析を与える。"national" と "punctuation" は、いかなる生成物にも現れないため、URI の中に現れることはないだろう。
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)
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. これは統一資源識別子(Uniform Resource Locator)の BNF に似た記述である。縦線 "|" は選択を表し、[ ブラケット ] は任意部分を表す。空白は "space" で表され、縦線は "vline" で表されている。単独の文字は単独の文字を表す。以下の 2 文字以上のすべての単語は、この説明のどこかで説明されているエンティティである。
The current IETF URI Working Group preference is for the prefixedurl production. (Nov 1993. July 93: url). 現在の IETF URI ワーキンググループの優先は、prefixedurl の生成物である(Nov 1993. July 93: url)。
The "national" and "punctuation" characters do not appear in any productions and therefore may not appear in URLs. "national" と "punctuation" は、いかなる生成物の中にも現れないため、URL の中に現れることはないだろう。
The "afsaddress" is left in as historical note, but is not a url production. "afsaddress" は歴史的注記として残されているが、url の生成物ではない。
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, <ftp://boombox.micro.umn.edu/pub/gopher/ gopher_protocol>. See also <gopher://gopher.micro.umn.edu/00/Information About Gopher/About Gopher>
Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)", CERN, December 1991, as updated from time to time, <ftp://info.cern.ch/pub/www/doc/http-spec.txt>
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. <ftp://quake.think.com/pub/wa is/doc/protspec.txt>
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", <ftp: //quake.think.com/pub/wais/doc/doc-ids.txt>
Kantor, B., and P. Lapsley, Kantor, B., and P. Lapsley, "Network News Transfer Protocol", RFC 977, UC San Diego & UC Berkeley, February 1986. <ftp://ds.internic.net/rfc/rfc977.txt>
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 <wais://quake.think.com/wais-discussion-archives?lynch>
Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987, <ftp://ds.internic.net/rfc/rfc1034.txt>
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 <ftp://prospero.isi.edu/pub/prospero/oir.ps>
Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/Information Sciences Institute, October 1985. <ftp://ds.internic.net/rfc/rfc959.txt>
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. <ftp://uu.psi.com/wp/nir.txt>
Yeong, W., "Representing Public Archives in the Directory", Work in Progress, November 1991, now expired.
Security issues are not discussed in this memo. この文書でセキュリティ問題は議論されていない。
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