RFC1736 日本語訳

Network Working Group                                           J. Kunze
Request for Comments: 1736                             IS&T, UC Berkeley
Category: Informational                                    February 1995

コメントを求めるワーキンググループJ.クンツェの要求をネットワークでつないでください: 1736はそうであり、T、UCはバークレーカテゴリです: 情報の1995年2月

       Functional Recommendations for Internet Resource Locators

インターネット資料ロケータのための機能的な推薦

Status of this Memo

この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.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

1. Introduction

1. 序論

   This document specifies a minimum set of requirements for Internet
   resource locators, which convey location and access information for
   resources.  Typical examples of resources include network accessible
   documents, WAIS databases, FTP servers, and Telnet destinations.

このドキュメントはインターネット資料ロケータのための最小のセットの要件を指定します。(ロケータはリソースのための位置とアクセス情報を伝えます)。 リソースの典型的な例はネットワークのアクセス可能なドキュメント、WAISデータベース、FTPサーバ、およびTelnetの目的地を含んでいます。

   Locators may apply to resources that are not always or not ever
   network accessible.  Examples of the latter include human beings and
   physical objects that have no electronic instantiation (that is,
   objects without an existence completely defined by digital objects
   such as disk files).

ロケータはいつもそうであるというわけではないリソースかかつてないときにネットワークにアクセスしやすい状態で適用されるかもしれません。 後者に関する例はどんな電子具体化(すなわち、ディスクファイルなどのデジタルオブジェクトによって完全に定義された存在のないオブジェクト)も持っていない人間と対象物を含んでいます。

   A resource locator is a kind of resource identifier.  Other kinds of
   resource identifiers allow names and descriptions to be associated
   with resources.  A resource name is intended to provide a stable
   handle to refer to a resource long after the resource itself has
   moved or perhaps gone out of existence.  A resource description
   comprises a body of meta-information to assist resource search and
   selection.

リソースロケータは一種のリソース識別子です。 他の種類に関するリソース識別子は、名前と記述がリソースに関連しているのを許容します。 リソース名がリソース自体が移行するか、または恐らく存在から行ったずっと後にリソースを示すために安定したハンドルを提供することを意図します。 リソース記述は、リソース検索と選択を促進するためにメタ情報のボディーを包括します。

   In this document, an Internet resource locator is a locator defined
   by an Internet resource location standard.  A resource location
   standard in conjunction with resource description and resource naming
   standards specifies a comprehensive infrastructure for network based
   information dissemination.  Mechanisms for mapping between locators,
   names, and descriptive identifiers are beyond the scope of this
   document.

本書では、インターネット資料ロケータはインターネット資料位置の規格によって定義されたロケータです。 リソース記述とリソース命名規格に関連したリソース位置の規格はネットワークのベースの情報普及に総合的なインフラを指定します。 ロケータと、名前と、描写的である識別子の間のマッピングのためのメカニズムはこのドキュメントの範囲を超えています。

2. Overview of Problem

2. 問題の概要

   Network-based information resource providers require a method of
   describing the location of and access to their resources.
   Information systems users require a method whereby client software
   can interpret resource access and location descriptions on their

プロバイダーが位置について説明するメソッドを必要とするネットワークベースの情報リソースとそれらのリソースへのアクセス。 情報システムユーザがクライアントソフトウェアがリソースアクセスを解釈できるメソッドと位置の記述を必要とする、それら

Kunze                                                           [Page 1]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[1ページ]RFC1736推薦

   behalf in a relatively transparent way.  Without such a method,
   transparent and widely distributed, open information access on the
   Internet would be difficult if not impossible.

比較的見え透いた方法で利益。 そのようなメソッドがなければ、透明で広く分配されていて、インターネットにおける公開情報アクセスは、難しいか、または不可能でしょう。

2.1 Defining the General Resource Locator

2.1 一般リソースロケータを定義すること。

   The requirements listed in this document impose restrictions on the
   general resource locator.  To better understand what the Internet
   resource locator is, the following general locator definition
   provides some contrast.

本書ではリストアップされた要件は一般的なリソースロケータに制限を課します。 インターネット資料ロケータが何であるかをより理解するために、以下の一般的なロケータ定義は何らかのコントラストを提供します。

        Definition:  A general resource locator is an object
                     that describes the location of a resource.

定義: 一般的なリソースロケータはリソースの位置について説明するオブジェクトです。

   This definition deliberately allows many degrees of freedom in order
   to contain the furthest reaches of the wide-ranging debate on
   resource location standards.  Vast as it is, this problem space is a
   useful backdrop for discussion of the requirements (later) that
   generate a smaller, more manageable problem space.  A resource
   location standard shrinks the space again by applying additional
   requirements.

