訳注:本文中で「開発中」とされている資源識別子のインターネット標準は、RFC3986(Uniform Resource Identifier (URI): Generic Syntax) だと思います。

Network Working Group
Request for Comments: 1630
Category: Informational

T. Berners-Lee
June 1994

Universal Resource Identifiers in WWW WWW における統一資源識別子(URI)

A Unifying Syntax for the Expression of
Names and Addresses of Objects on the Network
as used in the World-Wide Web

Status of this Memo この文書の位置付け

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. この文書はインターネットコミュニティのための情報を提供する。この文書はいかなる種類のインターネット標準も規定しない。この文書の配布に制限はない。

IESG Note: IESG 注記:

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 において開発中である。

Introduction 導入

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://www.w3.org/Addressing/URL/URI_Overview.html ですが、この RFC と整合性が取れているかどうかは未確認)

The Need For a Universal Syntax 汎用構文の必要性

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 document defines a way to encapsulate a name in any registered name space, and label it with the the name space, producing a member of the universal set. Such an encoded and labelled member of this set is known as a Universal Resource Identifier, or URI. この文書は任意の登録済み名前空間をカプセル化する方法を定義し、それにその名前空間のラベルを付け、汎用集合のメンバーを提供する。エンコードされラベル付けされたこの集合のメンバーは、統一資源識別子(Universal Resource Identifier)、あるいは URI として知られる。
The universal syntax allows access of objects available using existing protocols, and may be extended with technology. 汎用構文は既存のプロトコルを使用したオブジェクトへのアクセスを利用可能にし、技術によって拡張されてもよい。
The specification of the URI syntax does not imply anything about the properties of names and addresses in the various name spaces which are mapped onto the set of URI strings. The properties follow from the specifications of the protocols and the associated usage conventions for each scheme. この URI 構文の仕様は、URI 文字列の集合にマップされている様々な名前空間における名前とアドレスとの属性に関して、何も示唆しない。そのような属性は、そのプロトコルの仕様と各スキーマに関連する使用法の慣例とに従う。
For existing Internet access protocols, it is necessary in most cases to define the encoding of the access algorithm into something concise enough to be termed address. URIs which refer to objects accessed with existing protocols are known as "Uniform Resource Locators" (URLs) and are listed here as used in WWW, but to be formally defined in a separate document. 既存のインターネットアクセスプロトコルのためには、ほとんどの場合において、アクセスアルゴリズムのエンコードをアドレスと呼ぶのに十分なほど簡潔なものに定義する必要がある。既存のプロトコルでアクセスされるオブジェクトを参照する URI は、"統一資源位置指示子(Uniform Resource Locators)"(URL) として知られており、この文書では WWW において使用されているものとして記載しているが、正式には別の文書で定義されている。
There is currently a drive to define a space of more persistent names than any URLs. These "Uniform Resource Names" are the subject of an IETF working group's discussions. (See Sollins and Masinter, Functional Specifications for URNs, circulated informally.) 現在、どのような URL よりも持続的な名前の空間を定義しようという活動が存在する。その "統一資源名(Uniform Resource Names)" は、IETF ワーキンググループによる議論の対象である。(非公式に配布されている Sollins and Masinter, Functional Specifications for URNs を参照)
The URI syntax and URL forms have been in widespread use by World-Wide Web software since 1990. 1990 年以来、URI の構文と URL の形式は、ワールドワイドウェブのソフトウェアによって広く利用されている。

Design Criteria and Choices 設計の基準と選択

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: この構文は以下のような目的で設計されている:

Extensible 拡張性
New naming schemes may be added later. 新しい名前付けスキームを後から追加することができる。
Complete 完全性
It is possible to encode any naming scheme. すべての名前付けスキームがエンコード可能である。
Printable 印字可能
It is possible to express any URI using 7-bit ASCII characters so that URIs may, if necessary, be passed using pen and ink. 必要であれば URI をペンとインクででも伝えられるように、すべての URI は 7 ビット ASCII 文字を使用して表現可能である。

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 の正統な形式においてすべての空白文字をエンコードするのは、このためである。

Recommendations 推奨

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)構文は、まだ定義されていないプロトコルを使用して解決される名前のための、新しいスキームに関する枠組みを提供する。

