RFC2483 日本語訳

Network Working Group                                      M. Mealling
Request for Comments: 2483                     Network Solutions, Inc.
Category: Experimental                                  R. Daniel, Jr.
                                        Los Alamos National Laboratory
                                                          January 1999

コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 2483年のネットワークソリューションズ社カテゴリ: 実験的なR.ダニエル、Jr.ロスアラモス国立研究所1999年1月

                        URI Resolution Services
                      Necessary for URN Resolution

つぼの解決に必要なURI解決サービス

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

Abstract

要約

   Retrieving the resource identified by a Uniform Resource Identifier
   (URI) [1] is only one of the operations that can be performed on a
   URI.  One might also ask for and get a list of other identifiers that
   are aliases for the original URI or a bibliographic description of
   the resource the URI denotes, for example. This applies to both
   Uniform Resource Names (URNs) and Uniform Resource Locators (URLs).
   Uniform Resource Characteristics (URCs) are discussed in this
   document but only as descriptions of resources rather than
   identifiers.

Uniform Resource Identifier(URI)[1]によって特定されたリソースを検索するのは、URIに実行できる操作の唯一の1つです。 また、1つは、オリジナルのURIのための別名である他の識別子のリストか例えばURIが指示するリソースの図書目録の記述を求めて、得るかもしれません。 これはUniform Resource Names(URNs)とUniform Resource Locator(URL)の両方に適用されます。 一定のResource Characteristics(URCs)は本書では、しかし、単に識別子よりむしろリソースの記述として議論されています。

   A service in the network providing access to a resource may provide
   one or some of these options, but it need not provide all of them.
   This memo specifies an initial set of these operations that can be
   used to describe the interactions provided by a given access service.
   It also suggests guidelines that should be adhered to when those
   operations are encoded in a protocol.

リソースへのアクセスを提供するネットワークにおけるサービスはこれらのオプションの1かいくつかを提供するかもしれませんが、それはそれらを皆、提供する必要はありません。 このメモは与えられたアクセス・サービスで供給された相互作用について説明するのに使用できるこれらの操作の1人の始発を指定します。 また、それはそれらの操作がプロトコルでコード化されるとき固く守られるべきであるガイドラインを示します。

1. Introduction

1. 序論

   In the course of formulating current proposals [2] regarding URNs
   [3], it became apparent that requiring servers to manage all of the
   desired functions or requiring clients to process varied information
   returned by a server was unrealistic and a barrier to adoption. There
   needed to be some way for a client to be able to identify a server
   that specialized in the complex and another that specialized in the

[2] URNs[3]に関して、必要な機能のすべてを管理するためにサーバを必要とするか、またはクライアントがサーバによって返された様々な情報を処理するのが必要であるのが非現実的であったのが明らかになったという現在の提案とバリアを採用に定式化することの間に。 遠くにあるように、クライアントが複合体と別のものを専門に扱ったサーバを特定できるように、専攻されたそれが必要です。

Mealling & Daniel             Experimental                      [Page 1]

RFC 2483                URI Resolution Services             January 1999