この定義は、リソース位置の規格に関する広範囲の討論の最も遠い範囲を含むように故意に多くの度合いの自由を許容します。 それは広大ですが、この問題スペースは、より小さくて、より処理しやすい問題がスペースであると生成する要件(後で)の議論のための役に立つ背景です。 リソース位置の規格は、再び追加要件を適用することによって、スペースを縮小します。

   Consider the definition in four parts: (1) A general resource locator
   is an object (2) that describes (3) the location of (4) a resource.

4つの部品との定義を考えてください: (1) 一般的なリソースロケータは(3) (4) リソースの位置について説明するオブジェクト(2)です。

2.1.1.  A general resource locator is an object...

2.1.1. 一般的なリソースロケータはオブジェクトです…

   The object could be a complex data structure.  It could be a
   contiguous sequence of bytes.  It could be a pair of latitude-
   longitude coordinates, or a three-color road map printed on paper.
   It could be a sequence of characters that are capable of being
   printed on paper.

オブジェクトは複雑なデータ構造であるかもしれません。 それはバイトの隣接の系列であるかもしれません。 それは、1組の緯度経度座標、または紙上で印刷された三色のロードマップであるかもしれません。 それは紙上で印刷できるキャラクタの系列であるかもしれません。

2.1.2.  ...that describes

2.1.2. ...それは説明します。

   In the fully general case, there are many ways that a resource
   locator could describe the location.  It could employ a graphical or
   natural language description.  It could be heavily encoded or
   compressed.  It could be lightly encoded and readily understandable
   by human beings.  The description could be a multi-level hierarchy
   with common semantics at each level.  It could be a multi-level
   hierarchy with common semantics at only the first two levels, where
   semantics below the second level depend on the value given at the
   first level.  These are just a few possibilities.

完全に一般的な場合には、そのaリソースロケータが位置について説明するかもしれない多くの方法があります。 それはグラフィカルであるか自然言語記述を使うかもしれません。 それを大いにコード化したか、または圧縮できました。 それは、軽くコード化されていて人間を容易に理解できさせるかもしれません。 記述は各レベルにおける一般的な意味論があるマルチレベル階層構造であるかもしれません。 それは最初の2つのレベルだけで一般的な意味論でのマルチレベル階層構造であるかもしれません。そこでは、第2レベルの下における意味論が値に最初のレベルで与えられた依存します。 これらはわずかいくつかの可能性です。

Kunze                                                           [Page 2]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[2ページ]RFC1736推薦

2.1.3.  ...the location of

2.1.3. ...位置

   A resource locator describes a location but never guarantees that
   access may be established.  While access is often desired when
   clients follow location instructions given in a conformant resource
   locator, the resource need not exist any longer or need not exist
   yet.  Indeed it may never exist, even though the locator continues to
   describe a location where a resource might exist (e.g., it might be
   used as a placeholder with resource availability contingent upon an
   event such as a payment).

リソースロケータは、位置について説明しますが、アクセスが確立されるかもしれないのを決して保証しません。 クライアントがconformantリソースロケータで与えられた位置の指示に従うとき、アクセスがしばしば望まれている間、リソースは、もう存在する必要はありませんし、またまだ存在する必要はありません。 本当に、決して存在しないかもしれません、ロケータは、リソースが存在するかもしれない(例えばそれは支払いなどのイベント次第でプレースホルダとしてリソースの有用性で使用されるかもしれません)位置について説明し続けていますが。

   Furthermore, the nature of certain potential resources, especially
   animate beings or physical objects with no electronic instantiation,
   makes network access meaningless in some cases; such resources have
   locators that would imply non-networked access, but again, access is
   not guaranteed.

その上、ある潜在的リソースの本質(電子具体化のない特に生命がある存在か対象物)で、いくつかの場合、ネットワークアクセスは無意味になります。 そのようなリソースには非ネットワークでつながれたアクセスを含意するロケータがありますが、一方、アクセスは保証されません。

2.1.4.  ...a resource.

2.1.4. ...リソース。

   A resource can be many things.  Besides the non-networked or non-
   electronic resources just mentioned, familiar examples are an
   electronic document, an image, a server (e.g., FTP, Gopher, Telnet,
   HTTP), or a collection of items (e.g., Gopher menu, FTP directory,
   HTML page).  Other examples accompany multi-function protocols such
   as Z39.50, which can perform single round trip network access,
   session-oriented search refinement, and index browsing.

