Network Working Group N. Popp
Request for Comments: 3367 M. Mealling
Category: Standards Track VeriSign, Inc.
M. Moseley
Netword, Inc.
August 2002
Common Name Resolution Protocol (CNRP)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs. Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavailable. For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource.
人々はしばしば、共通の名前やフレーズ、例えば、商品名、会社名、または書籍のタイトルで、現実の世界で物事を参照してください。これらの名前は、URLよりも、時には人々が覚えておくために、簡単かつタイプです。また、理由のURLの限定された構文で、企業や個人がそのリソースのために最も合理的であるかもしれないものは、他の場所で使用されていることを発見し、これは使用できませんされています。このドキュメントの目的のために、「一般名は、」リソースと関連付けられてもよい課さ構文構造のない単語やフレーズが、あります。
This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is also intended to address issues of internationalization and localization. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added.
この取り組みは、ブラウザの機能拡張と検索サイトパラダイムの両方に例示するように、一般的な名前解決サービスと通信するためのクライアントアプリケーションのためのプロトコルの作成についてです。プロトコルの主な機能は、解像度ではあるが、また、国際化とローカライズの問題に対処することを意図しています。名前解決サービスは、一般的な検索サービスではありませんので、複雑なブールクエリ、関連性のランキングや同様の機能を提供する必要はありません。プロトコルは、単純な、最小限の相互運用性コアです。追加機能を追加できるように拡張するためのメカニズムが提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Important Notes . . . . . . . . . . . . . . . . . . . . . 4
2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 DTD is Definitive . . . . . . . . . . . . . . . . . . . . 4
2.3 Uniform Resource Identifiers . . . . . . . . . . . . . . . 5
3. Interaction Model . . . . . . . . . . . . . . . . . . . . 5
3.1 Services, Servers, Datasets and Referrals . . . . . . . . 5
3.2 Requests and Responses . . . . . . . . . . . . . . . . . . 5
3.3 Transport Independence . . . . . . . . . . . . . . . . . . 6
3.4 Character encoding . . . . . . . . . . . . . . . . . . . . 6
3.5 Queries . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Hints . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Object Model . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 Core properties . . . . . . . . . . . . . . . . . . . . . 8
4.1.2 Abstract and custom properties . . . . . . . . . . . . . . 9
4.1.3 Base properties . . . . . . . . . . . . . . . . . . . . . 9
4.1.4 Common name string encoding and equivalence rules . . . . 11
4.2 Objects . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Query . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1.1 Logical operations within a Query . . . . . . . . . . . . 12
4.2.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2.1 ResourceDescriptor . . . . . . . . . . . . . . . . . . . . 13
4.2.3 Service . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3.1 Datasets . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4 Status Messages . . . . . . . . . . . . . . . . . . . . . 19
4.2.4.1 Status of CNRP, Not the Transport . . . . . . . . . . . . 19
4.2.4.2 Codes and Description . . . . . . . . . . . . . . . . . . 19
4.2.4.3 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.5 Referral . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5.1 Loop Detection and Dataset Handling in Servers . . . . . . 22
4.2.6 Discoverability: ServiceQuery and Schema . . . . . . . . . 24
5. XML DTD for CNRP . . . . . . . . . . . . . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1 Service Description Request . . . . . . . . . . . . . . . 28
6.2 Sending A Query and Getting A Response . . . . . . . . . . 29
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1 HTTP Transport . . . . . . . . . . . . . . . . . . . . . . 30
7.2 SMTP Transport . . . . . . . . . . . . . . . . . . . . . . 31
8. Registration: application/cnrp+xml . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 32
References . . . . . . . . . . . . . . . . . . . . . . . . 33
A. Appendix A: Well Known Property and Type Registration
Templates . . . . . . . . . . . . . . . . . . . . . . . . 35
A.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 35
B. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 37
B.1 Level 1 (Informative) Codes . . . . . . . . . . . . . . . 37
B.2 Level 2 (Success) Codes . . . . . . . . . . . . . . . . . 38
B.3 Level 3 (Partial Success) Codes . . . . . . . . . . . . . 38
B.4 Level 4 (Transient Failure) Codes . . . . . . . . . . . . 40
B.5 Level 5 (Permanent Failures) Codes . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . . . . 42
Services are arising that offer a mapping from common names to Internet resources (e.g., as identified by a URI). These services often resolve common name categories such as company names, trade names, or common keywords. Thus, such a resolution service may operate in one or a small number of categories or domains, or may expect the client to limit the resolution scope to a limited number of categories or domains. For example, the phrase "Internet Engineering Task Force" is a common name in the "organization" category, as is "Moby Dick" in the book category.
サービスは、（URIによって識別される、例えば）それは、インターネットのリソースに共通の名前からのマッピングを提供して生じています。これらのサービスは、多くの場合、会社名、商標名、または共通のキーワードとして一般名カテゴリを解決します。したがって、そのような解決サービスは、1つまたはカテゴリまたはドメインの少数で動作することができる、またはクライアントがカテゴリまたはドメインの限られた数の解像度の範囲を限定することを期待することができます。ブックカテゴリで「白鯨」であるとして、たとえば、句「インターネットエンジニアリングタスクフォース」には、「組織」カテゴリ内の共通の名前です。
Two classes of clients of such services are being built, browser improvements and web accessible front-end services. Browser enhancements modify the "open" or "address" field of a browser so that a common name can be entered instead of a URL. Internet search sites integrate common name resolution services as a complement to search. In both cases, these may be clients of back-end resolution services. In the browser case, the browser must talk to a service that will resolve the common name. The search sites are accessed via a browser. In some cases, the search site may also be the back-end resolution service, but in others, the search site is a front-end to a collection of back-end services.
このようなサービスのクライアントの2つのクラスは、ブラウザの改善やウェブアクセスフロントエンドサービス、建設されています。一般的な名前ではなくURLを入力することができるように、ブラウザの拡張機能は、ブラウザの「オープン」または「アドレス」フィールドを変更します。インターネット検索サイトが検索を補完するものとして、共通の名前解決サービスを統合します。どちらの場合も、これらは、バックエンド解決サービスのクライアントになることがあります。ブラウザの場合、ブラウザは一般的な名前を解決するサービスに相談しなければなりません。検索サイトは、ブラウザを介してアクセスされています。いくつかのケースでは、検索サイトでは、バックエンド解決サービスであってもよいが、他に、検索サイトには、バックエンドサービスのコレクションのフロントエンドです。
This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added.
この取り組みは、ブラウザの機能拡張と検索サイトパラダイムの両方に例示するように、一般的な名前解決サービスと通信するためのクライアントアプリケーションのためのプロトコルの作成についてです。名前解決サービスは、一般的な検索サービスではありませんので、複雑なブールクエリ、関連性のランキングや同様の機能を提供する必要はありません。プロトコルは、単純な、最小限の相互運用性コアです。追加機能を追加できるように拡張するためのメカニズムが提供されます。
Several other issues, while of importance to the deployment of common name resolution services, are outside of the resolution protocol itself and are not in the initial scope of the proposed effort. These include discovery and selection of resolution service providers, administration of resolution services, name registration, name ownership, and methods for creating, identifying or insuring unique common names.
他のいくつかの問題、一般的な名前解決サービスの展開に重要で、解決プロトコル自体の外側にありながら、提案の努力の最初の範囲ではありません。これらは、発見と解決サービスプロバイダの選択、解決サービスの管理、名前登録、名前の所有権、および作成、同定またはユニークな共通の名前を保証するための方法を含みます。
For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource. These common names will be used primarily by humans, as opposed to machine agents. A common name "resolution service" handles these associations between common names and data (resources, information about resources, pointers to locations, etc.). A single common name may be associated with different data records, and more than one resolution service is expected to exist. Any common name may be used in any resolution service.
このドキュメントの目的のために、「一般名は、」リソースと関連付けられてもよい課さ構文構造のない単語やフレーズが、あります。マシン・エージェントとは対照的に、これらの一般的な名前は、人間が主に使用されます。一般名「解決サービスは、」共通の名前とデータ（資源などの資源、場所へのポインタ、の情報）との間でこれらの関連付けを処理します。単一の共通名は、異なるデータ・レコードに関連付けられてもよく、複数の解像度のサービスが存在すると予想されます。任意の一般名は、任意の解像度サービスで使用することができます。
Common names are not URIs (Uniform Resource Identifiers) in that they lack the syntactic structure imposed by URIs; furthermore, unlike URNs, there is no requirement of uniqueness or persistence of the association between a common name and a resource. (Note: common names may be expressed in a URI, the syntax for which is described in RFC 3368 [9].)
彼らはのURIによって課される構文構造が不足しているという点で共通する名前はURI（Uniform Resource Identifiers）ではありません。さらに、のURNとは異なり、共通名とリソースとの間の関連付けの一意性又は永続性の必要はありません。 （注：一般名はURIで表現することができる、RFC 3368に記載されているシンタックス[9]）。
This document will define a protocol for the parameterized resolution necessary to make common names useful. "Resolution" is defined as the retrieval of data associated (a priori) with descriptors that match the input request. "Parameterized" means the ability to have a multi-property descriptor. Descriptors are not required to provide unique identification, therefore 0 or more records may be returned to meet a specific input query.
この文書では、一般的な名前は有用なものとするために必要なパラメータ化解決のためのプロトコルを定義します。 「解像度」が入力された要求に一致する記述子に関連付けられたデータの検索（アプリオリ）として定義されます。 「パラメータは、」マルチプロパティ記述子を持っている能力を意味します。記述子は、従って、0以上のレコードが特定の入力クエリを満たすために戻すことができる、固有の識別を提供するために必要とされません。
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 [7].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[7]。
The descriptive portions of this document contain pieces of XML that are *illustrative examples only*. Section 5 of this document contains the XML DTD for CNRP, which is definitive. If any discrepancies are found, the DTD wins.
本書の記述部分のみ*の例示的な例であるXMLの部分を含みます。このドキュメントのセクション5は決定的であるCNRP、XML用のDTDが含まれています。不一致が見つかった場合、DTDは勝ちます。
All URIs used within the CNRP protocol MUST adhere to the 'absoluteURI' production found in the ABNF of [3]. CNRP does not define the semantics of a Base and therefore is not capable of expressing the 'URI-Reference' production.
CNRPプロトコル内で使用されるすべてのURI [3]のABNFに見出さ 'absoluteURIでの生産に接着しなければなりません。 CNRPは、ベースのセマンティクスを定義していない、したがって、「URIリファレンスの生産を発現することが可能ではありません。
CNRP assumes a particular interaction model where a generalized "service" provides common name resolution at one or more actual "servers". If the data contained in all its servers is identical (mirrors), the service need not identify any particular subset of data. If, however, the service provides different collections of data through different servers (e.g., subsets, specialized collections, etc.), it SHOULD indicate what subsets of its data that each server offers. This is done by using URIs to uniquely disambiguate one dataset from another. If the service offers a copy of a collection of data on agreement with a foreign service, the foreign service SHOULD provide a dataset URI to allow the collection to be identified as related to its own offerings.
CNRPは、一般的な「サービス」は、一つ以上の実際の「サーバ」で、共通の名前解決を提供し、特定の相互作用モデルを想定しています。そのすべてのサーバに含まれるデータは、（ミラー）と同一である場合、サービスは、データの任意の特定のサブセットを特定する必要はありません。しかし、サービスは（など、例えば、サブセット、専門的なコレクション）異なるサーバーを介してデータの異なるコレクションを提供している場合、それはそのデータのどのサブセット各サーバの提供ということを示す必要があります。これは、一意から別のデータセットを明確にするためのURIを使用して行われます。サービスは、外国のサービスとの契約上のデータのコレクションのコピーを提供する場合、外国人のサービスは、コレクションは、独自の製品に関連すると識別できるようにするためのデータセットのURIを提供する必要があります。
CNRP supports the concept of referrals. This is where a server can know that another Service exists, within the same Service or elsewhere, that can provide further answers to a particular query but decides to forward that fact onto the client instead of chaining the query for the client. A referral is sent along with the rest of the results from a server (if any). Referrals to a service SHOULD indicate the particular dataseturi that triggered the referral, if it is known. See Section 4.2.5 for details on referrals and loop detection.
CNRPは紹介の概念をサポートしています。サーバが別のサービスは、特定のクエリにさらに答えを提供することができます別の場所で同じサービスや、内部に存在するが、クライアントのクエリを連鎖するのではなく、クライアントにその事実を転送することを決定したことを知ることができる場所です。紹介は、サーバ（もしあれば）からの結果の残りの部分と一緒に送信されます。それがわかっている場合は、サービスへの紹介は、紹介をトリガし、特定のdataseturiを示すべきです。紹介してループ検出の詳細については、セクション4.2.5を参照してください。
The protocol consists of a simple request/response mechanism. A client sends one of a few types of requests to a server which responds with the results of that request. All requests and responses are encoded with XML [8] using the DTD found in Section 5. There are two types of requests. One is a general query for a common-name. The other is a request for an object that describes the service and its capabilities. There is only one type of response which is a set of results. Results can contain actual result items, referrals and/or status messages.
プロトコルは、簡単な要求/応答機構から成ります。クライアントは、その要求の結果を応答サーバへのリクエストの数タイプのいずれかを送信します。すべての要求と応答は要求の2種類があります[8]第5節で見つかったDTDを使用してXMLでエンコードされています。一つは、共通の名前のための一般的なクエリです。他のサービスとその機能について説明し、オブジェクトの要求です。結果の集合である応答の一種類のみがあります。結果は、実際の結果項目、紹介および/またはステータスメッセージを含めることができます。
CNRP is completely encapsulated within its XML definition, and is therefore transport-independent in its specification. However, clients need to have a clearly defined means of bootstrapping a connection with a server.
CNRPは完全にXML定義内にカプセル化され、したがって、トランスポートに依存し、その仕様になっています。ただし、クライアントがサーバーとの接続をブートストラップの明確に定義された手段を持っている必要があります。
It is possible to define special-purpose applications that use CNRP but which never need the HTTP bootstrapping method outlined below; those applications MUST define how to find the appropriate server/port/protocol. CNRP servers dedicated to those applications may provide service only on the ports/transport protocols defined by the application.
CNRPを使用していますが、HTTPブートストラップ法は以下のとおり必要はありませんこれは特殊な目的のアプリケーションを定義することが可能です。これらのアプリケーションは、適切なサーバ/ポート/プロトコルを見つける方法を定義しなければなりません。これらのアプリケーションに特化しCNRPサーバーのみ、アプリケーションによって定義されたポート/トランスポートプロトコル上でサービスを提供することができます。
All other (generic) CNRP clients and servers MUST support the HTTP (Section 7.1) transport on the default CNRP port of 1096.
他のすべての（ジェネリック）CNRPクライアントとサーバは、1096年のデフォルトCNRPポート上のHTTP（7.1節）トランスポートをサポートしなければなりません。
Note that a particular service may choose to change to a different transport or port via statements within a CNRP service description request, but with initial contacts between a client and a server being over HTTP on port 1096. For a short explanation of how CNRP employs HTTP, see Section 7.1 of this document. If other transports are used, they MUST be handled over a port other than the default CNRP port.
特定のサービスがCNRPサービス記述要求内の文を経由して異なるトランスポートまたはポートに変更することを選択することがありますが、クライアントとCNRPが採用方法の簡単な説明のためにポート1096上でHTTPを介しているサーバー間の最初の接点を持つHTTP 、このドキュメントのセクション7.1を参照してください。他のトランスポートを使用する場合は、デフォルトCNRPポート以外のポートを介して処理する必要があります。
To guarantee interoperability, the following provisions apply:
相互運用性を保証するために、以下の規定が適用されます。
o XML queries and responses MUST be encoded as UTF-8.
O XMLクエリと応答がUTF-8でエンコードする必要があります。
Note: As in any XML document, numeric character references may be used.
注意：任意のXML文書と同様に、数値文字参照を使用することができます。
o The encoding of characters in the CNRP URI is based on UTF-8; for details, please see [9].
O CNRP URIにおける文字のエンコーディングはUTF-8に基づいています。詳細については、[9]を参照してください。
Any interfaces electing to present/accept protocol elements in other representations are responsible for accurate transcoding for use in CNRP protocol elements, per the above provisions.
受け入れ/他の表現におけるプロトコル要素を提示することを選択する任意のインターフェースは、上記の規定ごとに、CNRPプロトコル要素に使用するための正確なトランスコーディングを担当しています。
Queries are sent by the client to the server. There are two types of queries.
クエリは、クライアントからサーバに送信されます。クエリの2種類があります。
1. A `special' initial query that establishes the schema for a particular CNRP database and communicates that to the client. The CNRP client will send this query, and in turn receive an XML document defining the query properties that the database supports. (In CNRP, XML [8] is used to define and express all objects.) This query is called the 'servicequery' in the DTD. In the case where a client does not know anything about the Service, the client MAY assume that it can at least issue the request via HTTP.
1.特定のCNRPデータベースのスキーマを確立し、クライアントにあることを伝える `」特別な初期のクエリ。 CNRPクライアントは、このクエリを送信し、今度はデータベースがサポートしているクエリのプロパティを定義するXML文書を受信します。 （CNRPにおいて、XML [8]は、すべてのオブジェクトを定義し、発現するために使用されている。）このクエリは、DTDの「servicequery」と呼ばれます。クライアントは、サービスについては何も知らない場合は、クライアントは、それは、少なくともHTTP経由でリクエストを発行できることを仮定してもよいです。
2. A `standard' query, which is the submission of the CNRP search string to the database. The query will conform to the schema that MAY have been previously retrieved from the service.
2.データベースへCNRP検索文字列の提出である `標準」のクエリ、。クエリは、以前のサービスから取得された可能性がスキーマに準拠します。
There will be a set of query properties, listed below, treated as hints by the server. Note: a CNRP database will accept any correctly encoded CNRP query property; the extent to which a query result is responsive to those properties is a service differentiator. The base properties that are always supported are common name, language, geography, category, and range (start and length of the result set). CNRP allows database service providers to create unique data types and expose them to any CNRP client via the CNRP schema XML documents.
サーバーによってヒントとして扱わ、下記のクエリプロパティのセット、があります。注意：CNRPデータベースは、任意の正しくエンコードCNRPクエリプロパティを受け入れます。クエリ結果は、これらのプロパティに応答する程度は、サービス差別化要因です。常にサポートされている塩基特性は一般名、言語、地理、カテゴリ、および範囲（開始し、結果セットの長さ）です。 CNRPは、データベース・サービス・プロバイダは、独自のデータ型を作成し、CNRPスキーマXML文書を経由して任意のCNRPクライアントにそれらを公開することができます。
A hint is an assertion by the user about himself, herself or itself and the context in which he/she/it is operating. There is no data type `hint'; a hint is expressed within the structure of the query itself and is limited or enabled by the richness of the defined query namespace. In effect, a query and any property within it is a hint.
ヒントは、自分自身、自分自身や自分自身と、彼/彼女は/それが動作している状況について、ユーザによって主張です。何のデータ型 `ヒントは"ありません。ヒントは、クエリ自体の構造内に発現され、定義されたクエリの名前空間の豊富さによって制限または有効になっています。実際には、クエリとその中のいずれかのプロパティがヒントです。
For example, the "language" property can be given as a hint in a query; this may be used to order search results. If one wants results first in US English followed by European French and finally South American Spanish, the following can be included in the query:
例えば、「言語」プロパティがクエリ中にヒントとして与えることができます。これは、検索結果を注文するために使用することができます。 1は米国英語で最初の結果を望んでいる場合は、欧州最後にフランスと南米のスペインに続いて、次のようにクエリに含めることができます。
<property name="language" type="rfc1766">en-US</property>
<プロパティ名= "言語" タイプ= "RFC1766"> EN-US </プロパティ>
<property name="language" type="rfc1766">fr-FR</property>
<プロパティ名= "言語" タイプ= "RFC1766"> FR-FR </プロパティ>
<property name="language" type="rfc1766">sp-MX</property>
<プロパティ名= "言語" タイプ= "RFC1766"> SP-MX </プロパティ>
Note that the property statements say nothing about whether the language is primary, secondary, etc. In this example, the ordering of the statement controls that--the first statement, being first, means that US English is the primary language. The second statement specifies the second region/language, and so on. *But this is only an example.* The extent to which hints are supported (or not) is a service differentiator.
この例ではなど、二次的、財産文は言語が主であるかどうかについては何も言わないことに注意してください、その文のコントロールの順序 - 最初の文は、最初にされ、米国英語が第一言語であることを意味します。 2番目のステートメントは、その上の第二の領域/言語を指定し、そして。 *しかし、これはあくまでも一例です。*ヒントがサポートされ（またはしない）されている程度のサービスの差別化要因です。
The fact that a hint exists does not mean that a CNRP database must respond to it. This best-effort approach is similar to relevance ranking in a search engine (high precision, low recall); hints are similar to a search engine's selection criteria. CNRP services will attempt to return the results "closest" to the selection criteria. This is quite different from a SQL database approach where a SQL query returns the entire results set and each result in the set must match all the requirements expressed by the qualifier (the SQL WHERE clause).
ヒントが存在するという事実はCNRPデータベースがそれに応答しなければならないという意味ではありません。このベストエフォート型のアプローチは、検索エンジン（高精度、低リコール）に関連ランキングに似ています。ヒントは、検索エンジンの選択基準に似ています。 CNRPサービスは、選択基準に結果「最も近い」を返そうとします。これは、SQLクエリは全体結果セットを返し、セット内の各結果は、修飾子（SQL WHERE句）で表されるすべての要件と一致している必要がありSQLデータベースアプローチとは全く異なります。
In CNRP, objects are property lists. A property is a named attribute. A property also has a well-defined type. Some properties can be part of the query or the results list or both. For simplicity, CNRP is limiting property values to string values.
CNRPでは、オブジェクトは、プロパティリストです。プロパティは、名前付き属性です。プロパティは、明確に定義されたタイプがあります。一部のプロパティは、クエリの一部または結果リストまたは両方にすることができます。簡単にするために、CNRPは、文字列値にプロパティ値を制限しています。
CNRP introduces a set of core properties. Core properties are the minimal set of properties that all CNRP services MUST support in order to reach CNRP compliance. Hence, the core properties define the level of interoperability between all CNRP services. The core properties are:
CNRPは、コアプロパティのセットを導入します。コアプロパティは、すべてのCNRPサービスがCNRPコンプライアンスを達成するためにサポートしなければならないプロパティの最小セットです。したがって、コアプロパティは、すべてのCNRPサービス間の相互運用性のレベルを定義します。コアプロパティは、次のとおりです。
2. ID: an opaque string that serves as a unique identifier for a result from a Service (typically a database ID). The ID is not globally unique, nor necessarily persistent (e.g., between queries at a given Service).
2. ID：サービス（典型的にはデータベースID）からの結果の一意の識別子として機能する不透明ストリング。 IDは、（例えば、所定のサービスにクエリとの間の）グローバルに一意な、また必ずしも永続的ではありません。
3. resourceURI: An 'absoluteURI' as defined in the collected ABNF found in RFC 2396 [3].
3. resourceURI 'absoluteURIで' 収集ABNFで定義されるようにRFC 2396に見られる[3]。
In addition to core properties, CNRP introduces the notion of abstract properties. The abstract property element provides schema extensibility beyond the core properties. The notion of abstract property is extremely important in CNRP since it enables a wider range of CNRP based services than those based on the core properties.
コア特性に加えて、CNRPは抽象的な性質の概念を導入しています。抽象プロパティ要素は、コアプロパティを超えてスキーマ拡張性を提供します。それはコアの特性に基づくものよりCNRPベースのサービスの広い範囲を可能にするので、抽象プロパティの概念はCNRPで非常に重要です。
To create concrete custom properties, a CNRP service must define a property name and a property type. Therefore, there are really two ways to create a custom property. The first way is to create a new property name and define at least one type for it. Another way is to extend an existing property by defining a new type. The "geography" property discussed in the next section is an example of a multi-type property. Note that a type is only applicable to the property it is defined for. If a new property is defined, a new type MUST be defined even though the value set for that type may be identical to an existing type for an existing property. In other words, types are scoped to a given property. Custom properties MUST be registered with IANA. Details about the registration process for new properties can be found in Section 10.
具体的なカスタムプロパティを作成するには、CNRPサービスは、プロパティ名とプロパティタイプを定義する必要があります。そのため、カスタムプロパティを作成するには2つの方法は本当にあります。最初の方法は、新しいプロパティ名を作成し、それのための少なくとも一つの型を定義することです。もう一つの方法は、新しい型を定義することによって、既存のプロパティを拡張することです。次のセクションで説明した「地理」プロパティは、多型性の一例です。タイプは、それがために定義されたプロパティにのみ適用可能であることに注意してください。新しいプロパティが定義されている場合、新しいタイプはそのタイプに設定された値は、既存のプロパティの既存の型と同一であっても定義されなければなりません。言い換えれば、種類が指定されたプロパティにスコープされています。カスタムプロパティは、IANAに登録しなければなりません。新しいプロパティのための登録プロセスの詳細については、セクション10に記載されています。
For example, let us assume that a CNRP service specialized on online books would like to introduce the ISBN property of type "number". This property would encapsulate the ISBN number of the book online and would have he following XML representation:
たとえば、私たちはオンラインブックに専門CNRPサービスは「数」タイプのISBNプロパティをご紹介したいと仮定しましょう。このプロパティは、オンラインブックのISBN番号をカプセル化するだろうし、彼はXML表現を以下のだろう。
<property name="isbn" type="number">92347231</property>
<プロパティ名= "ISBN" タイプ= "数"> 92347231 </プロパティ>
Illustrating the use of abstract property to extend the core schema, CNRP also defines a set of custom properties called base properties. In order to keep the requirements extremely simple, these properties are not mandatory to implement to reach CNRP compliance. Although, these properties are not required, it is expected that many services, especially large ones, will implement them. An equally important goal for introducing additional properties is to provide a results filtering mechanism. This is a requirement for large namespaces that contain several million names.
コアスキーマを拡張する抽象プロパティの使用を示す、CNRPは、ベースプロパティと呼ばれるカスタムプロパティのセットを定義します。非常に簡単な要件を保つために、これらのプロパティはCNRPのコンプライアンスに到達するために実装するために必須ではありません。これらの特性が要求されていない、が、多くのサービス、特に大規模なものは、それらを実装することが期待されます。追加のプロパティを導入するために等しく重要な目標は、結果のフィルタリング機構を提供することです。これは、数百万名を含む大規模な名前空間のための要件です。
The base properties and their types are defined in Appendix A but listed here for clarity:
基本プロパティとその種類は、付録Aで定義されているが、明確にするため、ここで記載されています：
o Language: The language associated with a resource. The default type of this property is 'RFC1766' and the vocabulary is drawn from the list of languages in RFC 1766 [4]. If RFC 1766 is updated, then the values listed in the updated version are also valid for this type.
O言語：リソースに関連付けられた言語。このプロパティのデフォルトのタイプは、「RFC1766」であり、語彙はRFC 1766で言語のリストから引き出されている[4]。 RFC 1766が更新されている場合は、更新されたバージョンに記載されている値は、このタイプのためにも有効です。
o Geography: The geographical region or location associated with a resource. Some of the possible types are listed below. See Appendix A for a complete list of types specified by this document.
O地理：リソースに関連付けられた地理的領域または場所。可能なタイプのいくつかを以下に示します。この文書で指定されたタイプの完全なリストについては、付録Aを参照してください。
* 'freeform': a free form expression for a geographical location (e.g., "palo alto in california").
*「フリーフォーム」：地理的位置のための遊離形態の式（例えば、「カリフォルニア州パロアルト」）。
* 'ISO3166-1': geographical region expressed using a standard country code as defined by ISO3166-1 (e.g., "US").
*「ISO3166-1」：（例えば、「US」）ISO3166-1で定義された地理的領域は、標準の国コードを使用して表現しました。
* 'ISO3166-2': value = a geographical region expressed using a standard region and country codes as defined by ISO3166-2 (e.g., "US-CA").
*「ISO3166-2」：値= ISO3166-2によって定義される地理的領域は、標準的な地域や国コードを使用して表現（例えば、「US-CA」）。
* 'lat-long': the latitude and longitude of a geographical location.
*「LAT-長い」：地理的位置の緯度と経度。
o Category: The category associated with a resource. There are large numbers of possible types for this property. Two possible ones are:
Oカテゴリ：リソースに関連付けられたカテゴリ。このプロパティの可能な種類の多数があります。二つの可能なものは以下のとおりです。
1. 'freeform': a free form expression for a category (e.g., "movies").
1.「自由形式」：カテゴリの自由形式の表現（例えば、「映画」）。
o Range: The range is a results set control property. The range property is used to specify the starting point and the length of a results set (e.g., I want 5 records starting at the 10th record). It should only ever have one type but, in the interest of extensibility and consistency, others can be created if there is a need. The default type is 'start-length' which takes the form of two integers separated by a dash. The first integer is the starting number and the second is the number of values to include.
O範囲：範囲は、結果がコントロールプロパティを設定しています。範囲プロパティを起点と（例えば、Iが10レコードから始まる5つのレコードたい）結果セットの長さを指定するために使用されます。それは今まで必要がある場合、拡張性と一貫性の利益のために、他の人が作成することができ、1種類を持っていますが、必要があります。デフォルトのタイプはダッシュで区切られた2つの整数の形をとる「長を開始」です。最初の整数は、開始番号であり、第二は、値の数が含まれることです。
o Dataseturi: An absoluteURI (as defined in [3] that identifies a defined set of Common Names and associated data.
O Dataseturi：absoluteURIで（で定義されている[3]共通の名前および関連するデータの定義済みセットを識別する。
Note: For many properties the default "type" is "freeform". The free form type value is important because it allows very simple user interface where the user can enter a value in a text field. It is up to the service to interpret the value correctly and take advantage of it to increase the relevance of results (using specialized dictionaries for instance).
注意：多くのプロパティのデフォルト「タイプは、」「自由形式」です。それは、ユーザーがテキストフィールドに値を入力することができる非常にシンプルなユーザーインターフェースを可能にするため、フリーフォーム型の値が重要です。これは、値を正しく解釈し、結果の妥当性を高めるためにそれを利用するためのサービスまで（例えば、特殊な辞書を使用して）です。
CNRP specifies that common name strings should be encoded using UTF-8. CNRP does not specify any string equivalence rules for matching a common name in the query against a common name of a Resource. String equivalence rules are language and service dependent. They are specific to relevance ranking algorithms, hence treated as CNRP services. Consequently, string equivalence rules are not part of the CNRP protocol specification. For example, the query member:
CNRPは、一般的な名前の文字列がUTF-8を使用してエンコードすることを指定します。 CNRPは、リソースの共通名に対するクエリで共通名を一致させるための任意の文字列の等価性規則を指定していません。文字列の等価性規則は、言語やサービスに依存しています。彼らは、それゆえCNRPサービスとして扱われ、ランキングアルゴリズムを、関連性の特定です。したがって、文字列等価性ルールはCNRPプロトコル仕様の一部ではありません。たとえば、クエリのメンバー：
<commonname>bmw</commonname>
<commonNameの> BMW </ commonNameの>
should be read as a selection criterion for a resource with a common name LIKE (similar to) the string "bmw" where the exact definition of the LIKE operator is intuitive, yet specific to the queried CNRP service.
共通名LIKE（と同様）のような演算子の正確な定義は直観的である文字列「BMW」、まだ照会CNRPサービスに固有のリソースのための選択基準として読まれるべきです。
It is also important to note that XML treats whitespace as a special case in many situations. In some cases, it collapses whitespace into a single space. Both client and server Implementors are warned to reference the XML standard for the various ramifications of using whitespace in queries and/or results.
多くの状況では、特殊なケースとして空白そのXMLの扱いに注意することも重要です。いくつかのケースでは、それが一つの空間に空白が崩壊します。クライアントとサーバの両方実装者は、クエリおよび/または結果に空白を使用しての様々な影響のためのXML標準を参照するように警告しています。
The Query object encapsulates all the query components such as CommonName, ID, and any properties. A Query cannot be empty. A Query must contain either one and only one common name, or one and only one ID. A Query can also contain the custom properties defined by a specific CNRP service.
クエリオブジェクトは、のCommonName、ID、および任意の特性などのすべてのクエリコンポーネントをカプセル化します。クエリは、空にすることはできません。クエリは、唯一の共通名、または、唯一のIDのいずれかが含まれている必要があります。クエリは、特定のCNRPサービスによって定義されたカスタムプロパティを含めることができます。
For example, a query for the first 5 resources whose common name is like "bmw" would be expressed as:
例えば、一般的な名前の最初の5つのリソースに対する問合せは、と表現されるだろう「BMW」のようなものです：
<query> <commonname>bmw</commonname> <property name="range" type="start-length">1-5</property> </query>
<照会> <commonNameの> BMW </ commonNameの> <プロパティ名= "範囲" タイプ= "開始長"> 1-5 </ property>の</クエリ>
The Query syntax is extremely simple. CNRP does not extensively support Boolean logic operator such as OR, AND or NOT. However, there exist two implicit logical operations that can be expressed through the Query object and its properties. First, a query with multiple property-value pairs implicitly expresses an AND operation on the query terms. For instance, the CNRP query to request all the resources whose common name is like "bmw", AND whose language is "German" can be expressed as:
クエリの構文は非常に簡単です。 CNRPは広範囲なORなどのブール論理演算子をサポートし、またはNOTはありません。しかし、クエリオブジェクトとそのプロパティを介して発現させることができる2つの暗黙的な論理動作が存在します。まず、複数のプロパティと値のペアを持つクエリは、暗黙的クエリ用語とのAND演算を表します。例えば、CNRPクエリは、その一般名「BMW」、のようなもので、その言語である「ドイツ語」として表現することができるすべてのリソースを要求します：
<query> <commonname>bmw</commonname> <property name="language" type="rfc1766"> de-DE </property> </query>
<照会> <commonNameの> BMW </ commonNameの> <プロパティ名= "言語" タイプ= "RFC1766">デDE </ property>の</クエリ>
Note however, that because the server is only trying to best match the Query criteria, there is no guarantee that all or any of the resources in the results match both requirements.
サーバは、最高のクエリ条件に一致するようにしようとしているので、結果内のリソースのすべてまたはいずれかが両方の要件を満たす保証がないこと、しかし、注意してください。
In addition, CNRP allows the client to express a logical OR by specifying multiple values for the same property within the Query. For example, the logical expression:
また、CNRPは、クライアントは、論理ORクエリ内の同じプロパティに複数の値を指定することによって表現することを可能にします。例えば、論理式：
property = value1 OR property = value2 OR property = valueN
プロパティ=値1 ORプロパティ=値2またはプロパティ=値
Will be expressed as:
以下のように表現されます。
<property>value1</property> <property>value2</property> <property>valueN</property>
<プロパティ>をvalue1 </ property>の<プロパティ>値2 </ property>の<プロパティ>値N </プロパティ>
So if there are different properties expressed, CNRP ANDs them; if there are multiples instances of the same property expressed, CNRP ORs them.
だから、CNRP論理積彼らは、異なる特性が発現がある場合。倍数がある場合は、同じプロパティのインスタンスは、CNRP論理和それらを表明しました。
It is important to underline that this form is only applicable to properties (with the exception of the CommonName itself which, even though it is a property, is the entire point of the query). In particular, logical OR operations on the common name are not supported. Note that the ordering or the property-value pairs in the query implies a precedence. As a consequence, CNRP also introduces one special string value: "*". Not surprisingly, "*" means all admissible values for the typed property. For example, the following query requests all the resources whose common name is like BMW and whose language is preferably in German or French or any other language.
なお、この形態は、（それがプロパティであっても、クエリの全体のポイントである、のCommonName自体を除く）の特性にのみ適用可能であることを強調することが重要です。具体的には、一般的な名前の論理OR演算がサポートされていません。クエリ内の秩序またはプロパティと値のペアが優先することを意味することに注意してください。その結果、CNRPも1つの特殊な文字列値が導入されています。「*」。驚くことではないが、「*」と入力プロパティのすべての許容値を意味します。たとえば、次のクエリは、その共通の名前BMWのようなもので、その言語ドイツ語やフランス語や他の言語であることが好ましく、すべてのリソースを要求します。
<query> <commonname>bmw</commonname> <property name="language" type="rfc1766">de-DE</property> <property name="language" type="rfc1766">fr-FR</property> <property name="language" type="rfc1766">*</property> </query>
<問い合わせ> <commonNameの> BMW </ commonNameの> <プロパティ名= "言語" タイプ= "RFC1766">デ-DE </プロパティ> <プロパティ名= "言語" タイプ= "RFC1766"> FR-FR </プロパティ> <プロパティ名= "言語" タイプ= "RFC1766"> * </ property>の</クエリ>
The results object is a container for CNRP results. The type of objects contained in Results can be: ResourceDescriptor, Error, Referral and Schema. Results from a CNRP service are ordered by decreasing relevance. When the results set contains results from multiple CNRP services, the results can no longer be ordered (since relevance ranking is specific to a given service). In that case, however, note that results originating from the same service remain ordered.
結果オブジェクトはCNRP結果の容器です。結果に含まれるオブジェクトの種類が指定できますResourceDescriptor、エラー、紹介およびスキーマ。 CNRPサービスからの結果は、関連性を減少させることによって順序付けされます。結果セットは、複数のCNRPサービスからの結果が含まれている場合（関連ランキングが特定のサービスに固有であるため）、結果はもはや発注することはできません。その場合には、しかし、同じサービスから発信結果が命じたままであることに注意してください。
The ResourceDescriptor object describes an Internet resource (e.g., a Web page, a person, any object identified by a URI). Therefore, the ResourceDescriptor MUST always include the resourceURI property. The ResourceDescriptor can also contain the commonname, URI, ID (the ID of this entry in the service's database), description, language, geography, and category of the resource. A ResourceDescriptor can also be augmented using custom properties and can reference a service object to indicate its origin (using the serviceRef element). As with referrals, a resourcedescriptor block can also contain an ID attribute that is used by a status message to refer to a particular resourcedescriptor. Be careful not to confuse this ID with the id tag itself which refers to the database id of the actual database entry.
ResourceDescriptorオブジェクトは、インターネットリソース（例えば、Webページ、人、URIで識別される任意のオブジェクト）について説明します。したがって、ResourceDescriptorは常にresourceURIプロパティを含まなければなりません。 ResourceDescriptorもあるcommonName、URI、ID（サービスのデータベースにこのエントリのID）、説明、言語、地理、およびリソースのカテゴリを含めることができます。 ResourceDescriptorは、カスタムプロパティを使用して拡張することができ、（serviceRef要素を使用して）その起源を示すためにサービスオブジェクトを参照することができます。照会と同様に、resourcedescriptorブロックは、特定のresourcedescriptorを参照するために、ステータス・メッセージによって使用されるID属性を含むことができます。実際のデータベースエントリのデータベースIDを参照するIDタグ自体にこのIDを混同しないように注意してください。
<results> <service id="i0"> <serviceuri>http://cnrp.bar.com/</serviceuri> </service> <resourcedescriptor id="i1"> <commonname>bmw</commonname> <id>foo.com:234364</id> <resourceuri>http://www.bmw.de/</resourceuri> <serviceref ref="i0" /> <description>BMW Motorcycles, International</description> <property name="language" type="rfc1766">de-DE</property> </resourcedescriptor> <referral> <serviceref ref="i0" /> </referral> </results>
<結果> <サービスID = "I0"> <serviceURIは> http://cnrp.bar.com/ </ serviceURIは> </サービス> <resourcedescriptorのID = "I1"> <commonNameの> BMW </ commonNameの> <ID > foo.com:234364 </ ID> <resourceuri> http://www.bmw.de/ </ resourceuri> <serviceref REF = "I0" /> <説明> BMWモーターサイクル、国際</記述> <プロパティ名= "言語" タイプ= "RFC1766">デDE </ property>の</ resourcedescriptor> <照会> <serviceref REF = "I 0" /> </照会> </結果>
The Service object provides an encapsulation of an instance of a CNRP service. A service is uniquely identified through the serviceuri tag which MUST be included in the Service object. A Service object MAY include a a brief textual description of the service. It MAY include datasets, servers and custom properties.
Serviceオブジェクトは、CNRPサービスのインスタンスのカプセル化を提供します。サービスは、一意のサービスオブジェクトに含まれなければならないserviceURIはタグによって識別されます。サービスオブジェクトは、サービスの簡潔なテキスト記述を含むことができます。これは、データセット、サーバーやカスタムプロパティを含むかもしれません。
<service> <serviceuri>http://cnrp.foo.com</serviceuri> <description>foo.com is a CNRP service specialized on cocktail recipes</description> </service>
<サービス> <serviceURIは> http://cnrp.foo.com </ serviceURIは> <説明> foo.com CNRPサービスは、</記述> </サービス>カクテルのレシピに特化しています
The service object MAY also be extended by including existing properties to further describe the service. For instance, a service that focuses on French companies could be expressed as:
サービスオブジェクトはまた、サービスを記述するために既存のプロパティを含めることによって延長することができます。例えば、フランスの企業に焦点を当てたサービスは次のように表すことができます。
<service> <serviceuri>http://cnrp.foo.com</serviceuri> <property name="category" type="freeform">companies</property> <property name="geography" type="ISO3166-1">FR</property> </service>
<サービス> <serviceURIは> http://cnrp.foo.com </ serviceURIは> <プロパティ名= "カテゴリ" タイプ= "自由形式">企業</プロパティ> <プロパティ名= "地理" タイプ= "ISO3166-1 「> FR </ property>の</サービス>
The dataset object represents a set of CN-to-URI mappings. For example, the database of AOL keywords and their URIs constitute a dataset. The dataset object allows a CNRP implementation to uniquely identify the database(s) of mappings that it resolves. In that respect, the notion of dataset allows a separation between resolution and data, providing the mechanism for a CNRP service to resolve common-names on behalf of another CNRP service or even multiple services. Conversely, the same dataset can be served by two distinct CNRP services. Since a CNRP service can resolve names within one or more datasets, the service object can contain one or more dataset objects (zero if the dataset is not formally declared).
DataSetオブジェクトは、CN-に-URIマッピングのセットを表しています。たとえば、AOLのキーワードとそのURIのデータベースは、データセットを構成します。 DataSetオブジェクトは、一意には解決マッピングのデータベース（複数可）を識別するためにCNRP実装を可能にします。その点では、データセットの概念は、他のCNRPサービスや複数のサービスの代わりに、共通の名前を解決するCNRPサービスのためのメカニズムを提供し、解像度とデータ間の分離を可能にします。逆に、同じデータセットは、2つの異なるCNRPサービスによって提供することができます。 CNRPサービスは、1つのまたは複数のデータセット内の名前を解決することができるので（データセットが正式に宣言されていない場合はゼロ）、サービスオブジェクトは、1つのまたは複数のデータセットオブジェクトを含めることができます。
Within the service object, a dataset is uniquely defined using the dataseturi property. Other properties, such as language and description, can describe the dataset further. Like the service object, the dataset object has an ID attribute associated with it that is unique within a particular XML message. Like the service object's ID attribute, this ID is used by resourcedescriptors and referrals to specify which service and/or dataset they came from or are referring to.
サービス・オブジェクト内に、データセットは、一意dataseturiプロパティを使用して定義されます。そのような言語や説明などの他の特性は、さらにデータセットを記述することができます。サービスオブジェクトと同様に、データセットオブジェクトは、特定のXMLメッセージ内で一意であることに関連したID属性を持っています。サービスオブジェクトのID属性と同様に、このIDはどこから来たサービスおよび/またはデータセットを指定するresourcedescriptorsや紹介で使用されているかを参照しています。
Any service can be said to have a 'default dataset' which is the dataset that considered to have been used if a server simply responds to a client's query that didn't contain a dataset. The 'default dataset' can also be said to be the only dataset that is used by Services that don't support datasets at all. This concept is useful for clients that intend on doing rigorous loop detection by way of keeping a list of visited service/dataset nodes.
いずれのサービスは、サーバは、単にデータセットが含まれていなかったクライアントのクエリに応答した場合に使用されたと考えられたデータセットである「既定のデータセット」を持っていると言うことができます。 「既定のデータセット」は、すべてのデータセットをサポートしていないサービスでのみ使用されたデータセットであると言うことができます。この概念は、訪問サービス/データセットのノードのリストを維持する方法により、厳格なループ検出を行う上で予定のクライアントのために有用です。
This example illustrates how the service object would look as it defines two datasets:
この例では、2つのデータセットを定義するように、サービスオブジェクトがどのように見えるかを示しています。
<service id="i0"> <serviceuri>http://acmecorp.com</serviceuri> <dataset id="i1"> <property name="dataseturi"> urn:oid:1.2.3.4.666.5.4.3.1 </property> <property name="language">en-us</property> <property name="language">en-gb</property> </dataset> <dataset id="i2"> <property name="dataseturi"> urn:oid:1.2.3.4.666.10.9.8.7.6 </property> <property name="language">fr</property> </dataset> </service>
<サービスID = "I0"> <serviceURIは> http://acmecorp.com </ serviceURIは> <データセットのid = "I1"> <プロパティ名= "dataseturi"> URN：OID：1.2.3.4.666.5.4.3。 1 </プロパティ> <プロパティ名= "言語"> EN-US </プロパティ> <プロパティ名= "言語">エンギガバイト</ property>の</セット> <データセットのid = "I2"> <プロパティ名= "dataseturi"> URN：OID：= "言語"> FR </ property>の</セット> </サービス1.2.3.4.666.10.9.8.7.6 </プロパティ> <プロパティ名>
The dataseturi property can also be used within the query as a hint to the service for the dataset within which the commonname should be resolved:
dataseturiプロパティは、commonNameのが解決すべき範囲内のデータセットのためのサービスへのヒントとしてクエリ内で使用することができます。
<query> <commonname>toys r us</commonname> <property name="dataseturi">urn:oid:1.2.3.4.666.5.4.3.1</property> </query>
<問い合わせ> <commonNameの>おもちゃたちをrを</ commonNameの> <プロパティ名= "dataseturi"> URN：OID：1.2.3.4.666.5.4.3.1 </ property>の</クエリ>
It is important to note that resolution rules (i.e., string equivalence, relevance ranking, etc.) are likely to be dataset specific. This is true even if the resolution is provided by the same service.
それは、その解決のルールを注意することが重要である（つまり、文字列の等価性、関連性のランキング、等）は、データセットの特定である可能性が高いです。これは、解像度が同じサービスによって提供された場合も同様です。
Another use of the dataseturi property is in a referral. In that case, the datasetref tag is used to pinpoint a specific dataset within the service.
dataseturiプロパティの別の用途は紹介しています。その場合、datasetrefタグは、サービス内の特定のデータセットを特定するために使用されます。
<referral> <serviceref ref="i0" /><datasetref ref="i1" /> </referral>
<紹介> <serviceref REF = "I0" /> <datasetref REF = "I1" /> </紹介>
While the concept of datasets is important for services wishing to make their data available via other services, it is important to remember that the declaration and use of datasets is completely optional. Compliance with the CNRP protocol does not require a service object to define or reference any dataset object. The only requirement for compliance is that a client and/or server know the format of the particular XML tags and deal with them syntactically. If it chooses to ignore them, then this is well within its rights.
データセットの概念は、他のサービスを経由して、そのデータを利用できるようにしたいサービスのために重要であるが、データセットの宣言と使用は完全に任意であることを覚えておくことが重要です。 CNRPプロトコルの遵守は、任意のDataSetオブジェクトを定義または参照するサービスオブジェクトを必要としません。コンプライアンスのための唯一の要件は、クライアントおよび/またはサーバが特定のXMLタグの形式を知っているし、構文的にそれらを扱うことです。それはそれらを無視することを選択した場合、これはその権利の範囲内です。
The service object also encapsulates a list of server objects. The server object is used to describe a CNRP server or set of servers. A server is identified through its serveruri. The URI used to identify a server is not a CNRP URI [9], but instead, is a URI of the scheme used as the CNRP transport mechanism. I.e., for a CNRP server that will communicate via the HTTP protocol to the host foo.com on port 6543, the serveruri would be http://foo.com:6543. If some other information is required in order for the correct transport to be used, then that information can be communicated via other properties. Note that a Service MUST have at least one Server that responds on the default CNRP port in order for a client to get the initial Service object.
サービスオブジェクトは、サーバオブジェクトのリストをカプセル化します。サーバーオブジェクトはCNRPサーバまたはサーバのセットを記述するために使用されます。サーバーは、そのserveruriによって識別されます。 URI [9] CNRP URIでないサーバを識別するために使用されるが、代わりに、CNRP搬送機構として使用されるスキームのURIです。すなわち、ポート6543上のホストfoo.comにHTTPプロトコルを介して通信するCNRPサーバのために、serveruriはhttp://foo.com:6543だろう。いくつかの他の情報を使用する正しい輸送のために必要とされる場合、その情報は、他のプロパティを介して通信することができます。サービスは、初期サービスオブジェクトを取得するためのクライアントのためのために、デフォルトCNRPポートに応答し、少なくとも一つのサーバを持たなければならないことに注意してください。
A server can serve one or more datasets declared by its service. The served databases are specified using the dataseturi property. As for other objects, a server can be further described using descriptive properties such as geography and description. The following XML completes the service definition from the previous example by defining two CNRP servers. One server is located in the US and the other is located in France. The US server is specialized and only serves the French dataset.
サーバは、そのサービスによって宣言された一個の以上のデータセットを提供することができます。提供するデータベースはdataseturiプロパティを使用して指定されています。他のオブジェクトのように、サーバは、さらに、地理や説明などの記述プロパティを使用して記述することができます。次のXMLは、2台のCNRPサーバを定義することによって、前の例から、サービス定義を完了します。 1台のサーバが米国に位置しており、他方はフランスに位置しています。米国のサーバーは、専門であり、唯一のフランス語のデータセットを提供しています。
<servers> <server> <serveruri>cnrp://router.us.widgetco.com:4321</serveruri> <property name="geography" type="ISO3166-1">US</property> </server> <server> <serveruri>cnrp://router.fr.acmeco.com:4321</serveruri> <property name="geography" type="ISO3166-1">FR</property> </server> </servers>
<サーバー> <サーバー> <serveruri> CNRP：//router.us.widgetco.com：4321 </ serveruri> <プロパティ名= "地理" タイプ= "ISO3166-1">米国</ property>の</サーバー> <サーバー> <serveruri> CNRP：//router.fr.acmeco.com：4321 </ serveruri> <プロパティ名= "地理" タイプ= "ISO3166-1"> FR </ property>の</サーバー> </サーバ>
As we will see in a following section, the Service object can contain Schema objects. These Schema objects fully describe the query and response interfaces implemented by a CNRP service. In that regard, the Service object is essential to discoverability. It constitutes the main entry point for a CNRP client to dynamically discover the capabilities of a resolution service. For that purpose, the Service object can be returned as part of the response to any resolution query. Furthermore, the Service object is the dedicated response to the specialized servicequery (see Section 4.2.6).
我々は次のセクションに表示されるように、サービスオブジェクトは、スキーマ・オブジェクトを含めることができます。これらのスキーマ・オブジェクトは、完全CNRPサービスによって実装クエリ及び応答インタフェースを記述する。その点では、サービスオブジェクトが発見可能に不可欠です。これは、動的に解決サービスの能力を発見するCNRPクライアントのメインエントリポイントを構成しています。そのために、サービスオブジェクトは、任意の解像度のクエリに対する応答の一部として返されます。さらに、サービスオブジェクトは、専門servicequery（4.2.6項を参照）に、専用の応答です。
Another use of Service is for other objects to indicate their CNRP service of origin. System messages, referrals and resourcedescriptors can include a reference to their Service object. For example, imagine a CNRP service that acts as a proxy for multiple CNRP services. For example, it is a requirement that CNRP allows aggregation of results from different sources. Consider one such CNRP service that acts as a proxy for multiple CNRP services. In this mode, the proxy service contacts each CNRP sub-service in parallel or serially. Then, the proxy combines the individual result sets into a unique response returned to the CNRP client. Since the aggregate result set contains resourcedescriptors from different services, the proxy adds a servicereference tag within each individual result to indicate their service of origin. In the event one of the referred services resolves names within multiple datasets, it is possible for these objects to refer to a specific dataset within the service by using the datasetref tag. This example is of a hybrid result set with resourcedescriptors referencing their service and dataset of origin:
サービスの別の用途は、起源の彼らのCNRPサービスを示すために、他のオブジェクトのためです。システムメッセージ、紹介とresourcedescriptorsは、そのサービスオブジェクトへの参照を含めることができます。例えば、複数のCNRPサービスのプロキシとして機能CNRPサービスを想像してみてください。例えば、CNRPが異なるソースからの結果の集約を可能にする要件です。複数CNRPサービスのプロキシとして動作するそのようなCNRPサービスを考えてみましょう。このモードでは、プロキシサービスコンタクト直列、並列または各CNRPサブサービス。次に、プロキシはCNRPクライアントに返すユニークな応答に個別の結果セットを組み合わせたものです。集計結果セットは異なるサービスからresourcedescriptorsを含んでいるので、プロキシは、起源の彼らのサービスを示すために、個々の結果内servicereferenceタグを追加します。イベントに呼ばれるサービスの一つは、これらのオブジェクトがdatasetrefタグを使用して、サービス内の特定のデータセットを参照することが可能であり、複数のデータセット内の名前を解決します。この例では、彼らのサービスと原点のデータセットを参照するresourcedescriptorsで設定したハイブリッドの結果は次のとおりです。
<?xml version="1.0"?> <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <cnrp> <results> <service id="i0"> <serviceuri>http://acmecorp.com</serviceuri> <dataset id="i1"> <property name="dataseturi"> urn:oid:1.2.3.4.666.5.4.3.1 </property> </dataset> <dataset id="i2"> <property name="dataseturi"> urn:oid:1.2.3.4.666.10.9.8.7.6 </property> </dataset> </service> <service id="i3"> <serviceuri>http://serverfarm.acmecorp.com</serviceuri> </service> <service id="i4"> <serviceuri>http://servers.acmecorp.co.uk</serviceuri> <dataset id="i5"> <property name="dataseturi"> urn:oid:1.2.3.4.666.5.4.3.1 </property> </dataset> </service> <resourcedescriptor> <commonname>Fidonet</commonname> <id>1333459455</id> <resourceuri>http://www.fidonet.ca</resourceuri> <serviceref ref="i0" /><datasetref ref="i1" /> <description>This is ye olde Canadian Fidonet</description> </resourcedescriptor> <resourcedescriptor> <commonname>Fidonet</commonname> <id>1333459455</id> <resourceuri>http://host:port/bla</resourceuri> <serviceref ref="i3" /> <description>An old Fidonet node</description> </resourcedescriptor> <referral> <serviceref ref="i0" /><datasetref ref="i2" /> </referral> </results>
<？xml version = "1.0"？> <PUBLIC CNRP DOCTYPE！ " - // IETF // DTD CNRP 1.0 // EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <CNRP> <結果> <サービスID = "I0"> <serviceURIは> http://acmecorp.com </ serviceURIは> <データセットID = "I1"> <プロパティ名= "dataseturi"> URN：OID：1.2.3.4.666.5 .4.3.1 </ property>の</セット> <セットID = "I2"> <プロパティ名= "dataseturi"> URN：OID：1.2.3.4.666.10.9.8.7.6 </ property>の</セット> < /サービス> <サービスID = "I3"> <serviceURIは> http://serverfarm.acmecorp.com </ serviceURIは> </サービス> <サービスID = "I4"> <serviceURIは>のhttp：//servers.acmecorp。 co.uk </ serviceURIは> <データセットのid = "i5の"> <プロパティ名= "dataseturi"> URN：OID：1.2.3.4.666.5.4.3.1 </ property>の</セット> </サービス> <resourcedescriptor > <commonNameの> FidoNetの</ commonNameの> <ID> 1333459455 </ ID> <resourceuri> http://www.fidonet.ca </ resourceuri> <serviceref REF = "I 0" /> <datasetref REF = "I1" / > <>これはイェオールドカナダFidoNetの</記述> </ resourcedescriptor> <resourcedescriptor> <commonNameの> FidoNetの</ commonNameの> <ID> 1333459455 </ ID> <リソース記述でありますURI>のhttp：//ホスト：ポート/ BLA </ resourceuri> <serviceref REF = "I3" /> <説明>古いFidoNetのノード</記述> </ resourcedescriptor> <紹介> <serviceref REF = "I0" / > <datasetref REF = "I2" /> </紹介> </結果>
</cnrp>
</ CNRP>
The status messages defined here are only applicable to operations defined by CNRP itself. If some feature or operation is defined by the transport (security via HTTP, mail failure via SMTP, etc.), then any status messages about that operation MUST be sent in accordance with that transport's reporting mechanism and not via CNRP.
ここで定義されたステータスメッセージがCNRP自体によって定義された操作にのみ適用されます。いくつかの機能や操作が（HTTP、SMTP経由でメールの失敗などを介したセキュリティ）輸送によって定義されている場合は、その操作についてのステータスメッセージは、そのトランスポートの報告メカニズムに従ってなくCNRPを経由して送らなければなりません。
A Status object indicates a message to the client in the results set. The object encapsulates two values: a status code and a description. The description can contain a textual description of the status being communicated. In many cases, additional diagnostic information can also be included. No attempt is made to standardize the description of a given status code since the only programmatic element that matters is the actual code.
Statusオブジェクトは、結果セット内のクライアントにメッセージを示します。ステータスコードと説明：オブジェクトが2つの値をカプセル化します。説明が通信中の状態のテキスト記述を含めることができます。多くの場合、追加の診断情報を含めることもできます。試みは重要のみプログラム要素が実際のコードであるので、所与の状況コードの記述を標準化するために行われません。
A status message can also specify which other CNRP element it refers to by including a reference to the ID of the element in question. For example, if a Service block has an ID of "i2" and a status message refers to that block, then it can put that ID in its ref attribute.
ステータスメッセージはまた、当該要素のIDへの参照を含めることによって、を意味する他のCNRP要素を指定することができます。サービス・ブロックが「I2」のIDを持っており、ステータスメッセージはそのブロックを参照する場合たとえば、それはその参照属性にそのIDを置くことができます。
<status code="x.y.z" ref="i2">
The CNRP foo.com database is temporarily unreachable
</status>
The organization of status codes is taken from RFC 1893 [10] which structures its codes in the form of x.yyy.zzz. Taken from RFC 1893 is the ABNF for the codes:
ステータスコードの組織はどのx.yyy.zzzの形態における構造のコードをRFC 1893 [10]から取られます。 RFC 1893から取られたコードのためのABNFは、次のとおりです。
status-code = class "." subject "." detail
class = "2"/"3"/"4"/"5"
subject = 1*3digit
detail = 1*3digit
The top level codes denote levels of severity of the status:
トップレベルのコードは、状況の重大度のレベルを示します。
o 1.X.X Informational
O 1.X.X情報
* The information conveyed by the code has no bearing or indication of the success or failure of any request. It is strictly for informational purposes only.
*コードによって伝達される情報には、軸受又は任意の要求の成功または失敗の表示を有していません。これは、情報提供のみを目的とし、厳密です。
o 2.X.X Success
O 2.X.X成功
* The request was processed and results were returned. In most cases, this status class won't be sent since actual results themselves denote success. In other cases, results were returned but some information needs to be returned to the client.
*リクエストが処理されたとの結果が返されました。ほとんどの場合、このステータスクラス自体は成功を表す実際の結果以降に送信されることはありません。他の例では、結果が返されますが、いくつかの情報がクライアントに返される必要があるました。
o 3.X.X Partial Success
O 3.X.X部分的な成功
* The request was processed and results were returned. In this case though, some values sent with the request were either invalid or ignored but in a way that the server still considers the response to be a successful one and not indicative of any true error condition.
*リクエストが処理されたとの結果が返されました。この場合は、しかし、要求で送られたいくつかの値が無効であるか、無視されますが、サーバーがまだ成功したものと任意の真のエラー状態を示していないことを応答を考慮することのようにいずれかでした。
o 4.X.X Transient Failure
O 4.X.X一時障害
* The request was valid as sent, but some temporary event prevents the successful completion of the request and/or sending of the results. Sending in the future may be possible.
*送信されたよう要求が有効であったが、いくつかの一時的なイベントは、要求および/または結果の送信が正常に完了したことを防ぎます。将来的に送ることは可能かもしれません。
o 5.X.X Permanent Failure
O 5.X.X永続的なエラー
* A permanent failure is one which is not likely to be resolved by re-sending the request in its current form. Some change to the request or the destination must be made for successful request.
*永続的な障害が現在の形で要求を再送信することにより解決される可能性が低いものです。要求または宛先へのいくつかの変更が成功した要求のために作られなければなりません。
The second level codes denote the subject of the status messages. This value applies to each of the five classifications. The subject sub-code, if recognized, must be reported even if the additional detail provided by the detail sub-code is not recognized. The enumerated values for the subject sub-code are: o X.0.X Other or Undefined Status
第二のレベルのコードは、ステータスメッセージの件名を示します。この値は、5つの分類のそれぞれに適用されます。主題のサブコードは、認識された場合、詳細サブコードによって提供される追加の詳細が認識されない場合でも、報告されなければなりません。主題のサブコードの列挙された値は、次のとおりX.0.Xその他または未定義のステータスoを
* No specific information is available about what subject class this message belongs to.
*具体的な情報は、このメッセージが属するものを対象クラスについて利用可能ではありません。
o X.1.X Query Related
O X.1.Xクエリ関連
* Any status related to some specific way in which the query was encoded or its values with the exception of properties.
*クエリが符号化又は特性を除いて、その値がされたいくつかの特定の方法に関連する任意の状態。
o X.2.X Service Related
O X.2.Xサービス関連
* Any status related to the service in which this server is cooperating in providing.
*このサーバが提供に協力しているサービスに関連する任意の状態。
Appendix B contains a list of all predefined status codes
付録Bは、すべての定義済みのステータスコードのリストが含まれています
A Referral object in the results set is a place holder for un-fetched results from a different service and possibly dataset. Referrals typically occur when a CNRP server knows of another service capable of providing relevant results for the query and wants to notify the client about this possibility. The client can decide whether it wants to follow the referral and resolve the extra results by contacting the referred-to service using the information contained within the Referral object (a Service object and possible properties). The Referral is a simple mechanism to enable hierarchical resolution as well as to join multiple resolution services together.
結果セット内の紹介の目的は、異なるサービスおよびおそらくデータセットから未フェッチ結果のプレースホルダーです。 CNRPサーバーがクエリに関連する結果を提供することが可能な他のサービスを知っていると、この可能性についてクライアントに通知したいときに紹介は、一般的に起こります。クライアントは、紹介に続き、紹介対象（サービスオブジェクトと可能なプロパティ）内に含まれる情報を使用して呼ば-にサービスを接触させることにより、余分な結果を解決するために望んでいるかどうかを決定することができます。紹介は、階層的な解決を有効にするだけでなく、一緒に複数の解決サービスに参加するシンプルな仕組みです。
<results> <service id="i0"> <serviceuri>http://cnrp.bar.com/</serviceuri> <dataset id="i1"> <property name="dataseturi"> urn:oid:1.3.6.1.4.1.782.1 </property> </dataset> <dataset id="i2"> <property name="dataseturi"> urn:oid:1.3.6.1.4.1.782.2 </property> </dataset> </service> <resourcedescriptor> <commonname>bmw</commonname> <id>foo.com:234364</id> <resourceuri>http://www.bmw.de/</resourceuri> <serviceref ref="i0" /><datasetref ref="i1" /> <description>BMW Motorcycles, International</description> <property name="language" type="iso646">de-DE</property> </resourcedescriptor> <referral> <serviceref ref="i0" /><datasetref ref="i2" /> </referral> </results>
<結果> <サービスID = "I0"> <serviceURIは> http://cnrp.bar.com/ </ serviceURIは> <データセットのid = "I1"> <プロパティ名= "dataseturi"> URN：OID：1.3。 6.1.4.1.782.1 </ property>の</セット> <セットID = "I2"> <プロパティ名= "dataseturi"> URN：OID：1.3.6.1.4.1.782.2 </ property>の</セット> </サービス> <resourcedescriptor> <commonNameの> BMW </ commonNameの> <ID> foo.com:234364 </ ID> <resourceuri> http://www.bmw.de/ </ resourceuri> <serviceref REF = "I 0" / > <datasetref REF = "I1" /> <説明> BMWモーターサイクル、国際</ = "ISO646" の記述> <プロパティ名= "言語" タイプ>デ-DE </ property>の</ resourcedescriptor> <紹介> <serviceref REF = "I0" /> <datasetref REF = "I2" /> </紹介> </結果>
Like other CNRP objects, a referral can be further described using custom properties. Like a resourcedescriptor, a referral can have an ID attribute that is used by a status message to talk about a particular referral block.
他のCNRPオブジェクトと同様に、紹介はさらにカスタムプロパティを使用して記述することができます。 resourcedescriptorと同様に、紹介は、特定の照会ブロックについて話をするステータスメッセージで使用されているID属性を持つことができます。
Referrals in CNRP can be handled in three ways:
CNRPでの紹介は、以下の3つの方法で処理することができます。
o application specific,
アプリケーションが特定のO、
o as hints only,
Oのみのヒントとして、
o rigorous loop detection.
厳格なループ検出O。
In the first two cases, the behavior of the client, when it receives a referral, is not defined in this memo. The client can chase the referral in such a way as to treat it as a hint only. In this case, datasets may or may not be handled. Loop detection can be nothing more than, "Have I talked to this hostname before?" or "Stop after the 3rd referral". These two cases are most likely to apply to simple or constrained implementations where the clients and servers have some a priori knowledge of their capabilities. Without such knowledge there is too much ambiguity vis-a-vis services and datasets for clients to do reliable loop detection.
最初の2例では、クライアントの動作が、それは紹介を受けたとき、このメモで定義されていません。クライアントはヒントとして扱いするような方法で紹介を追いかけることができます。この場合、データセットは、または取り扱うことがあってもなくてもよいです。ループ検出は、以上のものになることはできません「私は前にこのホスト名に話を聞いたことがありますか？」または「第三の紹介の後に停止します」。これらの2つのケースは、クライアントとサーバは、その機能のいくつかの予備知識を持っている単純または制約の実装に適用する可能性が最も高いです。そのような知識がないとあまりにもあいまいさが向かい合っ信頼性の高いループ検出を行うためのクライアントのためのサービスおよびデータセット。
The last case is where the client expects to talk to multiple servers that may know nothing about each other. This case expresses the basic semantics of what a server should tell a client if it understands datasets or referrals. Since a referral specifies the exact dataset to which it is referring, a node in the list of visited nodes is made up of a serviceuri and a dataseturi. Both of these values need to be considered during loop detection. In the case where a service does not support datasets, the visited node is made up of the service and the 'default dataset'.
クライアントがお互いについて何も知らないことがあり、複数のサーバーに話をすることを期待どこ最後のケースです。この場合は、それがデータセットや紹介を理解している場合、サーバーがクライアントに伝えるべきかの基本的な意味を表現しています。紹介は、それが参照しているために正確なデータセットを指定するので、訪れたノードのリスト内のノードは、serviceURIはとdataseturiで構成されています。これらの値の両方がループ検出の際に考慮する必要があります。サービスは、データセットをサポートしていない場合には、訪問したノードは、サービスと「既定のデータセット」から構成されています。
The major thing to remember when doing loop detection across servers is that some servers may not understand datasets at all, while others specifically rely on them. To help determine how loop detection nodes should be marked, three specific status messages have been defined:
サーバー間でループ検出を行う際に覚えておくべき主要な事は他の人が、特にそれらに依存している間、一部のサーバーは、すべてのデータセットを理解しないかもしれないということです。ループ検出ノードがマークされるべきか判断するために、3つの特定のステータスメッセージが定義されています。
The 3.1.3 (Datasets not supported) status message is used to denote that the server does not support datasets at all. It is sent in response to a query containing datasets. The client should consider that the server ignored the datasets and the client should consider this node to have been visited for all possible datasets (including the 'default' dataset).
3.1.3（データセットがサポートされていない）状態メッセージは、サーバーが全くデータセットをサポートしていないことを示すために使用されます。これは、データセットを含むクエリに応答して送信されます。クライアントは、サーバがデータセットを無視し、クライアントは、このノードが（「デフォルト」のデータセットを含む）すべての可能なデータセットのために訪問してきたために検討すべきであることを考慮すべきです。
The 3.1.4 (First dataset only supported) status message is used by a server to indicate the situation where a client has included several dataseturis in its query and the server can only support one at a time. In this case, the server is explicitly stating that it used the first dataseturi only. The client should consider that only the first dataseturi specified was processed correctly. The client should consider that the remaining datasets in the query were ignored completely. They would need to be sent individually as referrals if the client really cares about those results. Only the first serviceuri/dataseturi pair should be marked as visited.
3.1.4（のみ支持された第1のデータセット）のステータスメッセージは、クライアントがそのクエリ内のいくつかのdataseturisを含めた状況を示すために、サーバによって使用され、サーバは一度に1をサポートすることができます。この場合、サーバは明示的にそれが唯一の最初dataseturiを使用したことを述べています。クライアントは、指定された唯一の最初のdataseturiが正しく処理されたことを考慮すべきです。クライアントは、クエリ内の残りのデータセットは完全に無視されたことを考慮すべきです。クライアントが本当にそれらの結果を気なら、彼らは紹介として個別に送信する必要があります。訪れたとしてのみ最初のserviceURIは/ dataseturiペアをマークする必要があります。
The 3.1.5 (This dataset not supported) status message is used to indicate that a specific dataseturi sent in a query by a client is not supported by the server. This serviceuri/dataseturi pair should be considered as visited by the client. If this message is sent in reply to a query specifying multiple datasets, the client should behave the same as if it received the 3.1.3 message from above. It should be considered bad form for a server to send this status message back in response to a query with multiple datasets because it is ambiguous.
3.1.5（このデータセットがサポートされていない）状態メッセージは、クライアントによって、クエリで送信された特定のdataseturiがサーバによってサポートされていないことを示すために使用されます。クライアントが訪れたように、このserviceURIは/ dataseturiペアが考慮されるべきです。このメッセージは、複数のデータセットを指定して、クエリに応答して送信された場合、それは上から3.1.3のメッセージを受け取ったかのように、クライアントは同じように動作する必要があります。それがあいまいであるため、これは、複数のデータセットを使用してクエリに応答して、このステータスメッセージを返信するサーバーに悪い形と考えるべきです。
While there is no exact algorithm for loop detection that clients are encouraged to support, these status messages can be used by the server to be clear about what Services and Datasets it considers to have been queried. It is up to the client to decide what to do with these messages and how closely it attempts to do loop detection.
クライアントがサポートするように奨励されているループ検出のための正確なアルゴリズムはありませんが、これらのステータスメッセージは、それが照会されていると考えるものServicesおよびデータセットに関する明確にするためにサーバによって使用することができます。これは、これらのメッセージを、どのように密接にそれがループ検出を行うためにしようと何をすべきかを決定するためのクライアント次第です。
A subclass of Query, the ServiceQuery object supports the dynamic discovery of a specific CNRP service's characteristics. Note that CNRP compliance does not require that a service fully implements discoverability. In particular, returning the Service object with its serviceuri constitutes a minimal yet sufficient compliant implementation. Nevertheless, we expect that advanced CNRP services will choose to return a full description of their supported interfaces.
クエリのサブクラスは、ServiceQueryオブジェクトは、特定のCNRPサービスの特性のダイナミックな発見をサポートしています。 CNRPのコンプライアンスは、サービスが完全に発見可能に実装することを必要としないことに注意してください。特に、そのserviceUriとサービスオブジェクトを返すこと最小まだ十分準拠した実装を構成します。それにもかかわらず、我々は、高度なCNRPサービスが彼らのサポートされているインタフェースの完全な説明を返すように選択することを期待しています。
The complete response to a servicequery returns the Service object described in section 5.3.2 with the following schema information:
servicequeryへの完全な応答は、以下のスキーマ情報をセクション5.3.2に記述されたサービスオブジェクトを返します。
1. The base and custom properties used by the CNRP service (Property schema),
1. CNRPサービス（プロパティスキーマ）によって使用される塩基とカスタムプロパティ、
2. The properties used to describe the Service object (Service schema),
2.サービスオブジェクト（サービススキーマ）を記述するために使用されるプロパティ
4. The properties that belong to a resource within the results (Resource schema).
4.結果内のリソース（資源スキーマ）に所属するプロパティ。
These leads to the following new object definitions:
次の新しいオブジェクト定義にこれらのリード：
o propertyschema -- A property schema describes all the custom properties that are part of the service.
O propertyschema - プロパティスキーマは、サービスの一部であるすべてのカスタムプロパティを示しています。
o propertydeclaration -- A property declaration describes a base or custom property used by the CNRP service. A property declaration has a name and a type (the name and the type of the property that it refers to). Note that as part of the property schema, one MUST declare both existing and newly defined properties.
O propertydeclaration - プロパティ宣言はCNRPサービスによって使用される塩基またはカスタムプロパティを記述する。プロパティ宣言は、名前とタイプ（名前と、それが参照するプロパティの型）を有しています。プロパティスキーマの一部として、一つは既存および新たに定義されたプロパティを宣言しなければならないことに留意されたいです。
o propertyreference -- A property reference is a reference to a property declaration so that a given schema (a service, query or resource schema) can declare the property within its interface. Note that a property reference specify whether the use of the property is required or optional only.
O propertyreference - 指定されたスキーマ（サービス、クエリまたはリソース・スキーマ）は、そのインタフェース内のプロパティを宣言することができるように、プロパティの参照は、プロパティ宣言への参照です。プロパティ参照プロパティの使用が必須またはオプションの専用であるかどうかを指定することに留意されたいです。
o serviceschema -- The service schema defines the properties used to describe the service.
O serviceschema - サービススキーマは、サービスを記述するために使用されるプロパティを定義します。
o queryschema -- A query schema describes the structure of a query handled by the CNRP service. The properties referred within the query schema are part of the query interface of the resolution service.
O queryschema - クエリスキーマはCNRPサービスによって処理されるクエリの構造を記載します。クエリスキーマ内呼ば特性は解決サービスのクエリインタフェースの一部です。
o resourcedescriptorschema -- A ResourceDescriptor schema describes the resource returned as a result by the CNRP service.
O resourcedescriptorschema - ResourceDescriptorスキーマは、リソースがCNRPサービスによって結果として返さ記述する。
For example, a CNRP query to discover a service's capabilities will be in the form:
たとえば、サービスの機能を発見するCNRPクエリは形式になります。
<cnrp> <servicequery/> </cnrp>
<CNRP> <servicequery /> </ CNRP>
And for a CNRP service for cocktail recipes in French, the corresponding response would be:
そして、フランスのカクテルレシピ用CNRPサービスのために、対応する応答は次のようになります。
<service> <serviceuri>http://cnrp.recipe.com</serviceuri> <propertyschema> <propertydeclaration id="i1"> <propertyname>language</propertyname> <propertytype>rfc1766</propertytype> </propertydeclaration> <propertydeclaration id="i2"> <propertyname>cocktailrecipe</propertyname> <propertytype>freeform</propertytype> </propertydeclaration> </propertyschema> <queryschema> <propertyreference required="yes" ref="i1"/> </queryschema> <resourcedescriptorschema> <propertyreference required="yes" ref="i1"/> <propertyreference required="yes" ref="i2"/> </resourcedescriptorschema> </service>
<サービス> <serviceURIは> http://cnrp.recipe.com </ serviceURIは> <propertyschema> <propertydeclaration ID = "I1"> <プロパティ名>言語</プロパティ名> <プロパティタイプ> RFC1766 </プロパティタイプ> </ propertydeclaration> <propertydeclarationのID = "I2"> <プロパティ名> cocktailrecipe </プロパティ名> <プロパティタイプ>フリーフォーム</プロパティタイプ> </ propertydeclaration> </ propertyschema> <queryschema> <propertyreference必要= "YES" REF = "I1" /> < / queryschema> <resourcedescriptorschema> <propertyreference必要= "yes" をREF = "I1" /> <propertyreference必要= "yes" をREF = "I2" /> </ resourcedescriptorschema> </サービス>
This response stipulates that the service accepts the property language as part of the query interface and returns resourcedescriptors that contain both the language and cocktailRecipe properties.
この応答は、サービスは、クエリインターフェイスの一部としてプロパティ言語を受け入れ、言語やcocktailRecipe特性の両方が含まれているresourcedescriptorsを返すと規定しています。
<!-- The document tag --> <!ELEMENT cnrp (query|results|servicequery)>
<！ - 文書のタグ - > <ELEMENT CNRP！（クエリ|結果| servicequery）>
<!-- Used to request a Service object --> <!ELEMENT servicequery EMPTY>
<！ - サービスオブジェクトを要求するために使用します - > <！ELEMENTのservicequery EMPTYを>
<!-- A query can either request a schema, a specific record by --> <!-- id, or a common-name with a set of properties (or --> <!-- assertions) about the entity doing the query. --> <!ELEMENT query (id|(commonname,property*))> <!ELEMENT id (#PCDATA)>
<！ - プロパティのセットとID、または共通名（または - > <！ - - クエリは、スキーマによって、特定のレコードを要求することができますいずれか> <！ - アサーション）やって実体についてクエリ。 ！ - > <ELEMENTクエリ（ID |（commonNameを、プロパティ*））> <要素ID（#PCDATA）>！
<!ELEMENT commonname (#PCDATA)> <!-- NOTE: CNRP defines several well known properties --> <!-- and types. See Appendix A for details. --> <!ELEMENT property (#PCDATA)> <!-- The name of the property --> <!ATTLIST property name CDATA #REQUIRED> <!-- The type of the property --> <!ATTLIST property type CDATA "freeform">
< - 注意！：CNRPは、いくつかのよく知られた特性を定義します - > <ELEMENTのcommonName（#PCDATA）> <！ - とタイプ！。詳細については、付録Aを参照してください。 - > <！ELEMENTプロパティ（#PCDATA）> <！ - プロパティの名前 - > <！ATTLISTプロパティ名CDATA #REQUIRED> <！ - > <！ATTLISTプロパティタイプ - プロパティの種類CDATA "自由形式">
<!ELEMENT results (status? | ( service+, ( status | resourcedescriptor | referral )* )* )>
<！ELEMENT結果（ステータス？|（サービス+、（状況| resourcedescriptor |紹介）*）*）>
<!ELEMENT resourcedescriptor (commonname,id,resourceuri, serviceref, datasetref?, description, property*)> <!ATTLIST resourcedescriptor id ID #IMPLIED>
<！ELEMENTのresourcedescriptor（commonNameを、ID、resourceuri、serviceref、datasetref？、説明、プロパティ*）> <！ATTLIST resourcedescriptor IDのID #IMPLIED>
<!-- The entire point of all this... --> <!ELEMENT resourceuri (#PCDATA)> <!ELEMENT description (#PCDATA)>
<！ - このすべての全体のポイント... - > <！ELEMENT resourceuri（#PCDATA）> <！ELEMENT記述（#PCDATA）>
<!ELEMENT referral (serviceref, datasetref?)> <!ATTLIST referral id ID #IMPLIED>
<！ELEMENT紹介（サービスREF、データセット参照？）> <！ATTLIST紹介idが#IMPLIED IS>
<!ELEMENT status (#PCDATA)> <!ATTLIST status code CDATA #REQUIRED> <!ATTLIST status ref IDREF #IMPLIED>
<！ELEMENTステータス（#PCDATA）> <！ATTLISTステータスコードCDATA #REQUIRED> <！ATTLISTステータス参照IDREF #IMPLIED>
<!-- serviceRef is used to point to one of a set of provided --> <!-- service objects. This is so that a resource can point to -->
<！ - serviceRefが提供のセットの1つを指すために使用される - > <！ - サービスオブジェクト。リソースがポイントできるようにするためです - >
<!-- which service it came from. We could include the entire --> <!-- service object but then we would be repeating large --> <!-- amounts of information. -->
<！ - それはから来ているサービス。私たちは、全体を含めることができます - > <！ - サービスオブジェクトが、その後、私たちは大きな繰り返すことになる - > <！ - 情報の量を。 - >
<!ELEMENT serviceref EMPTY> <!ATTLIST serviceref ref IDREF #IMPLIED>
<！ELEMENT EMPTY serviceref> <！ATTLIST serviceref refのIDREF #IMPLIED>
<!ELEMENT service (serviceuri, dataset*, servers?, description?, property*,propertyschema?,queryschema?,resourcedescriptorschema?, serviceschema?)> <!-- The time to live of the schema in seconds since it was --> <!-- retrieved --> <!ATTLIST service ttl CDATA "0"> <!ATTLIST service id ID #IMPLIED> <!ELEMENT serviceuri (#PCDATA)> <!ELEMENT servers (server+)> <!ELEMENT server (serveruri, property*)> <!ELEMENT serveruri (#PCDATA)>
<<ELEMENTサービス（serviceURIは、データセット*、サーバ？、？、説明プロパティ*、propertyschema、queryschema、resourcedescriptorschema？serviceschema？？？）！> - ！それがあったので、秒単位でのスキーマの生存時間 - > <！ - 取得した - ！！！！！> <ATTLISTサービスTTL CDATA "0"> <ATTLISTサービスID ID #IMPLIED> <ELEMENT serviceURIは（#PCDATA）> <ELEMENTサーバ（サーバ+）> <ELEMENTサーバ（ serveruri、プロパティ*）> <！ELEMENTのserveruri（#PCDATA）>
<!ELEMENT dataset (property*)> <!ATTLIST dataset id ID #IMPLIED>
<！ELEMENTデータセット（プロパティ*）> <！ATTLISTデータセットのID ID #IMPLIED>
<!ELEMENT datasetref EMPTY> <!ATTLIST datasetref ref IDREF #IMPLIED>
<！EMPTY datasetref ELEMENT> <！ATTLIST datasetref refのIDREF #IMPLIED>
<!ELEMENT propertyschema (propertydeclaration*)> <!ELEMENT propertydeclaration (propertyname, propertytype*)> <!ATTLIST propertydeclaration id ID #IMPLIED>
<！ELEMENTのpropertyschema（propertydeclaration *）> <！ELEMENTのpropertydeclaration（propertyNameの、プロパティタイプ*）> <！ATTLISTのpropertydeclaration IDのID #IMPLIED>
<!ELEMENT propertyname (#PCDATA)> <!ELEMENT propertytype (#PCDATA)> <!-- This specifies if the type is meant to be the default --> <!-- type. This is usually reserved for "freeform". --> <!ATTLIST propertytype default (no|yes) "no">
<！ELEMENTのプロパティ名（#PCDATA）> <！ELEMENTのプロパティタイプ（#PCDATA）> <！ - タイプがデフォルトであることを意味する場合、これは指定 - > <！ - タイプ。これは通常、「自由形式」のために予約されています。 ！ - > <ATTLISTのプロパティタイプのデフォルト（NO | YES）、 "いいえ">
<!-- The properties you can use in a query --> <!ELEMENT queryschema (propertyreference*)>
<！ - クエリで使用できるプロパティ - > <！ELEMENTのqueryschema（propertyreference *）>
<!-- The properties you can expect to see in an Resource --> <!ELEMENT resourcedescriptorschema (propertyreference*)>
<！ - あなたがリソースに見ることを期待することができますプロパティ - > <！ELEMENTのresourcedescriptorschema（propertyreference *）>
<!-- The properties you can expect to find in a Service --> <!-- definition --> <!ELEMENT serviceschema (propertyreference*)>
<！ - あなたがサービスで見つけることを期待することができますプロパティ - > <！ - 定義 - > <！ELEMENTのserviceschema（propertyreference *）>
<!ELEMENT propertyreference EMPTY>
<！ELEMENTのpropertyreference EMPTY>
<!-- This specifies if a property is required as part of --> <!-- the query. --> <!ATTLIST propertyreference ref IDREF #REQUIRED> <!ATTLIST propertyreference required (no|yes) "no">
<！ - クエリ<！ - - プロパティはの一部として必要とされる場合、これは指定します>。 ！！ "ノー"> | - IDREF #REQUIRED> <ATTLISTのpropertyreference必要（はいいいえ）参照> <ATTLISTのpropertyreference
This is what the client sends when it is requesting a servers schema.
これは、サーバのスキーマを要求しているときに、クライアントが送信するものです。
<?xml version="1.0"?> <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <cnrp> <servicequery /> </cnrp>
<？xml version = "1.0"？> <PUBLIC CNRP DOCTYPE！ " - // IETF // DTD CNRP 1.0 // EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <CNRP> <servicequery /> </ CNRP>
This is the result. Notice how the Service tag is used to allow the service to describe itself in its own terms.
これが結果です。サービスタグは、サービスには独自の用語で自分自身を記述できるようにするために使用される方法に注目してください。
<?xml version="1.0"?> <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <cnrp> <results> <service ttl="43200"> <serviceuri>urn:foo:bar</serviceuri> <servers> <server> <serveruri>http://host1.acmecorp.com:4321/foo?</serveruri> </server> <server> <serveruri>smtp://host2.acmecorp.com:4321/foo?</serveruri> </server> </servers> <description>This is the Acme CNRP Service</description> <!-- This property means that Acme specializes in tradename services --> <property name="category" type="naics">544554</property> <property name="BannerAdServer" type="uri"> http://adserver.acmecorp.com/ </property> <propertyschema> <propertydeclaration id="i1"> <propertyname>workgroupID</propertyname> <propertytype default="yes">freeform</propertytype> <propertytype default="no">domainname</propertytype>
<？xml version = "1.0"？> <PUBLIC CNRP DOCTYPE！ " - // IETF // DTD CNRP 1.0 // EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <CNRP> <結果> <サービスTTL = "43200"> <serviceURIは> URN：FOO：？バー</ serviceURIは> <サーバー> <サーバー> <serveruri> http://host1.acmecorp.com:4321/foo </ serveruri> </サーバー> <サーバー> <serveruri> SMTP：//host2.acmecorp.com：？4321 / fooの</ serveruri> </サーバー> </サーバ> <説明>これはアクメCNRPサービス</記述> <です！ - このプロパティは、アクメは、商品名、サービスに特化していることを意味します - > <プロパティ名= "カテゴリ" タイプ= "NAICS"> 544554 </プロパティ> <プロパティ名= "BannerAdServer" タイプ= "URI">のhttp：// adserver.acmecorp.com/ </ property>の<propertyschema> <propertydeclaration ID = "I1"> <プロパティ名> workgroupID </プロパティ名> <プロパティタイプデフォルト= "YES">自由形式</プロパティタイプ> <プロパティタイプデフォルト= "いいえ">ドメイン名</プロパティタイプ>
</propertydeclaration> <propertydeclaration id="i2"> <propertyname>BannerAdServer</propertyname> <propertytype default="yes">URI</propertytype> </propertydeclaration> </propertyschema> <queryschema> <propertyreference ref="i1" required="yes" /> </queryschema> <resourcedescriptorschema> <propertyreference ref="i1" required="yes" /> </resourcedescriptorschema> <serviceschema> <propertyreference ref="i2" required="yes" /> </serviceschema> </service> </results> </cnrp>
</ propertydeclaration> <propertydeclaration ID = "I2"> <プロパティ名> BannerAdServer </プロパティ名> <プロパティタイプデフォルト= "YES"> URI </プロパティタイプ> </ propertydeclaration> </ propertyschema> <queryschema> <propertyreference REF = "I1 "必要=" はい」/> </ queryschema> <resourcedescriptorschema> <propertyreference REF = "I1" 必要= "はい" /> </ resourcedescriptorschema> <serviceschema> <propertyreference REF = "I2" 必要= "はい" /> </ serviceschema> </サービス> </結果> </ CNRP>
This is the query that is sent from the client to the server:
これは、クライアントからサーバーに送信されるクエリです。
<?xml version="1.0"?> <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <cnrp> <query> <commonname>Fido</commonname> <property name="geography" type="iso3166-2"> CA-QC</property> <property name="geography" type="iso3166-1">CA</property> <property name="language" type="rfc1766">fr-CA</property> </query> </cnrp>
<？xml version = "1.0"？> <PUBLIC CNRP DOCTYPE！ " - // IETF // DTD CNRP 1.0 // EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <CNRP> <問い合わせ> <commonNameの>ファイド</ commonNameの> <プロパティ名= "地理" タイプ= "iso3166-2"> CA-QC </プロパティ> <プロパティ名= "地理" タイプ= "ISO3166-1"> CA < /プロパティ> <プロパティ名= "言語" タイプ= "RFC1766"> FR-CA </ property>の</クエリ> </ CNRP>
This is the result set. It is sent back in response to the query. This result set includes a referral and a non-fatal error.
これは、結果セットです。これは、クエリに応答して返送されます。この結果セットには、照会および非致命的なエラーが含まれています。
<?xml version="1.0"?> <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <cnrp> <results> <service id="i0"> <serviceuri>http://acmecorp.com</serviceuri> </service> <service id="i1">
<？xml version = "1.0"？> <PUBLIC CNRP DOCTYPE！ " - // IETF // DTD CNRP 1.0 // EN" "http://ietf.org/dtd/cnrp-1.0.dtd"> <CNRP> <結果> <サービスID = "I0"> <serviceURIは> http://acmecorp.com </ serviceURIは> </サービス> <サービスID = "I1">
<serviceuri>http://serverfarm.acmecorp.com</serviceuri> </service> <service id="i2"> <serviceuri>http://servers.acmecorp.co.uk</serviceuri> </service> <resourcedescriptor> <commonname>Fidonet</commonname> <id>1333459455</id> <resourceuri>http://www.fidonet.ca</resourceuri> <serviceref ref="i0" /> <description>This is ye olde Canadian Fidonet</description> </resourcedescriptor> <resourcedescriptor> <commonname>Fidonet</commonname> <id>1333459455</id> <resourceuri>http://host:port/bla</resourceuri> <serviceref ref="i1" /> <description>An old Fidonet node</description> </resourcedescriptor> <referral><serviceref ref="i2" /></referral> <status code="3.1.1"> The language property 'fr-CA' was ignored </status> </results> </cnrp>
<serviceURIは> http://serverfarm.acmecorp.com </ serviceURIは> </サービス> <サービスID = "I2"> <serviceURIは> http://servers.acmecorp.co.uk </ serviceURIは> </サービス> <resourcedescriptor> <commonNameの> FidoNetの</ commonNameの> <ID> 1333459455 </ ID> <resourceuri> http://www.fidonet.ca </ resourceuri> <serviceref REF = "I 0" /> <説明>これはがたでありますオールドカナダのFidoNetの</記述> </ resourcedescriptor> <resourcedescriptor> <commonNameの> FidoNetの</ commonNameの> <ID> 1333459455 </ ID> <resourceuri>のhttp：//ホスト：ポート/ BLA </ resourceuri> <serviceref REF = "I1" /> <説明>古いからFidonetノード</記述> </ resourcedescriptor> <紹介> <serviceref REF = "I2" /> </紹介> <ステータスコード= "3.1.1">言語プロパティ ' FR-CAは、」</ステータス> </結果> </ CNRP>無視されました
Two CNRP transport protocols are specified. HTTP is used due to its popularity and ease of integration with other web applications. SMTP is also used as a way to illustrate a protocol that has a much different range of latency than most protocols.
二CNRPトランスポートプロトコルが指定されています。 HTTPは、その人気と他のWebアプリケーションとの統合の容易に使用されています。 SMTPはまた、ほとんどのプロトコルよりも待ち時間の大きく異なる範囲を有するプロトコルを示すための方法として使用されます。
In the cases where transports use MIME Media Types (HTTP and SMTP being examples of such), the CNRP payload MUST use the 'application/cnrp+xml' media type. See Section 8 for the registration template for this media type. One important note about this media type is that, since CNRP always uses UTF-8, there is no charset attribute.
MIMEメディアタイプ（HTTPおよびSMTPはそのようなものの例である）を使用して輸送する場合には、CNRPペイロードは「アプリケーション/ CNRP + XMLのメディアタイプを使用しなければなりません。このメディアタイプの登録テンプレートについては、セクション8を参照してください。このメディアタイプについての一つの重要な注意事項はCNRPは常にUTF-8を使用するので、何のcharset属性が存在しない、ということです。
The HTTP transport is fairly simple. The client connects to an HTTP based CNRP server and issues a request using the POST method to the "/" path with the Content-type and Accept header set to "application/cnrp+xml". The content of the POST body is the CNRP XML document that is being sent. All HTTP 1.1 features are allowed during the request.
HTTPトランスポートは非常に簡単です。クライアントは、HTTPベースのCNRPサーバーに接続し、「アプリケーション/ CNRP + XML」に設定ヘッダをコンテンツタイプと「/」パスにPOSTメソッドを使用し、受け入れ要求を発行します。 POST本体の内容が送信されているCNRPのXML文書です。すべてのHTTP 1.1機能は、リクエスト時に許可されています。
The results are sent back to the client with a Content-Type of "application/cnrp+xml". The body of the result is the CNRP XML document being sent to the client.
結果は、「アプリケーション/ CNRP + XML」のコンテンツタイプで、クライアントに送信されます。結果のボディは、クライアントに送信されるCNRPのXML文書です。
The SMTP transport is very similar to the HTTP transport. Since there is no method to specify, the CNRP XML document is simply sent to a particular SMTP endpoint with its Content-Type set to "application/cnrp+xml". The server responds by sending a response to the originator of the request with the results in the body and the Content-Type set to "application/cnrp+xml". The Service MUST specify at least one SMTP target (email address) to contact.
SMTPトランスポートは、HTTPトランスポートと非常によく似ています。指定する方法がないので、CNRP XML文書は、単に「アプリケーション/ CNRP + XML」に設定されたコンテンツタイプで、特定のSMTPエンドポイントに送信されます。サーバーは、体内での結果と「アプリケーション/ CNRP + XML」に設定のContent-Typeでの要求の発信元への応答を送信することで応答します。サービスは、ご連絡するために、少なくとも1つのSMTPターゲット（電子メールアドレス）を指定する必要があります。
This is the registration template for 'application/cnrp+xml' per [6].
これは、[6]あたり「アプリケーション/ CNRP + XML」の登録テンプレートです。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: cnrp+xml
MIMEサブタイプ名：CNRP + xmlの
Required parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: This media type consists of 8bit text which may necessitate the use of an appropriate content transfer encoding on some transports. Since these considerations are the same as XML in general, RFC3023's [6] discussion of XML and MIME is applicable.
符号の考慮：このメディアタイプは、いくつかのトランスポートに適切なコンテンツ転送符号化の使用を必要とすることができる8ビットのテキストで構成されています。これらの考慮事項は、一般的にはXMLと同じであるので、XMLとMIMEのRFC3023の[6]の議論を適用することが可能です。
Security considerations: none specific to this media type. See Section 9 for general CNRP considerations.
セキュリティの考慮事項：このメディアタイプに特有なし。一般CNRPの考慮事項については、セクション9を参照してください。
Interoperability considerations: n/a
相互運用性に関する注意事項：N / A
Published specification: This media type is a proper subset of the the XML 1.0 specification [8] except for the limitations placed on tags and encodings by this document.
公開された仕様：このメディアタイプは、XML 1.0仕様の適切なサブセットである[8]この文書でタグとエンコーディングに置か制限を除きます。
Applications which use this media type: any CNRP client/server wishing to send or receive CNRP requests or responses
CNRP要求または応答を送信または受信する任意のCNRPクライアント/サーバは希望：このメディアタイプを使用するアプリケーション
Additional Information: none
追加情報：なし
Contact for further information: c.f., the "Author's Address" section of this memo
詳細についてはお問い合わせ：C.F.、このメモの「作者のアドレス」セクション
Intended usage: limited use
意図している用法：限定使用
Author/Change controller: the IESG
著者/変更コントローラ：IESG
Three security threats exist for CNRP or applications that depend on it: Man in the Middle attacks, malicious agents posing as a service by spoofing a Service object, and denial of service attacks caused by adding a new level of indirection for resolution of a resource.
middle攻撃でマン、悪意のあるエージェントは、サービスオブジェクトを偽装することでサービスを装った、とリソースの解決のための間接の新しいレベルを追加することによって引き起こされるサービス妨害攻撃：3つのセキュリティ上の脅威はCNRPまたはそれに依存するアプリケーションのために存在します。
The proposed solution for man in the middle attacks is to utilize transport level authentication and encryption, where available. In the case where the transport can't provide the level of required authentication, individual entries or the entire response can be signed/encrypted using XML signature methods being developed by the XMLDSIG Working Group.
中間者攻撃の男のために提案された解決策が利用可能な場合、トランスポート・レベルの認証と暗号化を利用することです。輸送が必要な認証のレベルを提供できない場合には、個々のエントリ又は全体応答が署名することができる暗号化/ XMLDSIGワーキンググループによって開発されたXML署名方法を使用して。
In the case of where a service attempts to pose as another by spoofing the serviceuri in the Service object, the Service object should be signed. A client can then verify the Service object's veracity by verifying the signature. How the client obtains that authoritative public key is out of scope since it depends on the service discovery problem.
サービスは、サービスオブジェクトにserviceURIはスプーフィング別としてポーズしようとする場所の場合には、サービスオブジェクトは、署名されるべきです。その後、クライアントは、署名を検証することによって、サービスオブジェクトの信憑性を確認することができます。どのようにクライアントがサービス探索問題に依存するため、権威の公開鍵が範囲外であることを取得。
While this document cannot propose a solution for Denial Of Service (DOS) attacks, it can illustrate that, like many other cases, any time a new level of indirection is created, an opportunity for a DOS attack is created. Service providers are encouraged to be aware of this and to act accordingly to mitigate the effects of a DOS attack.
このドキュメントでは、サービス拒否（DoS）攻撃のためのソリューションを提案することはできませんが、それは任意の時間は間接の新しいレベルが作成され、他の多くの例のように、DOS攻撃の機会が作成された、ことを示していることができます。サービスプロバイダーは、このことを認識すると、DOS攻撃の影響を緩和するために応じて行動することをお勧めします。
The major consideration for the IANA is that the IANA will be registering well known properties, property types and status messages. It will not register values. Since this document does not discuss CNRP service discovery, the IANA will not be registering the existence of servers or Server objects.
IANAのための主要な考慮事項は、IANAがよく知られているプロパティ、プロパティタイプとステータスメッセージを登録されることです。これは、値を登録しません。この文書はCNRPサービスの発見を議論していないので、IANAは、サーバーまたはサーバーのオブジェクトの存在を登録されることはありません。
There are three types of entities the IANA can register: properties, property types, and status messages. If a property or type is not registered with the IANA, then they must start with "x-". Status messages can be created for local consumption and not registered. There is no requirement that new status messages are mandatory to implement unless this document is updated. Status message registrations are more for informational purposes.
プロパティ、プロパティタイプ、およびステータスメッセージ：IANA登録できるエンティティの3つのタイプがあります。プロパティまたはタイプがIANAに登録されていない場合、彼らは「X-」で始まらなければなりません。ステータスメッセージは、地元消費のために作成され、登録されていないことができます。新しいステータスメッセージは、この文書が更新されない限り、実装するために必須の要件はありません。ステータスメッセージの登録は、情報提供の目的のためのより多くのです。
The required information for the registration of a new property is the property's name, its default type, and a general description. A new type requires the type's name, what properties it is valid for, and a description. A new status message requires the X.Y.ZZZ code and a brief description of the state being communicated.
新しいプロパティの登録に必要な情報は、プロパティの名前、そのデフォルトのタイプ、および一般的な説明です。新しいタイプは、それがために有効な、と説明が何であるかの性質、種類の名前が必要です。新しいステータスメッセージはX.Y.ZZZコードと通信中状態の簡単な説明を必要とします。
All properties, types and status messages are registered on a First Come First Served basis with no review by the IANA or any group of experts. The consensus opinion of the CNRP Working Group is that review of property registrations should occur once there is operational experience with the protocol and an actual need for the review. If, at some future date, this policy needs to change, this document will be updated.
すべてのプロパティは、種類やステータスメッセージが最初に登録されているがまずIANAによってノーレビューや専門家のいずれかのグループに根拠を添えています。 CNRPワーキンググループのコンセンサス意見は、プロトコルやレビューのために実際の必要性と運用経験があるいったん財産登録の見直しを行うべきということです。 、いくつかの将来の日付で、このポリシーを変更する必要がある場合は、この文書が更新されます。
The property and type registration templates found in Appendix A should be registered by the IANA at publication time of this document.
付録Aで見つかったプロパティとタイプ登録テンプレートは、本書の出版時にIANAによって登録されなければなりません。
The IANA is also directed to register the Media Type specified in Section 8.
IANAはまた、セクション8で指定されたメディアタイプを登録するように指示されます。
References
リファレンス
[1] United States, "North American Industry Classification System", January 1997, <http://www.census.gov/epcd/www/naics.html>.
[1]米国、 "北米産業分類システム"、1997年1月、<http://www.census.gov/epcd/www/naics.html>。
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[2]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[3]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[4] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[4] Alvestrand、H.、 "言語識別のためのタグ"、RFC 1766、1995年3月。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5]堀、R.、 "URN構文"、RFC 2141、1997年5月を。
[6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6]村田、M.、サンローラン、S.およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[8] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", February 1998.
[8]ブレイ、T.、パオリ、J.及びC. Sperberg-マックイーン、 "拡張マークアップ言語（XML）1.0" 1998年2月。
[9] Mealling, M., "The 'go' URI Scheme for the Common Name Resolution Protocol", RFC 3368, August 2002.
[9] Mealling、M.、RFC 3368、2002年8月 "一般名解決プロトコルのための 'GO' URIスキーム"。
[10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[10]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 1893、1996年1月。
[11] "Country and Region Codes", ISO 3166, January 1996.
[11] "国と地域コード"、ISO 3166、1996年1月。
Appendix A. Well Known Property and Type Registration Templates
付録A.周知の特性とタイプ登録テンプレート
A.1 Properties
A.1プロパティ
Property Name: geography Default Type: iso3166-1 Description: A geographic location
プロパティ名：地理デフォルト・タイプ：ISO3166-1説明：地理的位置
Property Name: language Default Type: rfc1766 Description: A language specification
プロパティ名：言語のデフォルト・タイプ：RFC1766説明：言語仕様
Property Name: category Default Type: freeform Description: A node in some system of semantic relationships that is considered relevant to the common-name.
プロパティ名：カテゴリのデフォルト・タイプ：フリーフォームの説明：共通名に関連すると考えられている意味関係のいくつかのシステムのノード。
Property Name: range Default Type: range Description: A range given in the format "x,y" where x is the starting point and y is the length. This property is used by the client to tell the server that is is requesting a subrange of the results.
プロパティ名：範囲デフォルトタイプ：範囲説明：Xは開始点であり、yは長さの形式で与えられた範囲「X、Y」。このプロパティは、結果のサブレンジを要求しているされているサーバに伝えるために、クライアントによって使用されます。
Property Name: dataseturi Default Type: uri Description: A URI used to disambiguate between two Datasets offered by the same Service.
プロパティ名：dataseturiデフォルト・タイプ：URI説明：URIは、同じサービスが提供する2つのデータセット間で明確にするために使用しました。
A.2 Types
A.2タイプ
Type: freeform Property: category Description: The value is to be interpreted by the server the best way it knows how. This value has no defined structure.
タイプ：フリーフォームのプロパティ：カテゴリ説明：値は、サーバーによってそれがどのように知っている最良の方法を解釈されるべきです。この値には定義された構造を持っていません。
Type: freeform Property: geography Description: The value is to be interpreted by the server the best way it knows how. This value has no defined structure.
タイプ：フリーフォームのプロパティ：地理説明：値は、サーバーによってそれがどのように知っている最良の方法を解釈されるべきです。この値には定義された構造を持っていません。
Type: freeform Property: language Description: The value is to be interpreted by the server the best way it knows how. This value has no defined structure.
タイプ：フリーフォームのプロパティ：言語説明：値は、サーバーによってそれがどのように知っている最良の方法を解釈されるべきです。この値には定義された構造を持っていません。
Type: iso3166-2 Property: geography Description: The combination of country and sub-region codes found in ISO 3166-2 [11].
タイプ：iso3166-2プロパティ：地理説明：ISO 3166-2 [11]で見つけ国とサブ地域コードの組み合わせ。
Type: iso3166-1 Property: Geography Description: Country Codes found in ISO 3166-1 [11].
タイプ：ISO3166-1プロパティ：地理説明：ISO 3166-1 [11]で見つかった国コード。
Type: postalcode Property: Geography Description: A postal code that is valid for some region. A good example is the Zip code system used in the US.
種類：郵便番号プロパティ：地理説明：一部の地域で有効な郵便番号。良い例が、米国で使用される郵便番号システムです。
Type: lat-long Property: Geography Description:
タイプ：LAT-長いプロパティ：地理説明：
Values for latitude and longitude shall be expressed as decimal fractions of degrees. Whole degrees of latitude shall be represented by a two-digit decimal number ranging from 0 through 90. Whole degrees of longitude shall be represented by a decimal number ranging from 0 through 180. When a decimal fraction of a degree is specified, it shall be separated from the whole number of degrees by a decimal point. Decimal fractions of a degree may be expressed to the precision desired.
緯度と経度の値は、度の小数として表現されなければなりません。緯度の全体度程度の小数を指定した場合、それがなければならない0から180までの範囲の小数で表されなければならない0から経度の90全体度の範囲の2桁の10進数で表現されなければなりません小数点により度の整数から分離されます。度の小数は、所望の精度に表すことができます。
Latitudes north of the equator shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the designating degrees. Latitudes south of the Equator shall be designated by a minus sign (-) preceding the two digits designating degrees. A point on the Equator shall be assigned to the Northern Hemisphere.
指定度の前、（ - ）北赤道の緯度は、プラス記号（+）によって、またはマイナス記号が存在しないことによって指定されなければなりません。度を指定する2桁先行（ - ）南赤道の緯度は、マイナス記号で指定されなければなりません。赤道上の点は、北半球に割り当てされなければなりません。
Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the Longitudes west of the meridian shall be designated by minus sign (-) preceding the digits designating degrees. A point on the prime meridian shall be assigned to the
東本初子午線の経度はプラス記号（+）で指定されなければならない、又は西子午線の経度によってマイナス記号で指定されなければならない（ - ）度を指定する数字を先行します。本初子午線上の点は、に割り当てされなければなりません
Eastern Hemisphere. A point on the 180th meridian shall be assigned to the Western Hemisphere. One exception to this last convention is permitted. For the special condition of describing a band of latitude around the earth, the East Bounding Coordinate data element shall be assigned the value +180 (180) degrees.
東半球。 180度子午線上の点は、西半球に割り当てされなければなりません。この最後の大会の一つの例外が許可されています。地球の周りの緯度帯を説明する特別な条件のために、イーストバウンディングは、データ要素を座標（180）度値180を割り当てなければなりません。
Any spatial address with a latitude of +90 (90) or -90 degrees will specify the position at the North or South Pole, respectively. The component for longitude may have any legal value.
+90（90）または-90度の緯度と空間的アドレスは、それぞれ、北または南極の位置を指定します。経度のための成分は、任意の有効な値を有していてもよいです。
With the exception of the special condition described above, this form is specified in Department of Commerce, 1986, Representation of geographic point locations for information interchange (Federal Information Processing Standard 70-1): Washington, Department of Commerce, National Institute of Standards and Technology.
上記の特別な条件を除いて、このフォームは、商務省、1986情報交換用地点の位置の、表現（連邦情報処理規格70-1）で指定されている：ワシントン、商務省、米国国立標準研究所技術。
DEGREES = *PLUSMINUS DIGITS '.' DIGITS
PLUSMINUS = + | -
DIGITS = DIGIT *DIGIT
DIGIT = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Type: rfc1766 Property: Language Description: language codes as defined by RFC 1766 [4]
タイプ：RFC1766プロパティ：言語概要：言語コードRFC 1766によって定義される[4]。
Type: naics Property: Category Description: North American Industry Code System [1]
タイプ：NAICSプロパティ：カテゴリ説明：北米産業コードシステム[1]
Type: uri Property: dataseturi Description: A URI adhering to the 'absoluteURI' production of the Collected ABNF found in [3]
タイプ：uriプロパティ：dataseturi説明：URIがで見つかった収集ABNFの「absoluteURIでの生産に付着している[3]
Appendix B. Status Codes
付録B.ステータスコード
B.1 Level 1 (Informative) Codes
B.1レベル1（参考）コード
1.0.0 -- Undefined Information This code is used for any non-categorizable and informative message. If, for example, the server wanted to tell the client that the systems administrator's cat has blue hair, then this code would be the appropriate place for this information.
1.0.0 - このコードは、任意の非categorizableおよび情報メッセージのために使用されている未定義の情報。例えば、サーバはシステム管理者の猫は青い髪を持っていることをクライアントに伝えたかった、場合、このコードは、この情報を適切な場所でしょう。
1.1.0 -- Query related information This code is used for any informative information concerning the query that client sent. For example, "The query you sent was rather interesting!".
1.1.0 - このコードは、クライアントが送信したクエリに関するすべての有益な情報のために使用されるクエリの関連情報。たとえば、「あなたが送信されたクエリはかなり面白かったです！」。
1.2.0 -- An informative message pertaining to the Service This message concerns the Service in the general sense.
1.2.0 - サービスにこのメッセージを関連する情報メッセージは、一般的な意味でのサービスに関するものです。
B.2 Level 2 (Success) Codes
B.2レベル2（成功）コード
2.0.0 -- Something undefined succeeded There was success but the situation that this message concerns is undefined.
2.0.0 - 未定義の何かが成功ますが、このメッセージの懸念が定義されていないという状況がありました成功しました。
2.1.0 -- Query succeeded The query succeeded. This message MUST be returned when there were no results that matched the query. I.e., the query was successfully handled and the correct set of results contained no resources or referrals. The lack of results is not an error but a successful statement about the common-name.
2.1.0 - クエリは、クエリが成功した成功しました。クエリと一致し何も結果がなかった場合に、このメッセージが返されなければなりません。つまり、クエリが正常に処理し、結果の正しいセットには、リソースや紹介が含まれていません。結果の欠如は、エラーが、共通名程度成功した声明ではありません。
Note: The apparent lack of 2.X.X level codes is caused by success usually being indicated not by a status message but by the server returning only the objects that the client requested.
注意：2.X.Xレベルコードの見かけの欠如は通常はステータスメッセージではなく、クライアントが要求されたオブジェクトのみを返すサーバーによって示され、成功によって引き起こされます。
B.3 Level 3 (Partial Success) Codes
B.3レベル3（部分的な成功）コード
3.0.0 -- Something undefined was only partially successful Some request by the client was only partially successful. The exact situation or cause of that partial failure is not defined.
3.0.0 - 未定義の何かが、クライアントによっていくつかの要求が部分的にしか成功した部分的にしか成功しました。その部分的な障害の正確な状況や原因が定義されていません。
3.1.1 -- The query contained invalid or unsupported properties The query contained invalid or unsupported property names, types or values. The invalid properties were ignored and the query processed.
3.1.1 - クエリは、クエリが無効またはサポートされていないプロパティ名、タイプまたは値が含まれて無効またはサポートされていないプロパティが含まれていました。無効なプロパティは無視され、クエリが処理されました。
3.1.2 -- The XML was well formed but invalid The XML sent by the client was well formed but invalid. The server was smart enough to figure out what the client was talking about and return some results.
3.1.2 - XMLは十分に形成されますが、クライアントから送信されたXMLがうまく形成されるが無効だっ無効でした。サーバは、クライアントが話していたかを把握し、いくつかの結果を返すのに十分なスマートでした。
3.1.3 Server does not support datasets This status should be generated by servers that do not handle datasets. A server can send this status message at any time, but it especially useful for when a server receives a query from a client that contains a dataseturi. In this case and if the client is doing rigorous loop detection, the client should consider this entire service to have been visited.
3.1.3 Serverは、このステータスは、データセットを処理していないサーバーによって生成されなければならないデータセットをサポートしていません。サーバーは、いつでもこのステータスメッセージを送信することができますが、サーバーがdataseturiが含まれているクライアントからのクエリを受信したときのためには特に便利。この場合、クライアントは厳格なループ検出を行っている場合、クライアントが訪れてきたために、このサービス全体を考慮する必要があります。
3.1.4 The first dataset in the list of datasets you gave in the query was the only one used. This status message is used by a server to indicate the situation where a client has included several dataseturis in its query and the server can only support one at a time. In this case the server is explicitly stating that it used the first dataseturi only. The client should consider that only the first dataseturi specified was processed correctly. The client should consider that the remaining datasets in the query were ignored completely.
クエリで与えたデータセットのリストの最初のデータセットは使用だけだった3.1.4。このステータスメッセージは、クライアントがそのクエリ内のいくつかのdataseturisを含めた状況を示すために、サーバによって使用され、サーバは一度に1をサポートすることができます。この場合、サーバは、明示的にそれが唯一の最初dataseturiを使用したことを述べています。クライアントは、指定された唯一の最初のdataseturiが正しく処理されたことを考慮すべきです。クライアントは、クエリ内の残りのデータセットは完全に無視されたことを考慮すべきです。
They would need to be sent individually as referrals if the client really cares about those results. Only the first serviceuri/dataseturi pair should be marked as visited if loop detection is being handled.
クライアントが本当にそれらの結果を気なら、彼らは紹介として個別に送信する必要があります。訪れたとしてループ検出が処理されている場合のみ、最初のserviceURIは/ dataseturiペアをマークする必要があります。
3.1.5 This dataset not supported. This message is used to indicate that a specific dataseturi sent in a query by a client is not supported by the server. This serviceuri/dataseturi pair should be considered as visited by the client. If this message is sent in reply to a query specifying multiple datasets, the client should behave the same as if it received the 3.1.3 message from above. It should be considered bad form for a server to send this status message back in response to a query with multiple datasets because it is ambiguous.
3.1.5このデータセットはサポートされていません。このメッセージは、クライアントによって、クエリで送信された特定のdataseturiがサーバによってサポートされていないことを示すために使用されます。クライアントが訪れたように、このserviceURIは/ dataseturiペアが考慮されるべきです。このメッセージは、複数のデータセットを指定して、クエリに応答して送信された場合、それは上から3.1.3のメッセージを受け取ったかのように、クライアントは同じように動作する必要があります。それがあいまいであるため、これは、複数のデータセットを使用してクエリに応答して、このステータスメッセージを返信するサーバーに悪い形と考えるべきです。
3.2.0 -- The server caused a partially successful event Due to some internal server error, the results returned were incomplete.
3.2.0 - サーバーが何らかの内部サーバーエラーのために部分的に成功したイベントを発生させ、結果が不完全だった返さ。
3.2.1 -- Some referral server was unavailable This status message is used to denote that one or more of the referral services that are normally queried was unavailable. Results were generated, but they may not be representative of a complete answer.
3.2.1 - いくつかの参照サーバは、このステータスメッセージが正常に照会される照会サービスの1つ以上が利用できなかったことを示すために使用されて利用できませんでした。結果は、生成されたが、彼らは完全な答えの代表ではないかもしれません。
B.4 Level 4 (Transient Failure) Codes
B.4レベル4（一時的な障害）コード
4.1.0 -- There was an error in the query that made it unable to be interpreted.
4.1.0 - 解釈することができない作ったクエリでエラーが発生しました。
4.2.0 -- The query was to complex The query as specified was too complex for this Service to handle.
4.2.0 - 指定されたクエリが複雑なクエリにしたが、このサービスが処理するにはあまりにも複雑でした。
4.2.1 -- The Service was too busy Due to resource constraints, the entire service is too busy to handle requests. This means that any of the Servers cooperating in providing this Service would have also returned this same message.
4.2.1 - サービスにより、リソースの制約のためにあまりにも忙しかったが、全体のサービスは要求を処理するにはあまりにも忙しいです。これは、このサービスの提供に協力サーバーのいずれも、この同じメッセージを返したことを意味します。
4.2.2 -- The Server is in maintenance This server is now in maintenance mode. Try another server from this service or try again at a later time.
4.2.2 - Serverは、このサーバーがメンテナンスモードになり、メンテナンス中です。このサービスから別のサーバを試してみたり、後で再試行してください。
4.2.3 -- The Server had an internal error There was an internal error that caused the server to fail completely.
4.2.3 - サーバーは、サーバーが完全に失敗する原因内部エラーが発生しました内部エラーが発生しました。
B.5 Level 5 (Permanent Failures) Codes.
B.5レベル5（恒久的障害）コード。
5.2.1 -- This Service is no longer available. This Service has decided to no longer make itself available.
5.2.1 - このサービスは利用できなくなりました。このサービスは、もはや自身が利用できるようにしないことを決定しました。
5.2.2 -- The Server had a permanent failure. This server has permanently failed. Try another server from this service.
5.2.2 - Serverは、永久的な障害が発生していました。このサーバは永久に失敗しました。このサービスから別のサーバを試してみてください。
Authors' Addresses
著者のアドレス
Nico Popp VeriSign, Inc. 487 East Middlefield Road Mountain View, CA 94043
ニコPoppのベリサイン株式会社487東ミドルロード、マウンテンビュー、CA 94043
Phone: (650) 426-3291 EMail: npopp@verisign.com
電話：（650）426-3291 Eメール：npopp@verisign.com
Michael Mealling VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 US
マイケル・メオーリングベリサイン社21345 Ridgetopサークルスターリング、バージニア州20166米国
EMail: michael@verisignlabs.com
メールアドレス：michael@verisignlabs.com
Marshall Moseley Netword, Inc. 702 Russell Avenue Gaithersburg, MD 20877-2606 US
マーシャルモーズリーNetword、Inc.の702ラッセル・アベニューゲーサーズバーグ、MD 20877から2606米
Phone: (240) 631-1100 EMail: marshall@netword.com
電話：（240）631-1100 Eメール：marshall@netword.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。