URI syntax URI 構文

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 定義には含まれない。

Within the URI of a object, the first element is the name of the scheme, separated from the rest of the object by a colon. オブジェクトの URI の最初の要素はこのスキーム名であり、コロンによってそのオブジェクトの残りの部分と分離される。
The rest of the URI follows the colon in a format depending on the scheme. The path is interpreted in a manner dependent on the protocol being used. However, when it contains slashes, these must imply a hierarchical structure. URI の残りの部分は、そのスキームに依存する形式でコロンの後に続けられる。このパスは使われるプロトコルに依存した方法で解釈される。ただしそれがスラッシュを含む場合、それらは階層構造を含む。

Reserved characters 予約済み文字

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. いくつかの予約済み文字は、以下で定義されるような特別な用途を持つ。

The percent sign ("%", ASCII 25 hex) is used as the escape character in the encoding scheme and is never allowed for anything else. パーセント記号("%" ASCII 25(16 進))はエスケープ文字として使用され、それ以外の用途に使用されることは許されない。
The slash ("/", ASCII 2F hex) character is reserved for the delimiting of substrings whose relationship is hierarchical. This enables partial forms of the URI. Substrings consisting of single or double dots ("." or "..") are similarly reserved. スラッシュ文字("/" ASCII 2F(16進))は、階層関係にある部分文字列間の区切りとして予約されている。これにより部分形式の URI が可能となる。単一または二重のドット("." または "..")から成る部分文字列も同様に予約されている。
The significance of the slash between two segments is that the segment of the path to the left is more significant than the segment of the path to the right. ("Significance" in this case refers solely to closeness to the root of the hierarchical structure and makes no value judgement!) 二つの区分の間のスラッシュは、左側のパスが右側のパスよりも有意(significance)であることを表す。(この場合の "有意(Significance)" とは、単に階層構造のルートに近いことを表しており、その価値を表すものではない!)
Note 注意
The similarity to unix and other disk operating system filename conventions should be taken as purely coincidental, and should not be taken to indicate that URIs should be interpreted as file names. UNIX などのディスクオペレーティングシステムにおけるファイル名の習慣との類似は単なる偶然の一致と見なすべきであり、URI がファイル名として解釈されるべきであると示唆していると見なすべきではない。
The hash ("#", ASCII 23 hex) character is reserved as a delimiter to separate the URI of an object from a fragment identifier . ハッシュ文字("#" ASCII 23(16 進))は、フラグメント識別子とオブジェクトの URI とを分離するための区切りとして予約されている。
The question mark ("?", ASCII 3F hex) is used to delimit the boundary between the URI of a queryable object, and a set of words used to express a query on that object. When this form is used, the combined URI stands for the object which results from the query being applied to the original object. 疑問符("?" ASCII 3F(16 進))は、問い合わせ可能なオブジェクトと、そのオブジェクトの問い合わせを表すために使われる単語の集合との境界を区切るために使用される。この形式を使用して結合された URI は、元のオブジェクトに問い合わせが適用された結果のオブジェクトを表す。
Within the query string, the plus sign is reserved as shorthand notation for a space. Therefore, real plus signs must be encoded. This method was used to make query URIs easier to pass in systems which did not allow spaces. 問い合わせ文字列中のプラス記号は、空白文字の簡易表現として予約されている。したがって、本当のプラス記号はエンコードされなければならない。この方法は、空白を許可しないシステムにおいて問い合わせ URI の引き渡しをより簡単にするために、よく使用されていた。
The query string represents some operation applied to the object, but this specification gives no common syntax or semantics for it. In practice the syntax and sematics may depend on the scheme and may even on the base URI. 問い合わせ文字列はそのオブジェクトに適用される何らかの操作を表すが、この仕様はそのための共通構文やセマンティクスを規定しない。実際のところその構文とセマンティクスとはスキームに依存してよく、ベースの URI にさえも依存してよい。
The astersik ("*", ASCII 2A hex) and exclamation mark ("!" , ASCII 21 hex) are reserved for use as having special signifiance within specific schemes. アスタリスク("*" ASCII 2A(16 進))と感嘆符("!" ASCII 21(16進))は、特定のスキームにおいて特別な意味を持つものとして利用するために予約されている。