リソースは多くのものであるかもしれません。 ただ言及された非ネットワークでつながれたか非電子のリソース以外に、身近な例は、電子化文書、イメージ、サーバ(例えば、FTP、ゴーファー、Telnet、HTTP)、または項目の収集(例えば、ゴーファーメニュー、FTPディレクトリ、HTML形式のページ)です。 他の例はZ39.50などのマルチファンクションプロトコルに伴います。(Z39.50はただ一つの周遊旅行ネットワークアクセス、セッション指向の絞り込み検索、およびインデックスブラウジングを実行できます)。

2.2 Producers and Interpreters of Resource Locators

2.2 リソースロケータのプロデューサーとインタプリタ

   Central to the discussion of locator requirements is the issue of
   parsability.  This is the ability of an agent to recognize or
   understand a locator in whole or in part.  Discussion may be assisted
   by clearly distinguishing the two main actions associated with
   locators.

ロケータ要件の議論に主要であるのは、parsabilityの問題です。 これはエージェントが全体か一部ロケータを認識するか、または理解する能力です。 議論は、明確にロケータに関連している2つの主な動作を区別することによって、促進されるかもしれません。

   Resource locators are both produced and interpreted.  Producers are
   bound by the resource location standards that are in turn bound by
   requirements listed in this document.  Interpreters of locators are
   not bound by the requirements; they are beneficiaries of them.

リソースロケータは、生産されて、解釈されます。 プロデューサーは本書ではリストアップされた要件によって順番に縛られるリソース位置の規格によって縛られます。 ロケータのインタプリタは要件によって縛られません。 彼らはそれらの受益者です。

2.2.1 Resource Locator Interpreters

2.2.1 リソースLocator Interpreters

   A resource locator is interpreted by interpreting agents, which in
   this document are simply called interpreters.  Interpreters may be
   either human beings or software.  Along the way to establishing
   access based on information in a locator, one or more interpreters
   may be employed.  Some examples of multiple interpreters processing a
   single locator illustrate the concept that a resource locator may be

リソースロケータは、エージェントを解釈することによって、解釈されます。(そのエージェントは、本書では単にインタプリタと呼ばれます)。 Interpretersは、人間かソフトウェアのどちらかであるかもしれません。 ロケータで情報に基づくアクセスを確立することへの道に沿って、1人以上のインタプリタが雇われるかもしれません。 単一のロケータを処理する複数のインタプリタのいくつかの例がリソースロケータがそうであるという概念を例証します。

Kunze                                                           [Page 3]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[3ページ]RFC1736推薦

   understandable only in part by each of several interpreters, but
   understandable in its entirety by a combination of interpreters.

単に一部数人のインタプリタの各人を理解できさせますが、インタプリタの組み合わせは全体として理解できます。

   In the first example, a software interpreter recognizes enough of a
   locator to understand to which external agent it needs to forward it.
   Here, the external agent might be a user and the locator a library
   call number; the software forwards the locator simply by displaying
   it. The agent might be a network software layer specializing in a
   particular communications protocol; once the service is recognized,
   the locator is forwarded to it along with an access request.

最初の例では、ソフトウェアインタプリタはロケータが、それが、どの外部のエージェントにそれを進める必要であるかを理解する十分を認識します。 ここで、外部のエージェントはユーザであるかもしれなく、ロケータはライブラリ図書整理番号です。 ソフトウェアは、単にそれを表示することによって、ロケータを進めます。 エージェントは特定の通信規約を専門に扱うネットワークソフトウェア層であるかもしれません。 いったんサービスを認識すると、アクセス要求と共にロケータをそれに送ります。

   In another example, a human interpreter might also recognize enough
   of a locator to understand where to forward it.  Here, the person
   might be a user who recognizes a library call number as such but who
   does not understand the location information encoded in it; the
   person forwards it to a library employee (an external agent) who
   knows how to establish access to the library resource.

また、別の例では、人間のインタプリタはロケータがそれをどこに送るかを理解する十分を認識するかもしれません。 ここで、人はそういうもののライブラリ図書整理番号を認識しますが、それでコード化された位置情報を理解していないユーザであるかもしれません。 人はライブラリリソースへのアクセスを確立する方法を知っているライブラリの従業員(外部のエージェント)にそれを送ります。

   A prerequisite to interpreting a locator is understanding when an
   object in question actually is a locator, or contains one or more
   locators.  Some constrained environments make this question easy to
   answer, for example, within HTML anchors or Gopher menu items.  Less
   constrained environments, such as within running text, make it more
   difficult to answer without well-defined assumptions.  A resource
   location standard needs to make any such assumptions explicit.

ロケータを解釈することへの前提条件は、いつ問題のオブジェクトが実際にロケータであるかを理解しているか、または1つ以上のロケータを含んでいます。 いくつかの強制的な環境が例えば、HTMLアンカーの中で答えやすいこの質問かゴーファーをメニュー項目にします。広告のための活字原稿などのそれほど強制的でない環境で、明確な仮定なしで答えるのは、より難しくなります。 リソース位置の規格は、どんなそのような仮定も明白にする必要があります。