[1ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

   simple (but fast). Also, in subsequent conversations it became
   obvious that, in most cases, some of the operations were
   inappropriate or difficult for certain identifiers.

簡単です(速い)。 また、その後の会話では、多くの場合、ある識別子には、操作のいくつかが不適当であるか、または難しかったのが明白になりました。

   The Problem

問題

   In the process of learning about a resource in the Internet, there
   are a variety of possible functions that may be important and/or
   useful, such as discovery of locators, names, descriptions, and
   accessing the resource itself. A given service may support only a
   subset of these; hence, it is important to describe such an access
   service by the types of functions supported and the resources of
   which it has some knowledge. For example, in the framework for an RDS
   described in [5] the RDS itself may provide URLs [6][7], while the
   resolvers may provide descriptions, URLs, or even the resources
   themselves. The design of an RDS, as proposed in RFC 2168 [2], may be
   more generous and provide all of the above.

インターネットでリソースに関して学ぶことの途中に、さまざまなロケータと、名前と、記述と、リソース自体にアクセスする発見などのように重要な、そして/または、役に立つかもしれない可能な機能があります。 与えられたサービスはこれらの部分集合だけをサポートするかもしれません。 したがって、機能のタイプによるアクセス・サービスがサポートしたそのようなものとそれが何らかの知識を持っているリソースについて説明するのは重要です。 例えば、[5]で説明されたRDSのためのフレームワークに、RDS自身はURL[6][7]を提供するかもしれません、レゾルバが記述、URL、またはリソース自体さえ提供するかもしれませんが。 RFC2168[2]で提案されるRDSのデザインは、より寛大であり、上記のすべてを提供するかもしれません。

   This problem requires some well understood set of identifiers that
   specify those operations. But an exhaustive set would both be
   impossible and not very necessary. Thus, this document will list
   several operations, as well as, lay out requirements for specifying
   new operations.

この問題は何らかのよく理解されているセットにそれらの操作を指定する識別子を要求します。 しかし、徹底的なセットは、不可能であって、かつそれほど必要でないでしょう。 したがって、このドキュメントはいくつかの操作を記載して、良くて、新しい操作を指定するための要件を広げてください。

   The purpose of this document is to define a list of such functions
   and short names for them and then use them in defining the interface
   to an access service. Previous versions of this document referred to
   services where the arguments were specific types of URIs such as URNs
   or URLs.  These services were called "N2L" and "L2L",for example.
   Their use has been changed in favor of the more general URI form.

このドキュメントの目的は、それらのためにそのような機能と省略名のリストを定義して、次に、インタフェースをアクセス・サービスと定義する際にそれらを使用することです。 このドキュメントの旧バージョンは議論が特定のタイプのURNsかURLなどのURIであったところとサービスを呼びました。 これらのサービスは、呼ばれた"N2L"と例えば、"L2L"でした。 より一般的なURIフォームを支持して彼らの使用を変えました。

   Design Criteria

設計基準

   To meet these requirements a fairly simple design criteria was used.
   The need to identify the operation with some token such that its
   operands, algorithm, and errors were known proved sufficient to meet
   these requirements.

これらの必要条件を満たすために、かなり簡単な設計基準は使用されました。 オペランド、アルゴリズム、および誤りが何らかのトークンがそのようの操作でしたが、知られていて、特定する必要性はこれらの必要条件を満たすために十分であると判明しました。

2. General Specification

2. 一般仕様

   To provide a framework both for the specifications in this document
   and for future work to be written by others, the guidelines below are
   suggested for documents that seek to specify new operations. Any
   specification of a member of this set of operations should address
   these issues with respect to its operands, algorithm, output, and
   errors.

仕様のために本書では両方をフレームワークに提供して、今後の活動が他のものによって書かれているように、以下のガイドラインは新しい操作を指定しようとするドキュメントのために示されます。 このセットの操作のメンバーのどんな仕様もオペランド、アルゴリズム、出力、および誤りに関してこれらの問題を扱うべきです。

Mealling & Daniel             Experimental                      [Page 2]

RFC 2483                URI Resolution Services             January 1999

[2ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

   Due to the small number of listed functions, a registration mechanism
   was dismissed as premature. If this list grows, a registration
   mechanism will probably be needed.

記載された機能の少ない数のため、登録メカニズムは時期尚早であるとして捨てられました。 このリストが成長すると、登録メカニズムがたぶん必要でしょう。

   Also, due to the experimental nature of this document and the systems
   that use its specifications, the use of words like MUST and SHALL are
   limited. Where used they reflect a case where this specification
   could cause harm to existing, non-experimental systems such as HTTP
   and URNs.  Thus, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119.

また、それが仕様、単語の使用を使用するこのドキュメントとシステムの実験本質への支払われるべきものは限らなければなりません、そして、SHALLは限られています。 使用されているところに、彼らはこの仕様がHTTPやURNsなどの既存の、そして、非実験用のシステムに害を引き起こす場合があったケースを反映します。 したがって、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。

2.1 Operands

2.1 オペランド

   Operands must contain the following pieces of information:

オペランドは以下の情報を含まなければなりません:

      * name of the operation
      * case insensitive mnemonic for the operation
      * number of operands
      * type of each operand
      * format of each operand

* それぞれのオペランドのそれぞれのオペランド*形式のオペランド*タイプの操作*数のための操作*大文字と小文字を区別しないニーモニックの名前

2.2 Algorithm

2.2アルゴリズム

   The exact algorithm for the operation must either be specified
   completely or it must be considered opaque and defined by the server
   or application.

操作のための正確なアルゴリズムを完全に指定しなければならないか、サーバかアプリケーションでそれを不透明であると考えられて、定義しなければなりません。

2.3 Output

2.3 出力

   Output must specify one of the following:

出力は以下の1つを指定しなければなりません:

      * there is no output
      * the output is undefined
      * the output itself and its content
      * the fact that the output is an object and the object's
        type and format
      * any non-protocol specific errors

* どんな出力も*そこでは、出力でない、未定義の*が出力自体であり、内容*は出力がオブジェクトであり、オブジェクトのタイプと形式*があらゆる非プロトコルの特定の誤りであるという事実を出力すること。

2.4 Error Conditions

2.4 エラー条件

   All errors that are considered applicable across all implementations
   and application environments must be included. Errors that depend on
   the system conveying the service are not included. Thus, many of the
   expected errors such as service availability or operation syntax are
   not included in this document since they are implementation
   dependent.

すべての実装とアプリケーション環境の向こう側に適切であると考えられるすべての誤りを含まなければなりません。 サービスを伝えるシステムによる誤りは含まれていません。 したがって、それらが実装に依存しているので、サービスの有用性か操作構文などの期待誤差の多くが本書では含まれていません。

Mealling & Daniel             Experimental                      [Page 3]

RFC 2483                URI Resolution Services             January 1999

[3ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

2.5 Security Considerations

2.5 セキュリティ問題

   Any security considerations relating to the service provided must be
   specified. This does NOT include considerations dealing with the
   protocol used to convey the service or to those that normally
   accompany the results of the service. For example, a service that
   returned a single URL would need to discuss the situation where
   someone maliciously inserts an incorrect URL into the resolver but
   NOT the case where someone sends personal information across the
   Internet to the resource identified by the correct URL.

サービスとの関係が提供したどんなセキュリティ問題も指定しなければなりません。 これはプロトコルの取扱いなら以前はよくサービスか通常、サービスの結果に伴うものに伝えられていた問題を含んでいません。 例えば、ただ一つのURLを返したサービスは、だれかが個人情報を使いにやるリソースへのインターネットが正しいURLで特定したケースではなく、だれかが陰湿に不正確なURLをレゾルバに指し込む状況について議論する必要があるでしょう。

3. Encoding The Operations

3. 操作をコード化します。

   To be useful, these operations have to be used within some system or
   protocol. In many cases, these systems and protocols will place
   restrictions on which operations make sense and how those that do are
   syntactically represented. It is sufficient for those protocols to
   define new operations within their own protocol specification
   documents but care should be taken to make this fact well known.

役に立つように、これらの操作は何らかのシステムかプロトコルの中で使用されなければなりません。 多くの場合、これらのシステムとプロトコルはどの操作が理解できるか、そして、そうするものがどのようにシンタクス上表されるかに関する制限を置くでしょう。 それらのプロトコルがそれら自身のプロトコル仕様ドキュメントの中に新しい操作を定義するのが、十分ですが、この事実をよく明らかにするために注意するべきです。

   Also, a given system or protocol will have its own output
   specifications that may restrict the output formats of a given
   operation.  Additionally, a given protocol may have better solution
   for output than the ones given here. For example, the result of an
   operation that converts a URI to more than one URL may be encoded in
   a protocol-specific manner that conveys information about the
   closeness of each resource on the network.

また、与えられたシステムかプロトコルには、与えられた操作の出力形式を制限するかもしれないそれ自身の出力仕様があるでしょう。 さらに、与えられたプロトコルには、出力のためのここに与えられたものより良いソリューションがあるかもしれません。 例えば、1つ以上のURLにURIを変換する操作の結果はネットワークに関するそれぞれのリソースの密接に関して情報を伝達するプロトコル特有の方法でコード化されるかもしれません。

   Thus, the requirements on encoding these operations within a given
   system are as follows:

したがって、与えられたシステムの中でこれらの操作をコード化することに関する要件は以下の通りです:

      * which subset of the operations are allowed
      * how the operator is encoded
      * how the operands are encoded
      * how the error codes are returned

* オペレータがコード化される*が操作のどの部分集合に許容されているか、*オペランドがどのようにコード化されるか、*エラーコードはどのように返されるか。

   The text/uri-list MIME Media Type is specified in Section 5. This
   Media Type is merely a suggestion for experimental systems that need
   a simple implementation. It is included here merely as an example to
   show completeness (however simple it may be).

uriテキスト/リストMIMEメディアTypeはセクション5で指定されます。 このメディアTypeは単に簡単な実装を必要とする実験用システムのための提案です。 それは、完全性を示しているために単に例としてここに含まれています(それがどんなに簡単であっても)。

Mealling & Daniel             Experimental                      [Page 4]

RFC 2483                URI Resolution Services             January 1999

[4ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

4. The Incomplete Set

4. 不完全なセット

4.1 I2L (URI to URL)

4.1 I2L(URLへのURI)

      * Name: URI to URL
      * Mnemonic: I2L
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: One and only one URL
      * Errors Conditions:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied

* 以下を命名してください。 URL*ニーモニックへのURI: オペランドのI2L*数: それぞれのオペランドの1*タイプ: 最初のオペランドはURIです。 * それぞれのオペランドの形式: 最初のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: 1唯一無二のURL*誤りConditions: o 奇形のURI o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIが過去に存在しましたが、何も現在それに関して知られていない、o Accessは否定しました。

      * Security Considerations:
           o Malicious Redirection
             One of the fundamental dangers related to any service such
             as this is that a malicious entry in a resolver's database
             will cause clients to resolve the URI into the wrong URL.
             The possible intent may be to cause the client to retrieve
             a resource containing fraudulent or damaging material.
           o Denial of Service
             By removing the URL to which the URI maps, a malicious
             intruder may remove the client's ability to retrieve the
             resource.

* セキュリティ問題: o 基本的な危険の悪意があるRedirection Oneは、クライアントがリゾルバのデータベースにおける悪意があるエントリーで間違ったURLにURIに変えるとこれのようなどんなサービスにも話しました。 可能な意図はクライアントがURI地図であり悪意がある侵入者がリソースを検索するクライアントの能力を移すかもしれないURLを取り除く詐欺的であるかダメージが大きい材料oサービス妨害Byを含むリソースを検索することを引き起こすことであるかもしれません。

   This operation is used to map a single URI to a single URL. It is
   used by lightweight clients that do not have the ability to select
   from a list of URLs or understand a URC. The algorithm for this
   mapping is dependent on the URI scheme.

この操作は、ただ一つのURIをただ一つのURLに写像するのに使用されます。 それはURLのリストから選び抜くか、またはURCを理解する能力を持っていないライト級のクライアントによって使用されます。 このマッピングのためのアルゴリズムはURI体系に依存しています。

4.2 I2Ls (URI to URLs)

4.2 I2Ls(URLへのURI)

      * Name: URI to URLs
      * Mnemonic: I2LS
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: A list of zero or more URLs
      * Errors:
           o Malformed URI

* 以下を命名してください。 URL*ニーモニックへのURI: オペランドのI2LS*数: それぞれのオペランドの1*タイプ: 最初のオペランドはURIです。 * それぞれのオペランドの形式: 最初のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: より多くのURL* ゼロか誤りのリスト: o 奇形のURI

Mealling & Daniel             Experimental                      [Page 5]

RFC 2483                URI Resolution Services             January 1999

[5ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIは過去に存在しましたが、何も現在、それに関して知られていません。o Accessは*セキュリティConsiderationsを否定しました: o 悪意があるRedirection(I2Lを見る)oサービス妨害(I2Lを見ます)

   This operation is used to map a single URI to 0 or more URLs. It is
   used by a client that can pick from a list of URLs based on some
   criteria that are important to the client. The client should not make
   any assumptions about the order of the URLs returned. No matter what
   the particular media type, the result should be a list of the URLs
   that may be used to obtain an instance of the resource identified by
   the URI. All URIs shall be encoded according to the URL [7] and URN
   [3] specifications.

この操作は、ただ一つのURIを0つ以上のURLに写像するのに使用されます。 それはそれがいくつかの重要な評価基準に基づくURLのリストからクライアントまで選ぶことができるクライアントによって使用されます。 クライアントはURLの注文に関するどんな仮定も返させるべきではありません。 特定のメディアタイプが者であっても、結果はURIによって特定されたリソースのインスタンスを得るのに使用されるかもしれないURLのリストであるべきです。 すべてのURIがURL[7]とURN[3]仕様通りにコード化されるものとします。

4.3 I2R (URI to Resource)

4.3 I2R(リソースへのURI)

      * Name: URI to Resource
      * Mnemonic: I2R
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: An instance of the resource named by the URI.
      * Errors:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

* 以下を命名してください。 リソース*ニーモニックへのURI: オペランドのI2R*数: それぞれのオペランドの1*タイプ: 最初のオペランドはURIです。 * それぞれのオペランドの形式: 最初のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: URIによって指定されたリソースのインスタンス。 * 誤り: o 奇形のURI o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIは過去に存在しましたが、何も現在、それに関して知られていません。o Accessは*セキュリティConsiderationsを否定しました: o 悪意があるRedirection(I2Lを見る)oサービス妨害(I2Lを見ます)

   This operation is used to return a single instance of the resource
   that is named by the URI. The format of the output is dependent on
   the resource itself.

この操作は、URIによって命名されるリソースのただ一つのインスタンスを返すのに使用されます。 出力の形式はリソース自体に依存しています。

Mealling & Daniel             Experimental                      [Page 6]

RFC 2483                URI Resolution Services             January 1999

[6ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

4.4 I2Rs (URI to Resources)

4.4 I2Rs(リソースへのURI)

      * Name: URI to Resources
      * Mnemonic: I2Rs
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: Zero or more instances of the resource named by the URI.
      * Errors:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

* 以下を命名してください。 リソース*ニーモニックへのURI: オペランドのI2Rs*数: それぞれのオペランドの1*タイプ: 最初のオペランドはURIです。 * それぞれのオペランドの形式: 最初のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: URIによって指定されたリソースのゼロか、より多くのインスタンス。 * 誤り: o 奇形のURI o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIは過去に存在しましたが、何も現在、それに関して知られていません。o Accessは*セキュリティConsiderationsを否定しました: o 悪意があるRedirection(I2Lを見る)oサービス妨害(I2Lを見ます)

   This operation is used to return multiple instances of a resource,
   for example, GIF and JPEG versions of an image. The judgment about
   the resources being "the same" resides with the naming authority that
   issued the URI.

この操作は、例えば、リソースの複数のインスタンスにGIFを返して、イメージのバージョンをJPEGに返すのに使用されます。 「同じ」リソースに関する判断はURIを発行した命名権威であります。

   The output shall be a MIME multipart/alternative [4] message with the
   alternative versions of the resource in separate body parts. If there
   is only one version of the resource identified by the URN, it MAY be
   returned without the multipart/alternative wrapper.

出力は別々の身体の部分のリソースの異本をもってMIMEの複合の、または、代替の[4]メッセージになるでしょう。 URNによって特定されたリソースの1つのバージョンしかなければ、複合の、または、代替のラッパーなしでそれを返すかもしれません。

4.5 I2C (URI to URC)

4.5 I2C(URCへのURI)

      * Name: URI to URC * Mnemonic: I2C * Number of Operands: 1 * Type
      of Each Operand: First operand is a URI.  * Format of Each
      Operand: First operand is encoded as a URI.  * Algorithm: Opaque *
      Output: A URC * Errors:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

* 以下を命名してください。 URC*ニーモニックへのURI: オペランドのI2C*数: それぞれのオペランドの1*タイプ: 最初のオペランドはURIです。 * それぞれのオペランドの形式: 最初のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: URC*誤り: o 奇形のURI o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIは過去に存在しましたが、何も現在、それに関して知られていません。o Accessは*セキュリティConsiderationsを否定しました: o 悪意があるRedirection(I2Lを見る)oサービス妨害(I2Lを見ます)

Mealling & Daniel             Experimental                      [Page 7]

RFC 2483                URI Resolution Services             January 1999

[7ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

   Uniform Resource Characteristics are descriptions of resources. This
   request allows the client to obtain a description of the resource
   identified by a URI, as opposed to the resource itself or simply the
   resource's URLs. The description might be a bibliographic citation, a
   digital signature, or a revision history. This memo does not specify
   the content of any response to a URC request. That content is
   expected to vary from one server to another.

一定のResource Characteristicsはリソースの記述です。 クライアントはこの要求でURIによって特定されたリソースの記述を得ることができます、リソース自体か単にリソースのURLと対照的に。 記述は、図書目録の引用、デジタル署名、または改訂履歴であるかもしれません。 このメモはURC要求へのどんな応答の内容も指定しません。 その内容が1つのサーバから別のものに異なると予想されます。

4.6 I2CS (URI to URCs)

4.6 I2CS(URCsへのURI)

      * Name: URI to URCs
      * Mnemonic: I2CS
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: Zero or more URCs
      * Errors:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

* 以下を命名してください。 URCs*ニーモニックへのURI: オペランドのI2CS*数: それぞれのオペランドの1*タイプ: 最初のオペランドはURIです。 * それぞれのオペランドの形式: 最初のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: ゼロか、より多くのURCs*誤り: o 奇形のURI o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIは過去に存在しましたが、何も現在、それに関して知られていません。o Accessは*セキュリティConsiderationsを否定しました: o 悪意があるRedirection(I2Lを見る)oサービス妨害(I2Lを見ます)

   URCs can come in different formats and types. This operation returns
   zero or more URCs that are appropriate for the given URI.

URCsは異なった形式に入ることができて、タイプします。 この操作がゼロを返すか、または、より多くのURCsが付与のためにURIを当てます。

4.7 I2N (URI to URN)

4.7 I2N(つぼへのURI)

      * Name: URI to URN
      * Mnemonic: I2N
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URN.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: One and only one URN
      * Errors:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.

* 以下を命名してください。 つぼ*ニーモニックへのURI: オペランドのI2N*数: それぞれのオペランドの1*タイプ: 最初のオペランドはURNです。 * それぞれのオペランドの形式: 最初のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: 唯一無二の1つのURN*誤り: o 奇形のURI o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIは過去に存在しましたが、何も現在、それに関して知られていません。

Mealling & Daniel             Experimental                      [Page 8]

RFC 2483                URI Resolution Services             January 1999

[8ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

o アクセスは*セキュリティConsiderationsを否定しました: o 悪意があるRedirection(I2Lを見る)oサービス妨害(I2Lを見ます)

   While URNs are supposed to identify one and only one resource, that
   does not mean that a resource may have one and only one URN. For
   example, consider a resource that one organization wishes to name
   'foo'; another organization, in agreement with the first, wants to
   call the resource 'bar'. Both organizations can agree that both names
   'name' the same resource and that the URNs 'foo' and 'bar' are
   equivalent.

URNsが唯一無二の1つのリソースを特定するべきである間、それは、リソースには唯一無二の1URNがあるかもしれないことを意味しません。 例えば、1つの組織が'foo'を命名したがっているリソースを考えてください。 1番目に合意して、別の組織は'バー'というリソースを呼びたがっています。 両方の組織は両方の名前が同じリソースを'命名し'て、URNs'foo'と'バー'が同等であるのに同意できます。

   The result is a URN, known to the server, that identifies the same
   resource as the input URN.

結果は同じリソースが入力URNであると認識するサーバに知られているURNです。

   Extreme care should be taken with this service as it toys with the
   idea of equality with respect to URNs. As mentioned in several URN
   documents, the idea of equality is very domain specific. For example,
   a URN pointing to a weather map for a particular day and a URN
   pointing to the map as it changes from day to day would NOT be
   returned in this example because they point to do different
   resources. Some other concept of temporary equivalence is at work.
   This service instead deals with resources that have two different
   names where there is a binding between the names that is agreed by
   both name assigners. I.e., both namespaces MUST have agreed that the
   each name can be used in place of the other and the meaning does not
   change.

URNsに関して平等の考えをもてあそぶとき、極端な注意はこのサービスで払われるべきです。 いくつかのURNドキュメントで言及されるように、平等の考えはドメイン非常に特有です。 例えば、彼らが異なったリソースをするために指すので、特定の日、URNのために日々に変化するのに従って地図を示しながら天気図を示すURNはこの例で返されないでしょう。 一時的な等価性のある他の概念は仕事しています。 このサービスは代わりにすなわち名前の間に結合がある両方の名前指定人によって同意された2つの異なった名前を持っているリソースに対処します。 すなわち両方の名前空間は、もう片方に代わってそれぞれ名義を使用できるのに同意したに違いありません、そして、意味は変化しません。

4.8 I2Ns (URI to URNs)

4.8 I2Ns(つぼへのURI)

      * Name: URI to URNs
      * Mnemonic: I2NS
      * Number of Operands: 1
      * Type of Each Operand: First operand is a URI.
      * Format of Each Operand: First operand is encoded as a URI.
      * Algorithm: Opaque
      * Output: A list of URNs
      * Errors:
           o Malformed URI
           o URI is syntactically valid but does not exist in any form.
           o URI exists but there is no available output from this
             operation.
           o URI existed in the past but nothing is currently known
             about it.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)

* 以下を命名してください。 つぼ*ニーモニックへのURI: オペランドのI2NS*数: それぞれのオペランドの1*タイプ: 最初のオペランドはURIです。 * それぞれのオペランドの形式: 最初のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: URNs*誤りのリスト: o 奇形のURI o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIは過去に存在しましたが、何も現在、それに関して知られていません。o Accessは*セキュリティConsiderationsを否定しました: o 悪意があるリダイレクション(I2Lを見ます)

Mealling & Daniel             Experimental                      [Page 9]

RFC 2483                URI Resolution Services             January 1999

[9ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

           o Denial of Service (see I2L)

o サービス妨害(I2Lを見ます)

   This operation simply returns zero or more URNs following the same
   criteria and cautions as the I2N operation.

この操作はI2N操作として単にゼロか同じより多くのURNs次の評価基準と警告を返します。

4.9 I=I (Is URI equal to URI):

4.9 私は私(URIと等しいURIである)と等しいです:

      * Name: URI = URI
      * Mnemonic: I=I
      * Number of Operands: 2
      * Type of Each Operand: Both operands are URIs.
      * Format of Each Operand: Both operands are encoded as a URIs.
      * Algorithm: Opaque
      * Output: TRUE or FALSE
      * Errors:
           o Malformed URIs
           o URIs are syntactically valid but do not exist in any form.
           o URIs exist but there is no available output from this
             operation.
           o URIs existed in the past but nothing is currently known
             about them.
           o Access denied
      * Security Considerations:
           o Malicious Redirection (see I2L)
           o Denial of Service (see I2L)

* 以下を命名してください。 URIはURI*ニーモニックと等しいです: 私はオペランドのI*数と等しいです: それぞれのオペランドの2*タイプ: 両方のオペランドはURIです。 * それぞれのオペランドの形式: 両方のオペランドはURIとしてコード化されます。 * アルゴリズム: *出力について不透明にしてください: 本当の、または、誤った*誤り: o 奇形のURI o URIは、シンタクス上有効ですが、どんなフォームにも存在していません。o URIは存在していますが、この操作からの有効出力が全くありません。o URIは過去に存在しましたが、何も現在、それらに関して知られていません。o Accessは*セキュリティConsiderationsを否定しました: o 悪意があるRedirection(I2Lを見る)oサービス妨害(I2Lを見ます)

   This operation is used to determine whether two given URIs are
   considered to be equal by the server being asked the question. The
   algorithm used to determine equality is opaque. No assertions are
   made about whether or not the URIs exhibits characteristics of URNs
   or URLs.

この操作は、2つの与えられたURIが質問が行われるサーバで等しいと考えられるかどうか決定するのに使用されます。 アルゴリズムは、以前はよく平等が不明瞭であることを決定していました。 URIがURNsかURLの特性を示すかどうかを主張を全くしません。

Mealling & Daniel             Experimental                     [Page 10]

RFC 2483                URI Resolution Services             January 1999

[10ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

5. The text/uri-list Internet Media Type

5. uriテキスト/リストインターネットメディアType

   Several of the resolution service requests, such as I2Ls, I2Ns,
   result in a list of URIs being returned to the client. The text/uri-
   list Internet Media Type is defined to provide a simple format for
   the automatic processing of such lists of URIs.

I2Lsなどのいくつかの解決サービスのリクエスト(I2Ns)がクライアントに返されるURIのリストをもたらします。 テキスト/uriリストインターネットメディアTypeは、URIのそのようなリストの自動処理のための簡単な形式を提供するために定義されます。

   This is a copy of the IANA registration of the text/uri-list Media
   Type.

これはuriテキスト/リストメディアTypeのIANA登録のコピーです。

    Date: Fri, 18 Apr 97 08:36:07 PDT
    From: Ron Daniel Jr. <rdaniel@lanl.gov>
    To: iana@iana.org, rdaniel@lanl.gov
    Subject: Request for MIME media type Text/IETF Tree - uri-list

日付: 金曜日、1997年4月18日の太平洋夏時間8時36分7秒From: ロンダニエル Jr. <rdaniel@lanl.gov 、gt;、To: iana@iana.org 、rdaniel@lanl.gov Subject: MIMEメディアタイプText/IETF Treeを求める要求--uri-リスト

    Name : Ron Daniel Jr.

以下を命名してください。 ロンダニエルJr.

    E-mail : rdaniel@lanl.gov

メール: rdaniel@lanl.gov

    MIME media type name : Text

MIMEメディア型名: テキスト

    MIME subtype name : IETF Tree -uri-list

MIME「副-タイプ」は以下を命名します。 IETF木の-uri-リスト

    Required parameters : none

必要なパラメタ: なし

    Optional parameters : charset

任意のパラメタ: charset

    Currently, URIs can be represented using US-ASCII. However, there
    are many non-standard URIs which use special character sets.
    Discussion of how to best achieve internationalization of URIs is
    underway. This registration will be updated with a discussion of the
    URI charsets once that discussion has concluded.

現在、米国-ASCIIを使用することでURIを表すことができます。 しかしながら、特殊文字セットを使用する多くの標準的でないURIがあります。 どうURIの国際化を最もよく達成するかに関する議論は進行中です。 その議論がいったん終わると、URI charsetsの議論でこの登録をアップデートするでしょう。

    Encoding considerations : Some transfer protocols, such as SMTP,
    place limits on the length of lines. Very long URIs might exceed
    those limits. Systems must therefore be prepared to use a suitable
    content transfer encoding. This is anticipated to be a rare
    occurance.

問題をコード化します: SMTPなどのいくつかの転送プロトコルが系列の長さに限界を置きます。 非常に長いURIはそれらの限界を超えるかもしれません。 したがって、適当な満足している転送コード化を使用するようにシステムを準備しなければなりません。 これは、まれなoccuranceになるように予期されます。

    Security considerations : Client software should be aware of the
    security considerations of URIs.  For example, accessing some URIs
    can result in sending a death threat to a head of state, frequently
    prompting a visit from the relevant protective service.  Accessing
    other URIs may result in financial obligations, or access to
    resources considered inappropriate by one's employer.

セキュリティ問題: クライアントソフトウェアはURIのセキュリティ問題を意識しているべきです。 例えば、いくつかのURIにアクセスするのは殺人予告を元首に送るのに結果として生じることができます、関連保護的なサービスから訪問を頻繁にうながして。 他のURIにアクセスすると、財政分担、または不適当であると人の雇い主によって考えられたリソースへのアクセスがもたらされるかもしれません。

Mealling & Daniel             Experimental                     [Page 11]

RFC 2483                URI Resolution Services             January 1999

[11ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

    While the legitimate provider of a uri-list could exploit these
    properties for good or ill, it is more likely that uri-lists will be
    falsified in order to exploit such characteristics of URIs.

uri-リストの正統のプロバイダーは良かれ悪しかれこれらの特性を利用するかもしれませんが、uri-リストがURIのそのような特性を利用するために改竄されるのは、おそらくです。

    Additionally, the lookup and reverse lookup potential of the uri-
    list may be attractive to traffic analysts. URI lists may also
    reveal confidential information, such as the location of sensitive
    information.

さらに、トラフィックアナリストには、uriリストのルックアップと逆のルックアップの可能性は魅力的であるかもしれません。 また、URIリストは機密情報の位置などの秘密情報を明らかにするかもしれません。

    Because of these considerations, external confidentiality measures
    should be available to protect uri-list responses when appropriate.

これらの問題のために、外部の秘密性程度は、適切であるときに、uri-リスト応答を保護するために利用可能であるべきです。

    Interoperability considerations : none known

相互運用性問題: 知られていないなにも

    Published specification : Uniform Resource Locators (URLs) and
    Uniform Resource Names (URNs) are two instances of the more general
    class of identifiers known as Uniform Resource Identifiers (URIs).
    URN resolution methods frequently wish to return lists of URLs for a
    resource so that fault-tolerance and load balancing can be achieved.
    The text/uri-list format is intended to be a very simple format for
    communicating such lists of URLs (and URNs) in a form suitable for
    automatic processing.

広められた仕様: Uniform Resource Locator(URL)とUniform Resource Names(URNs)はUniform Resource Identifier(URI)として知られているより一般的なクラスに関する識別子の2つのインスタンスです。 耐障害性とロードバランシングを達成できて、URN解決メソッドはリソースのために頻繁にURLのリストを返したがっています。 uriテキスト/リスト形態は自動処理に適したフォームでURL(そして、URNs)のそのようなリストを伝えるための非常に簡単な形式であることを意図します。

    The format of text/uri-list resources is:

uriテキスト/リストリソースの形式は以下の通りです。

    1) Any lines beginning with the '#' character are comment lines
        and are ignored during processing. (Note that URIs may contain
        the '#' character, so it is only a comment character when it is
        the first character on a line.)

1) '#'キャラクタと共に始まるどんな系列も、注釈行であり、処理の間、無視されます。 (系列の最初のキャラクタであるときにだけ、それがコメントキャラクタであるためにURIが'#'キャラクタを含むかもしれないことに注意してください。)

    2) The remaining non-comment lines shall be URIs (URNs or URLs),
        encoded according to the URL or URN specifications (RFC2141,
        RFC1738 and RFC2396). Each URI shall appear on one and only one
        line. Very long URIs are not broken in the text/uri-list format.
        Content-transfer-encodings may be used to enforce line length
        limitations.

2) 残っている非注釈行は、URLによると、コード化されたURI(URNsかURL)かURN仕様になるでしょう(RFC2141、RFC1738、およびRFC2396)。 各URIは唯一無二の1つの系列に現れるものとします。 非常に長いURIはuriテキスト/リスト形態で壊されません。 満足している転送encodingsは、行長制限を実施するのに使用されるかもしれません。

    3) As for all text/* formats, lines are terminated with a CRLF pair.

3) すべてのテキスト/*形式に関して、系列はCRLF組と共に終えられます。

    In applications where one URI has been mapped to a list of URIs, the
    first line of the text/uri-list response SHOULD be a comment giving
    the original URI.

1つのURIがURIのリスト、uriテキスト/リスト応答SHOULDの最初の系列に写像されたアプリケーションでは、オリジナルのURIを与えるコメントになってください。

Mealling & Daniel             Experimental                     [Page 12]

RFC 2483                URI Resolution Services             January 1999

[12ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

    An example of the format is given below:

形式に関する例は以下に出されます:

      # urn:isbn:0-201-08372-8
      http://www.huh.org/books/foo.html
      http://www.huh.org/books/foo.pdf
      ftp://ftp.foo.org/books/foo.txt

# つぼ:isbn:0-201-08372-8 http://www.huh.org/books/foo.html http://www.huh.org/books/foo.pdf ftp://ftp.foo.org/books/foo.txt

    Applications which use this media : URN resolvers are the initial
    applications. Web clients and proxies are applications that are
    likely to support this format in the future.

このメディアを使用するアプリケーション: URNレゾルバは初期のアプリケーションです。 ウェブクライアントとプロキシは将来この形式をサポートしそうなアプリケーションです。

    Additional information :

追加情報:

    1. Magic number(s) : none at this time
    2. File extension(s) : .uris or .uri recommended
    3. Macintosh file type code : URIs recommended

1. マジックナンバー(s): 今回のなにも、2 ファイル拡張子(s): .urisか.uriが3を推薦しました。 マッキントッシュファイルの種類コード: 推薦されたURI

    This media type is the product of the URN working group of the IETF.

このメディアタイプはIETFのURNワーキンググループの製品です。

    Person to contact for further information :

詳細のために連絡する人:

    1. Name : Ron Daniel Jr.
    2. E-mail : rdaniel@lanl.gov

1. 以下を命名してください。 ロンダニエルJr.2。 メール: rdaniel@lanl.gov

    Intended usage : Limited Use
    The text/uri-list media type is intended for use in applications
    which utilize URIs for replicated resources.

意図している用法: uriテキスト/リストメディアがタイプする限られたUseは模写されたリソースにURIを利用するアプリケーションにおける使用のために意図します。

    Author/Change controller : Ron Daniel Jr.
    Los Alamos National Laboratory
    rdaniel@lanl.gov

コントローラを書くか、または変えてください: ロンダニエルJr.ロスアラモス国立研究所 rdaniel@lanl.gov

Mealling & Daniel             Experimental                     [Page 13]

RFC 2483                URI Resolution Services             January 1999

[13ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

   In applications where one URI has been mapped to a list of URIs, such
   as in response to the I2Ls request, the first line of the text/uri-
   list response SHOULD be a comment giving the original URI. An example
   of such a result for the I2L request is shown below in Figure 1.

I2Ls要求に対応したなど1つのURIがURIのリストに写像されたアプリケーション、テキスト/uriリスト応答SHOULDの最初の系列では、オリジナルのURIを与えるコメントになってください。 I2L要求のためのそのような結果に関する例は図1に以下に示されます。

6. Security Considerations

6. セキュリティ問題

   Communications with a server may be of a sensitive nature. Some
   servers will hold information that should only be released to
   authorized users. The results from servers may be the target of
   spoofing, especially once electronic commerce transactions are common
   and there is money to be made by directing users to pirate
   repositories rather than repositories that pay royalties to rights-
   holders. Server requests may be of interest to traffic analysts. The
   requests may also be subject to spoofing.

サーバとのコミュニケーションは敏感な本質のものであるかもしれません。 いくつかのサーバが認定ユーザに発表されるだけであるべきである情報を保持するでしょう。 サーバからの結果はスプーフィングの目標であるかもしれなく、電子商取引トランザクションがいったん特にそこで一般的になると、ロイヤリティを元通り支払う倉庫よりむしろ倉庫に海賊を働かせるようユーザに指示することによって稼がれるお金は所有者ですか? トラフィックアナリストに、サーバ要求は興味深いかもしれません。 また、要求もスプーフィングを受けることがあるかもしれません。

   The "Access denied" error message assumes a system within which the
   operation is being performed that can convey an authenticated concept
   of access control. Thus, the "Access denied" message should only be
   returned by systems that have an appropriate method of determining
   access control.

「アクセス拒否」エラーメッセージは操作が実行することにされるのであるアクセスコントロールの認証された概念を伝えることができるシステムを仮定します。 したがって、アクセスコントロールを決定する適切なメソッドを持っているシステムは「アクセス拒否」メッセージを返すだけであるべきです。

7. References

7. 参照

   [1] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
       Unifying Syntax for the Expression of Names and Addresses of
       Objects on the Network as Used in the World-Wide Web", RFC 1630,
       June 1994.

[1] バーナーズ・リー、T.、「WWWの普遍的なリソース識別子:」 「オブジェクトの名前とアドレスの式のためのWWWに使用されるネットワークの統一構文」、RFC1630(1994年6月)。

   [2] Daniel, R., and Mealling, M., "Resolution of Uniform Resource
       Identifiers using the Domain Name System", RFC 2168, February
       1997.

1997年2月の[2] ダニエル、R.と食事、M.、「ドメインネームシステムを使用するUniform Resource Identifierの解決」RFC2168。

   [3] Moats, R., "URN Syntax", RFC 2141, January 1997.

[3] モウツ、R.、「つぼの構文」、RFC2141、1997年1月。

   [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.

解放された[4]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

   [5] Sollins, K., "Architectural Principles of Uniform Resource Name
       Resolution", RFC 2276, January 1998.

[5]Sollins、1998年1月のK.、「一定のリソース名前解決の建築プリンシプルズ」RFC2276。

   [6] Kunze, J., "Functional Recommendations for Internet Resource
       Locators", RFC 1736, February 1995.

[6] クンツェ、J.、「インターネット資料ロケータのための機能的な推薦」、RFC1736、1995年2月。

   [7] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
       Locators (URL)", RFC 1738, December 1994.

[7] バーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。

Mealling & Daniel             Experimental                     [Page 14]

RFC 2483                URI Resolution Services             January 1999

[14ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

8. Authors' Addresses

8. 作者のアドレス

   Michael Mealling
   Network Solutions
   505 Huntmar Park Drive
   Herndon, VA 22070

ネットワークソリューション505Huntmar公園Driveハーンドン、ヴァージニア 22070を荒びきにするマイケル

   Phone: (703) 742-0400
   Fax:   (703) 742-9552
   EMail: michaelm@rwhois.net

以下に電話をしてください。 (703) 742-0400 Fax: (703) 742-9552 メールしてください: michaelm@rwhois.net

   Ron Daniel
   Advanced Computing Lab, MS B287
   Los Alamos National Laboratory
   Los Alamos, NM, USA, 87545

ロンダニエルは、研究室、MS B287ロスアラモス国立研究所ロスアラモス(ニューメキシコ)米国 87545を計算しながら、進みました。

   Phone: (505) 665-0597
   Fax:   (505) 665-4939
   EMail: rdaniel@lanl.gov

以下に電話をしてください。 (505) 665-0597 Fax: (505) 665-4939 メールしてください: rdaniel@lanl.gov

Mealling & Daniel             Experimental                     [Page 15]

RFC 2483                URI Resolution Services             January 1999

[15ページ]RFC2483URI解決サービス1999年1月に実験的な食事とダニエル

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Mealling & Daniel             Experimental                     [Page 16]

食事とダニエルExperimentalです。[16ページ]