Unsafe characters 安全でない文字

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 ビット文字を、正統な形式においてエンコードせずに使用するべきではない。これは円滑な相互交換のための推奨事項であり、以下で示すように、エンコードされた文字セットは拡張されたり縮小されたりしてもよい。

Encoding reserved characters 予約済み文字のエンコード

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 の各アドレスのマッピングに使用される。

Where the local naming scheme uses ASCII characters which are not allowed in the URI, these may be represented in the URL by a percent sign "%" immediately followed by two hexadecimal digits (0-9, A-F) giving the ISO Latin 1 code for that character. Character codes other than those allowed by the syntax shall not be used unencoded in a URI. ローカルの名前付けスキームが URI で許可されていない ASCII 文字を使用する場合、パーセント記号 "%" の直後に、その文字の ISO Latin 1 コードを表す 2 桁の 16 進数値(0-9, A-F)を続けることによって表現することが許される。URI において、その構文で許可されていない文字コードをエンコードせずに使用するべきではない。
The same encoding method may be used for encoding characters whose use, although technically allowed in a URI, would be unwise due to problems of corruption by imperfect gateways or misrepresentation due to the use of variant character sets, or which would simply be awkward in a given environment. Because a % sign always indicates an encoded character, a URI may be made "safer" simply by encoding any characters considered unsafe, while leaving already encoded characters still encoded. Similarly, in cases where a larger set of characters is acceptable, % signs can be selectively and reversibly expanded. 技術的には URI での使用が許可されているが、不完全なゲートウェイによる汚染や様々な文字セットの使用による誤表現のために分別の無い文字、あるいは単に与えられた環境で扱いにくい文字をエンコードするために、同じエンコード方法を使用することができる。% 記号は常にエンコードされた文字を表すため、単純に既にエンコードされている文字をそのままにしながら、安全でないと考えられる文字をすべてエンコードすることで、URI を "より安全(safer)" なものにすることができる。同様に、より大きな文字セットが受け入れられる場合、% 記号は選択的かつ可逆的に拡張することができる。
Before two URIs can be compared, it is therefore necessary to bring them to the same encoding level. したがって 2 つの URI を比較する前に、それらを同じエンコードレベルにする必要がある。
However, the reserved characters mentioned above have a quite different significance when encoded, and so may NEVER be encoded and unencoded in this way. ただし、前述の予約された文字はエンコードされると全く異なる意味を持つため、このような方法でエンコードされたり、エンコードされなかったりしてはならない。
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.) パーセント記号は常にエンコードされていることを表すため、パーセント記号そのものを表す場合は常にエンコードされなければならない。パーセント記号で始まるが 2 桁の 16 進文字がその後に続かないシーケンスは、将来の拡張のために予約されている。(例 3 参照)
Example 1 例 1
The URIs 以下の URI、
are identical, as the %2D encodes a hyphen character. は、%2D がハイフンにエンコードされるため同一である。
Example 2 例 2
The URIs 以下の URI、
are NOT identical, as in the second case the encoded slash does not have hierarchical significance. は、後者のエンコードされたスラッシュが階層の意味を持たないため、同一ではない。
Example 3 例 3
The URIs 以下の URI、
are illegal, as all % characters imply encodings, and there is no decoding defined for "%*" or "%as" in this recommendation. は、すべての % 文字がエンコードを必要とされ、この推奨では "%*" や "%as" のために定義されたエンコード方法が存在しないため、違反である。

Partial (relative) form 部分(相対)形式

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 の使用が推奨される。


In the context of URI 次の URI コンテキストにおいて、


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 コンテキストにおいて、


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. フラグメント識別子には、それ自体でオブジェクトとして展開できる何かを参照しているという意味はない。例えばフラグメント識別子は、オブジェクト内の分割できない位置を参照してもよい。

Specific Schemes 個別のスキーム

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 として言及される。対象となるスキームは以下の通り:

Hypertext Transfer Protocol (examples) ハイパーテキストトランスファープロトコル(例)
(Hypertext Transfer Protocol)
File Transfer protocol ファイル転送プロトコル
(File Transfer protocol)
Gopher protocol ゴーファープロトコル
(Gopher protocol)
Electronic mail address 電子メールアドレス
Usenet news Usenetニュース
(Usenet news)
telnet, rlogin, tn3270
Reference to interactive sessions 対話式セッションへの参照
Wide Area Information Servers ワイドエリアインフォメーションサーバー
(Wide Area Information Servers)
Local file access ローカルファイルアクセス

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: 以下のスキームはウェブと電子メールとの統合に不可欠なものとして提案されているが、(著者の知る限りでは)今のところ実装されていない:

Message identifiers for electronic mail 電子メールのためのメッセージ識別子
Content identifiers for MIME body part MIME ボディ部のための内容識別子

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 による転送のためにはエスケープされなければならない。


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 は通常以下のようになる:


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 はすべて極めて一般的なものである。





A URL for a server on a different port to 80 looks like 80 以外のポートのサーバーへの URL は次のようになる:


A reference to a particular part of a document may, including the fragment identifier, look like 文書の特定部分への参照(フラグメント識別子を含む)は以下のようになるだろう。


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 テキストデータベースでの検索は以下のようになるだろう:


and on another database また別のデータベースでは以下のようになるだろう:


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 サーバーポートを表す。

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. この構文により、匿名 FTP の習慣を使用しないシステムのために、ユーザー名と、さらにパスワードも含めることができる。しかしながら、ユーザー名またはパスワードが提供されない場合、デフォルトは匿名 FTP の習慣、すなわち、ユーザー名に "anonymous"、パスワードにそのユーザーのインターネット形式のメールアドレスを使用することになる。
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. 可能なら、このメールアドレスはそのユーザーの利用可能なメールアドレスに相当するべきであり、そのクライアントの IP アドレスへと解決できる DNS ホスト名を与えられることが望ましい。一般に匿名パスワードの扱いはサーバーごとに異なることに注意してほしい。
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. FTP プロトコルは、実際にファイルにアクセスする RETR(取得:retrieve) や NLIST(など)といったサービスコマンドに先立って、一連の CWD コマンド(作業ディレクトリの変更:change working directory)と TYPE コマンドとを許可している。
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. すべての CWD コマンドの引数はスラッシュで区切られた URL の連続する断片であり、最後の断片は RETR コマンドのためのファイル名引数や、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. 一部のファイルシステム(特に Unix)の場合、URL の階層構造を表す "/" がファイル名の階層構造を表す区切り文字と同一であるため、ファイル名が URL パスと同じように見えるだろう。しかしこれは、URL が Unix のファイル名であるという意味ではない。
Note: Retrieving subsequent URLs from the same host 注意: 同じホストから後続の URL を取得する
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. FTP プロトコルに共通する階層モデルは存在しない。したがって、ディレクトリ変更コマンドが与えられた場合、二回目の取得で別のディレクトリへ移動するための手順を推測することは一般に不可能である。唯一の信頼できるアルゴリズムは、いったん切断し、再度コントロール接続を確立することである。
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. 一般的な FTP の場合、ファイルの内容の種類はその名前から推測するしかない。通常はファイル名の接尾辞から推測するが、標準化はされていない。別の方法は、それ用に URL の外部の情報を送信することである。適当な FTP 送信型(例えばバイナリの "I"、またはテキストの "A")は、そのデータの内容の種類から推測されるべきである。公のアーカイブの接尾辞のための習慣が確立されることが推奨されるが、それはこの標準の範囲外である。
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. FTP URL では、オブジェクトを取得する FTP データ通信の種類をオプションで指定することができる。大部分の方法は、FTP において TYPE コマンドによって規定されている通りの、ドキュメント取得のための FTP "データ型(Data Types)"、ASCII と IMAGE とに相当する。もうひとつの方法はディレクトリアクセスを表す。
The data type is specified by a suffix to the URL. Possible suffixes are: データ型は URL の接尾辞によって指定される。可能な接尾辞は以下の通り:
;type = <type-code>
Use FTP type as given to perform data transfer. データを転送するために、与えられた FTP の型を使用する。
Use FTP directory list commands to read directory ディレクトリを読み込むために、FTP のディレクトリリスト命令を使用する。
The type code is in the format defined in RFC 959 except that THE SPACE IS OMITTED FROM THE URL. URL から空白が取り除かれることを除き、型コード(type code)は RFC 959 で定義されている通りの形式である。
Transfer Mode 通信モード
Stream Mode is always used. 常にストリームモードが使用される。

