[要約] RFC 2483は、URN解決に必要なURI解決サービスについての要約と目的を提供しています。このRFCの目的は、URNを解決するためのURI解決サービスの仕様を定義し、URNの一意性と持続性を確保することです。
Network Working Group M. Mealling
Request for Comments: 2483 Network Solutions, Inc.
Category: Experimental R. Daniel, Jr.
Los Alamos National Laboratory
January 1999
URI Resolution Services Necessary for URN Resolution
URN解決に必要なURI解決サービス
Status of this 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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準も規定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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つにすぎません。たとえば、元のURIのエイリアスである他の識別子のリストや、URIが示すリソースの書誌的説明を要求して取得することもできます。これは、統一リソース名（URN）と統一リソースロケーター（URL）の両方に適用されます。このドキュメントではUniform Resource Characteristic（URC）について説明しますが、識別子ではなくリソースの説明としてのみ説明します。
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つまたはいくつかを提供できますが、それらのすべてを提供する必要はありません。このメモは、特定のアクセスサービスによって提供される相互作用を説明するために使用できるこれらの操作の初期セットを指定します。また、これらの操作がプロトコルでエンコードされている場合に準拠する必要があるガイドラインも示しています。
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 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.
URN [3]に関する現在の提案[2]を策定する過程で、サーバーが必要なすべての機能を管理すること、またはクライアントがサーバーから返されたさまざまな情報を処理することを要求することは非現実的であり、採用の障害となることが明らかになりました。クライアントが、複合システムに特化したサーバーと、単純（ただし高速）に特化したサーバーを識別できるようにする方法が必要でした。また、その後の会話では、ほとんどの場合、一部の操作が特定の識別子に対して不適切または困難であることが明らかになりました。
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、またはリソース自体を提供する場合があります。 RFC 2168 [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.
このドキュメントの目的は、そのような関数とそれらの短縮名のリストを定義し、それらをアクセスサービスへのインターフェースの定義に使用することです。このドキュメントの以前のバージョンは、引数がURNや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.
これらの要件を満たすために、かなり単純な設計基準が使用されました。オペランド、アルゴリズム、およびエラーがわかっているようなトークンで操作を識別する必要性は、これらの要件を満たすのに十分であることが証明されました。
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.
このドキュメントの仕様と他のユーザーが作成する将来の作業の両方のフレームワークを提供するために、新しい操作を指定しようとするドキュメントについて、以下のガイドラインを提案します。この一連の操作のメンバーの仕様は、オペランド、アルゴリズム、出力、およびエラーに関するこれらの問題に対処する必要があります。
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.
また、このドキュメントの実験的な性質と、その仕様を使用するシステムにより、MUSTやSHALLなどの単語の使用は制限されています。使用される場所は、この仕様がHTTPやURNなどの既存の非実験的システムに害を及ぼす可能性がある場合を反映しています。したがって、このキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」ドキュメントは、RFC 2119に記載されているように解釈されます。
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
* 演算の名前*演算の大文字と小文字を区別しないニーモニック*オペランドの数*各オペランドのタイプ*各オペランドの形式
The exact algorithm for the operation must either be specified completely or it must be considered opaque and defined by the server or application.
操作の正確なアルゴリズムは完全に指定するか、不透明であると見なしてサーバーまたはアプリケーションで定義する必要があります。
Output must specify one of the following:
出力では、次のいずれかを指定する必要があります。
* 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
* 出力はありません*出力は未定義です*出力自体とその内容*出力がオブジェクトであるという事実とオブジェクトのタイプと形式*非プロトコル固有のエラー
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.
すべての実装およびアプリケーション環境に適用可能と見なされるすべてのエラーを含める必要があります。サービスを伝達するシステムに依存するエラーは含まれません。したがって、サービスの可用性や操作構文などの予想されるエラーの多くは、実装に依存するため、このドキュメントには含まれていません。
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で識別されるリソースにインターネットを介して個人情報を送信する場合については話し合いません。
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.
また、特定のシステムまたはプロトコルには、特定の操作の出力形式を制限する独自の出力仕様があります。さらに、指定されたプロトコルは、ここで指定されたものよりも出力のソリューションが優れている場合があります。たとえば、URIを複数のURLに変換する操作の結果は、ネットワーク上の各リソースの近さに関する情報を伝えるプロトコル固有の方法でエンコードできます。
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).
text / uri-list MIMEメディアタイプはセクション5で指定されています。このメディアタイプは、単純な実装を必要とする実験システムに対する提案にすぎません。これは、完全性を示すための例としてのみここに含まれています（それがどれほど単純であっても）。
* 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
* 名前：URIからURL *ニーモニック：I2L *オペランドの数：1 *各オペランドのタイプ：最初のオペランドはURIです。 *各オペランドの形式：最初のオペランドはURIとしてエンコードされます。 *アルゴリズム：不透明*出力：唯一のURL *エラー条件：o不正な形式のURI o URIは構文的には有効ですが、どの形式でも存在しません。 o URIは存在しますが、この操作から利用可能な出力はありません。 o URIは過去に存在していましたが、現時点では何も知られていません。 oアクセスが拒否されました
* 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悪意のあるリダイレクトこのようなサービスに関連する基本的な危険の1つは、リゾルバーのデータベースに悪意のあるエントリがあると、クライアントがURIを間違ったURLに解決することです。可能性のある目的は、クライアントに詐欺的または有害な素材を含むリソースを取得させることです。 oサービス拒否URIがマッピングされているURLを削除することにより、悪意のある侵入者はクライアントがリソースを取得する機能を削除する可能性があります。
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スキームに依存しています。
* 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
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)
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]仕様に従ってエンコードされます。
* 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アクセス拒否*セキュリティに関する考慮事項：o悪意のあるリダイレクト（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で指定されたリソースの単一のインスタンスを返すために使用されます。出力の形式は、リソース自体に依存します。
* 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 *ニーモニック：I2R *オペランドの数：1 *各オペランドのタイプ：最初のオペランドはURIです。 *各オペランドの形式：最初のオペランドはURIとしてエンコードされます。 *アルゴリズム：不透明*出力：URIで指定されたリソースの0個以上のインスタンス。 *エラー：o不正な形式のURI o URIは構文的には有効ですが、どのような形式でも存在しません。 o URIは存在しますが、この操作から利用可能な出力はありません。 o URIは過去に存在していましたが、現時点では何も知られていません。 oアクセス拒否*セキュリティに関する考慮事項：o悪意のあるリダイレクト（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 multipart / alternative [4]メッセージであり、リソースの代替バージョンが個別の本文部分に含まれています。 URNによって識別されるリソースのバージョンが1つしかない場合、マルチパート/代替ラッパーなしで返される場合があります。
* 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アクセス拒否*セキュリティに関する考慮事項：o悪意のあるリダイレクト（I2Lを参照）oサービス拒否（I2Lを参照）
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.
ユニフォームリソース特性は、リソースの説明です。このリクエストにより、クライアントは、リソース自体または単にリソースのURLではなく、URIで識別されるリソースの説明を取得できます。説明は、参考文献の引用、デジタル署名、または改訂履歴です。このメモは、URC要求に対する応答の内容を指定していません。その内容は、サーバーごとに異なることが予想されます。
* 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)
* 名前：URCへのURI *ニーモニック：I2CS *オペランドの数：1 *各オペランドのタイプ：最初のオペランドはURIです。 *各オペランドの形式：最初のオペランドはURIとしてエンコードされます。 *アルゴリズム：不透明*出力：0個以上のURC *エラー：o不正な形式のURI o URIは構文的には有効ですが、どの形式でも存在しません。 o URIは存在しますが、この操作から利用可能な出力はありません。 o URIは過去に存在していましたが、現時点では何も知られていません。 oアクセス拒否*セキュリティに関する考慮事項：o悪意のあるリダイレクト（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.
URCにはさまざまな形式とタイプがあります。この操作は、指定されたURIに適切な0個以上のURCを返します。
* 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.
* 名前：URNへのURI *ニーモニック：I2N *オペランドの数：1 *各オペランドのタイプ：最初のオペランドはURNです。 *各オペランドの形式：最初のオペランドはURIとしてエンコードされます。 *アルゴリズム：不透明*出力：唯一のURN *エラー：o不正な形式のURI o URIは構文的には有効ですが、どの形式でも存在しません。 o URIは存在しますが、この操作から利用可能な出力はありません。 o URIは過去に存在していましたが、現時点では何も知られていません。
o Access denied * Security Considerations: o Malicious Redirection (see I2L) o Denial of Service (see I2L)
oアクセス拒否*セキュリティに関する考慮事項：o悪意のあるリダイレクト（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.
URNは1つだけのリソースを識別することになっていますが、リソースが1つだけのURNを持つ可能性があることを意味しません。たとえば、ある組織が「foo」という名前を付けたいリソースについて考えてみましょう。別の組織は、最初の組織と合意して、リソースを「バー」と呼びたいと考えています。どちらの組織も、両方の名前「name」は同じリソースであり、URNの「foo」と「bar」は同等であることに同意できます。
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.
このサービスは、URNに関する平等の考えをもてあそぶので、このサービスには細心の注意を払う必要があります。いくつかのURNドキュメントで言及されているように、同等性の概念は非常にドメイン固有です。たとえば、特定の日の天気図を指すURNと、日ごとに変化するマップを指すURNは、異なるリソースを指すため、この例では返されません。一時的等価性のその他の概念が機能しています。代わりに、このサービスは、2つの異なる名前を持つリソースを扱います。この場合、両方の名前割り当て者によって合意された名前間にバインディングがあります。つまり、両方の名前空間は、それぞれの名前を他の名前の代わりに使用でき、意味が変わらないことに同意している必要があります。
* 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)
o Denial of Service (see I2L)
This operation simply returns zero or more URNs following the same criteria and cautions as the I2N operation.
この操作は、I2N操作と同じ基準と注意に従って、0個以上のURNを返すだけです。
4.9 I=I (Is URI equal to URI):
4.9 I = I（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 = I *オペランドの数：2 *各オペランドのタイプ：両方のオペランドはURIです。 *各オペランドの形式：両方のオペランドはURIとしてエンコードされます。 *アルゴリズム：不透明*出力：TRUEまたはFALSE *エラー：o不正な形式のURI o URIは構文的には有効ですが、どの形式でも存在しません。 o URIは存在しますが、この操作から利用可能な出力はありません。 o URIは過去に存在していましたが、現在は何も知られていません。 oアクセス拒否*セキュリティに関する考慮事項：o悪意のあるリダイレクト（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がURNまたはURLの特性を示すかどうかについては、アサーションは作成されません。
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.
I2L、I2Nなどのいくつかの解決サービス要求により、URIのリストがクライアントに返されます。 text / uri-listインターネットメディアタイプは、このようなURIリストの自動処理のための単純なフォーマットを提供するために定義されています。
This is a copy of the IANA registration of the text/uri-list Media Type.
これは、text / uri-listメディアタイプの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
Name : Ron Daniel 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-list
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.
現在、URIはUS-ASCIIを使用して表すことができます。ただし、特殊な文字セットを使用する非標準のURIは多数あります。 URIの国際化を実現する最良の方法についての議論が進行中です。この登録は、その議論が終了すると、URI文字セットの議論で更新されます。
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はこれらの制限を超える可能性があります。したがって、適切なコンテンツ転送エンコーディングを使用するようにシステムを準備する必要があります。これはまれな出来事であると予想されます。
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にアクセスすると、金銭的義務が生じたり、雇用主が不適切と見なしたリソースにアクセスしたりする可能性があります。
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-listの検索と逆検索の可能性は、トラフィックアナリストにとって魅力的です。 URIリストは、機密情報の場所などの機密情報を明らかにする場合もあります。
Because of these considerations, external confidentiality measures should be available to protect uri-list responses when appropriate.
これらの考慮事項のため、適切な場合、uri-listの応答を保護するために、外部の機密保持手段を利用できる必要があります。
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（URN）は、Uniform Resource Identifier（URI）と呼ばれるより一般的な識別子のクラスの2つのインスタンスです。 URN解決メソッドは、リソースのURLのリストを返し、フォールトトレランスとロードバランシングを実現できるようにすることがよくあります。 text / uri-list形式は、URL（およびURN）のそのようなリストを自動処理に適した形式で通信するための非常に単純な形式であることを意図しています。
The format of text/uri-list resources is:
text / uri-listリソースの形式は次のとおりです。
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（URNまたはURL）であり、URLまたはURN仕様（RFC2141、RFC1738、およびRFC2396）に従ってエンコードされます。各URIは1行だけに表示されます。非常に長いURIは、text / uri-list形式では壊れません。 content-transfer-encodingsを使用して、行の長さの制限を適用できます。
3) As for all text/* formats, lines are terminated with a CRLF pair.
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のリストにマップされているアプリケーションでは、text / uri-list応答の最初の行は、元のURIを示すコメントにする必要があります（SHOULD）。
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
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リゾルバーは最初のアプリケーションです。 Webクライアントとプロキシは、将来この形式をサポートする可能性が高いアプリケーションです。
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. マジックナンバー：現時点ではなし2.ファイル拡張子：.urisまたは.uriを推奨3. Macintoshファイルタイプコード：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. 名前：ロンダニエルジュニア2. Eメール：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.
使用目的：制限付き使用text / uri-listメディアタイプは、複製されたリソースにURIを利用するアプリケーションでの使用を目的としています。
Author/Change controller : Ron Daniel Jr. Los Alamos National Laboratory rdaniel@lanl.gov
著者/変更コントローラ：ロンダニエルジュニアロスアラモス国立研究所rdaniel@lanl.gov
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.
I2Lリクエストへの応答など、1つのURIがURIのリストにマッピングされているアプリケーションでは、text / uri-list応答の最初の行は、元のURIを示すコメントにする必要があります（SHOULD）。 I2L要求の結果の例を以下の図1に示します。
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.
「アクセスが拒否されました」というエラーメッセージは、アクセス制御の認証された概念を伝えることができる操作が実行されているシステムを想定しています。したがって、「アクセスが拒否されました」というメッセージは、アクセス制御を決定する適切な方法を持つシステムによってのみ返されるべきです。
[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] Berners-Lee、T。、「WWWのユニバーサルリソース識別子：World-Wide Webで使用されるネットワーク上のオブジェクトの名前とアドレスの表現のための統一構文」、RFC 1630、1994年6月。
[2] Daniel, R., and Mealling, M., "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, February 1997.
[2] Daniel、R.、およびMealling、M.、「ドメインネームシステムを使用したUniform Resource Identifiersの解決」、RFC 2168、1997年2月。
[3] Moats, R., "URN Syntax", RFC 2141, January 1997.
[3] Moats、R。、「URN構文」、RFC 2141、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] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[5] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[5] Sollins、K。、「Architectual Principles of Uniform Resource Name Resolution」、RFC 2276、1998年1月。
[6] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February 1995.
[6] Kunze、J。、「Internet Resource Locatorsの機能上の推奨事項」、RFC 1736、1995年2月。
[7] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[7] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070
Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon、VA 22070
Phone: (703) 742-0400 Fax: (703) 742-9552 EMail: michaelm@rwhois.net
電話：（703）742-0400ファックス：（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ファックス：（505）665-4939メール：rdaniel@lanl.gov
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。