2.2.2 Resource Locator Producers

2.2.2 リソースロケータプロデューサー

   Resource locators are produced in many ways, often by an agent that
   also interprets them.  The provider of a resource may produce a
   locator for it, leaving the locator in places where it is intended to
   be discovered, such as an HTML page, a Gopher menu, or an
   announcement to an e-mail list.

リソースロケータは様々な意味でしばしばまた、それらを解釈するエージェントによって生産されます。 リソースのプロバイダーはそれのためにロケータを生産するかもしれません、発見されるのが意図している場所にロケータを残して、1HTML形式のページ、ゴーファーメニュー、またはメーリングリストへの発表などのように。

   Non-providers of resources can be major producers of locators; for
   example, WWW client software produces locators by translating foreign
   resource locators (e.g., Gopher menu items) to its own format.  Some
   locator databases (e.g., Archie) have been maintained by automated
   processes that produce locators for hundreds of thousands of FTP
   resources that they "discover" on the Internet.

リソースの非プロバイダーはロケータの一流のプロデューサーであるかもしれません。 例えば、WWWクライアントソフトウェアは、外国リソースロケータ(例えば、ゴーファーメニュー項目)をそれ自身の形式に翻訳することによって、ロケータを生産します。 いくつかのロケータデータベース(例えば、アーチー)がそれらがインターネットで「発見する」何十万ものFTPリソースのロケータを生産する自動化されたプロセスによって維持されました。

   Users are major producers of resource locators.  A user constructing
   one to share with others is responsible for conformance with locator
   standards.  Sometimes a user composes a resource locator based on an
   educated guess and submits it to client software with the intent of
   establishing access.  Such a user is a producer in a sense, but if
   the locator is purely for personal consumption the user is not bound
   by the requirements.  In fact, some client software may offer as a

ユーザはリソースロケータの一流のプロデューサーです。 他のものと共有する1つを組み立てているユーザはロケータ規格で順応に責任があります。 ユーザは、時々、経験に基づいた推測に基づくリソースロケータを構成して、アクセサリーを設立する意図をもってクライアントソフトウェアにそれを提出します。 そのようなユーザはある意味でプロデューサーですが、ロケータが純粋に個人消費のためのものであるなら、ユーザは要件によって縛られません。 事実上ソフトウェアがaとして提供するかもしれないクライアント

Kunze                                                           [Page 4]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[4ページ]RFC1736推薦

   service to translate abbreviated, non-conformant locators entered by
   users into successful access instructions or into conformant locators
   (e.g., by adding a domain name to an unqualified hostname)

簡略化されて、非conformantのロケータを翻訳するサービスはユーザからうまくいっているアクセス指示かconformantロケータの中に入りました。(例えば、資格のないホスト名にドメイン名を追加するのによる)

2.3 Uniqueness of Resource Locators

2.3 リソースロケータのユニークさ

   The topic of a "uniqueness" requirement for resource locators has
   been discussed a great deal.  This document considers the following
   aspects of uniqueness, but deliberately rejects them as requirements.
   It is incumbent upon a resource location standard that takes on this
   topic to be clear about which aspects it addresses.

リソースロケータのための「ユニークさ」要件の話題について大いに議論しました。 このドキュメントは、ユニークさの以下の局面を考えますが、故意に要件としてそれらを拒絶します。 この話題を帯びるリソース位置の規格では、それがどの局面を扱うかに関して明確であるのは現職です。

2.3.1. Uniqueness and Multiple Copies of a Resource

2.3.1. リソースのユニークさと複本

   A uniqueness requirement might dictate that no identical copies of a
   resource may exist.  This document makes no such requirement.

ユニークさの要件は、リソースの同一の複製物が全く存在しないかもしれないと決めるかもしれません。 このドキュメントはどんなそのような要件も作りません。

2.3.2. Uniqueness and Deterministic Access

2.3.2. ユニークさと決定論的なアクセス

   A uniqueness requirement might dictate that the same resource
   accessed in one attempt will also be the result of any other
   successful attempt.  This document makes no such requirement, nor
   does it define "sameness".  It is inappropriate for a resource
   location standard to define "sameness" among resources.

ユニークさの要件は、また、1つの試みでアクセスした同じリソースがいかなる他のうまくいっている試みの結果にもなると決めるかもしれません。 このドキュメントはどんなそのような要件も作りません、そして、それは「同一性」を定義しません。 リソース位置の規格がリソースの中で「同一性」を定義するのは、不適当です。

2.3.3. Uniqueness and Multiple Locators