Gopher ゴーファー(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. ゴーファーの 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 に変換する必要があることに注意してほしい(これは例えば、ゲートウェイを通過させるメールアドレスを構築するときに使用される)。

News ニュース(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). ニュース位置指定子は、ニュースグループ名、または 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 ニュース記事の伝達のための他のプロトコルかを使用して、または受信済みニュース記事の本文への参照によって、逆参照されてもよい。

Note 1: 注意 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. URL の中でも "ニュース(news)" の URL は、位置に依存しないという点で変則的である。NNTP のアーキテクチャは記事の期限切れに依存しており、したがって小さい番号の記事はいつでも利用できるため、URN の候補には適さない。news: の URL が引用される場合、その読者は彼/彼女のローカルのニュースホストからその記事またはグループを取得するであろうという仮定が存在する。ニュースホストはニュース URL の一部ではない。
Note 2: 注意 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. 未解決の問題は、保管場所やファイル名を取得するアルゴリズムが存在しないために、期限切れの記事の回収を可能にするにはメッセージ識別子では不充分ということである。これは、ディレクトリがニュースグループによるアーカイブサイトを用意していれば、その記事の URL に日付とニュースグループとを追加することで可能となるだろう。
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. NNTP ワーキンググループにより提案されている研究課題。更なる拡張が、アドレス可能なオブジェクトとしてサブジェクトのスレッドの名前付けを許可してもよい。

Telnet, rlogin, tn3270

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 例えば以下のようになるだろう


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 を追加する必要がある。そのための構文は定義されていない。

Schemes for Further Study さらなる研究を要するスキーム

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. URL に x500 の名前をマップする方法はここでは定義されない。"distinguished names" または "user friendly names"(ufn)、またはその両方の、何れを許可するかの判断が必要である。採用される x500 表現が、何らかの句読法の変換(例えば ufn の各部の間のスラッシュの使用など)を必要とする場合、それらが定義されなければならない。これは研究課題である。
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. このプレフィクスは、定義の途上にあるスキーム "whois++" を使用したアクセスを記述する。ホスト名部分は他の IP ベースのスキームの場合と同じである。パス部分はオブジェクト全体の whois ハンドル、または有効な whois 問い合わせ文字列を採ることができる。これは更なる研究を要する課題である。
This is a subject for study. これは研究課題である。
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. これはニュース記事を参照するもうひとつの形式であり、具体的には NNTP サーバー、特にメッセージ識別子による取得を許可しない不完全なサーバー実装で使用される。その他のすべての場合にはスキーム "news" が使用されるべきである。
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. ニュースサーバー名とニュースグループ名、およびその特定サーバー上のニュースグループ内の記事の索引番号が与えられる。NNTP プロトコルが使用されなければならない。
Note 1. 注意 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. 一般的な NNTP サーバーはローカルクライアントからのアクセスのみを許可するため、この形式の URL にグローバルなアクセス性はない。グループ内の記事番号はサーバーによって異なることに注意してほしい。
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. この形式の URL は、そのローカル領域の外で引用されるべきではない。これは一台のサーバーよりも広く配布されるニュース記事内で使用されるべきではない。これは多くの場合グローバルに利用可能なリソースのためのローカル識別子であり、そのため、ローカルサーバー上の不完全な NNTP 実装がその採用を強制する場合を除いては推奨されない。


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 としては表現されない。

Registration of naming schemes 名前付けスキームの登録

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 による取得を許可する場合、クライアントソフトウェアは、新しい名前付けスキームを通して間接的にアクセスするための、特別なゲートウェイ位置子を使用する設定を提供することも同様に推奨される。

BNF of Generic URI Syntax 汎用 URI 構文の BNF

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            < | >


      (end of URI BNF)

BNF for specific URL schemes 個々の 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. これは統一資源識別子(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                  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 ]


      (end of URL BNF)

References 参考文献

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 Considerations セキュリティ考察

Security issues are not discussed in this memo. この文書でセキュリティ問題は議論されていない。

Author's Address 著者の連絡先

   Tim Berners-Lee
   World-Wide Web project
   1211 Geneva 23,

   Phone: +41 (22)767 3755
   Fax:   +41 (22)767 7155
   EMail: timbl@info.cern.ch