[要約] RFC 3367は、Common Name Resolution Protocol（CNRP）に関する標準化ドキュメントであり、CNRPの目的は、ネットワーク上のエンティティの一意の識別と名前解決を提供することです。
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)
一般名解決プロトコル（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.
Copyright（c）The Internet Society（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つまたは少数のカテゴリまたはドメインで動作する場合があります。また、クライアントが解像度スコープを限られた数のカテゴリまたはドメインに制限することを期待する場合があります。たとえば、「インターネットエンジニアリングタスクフォース」というフレーズは、「組織」カテゴリの一般名であり、本カテゴリの「Moby Dick」と同様です。
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つのクラスのクライアントが構築されており、ブラウザの改善とWebアクセス可能なフロントエンドサービスがあります。ブラウザの拡張は、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].)
一般名は、urisによって課される構文構造を欠いているという点で、uris（均一なリソース識別子）ではありません。さらに、urとは異なり、共通名とリソースの間に関連性の独自性や持続性の要件はありません。（注：共通名は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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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に見られる「絶対的な」生産に準拠する必要があります。CNRPはベースのセマンティクスを定義していないため、「URI-Reference」の生産を表現することはできません。
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は、一般化された「サービス」が1つ以上の実際の「サーバー」で共通名の解像度を提供する特定の相互作用モデルを想定しています。すべてのサーバーに含まれるデータが同一である場合（ミラー）、サービスはデータの特定のサブセットを識別する必要はありません。ただし、サービスが異なるサーバー（サブセット、専門コレクションなど）を介して異なるデータのコレクションを提供する場合、各サーバーが提供するデータのサブセットを示す必要があります。これは、urisを使用して、あるデータセットを別のデータセットから独自に明確にしていることによって行われます。サービスが外国サービスとの契約に関するデータコレクションのコピーを提供している場合、外国サービスは、コレクションを独自のサービスに関連するものとして識別できるようにデータセット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は紹介の概念をサポートしています。これは、同じサービスまたは他の場所に別のサービスが存在することをサーバーが知ることができる場所であり、特定のクエリへのさらなる回答を提供できますが、クライアントのクエリをチェックする代わりにその事実をクライアントに転送することを決定します。紹介は、サーバーからの残りの結果とともに送信されます（ある場合）。サービスへの紹介は、紹介がわかっている場合、紹介をトリガーした特定のデータセチュリを示す必要があります。紹介とループ検出の詳細については、セクション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.
プロトコルは、単純な要求/応答メカニズムで構成されています。クライアントは、そのリクエストの結果で応答するいくつかのタイプのリクエストの1つをサーバーに送信します。すべてのリクエストと応答は、セクション5にあるDTDを使用してXML [8]でエンコードされます。リクエストには2つのタイプがあります。1つは、コモンネームの一般的なクエリです。もう1つは、サービスとその機能を説明するオブジェクトのリクエストです。結果のセットである応答のタイプは1つだけです。結果には、実際の結果項目、紹介、および/またはステータスメッセージが含まれます。
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サービスの説明要求内のステートメントを介して別のトランスポートまたはポートに変更することを選択できることに注意してください。、このドキュメントのセクション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:
たとえば、「言語」プロパティは、クエリのヒントとして与えることができます。これは、検索結果を注文するために使用できます。米国英語で最初に結果を望んでいる場合、ヨーロッパのフランス語、最後に南アメリカのスペイン語が続きます。以下をクエリに含めることができます。
<property name="language" type="rfc1766">en-US</property>
<property name="language" type="rfc1766">fr-FR</property>
<property name="language" type="rfc1766">sp-MX</property>
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番目のステートメントは、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データベースアプローチとはまったく異なり、セットの各結果は、予選（SQL Where句）で表されるすべての要件と一致する必要があります。
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サービス間の相互運用性のレベルを定義します。コアプロパティは次のとおりです。
1. CommonName: the common name associated with a resource.
1. CommonName：リソースに関連付けられた共通名。
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：RFC 2396 [3]で見つかった収集されたABNFで定義されている「Absoluteuri」。
4. description: A free text description of the resource.
4. 説明：リソースの無料テキスト説明。
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つの方法があります。最初の方法は、新しいプロパティ名を作成し、少なくとも1つのタイプを定義することです。別の方法は、新しいタイプを定義して既存のプロパティを拡張することです。次のセクションで説明する「地理」プロパティは、マルチタイプのプロパティの例です。タイプは、定義されているプロパティにのみ適用されることに注意してください。新しいプロパティが定義されている場合、そのタイプの値が既存のプロパティの既存のタイプと同一である場合でも、新しいタイプを定義する必要があります。言い換えれば、タイプは特定のプロパティにスコープされます。カスタムプロパティは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>
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は、ベースプロパティと呼ばれる一連のカスタムプロパティも定義します。要件を非常にシンプルに保つために、これらのプロパティは、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").
* 「Freeform」：地理的位置のフリーフォーム式（例：「カリフォルニアのパロアルト」）。
* 'ISO3166-1': geographical region expressed using a standard country code as defined by ISO3166-1 (e.g., "US").
* 「ISO3166-1」：ISO3166-1（例えば、「US」）で定義されている標準国コードを使用して表現された地理的領域。
* 'ISO3166-2': value = a geographical region expressed using a standard region and country codes as defined by ISO3166-2 (e.g., "US-CA").
* 「ISO 3166-2」：値= ISO 3166-2（E.N.G.、「US-CA」）で定義されている標準領域と国コードを使用して表現された地理的領域。
* 'lat-long': the latitude and longitude of a geographical location.
* 「Lat-Long」：地理的位置の緯度と経度。
o Category: The category associated with a resource. There are large numbers of possible types for this property. Two possible ones are:
o カテゴリ：リソースに関連付けられたカテゴリ。このプロパティには、可能な種類が多数あります。可能な2つのものは次のとおりです。
1. 'freeform': a free form expression for a category (e.g., "movies").
1. 「Freeform」：カテゴリのフリーフォーム式（「映画」など）。
2. 'NAICS': The North American Industry Code System.
2. 「NAICS」：北米産業コードシステム。
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 範囲：範囲は結果セット制御プロパティです。範囲プロパティは、結果セットの開始点と長さを指定するために使用されます（たとえば、10番目のレコードから5つのレコードが必要です）。1つのタイプのみが必要ですが、拡張性と一貫性のために、必要な場合は他のものを作成できます。デフォルトのタイプは「スタートレングス」で、ダッシュで区切られた2つの整数の形をとります。最初の整数は開始数で、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>
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 Operatorの正確な定義は直感的でありながら照合されたCNRPサービスに固有の文字列「BMW」のような共通名を持つリソースの選択基準として読む必要があります。
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は多くの状況で特別なケースとして白人を扱うことに注意することも重要です。場合によっては、空白を単一の空間に崩壊させます。クライアントとサーバーの両方の実装者は、クエリおよび/または結果でWhitespaceを使用することのさまざまな影響について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、および任意のプロパティなどのすべてのクエリコンポーネントをカプセル化します。クエリを空にすることはできません。クエリには、1つと1つの共通名、または1つのIDのみが含まれている必要があります。クエリには、特定のCNRPサービスによって定義されたカスタムプロパティも含めることができます。
For example, a query for the first 5 resources whose common name is like "bmw" would be expressed as:
たとえば、共通名が「BMW」のようなものである最初の5つのリソースのクエリは、次のように表現されます。
<query>
<commonname>bmw</commonname>
<property name="range" type="start-length">1-5</property>
</query>
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などのブールロジック演算子を広範囲にサポートしていません。ただし、クエリオブジェクトとそのプロパティを介して表現できる2つの暗黙の論理操作が存在します。まず、複数のプロパティと価値のペアを持つクエリは、クエリ項で暗黙的に操作を表現します。たとえば、CNRPクエリは、共通名が「BMW」のようなもので、言語が「ドイツ語」であるすべてのリソースを要求します。
<query>
<commonname>bmw</commonname>
<property name="language" type="rfc1766">
de-DE
</property>
</query>
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により、クライアントは、クエリ内の同じプロパティの複数の値を指定するか、クライアントを表現できます。たとえば、論理式：
property = value1 OR property = value2 OR property = valueN
Will be expressed as:
次のように表現されます
<property>value1</property>
<property>value2</property>
<property>valueN</property>
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自体を除きます）。特に、一般名の論理または操作はサポートされていません。クエリの順序付けまたはプロパティと価値のペアは、優先順位を意味することに注意してください。結果として、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>
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結果のコンテナです。結果に含まれるオブジェクトのタイプは、ResourceScriptor、エラー、紹介、およびスキーマです。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ブロックには、特定のResourceScriptorを参照するためにステータスメッセージで使用される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>
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.
サービスオブジェクトは、CNRPサービスのインスタンスのカプセル化を提供します。サービスは、サービスオブジェクトに含める必要があるServiceUriタグを通じて、サービスが独自に識別されます。サービスオブジェクトには、サービスの簡単なテキスト説明が含まれる場合があります。データセット、サーバー、カスタムプロパティが含まれる場合があります。
<service>
<serviceuri>http://cnrp.foo.com</serviceuri>
<description>foo.com is a CNRP service specialized on cocktail
recipes</description>
</service>
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>
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).
データセットオブジェクトは、CNからURIへのマッピングのセットを表します。たとえば、AOLキーワードとそのURIのデータベースはデータセットを構成します。データセットオブジェクトにより、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属性があります。Service ObjectのID属性と同様に、このIDは、ResourceScriptorsおよび紹介で使用され、どのサービスおよび/またはデータセットから来た、または参照しているかを指定します。
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>
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>
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>
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プロトコルへのコンプライアンスでは、データセットオブジェクトを定義または参照するためのサービスオブジェクトは必要ありません。コンプライアンスの唯一の要件は、クライアントおよび/またはサーバーが特定の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は、CNRP URI [9]ではなく、CNRP輸送メカニズムとして使用されるスキームのURIです。つまり、HTTPプロトコルを介してポート6543のホストfoo.comに通信するCNRPサーバーの場合、serveruriはhttp://foo.com:6543になります。正しい輸送を使用するために他の情報が必要な場合、その情報は他のプロパティを介して伝達できます。クライアントが最初のサービスオブジェクトを取得するために、デフォルトのCNRPポートで応答する少なくとも1つのサーバーが必要であることに注意してください。
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.
サーバーは、サービスによって宣言された1つ以上のデータセットを提供できます。提供されるデータベースは、DataSeturiプロパティを使用して指定されています。他のオブジェクトについては、地理や説明などの記述プロパティを使用してサーバーをさらに説明できます。次のXMLは、2つのCNRPサーバーを定義することにより、前の例からサービス定義を完了します。1つのサーバーは米国にあり、もう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>
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クライアントが解決サービスの機能を動的に発見する主なエントリポイントを構成します。その目的のために、解像度クエリへの応答の一部としてサービスオブジェクトを返すことができます。さらに、サービスオブジェクトは、専門のサービスクエリに対する専用の応答です（セクション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の原点サービスを示すことです。システムメッセージ、紹介、およびリソース登録者には、サービスオブジェクトへの参照を含めることができます。たとえば、複数のCNRPサービスのプロキシとして機能するCNRPサービスを想像してください。たとえば、CNRPがさまざまなソースからの結果の集約を許可することを要求しています。複数のCNRPサービスのプロキシとして機能するそのようなCNRPサービスの1つを考慮してください。このモードでは、プロキシサービスは各CNRPサブサービスに並行または連続的に接触します。次に、プロキシは個々の結果セットをCNRPクライアントに返した一意の応答に組み合わせます。Aggregate result SetにはさまざまなサービスのResourcedistrictionsが含まれているため、プロキシは個々の結果にサービスを追加して、原産地のサービスを示します。紹介されたサービスの1つが複数のデータセット内の名前を解決した場合、これらのオブジェクトはデータセットタグを使用してサービス内の特定のデータセットを参照することができます。この例は、ResourceScriptorsが彼らのサービスと原産地のデータセットを参照しているハイブリッド結果セットのものです。
<?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>
</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.
ステータスオブジェクトは、結果セットでクライアントへのメッセージを示します。オブジェクトは、ステータスコードと説明の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をREF属性に配置できます。
<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
2番目のレベルコードは、ステータスメッセージの主題を示します。この値は、5つの分類のそれぞれに適用されます。被験者のサブコードは、認識された場合、詳細サブコードによって提供される追加の詳細が認識されていなくても、報告する必要があります。サブジェクトサブコードの列挙値は次のとおりです。ox.0.xその他または未定義のステータス
* 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>
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つのケースでは、クライアントが紹介を受けるときの動作は、このメモでは定義されていません。クライアントは、それをヒントのみとして扱うような方法で紹介を追いかけることができます。この場合、データセットが処理される場合とできない場合があります。ループの検出は、「以前にこのホスト名と話をしたことがありますか？」に過ぎません。または「3番目の紹介後に停止」。これらの2つのケースは、クライアントとサーバーがその機能に関する先験的な知識を持っている単純または制約のある実装に適用される可能性が最も高くなります。そのような知識がなければ、クライアントが信頼できるループ検出を行うには、あいまいさがあまりにも多く、Visサービスとデータセットがあります。
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'.
最後のケースは、クライアントがお互いについて何も知らないかもしれない複数のサーバーと話すことを期待する場所です。このケースは、データセットまたは紹介を理解している場合、サーバーがクライアントに指示すべきものの基本的なセマンティクスを表しています。紹介は参照している正確なデータセットを指定するため、訪問したノードのリストのノードは、servideuriと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つしかサポートできない状況を示すために使用されます。この場合、サーバーは最初のデータセチュリのみを使用したことを明示的に述べています。クライアントは、指定した最初のデータセチュリのみが正しく処理されたことを考慮する必要があります。クライアントは、クエリ内の残りのデータセットが完全に無視されたことを考慮する必要があります。クライアントが実際にそれらの結果を気にかけている場合、それらは紹介として個別に送信する必要があります。最初の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（このデータセットがサポートされていない）ステータスメッセージは、クライアントがクエリで送信した特定のデータセチュリがサーバーによってサポートされていないことを示すために使用されます。この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.
クライアントがサポートするように奨励されているループ検出には正確なアルゴリズムはありませんが、これらのステータスメッセージを使用して、どのサービスとデータセットが質問されたと考えるかを明確にすることができます。これらのメッセージをどうするか、そしてそれがどの程度密接にループ検出を試みるかを決定するのはクライアント次第です。
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. サービスオブジェクト（サービススキーマ）を説明するために使用されるプロパティ、
3. The properties that belong to the query interface (Query schema),
3. クエリインターフェイス（クエリスキーマ）に属するプロパティ、
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 -Service Schemaは、サービスを説明するために使用されるプロパティを定義します。
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>
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>
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.
この応答は、サービスがクエリインターフェイスの一部としてプロパティ言語を受け入れ、言語とカクテルレシピの両方のプロパティを含むResourceScriptorsを返すことを規定しています。
<!-- The document tag -->
<!ELEMENT cnrp (query|results|servicequery)>
<!-- Used to request a Service object -->
<!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)>
<!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">
<!ELEMENT results (status? | ( service+, ( status | resourcedescriptor | referral )* )* )>
<！要素結果（ステータス？|（service、（status | resourcecriptor | referral）*）*）>
<!ELEMENT resourcedescriptor (commonname,id,resourceuri,
serviceref, datasetref?,
description,
property*)>
<!ATTLIST resourcedescriptor id ID #IMPLIED>
<!-- The entire point of all this... -->
<!ELEMENT resourceuri (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT referral (serviceref, datasetref?)>
<!ATTLIST referral id ID #IMPLIED>
<!ELEMENT status (#PCDATA)>
<!ATTLIST status code CDATA #REQUIRED>
<!ATTLIST status ref 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 -->
<!-- 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 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 dataset (property*)>
<!ATTLIST dataset id ID #IMPLIED>
<!ELEMENT datasetref EMPTY>
<!ATTLIST datasetref ref IDREF #IMPLIED>
<!ELEMENT propertyschema (propertydeclaration*)>
<!ELEMENT propertydeclaration (propertyname, propertytype*)>
<!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">
<!-- The properties you can use in a query -->
<!ELEMENT queryschema (propertyreference*)>
<!-- The properties you can expect to see in an Resource -->
<!ELEMENT resourcedescriptorschema (propertyreference*)>
<!-- The properties you can expect to find in a Service -->
<!-- definition -->
<!ELEMENT serviceschema (propertyreference*)>
<!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">
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>
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>
</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>
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>
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">
<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>
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.
2つの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を参照してください。このメディアタイプに関する重要な注意の1つは、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サーバーに接続し、POSTメソッドを使用して「/」パスを使用してコンテンツタイプを使用して「アプリケーション/CNRP XML」にヘッダーセットを受け入れるリクエストを発行します。ポストボディの内容は、送信されている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」に設定されます。サービスは、連絡先に少なくとも1つのSMTPターゲット（メールアドレス）を指定する必要があります。
This is the registration template for 'application/cnrp+xml' per [6].
これは、[6]あたり「アプリケーション/CNRP XML」の登録テンプレートです。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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.
CNRPまたはそれに依存するアプリケーションには、3つのセキュリティの脅威が存在します。中央の攻撃の男性、サービスオブジェクトをスプーフィングすることでサービスを装う悪意のあるエージェント、およびリソースの解決のために新しいレベルの間接を追加することによって引き起こされるサービス攻撃の拒否。
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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Murata、M.、St。Laurent、S。およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[8] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", February 1998.
[8] Bray、T.、Paoli、J。、およびC. Sperberg-Mcqueen、「拡張可能なマークアップ言語（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。、「一般名解決プロトコルの「Go」URIスキーム」、RFC 3368、2002年8月。
[10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[10] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 1893、1996年1月。
[11] "Country and Region Codes", ISO 3166, January 1996.
[11] 「国と地域のコード」、ISO 3166、1996年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説明：同じサービスで提供される2つのデータセット間で明確にするために使用されるURI。
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.
タイプ：Freeformプロパティ：カテゴリ説明：値は、どのように知っているかが最良の方法でサーバーによって解釈されます。この値には定義された構造はありません。
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.
タイプ：Freeformプロパティ：地理的説明：値は、どのように知っているかが最良の方法でサーバーによって解釈されることです。この値には定義された構造はありません。
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.
タイプ：Freeformプロパティ：言語説明：値は、どのように知っているかが最良の方法でサーバーによって解釈されることです。この値には定義された構造はありません。
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〜90の範囲の2桁の10桁の10桁の数字で表されるものとします。経度全体は、0〜180の範囲の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番目の子午線のポイントは、西半球に割り当てられます。この最後のコンベンションの1つの例外が許可されています。地球周辺の緯度の帯を記述する特別な条件のために、東境界座標データ要素には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年の商務省で指定されています。テクノロジー。
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説明：[3]で見つかった収集されたABNFの「絶対的な」生産を順守するURI
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 - 未定義の情報このコードは、分類できない有益なメッセージに使用されます。たとえば、サーバーがクライアントにシステム管理者の猫が青い髪を持っていることを伝えたい場合、このコードはこの情報に適した場所になります。
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 - サービスに関連する有益なメッセージこのメッセージは、一般的な意味でのサービスに関するものです。
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レベルコードの明らかな欠如は、通常、ステータスメッセージではなく、クライアントが要求したオブジェクトのみを返すサーバーによって成功することによって引き起こされます。
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.0 -- The query was only partially successful.
3.1.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 サーバーはデータセットをサポートしていませんこのステータスは、データセットを処理しないサーバーによって生成する必要があります。サーバーはいつでもこのステータスメッセージを送信できますが、サーバーがデータセチュリを含むクライアントからクエリを受信したときに特に役立ちます。この場合、クライアントが厳密なループ検出を行っている場合、クライアントはこのサービス全体が訪問されたと考える必要があります。
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 クエリで提供したデータセットのリストの最初のデータセットは、使用されている唯一のデータでした。このステータスメッセージは、クライアントがクエリに複数のデータセチュリスを含め、サーバーが一度に1つしかサポートできない状況を示すためにサーバーによって使用されます。この場合、サーバーは最初のデータセチュリのみを使用したことを明示的に述べています。クライアントは、指定した最初のデータセチュリのみが正しく処理されたことを考慮する必要があります。クライアントは、クエリ内の残りのデータセットが完全に無視されたことを考慮する必要があります。
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 このデータセットはサポートされていません。このメッセージは、クライアントからクエリで送信された特定のデータセチュリがサーバーによってサポートされていないことを示すために使用されます。この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つ以上が利用できないことを示すために使用されます。結果は生成されましたが、それらは完全な答えを表すものではない場合があります。
4.0.0 -- Something undefined caused a persistent transient failure.
4.0.0 - 未定義のものは、持続的な一時的な障害を引き起こしました。
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 - サーバーはメンテナンス中ですこのサーバーは現在メンテナンスモードになっています。このサービスから別のサーバーを試すか、後で再試行してください。
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.0.0 -- Something undefined caused a permanent failure.
5.0.0 - 未定義の何かが恒久的な障害を引き起こしました。
5.1.0 -- The query permanently failed.
5.1.0 - クエリは永久に失敗しました。
5.2.0 -- The service had a permanent failure.
5.2.0 - サービスには恒久的な障害がありました。
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 - サーバーには永続的な障害がありました。このサーバーは永続的に失敗しました。このサービスから別のサーバーを試してください。
Authors' Addresses
著者のアドレス
Nico Popp VeriSign, Inc. 487 East Middlefield Road Mountain View, CA 94043
Nico Popp Verisign、Inc。487 East Middlefield Road Mountain View、CA 94043
Phone: (650) 426-3291 EMail: npopp@verisign.com
電話：（650）426-3291メール：npopp@verisign.com
Michael Mealling VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling Verisign、Inc。21345 Ridgetop Circle Sterling、VA 20166 US
EMail: michael@verisignlabs.com
Marshall Moseley Netword, Inc. 702 Russell Avenue Gaithersburg, MD 20877-2606 US
Marshall Moseley Netword、Inc。702 Russell Avenue Gaithersburg、MD 20877-2606 US
Phone: (240) 631-1100 EMail: marshall@netword.com
電話：（240）631-1100メール：marshall@netword.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。