2.3.3. ユニークさと複数のロケータ

   A uniqueness requirement might dictate that a resource have no more
   than one locator unless all such locators be the same.  This document
   makes no such requirement, nor does it define "sameness" among
   locators (which a standard might do using, for example,
   canonicalization rules).

ユニークさの要件は、そのようなすべてのロケータが同じであるというわけではないならリソースには1つ未満のロケータがあると決めるかもしれません。 このドキュメントはどんなそのような要件も作りません、そして、それはロケータ(規格が例えばcanonicalization規則を使用することでするかもしれない)の中で「同一性」を定義しません。

2.3.4. Uniqueness, Ambiguity, and Multiple Objects per Access

2.3.4. 1アクセスあたりのユニークさ、あいまいさ、および複数のオブジェクト

   A uniqueness requirement might dictate that a resource locator
   identify exactly one object as opposed to several objects.  This
   document makes no general definition of what constitutes one object,
   several objects, or one object consisting of several objects.

ユニークさの要件は、リソースロケータが数個のオブジェクトと対照的にちょうど1個のオブジェクトを特定すると決めるかもしれません。 このドキュメントは数個のオブジェクトから成る1個のオブジェクト、数個のオブジェクト、または1個のオブジェクトを構成することに関するどんな一般的な定義もしません。

3. Resource Access and Availability

3. リソースアクセスと有用性

   A locator never guarantees access, but establishing access is by far
   the most important intended application of a resource locator.  While
   it is considered ungracious to advertize a locator for a resource
   that will never be accessible (whether a "networkable" resource or
   not), it is normal for resource access to fail at a rate that
   increases with the age of the locator used.

ロケータはアクセスを決して保証しませんが、アクセスを確立するのは、リソースロケータの断然最も重要な意図しているアプリケーションです。 それはアクセス可能に決してならないリソースのためにロケータをadvertizeするように無作法であると考えられますが("「ネットワーク-可能」"リソースであるか否かに関係なく)、リソースアクセスがロケータの時代が費やされている状態で増加するレートで失敗するのは、通常です。

Kunze                                                           [Page 5]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[5ページ]RFC1736推薦

   Resource access can fail for many reasons.  Providers fundamentally
   affect accessibility by moving, replacing, or deleting resources over
   time.  The frequency of such changes depends on the nature of the
   resource and provider service practices, among other things.  A
   locator that conforms to a location standard but fails for one of
   these reasons is called "invalid" for the purposes of this document;
   the term invalid locator does not apply to malformed or non-
   conformant locators.  Resource naming standards address the problem
   of invalid locators.

リソースアクセスは種々の理由で失敗できます。 時間がたつにつれてリソースを動くか、置き換えるか、または削除することによって、プロバイダーは基本的にアクセシビリティに影響します。 そのような変化の頻度は特にリソースとプロバイダーサービス練習の本質に依存します。 位置の規格に従いますが、個人的にはこれらの理由をしそこなうロケータはこのドキュメントの目的のために「無効である」と呼ばれます。 用語の無効のロケータは奇形の、または、非conformantのロケータに適用されません。 リソース命名規格は無効のロケータのその問題を訴えます。

   Ordinary provider support policies may cause resources to be
   inaccessible during predictable time periods (e.g., certain hours of
   the day, or days of the year), or during periods of heavy system
   loading.  Rights clearance restrictions impossible to express in a
   locator also affect accessibility for certain user populations.
   Heavy network load can also prevent access.  In such situations, this
   document calls a resource "unavailable".  A locator can both be valid
   and identify a resource that is unavailable.  Resource description
   standards address, among other things, some aspects of resource
   availability.

普通のプロバイダーサポート方針は、予測できる期間(例えば、1日のある時間、または1年の何日も)、または重いシステムローディングの期間、リソースが近づきがたいことを引き起こすかもしれません。 また、ロケータで言い表すのが不可能である権利クリアランス制限はあるユーザ人口のためのアクセシビリティに影響します。 また、重いネットワーク負荷はアクセサリーを防ぐことができます。 そのような状況で、このドキュメントは、リソースが「入手できません」と言います。 ロケータは、ともに有効であり、入手できないリソースを特定できます。 リソース記述規格は特にリソースの有用性のいくつかの局面を扱います。

   In general, the probability with which a given resource locator leads
   to successful access decreases over time, and depends on conditions
   such as the nature of the resource, support policies of the provider,
   and loading of the network.

一般に、与えられたリソースロケータがうまくいっているアクセスに通じる確率は、時間がたつにつれて減少して、リソースの本質などの状態、プロバイダーのサポート方針、およびネットワークのローディングに依存します。

4. Requirements List for Internet Resource Locators

4. 要件はインターネット資料ロケータのためにリストアップされています。

   This list of requirements is applied to the set of general locators
   defined in section 2.1.  The resulting subset, called Internet
   locators in this document, is suitable for further refinement by an
   Internet resource location standard.  Some requirements concern
   locator encoding while others concern locator function.

要件のこのリストはセクション2.1で定義された一般的なロケータのセットに適用されます。 本書ではインターネットロケータと呼ばれる結果として起こる部分集合はインターネット資料位置の規格でさらなる気品に適しています。 他のものはロケータ機能に関係がある間、いくつかの要件がロケータコード化に関係があります。

   One requirement from the original draft list was dropped after
   extensive discussion revealed it to be impractical to meet.  It
   stated that with a high degree of reliability, software can recognize
   Internet locators in certain relatively unstructured environments,
   such as within running ASCII text.

大規模な議論が、それが会うために非実用的であることを明らかにした後にオリジナルの草稿リストからの1つの要件が下げられました。 それは、高度合いの信頼性で、ソフトウェアが、ある比較的不統一な環境でインターネットロケータを認識できると述べました、実行しているASCIIテキストなどのように。

4.1 Locators are transient.

4.1のロケータが一時的です。

   The probability with which a given Internet resource locator leads to
   successful access decreases over time.  More stable resource
   identifier schemes are addressed in resource naming standards and are
   outside the scope of a resource location standard.

与えられたインターネット資料ロケータがうまくいっているアクセスに通じる確率は時間がたつにつれて、減少します。 より安定したリソース識別子体系は、リソース命名規格で扱われて、リソース位置の規格の範囲の外にあります。

Kunze                                                           [Page 6]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[6ページ]RFC1736推薦

4.2 Locators have global scope.

4.2のロケータには、グローバルな範囲があります。

   The name space of resource locators includes the entire world.  The
   probability of successful access using an Internet locator depends in
   no way, modulo resource availability, on the geographical or Internet
   location of the client.

リソースロケータの名前スペースは全世界を含んでいます。 うまくいっているアクセスがインターネットロケータを使用するという確率を決して依存しません、法リソースの有用性、クライアントの地理的であるかインターネット位置で。

4.3 Locators are parsable.

4.3のロケータが「パー-可能」です。

   Internet locators can be broken down into complete constituent parts
   sufficient for interpreters (software or human) to attempt access if
   desired.  While these requirements do not bind interpreters, three
   points bear emphasizing:

望まれているなら、インターネットロケータはインタプリタ(ソフトウェアか人間)がアクセスを試みることができるくらいの完全な構成している部分へ砕けている場合があります。 これらの要件はインタプリタを縛りませんが、3ポイントは、強調するのに堪えます:

4.3.1  A given kind of locator may still be parsable even if a given
       interpreter cannot parse it.

4.3.1 与えられたインタプリタがそれを分析できないでも、与えられた種類のロケータはまだ「パー-可能」であるかもしれません。

4.3.2  Parsable by users does not imply readily parsable by untrained
       users.

4.3.2 ユーザによる「パルス-可能」は未熟なユーザで容易に「パー-可能」を含意しません。

4.3.3  A given locator need not be completely parsable by any one
       interpreter as long as a combination of interpreters can parse
       it completely.

4.3.3 インタプリタの組み合わせがそれを完全に分析できる限り、与えられたロケータはどんなインタプリタでも完全に「パー-可能」でなければならないというわけではありません。

4.4 Locators can be readily distinguished from naming and descriptive
    identifiers that may occupy the same name space.

同じ名前スペースを占めるかもしれない命名と描写的である識別子と4.4のロケータを容易に区別できます。

   During a transition period (of possibly indefinite length), other
   kinds of resource identifier are expected to co-exist in data
   structures along with Internet locators.

過渡期(ことによると無期の長さの)の間、リソース識別子の他の種類がインターネットロケータに伴うデータ構造で共存すると予想されます。

4.5 Locators are "transport-friendly".

4.5のロケータが「輸送に優しいです」。

   Internet locators can be transmitted from user to user (e.g, via e-
   mail) across Internet standard communications protocols without loss
   or corruption of information.

インターネット標準通信規約の向こう側に情報の損失も不正なしでインターネットロケータをユーザからユーザ(電子メールを通したe.g)まで送ることができます。

4.6 Locators are human transcribable.

4.6のロケータが人間の転写可能です。

   Users can copy Internet locators from one medium to another (such as
   voice to paper, or paper to keyboard) without loss or corruption of
   information.  This process is not required to be comfortable.

ユーザは情報の損失も不正なしでインターネットロケータを1つの媒体から別のもの(紙への声、またはキーボードへの紙などの)までコピーできます。 このプロセスが快適であることが必要ではありません。

Kunze                                                           [Page 7]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[7ページ]RFC1736推薦

4.7 An Internet locator consists of a service and an opaque parameter
    package.

4.7 インターネットロケータはサービスと不明瞭なパラメタパッケージから成ります。

   The parameter package has meaning only to the service with which it
   is paired, where a service is an abstract access method.  An abstract
   access method might be a software tool, an institution, or a network
   protocol.  The parameter package might be service-specific access
   instructions.  In order to protect creative development of new
   services, there is an extensible class of services for which no
   parameter package semantics common across services may be assumed.

パラメタパッケージはそれが対にされるサービスだけに意味を持っています。そこでは、サービスが抽象的なアクセス法です。 抽象的なアクセス法は、ソフトウェアツール、団体、またはネットワーク・プロトコルであるかもしれません。 パラメタパッケージはサービス特有のアクセス指示であるかもしれません。 新種業務の創造的な開発を保護するために、サービスの向こう側に一般的などんなパラメタパッケージ意味論も想定されないかもしれない広げることができるクラスのサービスがあります。

4.8 The set of services is extensible.

4.8 サービスのセットは広げることができます。

   New services can be added over time.

時間がたつにつれて、新種業務を加えることができます。

4.9 Locators contain no information about the resource other than that
    required by the access mechanism.

アクセス機構が必要である以外に、4.9のロケータはリソースの情報を全く含んでいません。

   The purpose of an Internet locator is only to describe the location
   of a resource, not other properties such as its type, size,
   modification date, etc.  These and other properties belong in a
   resource description standard.

インターネットロケータの目的は単にタイプ、サイズ、変更日付などの他の特性ではなく、リソースの位置について説明することです。 リソース記述規格にはこれらと他の特性があります。

5. Security Considerations

5. セキュリティ問題

   While the requirements have no direct security implications,
   applications based on standards that fulfill them may need to
   consider two potential vulnerabilities.  First, because locators are
   transient, a client using an invalid locator might unwittingly gain
   access to a resource that was not the intended target.  For example,
   when a hostname becomes unregistered for a period of time and then
   re-registered, a locator that was no longer valid during that period
   might once again lead to a resource, but perhaps to one that only
   pretends to be the original resource.

要件にはどんなダイレクトセキュリティ意味もない間、それらを実現させる規格に基づくアプリケーションは、2つの潜在的脆弱性を考える必要があるかもしれません。 ロケータが一時的であるので、まず最初に、無効のロケータを使用しているクライアントは意図している目標でなかったリソースへのアクセスを知らず知らず得るかもしれません。 例えば、ホスト名がしばらく、登録されていなく次に、再登録されるようになると、もうその期間、有効でなかったロケータは、もう一度リソースに導きますが、恐らくオリジナルのリソースであるふりをするだけであるものに導くかもしれません。

   Second, because a locator consists of a service and a parameter
   package, potentially enormous processing freedom is allowed,
   depending on the individual service.  A server is vulnerable unless
   it suitably restricts its input parameters.  For example, a server
   that advertizes locators for certain local filesystem objects may
   inadvertently open a door through which other filesystem objects can
   be accessed.

2番目に、ロケータがサービスとパラメタパッケージから成るので、潜在的に莫大な処理自由は許容されています、個々のサービスによって。 適当に入力パラメタを制限しない場合、サーバは被害を受け易いです。 例えば、どの他のファイルシステム対象物にアクセスできるかを通してある地方のファイルシステム対象物のためにロケータをadvertizesするサーバはうっかり戸を開けるかもしれません。

   A client is also vulnerable unless it understands the limitations of
   the service it is using.  For example, a client trusting a locator
   obtained from an uncertain source might inadvertently trigger a
   mechanism that applies charges to a user account.  Having a clear
   definition of service limitations could help alleviate some of these

また、それが利用しているサービスの制限を理解していない場合、クライアントも被害を受け易いです。 例えば、不確実なソースから得られたロケータを信じるクライアントはうっかりユーザアカウントに充電を適用するメカニズムの引き金となるかもしれません。 サービス制限の明確な定義を持っているのは、これらのいくつかを軽減するのを助けるかもしれません。

Kunze                                                           [Page 8]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[8ページ]RFC1736推薦

   concerns.

関係があります。

   For services that by nature offer a great deal of user freedom
   (remote login for example), the pre-specification of user commands
   within a locator presents vulnerabilities.  With careful command
   screening, the deleterious effects of unknowingly executing (at the
   client or server) an embedded command such as "rm -fr *" can be
   avoided.

生来、多くのユーザ自由(例えば、リモート・ログイン)を提供するサービスのために、ロケータの中のユーザコマンドのプレ仕様は脆弱性を提示します。 慎重なコマンド選別で、「rm -fr*」などの埋め込まれたコマンドを知らずに実行するという(クライアントかサーバで)有害な効果を避けることができます。

6. Conclusion

6. 結論

   Resource location standards, which define Internet resource locators,
   give providers the means to describe access information for their
   resources.  They give client developers the ability to access
   disparate resources while hiding access details from users.

リソース位置の規格(インターネット資料ロケータを定義する)はそれらのリソースのためのアクセス情報について説明する手段をプロバイダーに与えます。 彼らはアクセスの詳細にユーザから隠している間に異種のリソースにアクセスする能力をクライアント開発者に与えます。

   Several minimum requirements distinguish an Internet locator from a
   general locator.  Internet resource locators are impermanent handles
   sufficiently qualified for resource access not to depend in general
   on client location.  Locators can be recognized and parsed, and can
   be transmitted unscathed through a variety of human and Internet
   communication mechanisms.

いくつかの必要最小限が一般的なロケータとインターネットロケータを区別します。 インターネット資料ロケータは十分一般に、リソースアクセスがクライアント位置によらないのに資格があった一時的なハンドルです。 さまざまな人間とインターネット通信メカニズムを通して無事な状態でロケータは、認識して、分析できて、送ることができます。

   An Internet resource locator consists of a service and access
   parameters meaningful to that service.  The form of the locator does
   not discourage the addition of new services or the migration to other
   resource identifiers.  A clean distinction between resource location,
   resource naming, and resource description standards is preserved by
   limiting Internet locators to no more information than what is
   required by an access mechanism.

インターネット資料ロケータはそのサービスに重要なサービスとアクセスパラメタから成ります。 ロケータのフォームは他のリソース識別子に新種業務か移行の追加に水をさしていません。 リソース位置と、リソース命名と、リソース記述規格の清潔な区別は、インターネットロケータをアクセス機構によって必要とされることが情報でないことのようなどんな情報にも制限しないことによって、保存されます。

7. Acknowledgements

7. 承認

   The core requirements of this document arose from a collaboration of
   the following people at the November 1993 IETF meeting in Houston,
   Texas.

このドキュメントのコア要件はヒューストン(テキサス)での1993年11月のIETFミーティングに以下の人々の共同から起こりました。

      Farhad Ankelesaria, University of Minnesota
      John Curran, NEARNET
      Peter Deutsch, Bunyip
      Alan Emtage, Bunyip
      Jim Fullton, CNIDR
      Kevin Gamiel, CNIDR
      Joan Gargano, University of California at Davis
      John Kunze, University of California at Berkeley
      Clifford Lynch, University of California
      Lars-Gunnar Olson, Swedish University of Agriculture
      Mark McCahill, University of Minnesota

Farhad Ankelesaria、ミネソタ大学のジョン・カラン、NEARNETは尽きます。ドイツ語、詐欺師アランEmtage、詐欺師ジムFullton、CNIDRケビンGamiel、CNIDRジョーン・ガルガノ・カリフォルニア大学デイビス校のジョン・クンツェ、カリフォルニア大学バークレイ校のクリフォード・リンチ、カリフォルニア大学のラース-グナー・オルソン、農業のスウェーデンの大学がMcCahillをマークする、ミネソタ大学

Kunze                                                           [Page 9]

RFC 1736                Recommendations for IRLs           February 1995

IRLs1995年2月のためのクンツェ[9ページ]RFC1736推薦

      Michael Mealing, Georgia Tech
      Mitra, Pandora Systems
      Pete Percival, Indiana University
      Margaret St. Pierre, WAIS, Inc.
      Rickard Schoultz, KTH
      Janet Vratny, Apple Computer Library
      Chris Weider, Bunyip

マイケルMealing、ジョージア工科大ミトラ、パンドラシステムピートパーシバル、インディアナ大学マーガレットサン・ピエール島、WAIS Inc.リカードSchoultz、KTHジャネットVratny、アップル・コンピューターの図書館クリス・ワイダー、詐欺師

8. Author's Address

8. 作者のアドレス

   John A. Kunze
   Information Systems and Technology
   293 Evans Hall
   Berkeley, CA  94720

ジョンA.クンツェ情報システムと技術293エヴァンス・Hallバークレー、カリフォルニア 94720

   Phone: (510) 642-1530
   Fax:   (510) 643-5385
   EMail: jak@violet.berkeley.edu

以下に電話をしてください。 (510) 642-1530 Fax: (510) 643-5385 メールしてください: jak@violet.berkeley.edu

Kunze                                                          [Page 10]

クンツェ[10ページ]