RFC3367 日本語訳
3367 Common Name Resolution Protocol (CNRP). N. Popp, M. Mealling, M.Moseley. August 2002. (Format: TXT=86889 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Popp
Request for Comments: 3367 M. Mealling
Category: Standards Track VeriSign, Inc.
M. Moseley
Netword, Inc.
August 2002
コメントを求めるワーキンググループN.ポップの要求をネットワークでつないでください: 3367年のM.食事カテゴリ: 標準化過程ベリサインInc.M.モーズリーNetword Inc.2002年8月
Common Name Resolution Protocol (CNRP)
俗称解決プロトコル(CNRP)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
この努力はクライアントアプリケーションが一般名解決サービスと伝えるプロトコルの創造に関するものです、ブラウザ増進と検索サイトパラダイムの両方で例示されるように。プロトコルの第一の機能は解決ですが、また、国際化とローカライズの問題は記述するつもりです。 名前解決サービスは、一般的なサーチサービスでなく、その結果、複雑なブール質問(関連性の幹部の、または、同様の能力)を提供する必要はありません。 プロトコルは簡単で、最小量の共同利用できるコアです。 追加能力を加えることができるように拡大のためのメカニズムを提供します。
Popp, et. al. Standards Track [Page 1] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[1ページ]RFC3367
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 3 2。 重要なNotes. . . . . . . . . . . . . . . . . . . . . 4 2.1Terminology. . . . . . . . . . . . . . . . . . . . . . . 4 2.2DTDはDefinitive. . . . . . . . . . . . . . . . . . . . 4 2.3です。Uniform Resource Identifier. . . . . . . . . . . . . . . 5 3。 相互作用Model.53.1Services、Servers、Datasets、およびReferrals. . . . . . . . 5 3.2Requests、およびコード化.63.5Responses. . . . . . . . . . . . . . . . . . 5 3.3Transport Independence. . . . . . . . . . . . . . . . . . 6 3.4キャラクターQueries. . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6ヒント. . . . . . . . . . . . . . . . . . . . . . . . . . 7 4。 物のModel. . . . . . . . . . . . . . . . . . . . . . . 8 4.1Properties. . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1のCore特性. . . . . . . . . . . . . . . . . . . . . 8 4.1の.2の抽象的でカスタムの特性. . . . . . . . . . . . . . 9 4.1の.3の基地の特性. . . . . . . . . . . . . . . . . . . . . 9 4.1の.4Commonは.114.2Objects. . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1Queryとストリングコード化と等価性規則を命名します…; . . . . 11 4.2.1.1 Query. . . . . . . . . . . . 12 4.2.2Results. . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2.1ResourceDescriptor. . . . . . . . . . . . . . . . . . . . 13 4.2.3Service. . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3.1Datasets. . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3.2Servers. . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.4Status Messagesの中の論理演算、CNRの.194.2.4.1Statusサーバで扱われる輸送. . . . . . . . . . . . 19 4.2.4の.2コードと記述. . . . . . . . . . . . . . . . . . 19 4.2.4の.3のステータスコード. . . . . . . . . . . . . . . . . . . . . . . 19 4.2.5の紹介. . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.5の.1の輪の検出とデータセットではなく、P、.224.2、.6Discoverability、: ServiceQueryと図式. . . . . . . . . 24 5。 CNRP. . . . . . . . . . . . . . . . . . . . . 26 6のためのXML DTD。 質問を送って、応答. . . . . . . . . . 29 7を得る例. . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1のサービス記述要求. . . . . . . . . . . . . . . 28 6.2。 輸送. . . . . . . . . . . . . . . . . . . . . . . . 30 7.1HTTP輸送. . . . . . . . . . . . . . . . . . . . . . 30 7.2SMTPは.318を輸送します。 登録: アプリケーション/cnrp+xml.319。 セキュリティ問題. . . . . . . . . . . . . . . . . 32 10。 IANA問題. . . . . . . . . . . . . . . . . . . 32参照. . . . . . . . . . . . . . . . . . . . . . . . 33
Popp, et. al. Standards Track [Page 2] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[2ページ]RFC3367
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
A.付録A: よく知られている特性とタイプ登録テンプレート. . . . . . . . . . . . . . . . . . . . . . . . 35A.1の特性. . . . . . . . . . . . . . . . . . . . . . . . 35のA.2がB.1レベル1(有益な)がコード化する.35のB.ステータスコード. . . . . . . . . . . . . . . . . . . . . . . 37をタイプする、.37、B; 2 レベル2(成功)は.38B.3レベル3(部分的な成功)コード. . . . . . . . . . . . . 38B.4レベル4(一時障害)コード. . . . . . . . . . . . 40B.5レベル5(永久的な失敗)コード. . . . . . . . . . . . 40作者のアドレス. . . . . . . . . . . . . . . . . . . . 41の完全な著作権宣言文. . . . . . . . . . . . . . . . . 42をコード化します。
1. Introduction
1. 序論
Services are arising that offer a mapping from common names to Internet resources (e.g., as identified by a URI). These services often resolve common name categories such as company names, trade names, or common keywords. Thus, such a resolution service may operate in one or a small number of categories or domains, or may expect the client to limit the resolution scope to a limited number of categories or domains. For example, the phrase "Internet Engineering Task Force" is a common name in the "organization" category, as is "Moby Dick" in the book category.
一般名からインターネット資料までマッピングを提供するサービスが起こっています(例えば、URIによって特定されるように)。 これらのサービスはしばしば会社名、商号、または一般的なキーワードなどの一般名カテゴリを決議します。 したがって、そのような解決サービスは、1か少ない数のカテゴリかドメインで作動するか、またはクライアントが解決範囲を限られた数のカテゴリかドメインに制限すると予想するかもしれません。 例えば、「インターネット・エンジニアリング・タスク・フォース」という句は「組織」カテゴリにおいて一般名です、本のカテゴリにおける「白鯨」のように。
Two classes of clients of such services are being built, browser improvements and web accessible front-end services. Browser enhancements modify the "open" or "address" field of a browser so that a common name can be entered instead of a URL. Internet search sites integrate common name resolution services as a complement to search. In both cases, these may be clients of back-end resolution services. In the browser case, the browser must talk to a service that will resolve the common name. The search sites are accessed via a browser. In some cases, the search site may also be the back-end resolution service, but in others, the search site is a front-end to a collection of back-end services.
そのようなサービスのクライアントの2つのクラスは、組立のブラウザ改良とウェブのアクセスしやすいフロントエンドサービスです。 ブラウザ増進は、URLの代わりに一般名を入れることができるようにブラウザの「戸外」か「アドレス」分野を変更します。 インターネット検索サイトは、探すために補数として一般名解決サービスを統合します。 どちらの場合も、これらはバックエンド解決サービスのクライアントであるかもしれません。 ブラウザ事件では、ブラウザは一般名を決議するサービスと話さなければなりません。 ブラウザで検索サイトはアクセスされます。 また、いくつかの場合、検索サイトはバックエンド解決サービスであるかもしれませんが、他のものでは、検索サイトはバックエンドサービスの収集へのフロントエンドです。
This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added.
この努力はクライアントアプリケーションが一般名解決サービスと伝えるプロトコルの創造に関するものです、ブラウザ増進と検索サイトパラダイムの両方で例示されるように。名前解決サービスは、一般的なサーチサービスでなく、その結果、複雑なブール質問を提供する必要はありません、関連性の幹部の、または、同様の能力。 プロトコルは簡単で、最小量の共同利用できるコアです。 追加能力を加えることができるように拡大のためのメカニズムを提供します。
Popp, et. al. Standards Track [Page 3] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[3ページ]RFC3367
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.
このドキュメントの目的のために、「一般名」は、単語か課された統語構造がなければリソースに関連するかもしれない句です。 これらの一般名はマシンエージェントと対照的に主として人間によって使用されるでしょう。 一般名「解決サービス」は一般名とデータ(リソース、リソースの情報、位置へのポインタなど)とのこれらの協会を扱います。 ただ一つの一般名は異なったデータレコードに関連しているかもしれません、そして、1つ以上の解決サービスが存在すると予想されます。 どんな一般名もどんな解決サービスにも使用されるかもしれません。
Common names are not URIs (Uniform Resource Identifiers) in that they lack the syntactic structure imposed by URIs; furthermore, unlike URNs, there is no requirement of uniqueness or persistence of the association between a common name and a resource. (Note: common names may be expressed in a URI, the syntax for which is described in RFC 3368 [9].)
URIによって課された統語構造を欠いているので、一般名はURI(Uniform Resource Identifier)ではありません。 その上、一般名とリソースとの協会のユニークさか固執の要件は全くURNsと異なっていません。 (注意: 一般名はどれがRFC3368[9]で説明されるかためにURI、構文で表されるかもしれません。)
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.
このドキュメントは一般名を役に立つようにするのに必要なparameterized解決のためにプロトコルを定義するでしょう。 「解決」は(先験的に)入力要求に合っている記述子に関連しているデータ検索と定義されます。 「Parameterizedしたこと」はマルチの特性の記述子を持つ能力を意味します。 ユニークな識別を提供するために記述子を必要としません、したがって、特定の入力質問を満たすために0つ以上の記録を返すかもしれません。
2. Important Notes
2. 重要な注意
2.1 Terminology
2.1 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[7]で説明されるように本書では解釈されることであるべきですか?
2.2 DTD is Definitive
2.2DTDはDefinitiveです。
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を含みます。(CNRPは決定的です)。 何か食い違いが見つけられるなら、DTDは得られます。
Popp, et. al. Standards Track [Page 4] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[4ページ]RFC3367
2.3 Uniform Resource Identifiers
2.3 Uniform Resource Identifier
All URIs used within the CNRP protocol MUST adhere to the 'absoluteURI' production found in the ABNF of [3]. CNRP does not define the semantics of a Base and therefore is not capable of expressing the 'URI-Reference' production.
CNRPプロトコルの中で使用されたすべてのURIが[3]のABNFで見つけられた'absoluteURI'生産を固く守らなければなりません。 CNRPは基地の意味論を定義しないで、したがって、'URI参照'生産を言い表すことができません。
3. Interaction Model
3. 相互作用モデル
3.1 Services, Servers, Datasets and Referrals
3.1 サービス、サーバ、データセット、および紹介
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実際の「サーバ」で一般名解決を提供する特定の相互作用モデルに就きます。 すべてのサーバに含まれたデータが同じであるなら(映します)、サービスはデータのどんな特定の部分集合も特定する必要はありません。 しかしながら、サービスは異なったサーバ(例えば、部分集合、専門化している収集など)を通したデータの異なった収集を提供します、それ。SHOULDは各サーバが提供するデータのすべての部分集合を示します。 唯一別のものからの1つのデータセットのあいまいさを除くのにURIを使用することによって、これをします。 サービスが外国サービスとの協定のデータの収集のコピーを提供するなら、外国サービスSHOULDは、それ自身の提供に関連されるように収集が特定されるのを許容するためにデータセット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は紹介の概念を支持します。 これがサーバは、別のServiceが存在するのを知ることができます、同じServiceの中でところであるかほかの場所では、それは、特定の質問のさらなる答えを提供できますが、クライアントのために質問をチェーニングすることの代わりにクライアントにその事実を転送すると決めます。 結果の残りと共にサーバ(もしあれば)から紹介を送ります。 サービスSHOULDへの紹介はそれが知られているなら紹介の引き金となった特定のdataseturiを示します。 紹介と輪の検出に関する詳細に関してセクション4.2.5を見てください。
3.2 Requests and Responses
3.2 要求と応答
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つにその要求の結果で反応するサーバに行かせます。 すべての要求と応答は、XMLと共に[8] セクション5で見つけられたDTDを使用することでコード化されます。 2つのタイプの要求があります。 1つは一般名のための一般的な質問です。 サービスとその能力について説明する物を求めてもう片方は要求です。 1セットの結果である1つのタイプの唯一の応答があります。 結果は実際の結果項目、紹介、そして/または、ステータスメッセージを含むことができます。
Popp, et. al. Standards Track [Page 5] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[5ページ]RFC3367
3.3 Transport Independence
3.3 輸送独立
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サービス記述要求の中の声明で異なった輸送かポートに変化するのを選ぶかもしれないことに注意しなさい、ただし、クライアントとサーバとの初期接触がHTTPの上で進行中で、1096を移植してください。 CNRPがどうHTTPを使うかに関する短い説明に関しては、このドキュメントのセクション7.1を見てください。 他の輸送が使用されているなら、デフォルトCNRPポート以外のポートの上でそれらを扱わなければなりません。
3.4 Character Encoding
3.4 キャラクターコード化
To guarantee interoperability, the following provisions apply:
相互運用性を保証するために、以下の条項は申し込まれます:
o XML queries and responses MUST be encoded as UTF-8.
o UTF-8としてXML質問と応答をコード化しなければなりません。
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プロトコル要素における使用において、他の表現でプロトコル要素を提示するか、または受け入れるのを選ぶどんなインタフェースも、正確なコード変換に責任があります、上記の条項単位で。
Popp, et. al. Standards Track [Page 6] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[6ページ]RFC3367
3.5 Queries
3.5 質問
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'と呼ばれます。 クライアントがServiceに関して何も知らない場合では、クライアントは、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クライアントにもそれらを露出させます。
3.6 Hints
3.6 ヒント
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>
<特性名前=「言語」タイプが等しい、「rfc1766「>アン米国の</特性の>」
<property name="language" type="rfc1766">fr-FR</property>
<特性名前=「言語」タイプが等しい、「rfc1766「>fr-FRの</特性の>」
<property name="language" type="rfc1766">sp-MX</property>
<特性名前=「言語」タイプが等しい、「rfc1766「>sp-MXの</特性の>」
Popp, et. al. Standards Track [Page 7] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[7ページ]RFC3367
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.
特性の声明が言語が第一の、そして、二次のなどであるかどうかを沈黙することに注意してください。 この例では、声明の注文はそれを制御します--1番目であり最初の声明は、米国の英語が第一の言語であることを意味します。 2番目の声明は2番目の領域/言語などを指定します。 *しかし、これは例にすぎません。*ヒントが支持された(or not)である範囲はサービス識別因子です。
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節)によって言い表されたすべての要件に合わなければなりません。
4. Object Model
4. オブジェクト・モデル
4.1 Properties
4.1 特性
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は特性の値をストリング値に制限しています。
4.1.1 Core Properties
4.1.1 コアの特性
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は1セットのコア資産を紹介します。 コアの特性はすべての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: 結果のためのユニークな識別子としてService(通常データベースID)から機能する不透明なストリング。 IDは必ずしつこい状態で(例えば、与えられたServiceでの質問の間の)グローバルにユニークであるというわけではありません。
3. resourceURI: An 'absoluteURI' as defined in the collected ABNF
found in RFC 2396 [3].
3. resourceURI: 集まっているABNFで定義される'absoluteURI'はRFCで2396[3]を見つけました。
4. description: A free text description of the resource.
4. 記述: リソースの無料のテキスト記述。
Popp, et. al. Standards Track [Page 8] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[8ページ]RFC3367
4.1.2 Abstract and Custom Properties
4.1.2 抽象的でカスタムの特性
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>
<特性名前="isbn"タイプが等しい、「数の「>92347231</特性の>」
4.1.3 Base Properties
4.1.3 基地の特性
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はベースの特性と呼ばれる1セットのカスタム特性を定義します。 非常に簡単に要件を保って、これらの特性は、CNRPコンプライアンスに達するように実行するために義務的ではありません。 これらの特性は必要でなく、多くのサービス(特に大きいもの)がそれらを実行すると予想されます。 追加資産を紹介する等しく重要な目標はメカニズムをフィルターにかける結果を提供することです。 これは数100万の名前を含む大きい名前空間のための要件です。
Popp, et. al. Standards Track [Page 9] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[9ページ]RFC3367
The base properties and their types are defined in Appendix A but listed here for clarity:
ベースの特性と彼らのタイプは、Appendix 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'です、そして、RFC1766[4]で言語のリストからボキャブラリーを得ます。 また、RFC1766をアップデートするなら、このタイプに、アップデートされたバージョンに記載された値も有効です。
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 地理学: リソースに関連している地理的な領域か位置。 可能なタイプの中には、以下に記載されている人もいます。 タイプに関する全リストのためのAppendix Aがこのドキュメントによって指定されるのを見てください。
* 'freeform': a free form expression for a geographical location
(e.g., "palo alto in california").
* '自由形状': 地理的な位置(例えば、「californiaのpaloアルト」)のための自由形式表現。
* 'ISO3166-1': geographical region expressed using a standard
country code as defined by ISO3166-1 (e.g., "US").
* 'ISO3166-1': ISO3166-1(例えば、「米国」)によって定義されるように標準の国名略号を使用することで言い表された地理的な領域。
* 'ISO3166-2': value = a geographical region expressed using a
standard region and country codes as defined by ISO3166-2
(e.g., "US-CA").
* 'ISO3166-2': ISO3166-2によって定義されるように地理的な値=領域は標準の領域を使用して、国名略号を言い表しました(例えば、「米国-カリフォルニア」)。
* 'lat-long': the latitude and longitude of a geographical
location.
* 'lat長い': 地理的な位置の緯度と経度。
o Category:
The category associated with a resource. There are large numbers
of possible types for this property. Two possible ones are:
o カテゴリ: リソースに関連しているカテゴリ。 この特性のための多くの可能なタイプがあります。 2つの可能なものは以下の通りです。
1. 'freeform': a free form expression for a category (e.g.,
"movies").
1. '自由形状': カテゴリ(例えば、「映画」)のための自由形式表現。
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 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.
Popp, et. al. Standards Track [Page 10] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 10] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
o Dataseturi: An absoluteURI (as defined in [3] that identifies a
defined set of Common Names and associated data.
o Dataseturi: An absoluteURI (as defined in [3] that identifies a defined set of Common Names and associated data.
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).
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).
4.1.4 Common Name String Encoding and Equivalence Rules
4.1.4 Common Name String Encoding and Equivalence Rules
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 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:
<commonname>bmw</commonname>
<commonname>bmw</commonname>
should be read as a selection criterion for a resource with a common name LIKE (similar to) the string "bmw" where the exact definition of the LIKE operator is intuitive, yet specific to the queried CNRP service.
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.
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.
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.
4.2 Objects
4.2 Objects
4.2.1 Query
4.2.1 Query
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.
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.
Popp, et. al. Standards Track [Page 11] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 11] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
For example, a query for the first 5 resources whose common name is like "bmw" would be expressed as:
For example, a query for the first 5 resources whose common name is like "bmw" would be expressed as:
<query>
<commonname>bmw</commonname>
<property name="range" type="start-length">1-5</property>
</query>
<query> <commonname>bmw</commonname> <property name="range" type="start-length">1-5</property> </query>
4.2.1.1 Logical Operations Within a Query
4.2.1.1 Logical Operations Within a 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:
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:
<query>
<commonname>bmw</commonname>
<property name="language" type="rfc1766">
de-DE
</property>
</query>
<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.
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:
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:
property = value1 OR property = value2 OR property = valueN
property = value1 OR property = value2 OR property = valueN
Will be expressed as:
Will be expressed as:
<property>value1</property> <property>value2</property> <property>valueN</property>
<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.
So if there are different properties expressed, CNRP ANDs them; if there are multiples instances of the same property expressed, CNRP ORs them.
Popp, et. al. Standards Track [Page 12] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 12] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
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.
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.
<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>
<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>
4.2.2 Results
4.2.2 Results
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.
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.
4.2.2.1 ResourceDescriptor
4.2.2.1 ResourceDescriptor
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.
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.
Popp, et. al. Standards Track [Page 13] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 13] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
<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>
<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>
4.2.3 Service
4.2.3 Service
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.
The Service object provides an encapsulation of an instance of a CNRP service. A service is uniquely identified through the serviceuri tag which MUST be included in the Service object. A Service object MAY include a a brief textual description of the service. It MAY include datasets, servers and custom properties.
<service>
<serviceuri>http://cnrp.foo.com</serviceuri>
<description>foo.com is a CNRP service specialized on cocktail
recipes</description>
</service>
<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:
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>
<service> <serviceuri>http://cnrp.foo.com</serviceuri> <property name="category" type="freeform">companies</property> <property name="geography" type="ISO3166-1">FR</property> </service>
4.2.3.1 Datasets
4.2.3.1 Datasets
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
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
Popp, et. al. Standards Track [Page 14] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 14] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
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).
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).
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.
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.
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.
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:
This example illustrates how the service object would look as it defines two datasets:
<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>
<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:
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:
Popp, et. al. Standards Track [Page 15] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 15] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
<query>
<commonname>toys r us</commonname>
<property name="dataseturi">urn:oid:1.2.3.4.666.5.4.3.1</property>
</query>
<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.
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.
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.
<referral>
<serviceref ref="i0" /><datasetref ref="i1" />
</referral>
<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.
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.
4.2.3.2 Servers
4.2.3.2 Servers
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.
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.
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
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
Popp, et. al. Standards Track [Page 16] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 16] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
other is located in France. The US server is specialized and only serves the French dataset.
other is located in France. The US server is specialized and only serves the French dataset.
<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>
<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).
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).
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:
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:
Popp, et. al. Standards Track [Page 17] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 17] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service id="i0">
<serviceuri>http://acmecorp.com</serviceuri>
<dataset id="i1">
<property name="dataseturi">
urn:oid:1.2.3.4.666.5.4.3.1
</property>
</dataset>
<dataset id="i2">
<property name="dataseturi">
urn:oid:1.2.3.4.666.10.9.8.7.6
</property>
</dataset>
</service>
<service id="i3">
<serviceuri>http://serverfarm.acmecorp.com</serviceuri>
</service>
<service id="i4">
<serviceuri>http://servers.acmecorp.co.uk</serviceuri>
<dataset id="i5">
<property name="dataseturi">
urn:oid:1.2.3.4.666.5.4.3.1
</property>
</dataset>
</service>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://www.fidonet.ca</resourceuri>
<serviceref ref="i0" /><datasetref ref="i1" />
<description>This is ye olde Canadian
Fidonet</description>
</resourcedescriptor>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://host:port/bla</resourceuri>
<serviceref ref="i3" />
<description>An old Fidonet node</description>
</resourcedescriptor>
<referral>
<serviceref ref="i0" /><datasetref ref="i2" />
</referral>
</results>
<?xml version="1.0"?> <!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>
Popp, et. al. Standards Track [Page 18] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 18] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
</cnrp>
</cnrp>
4.2.4 Status Messages
4.2.4 Status Messages
4.2.4.1 Status of CNRP, Not the Transport
4.2.4.1 Status of CNRP, Not the Transport
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.
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.
4.2.4.2 Codes and Description
4.2.4.2 Codes and Description
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.
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.
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.
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.
<status code="x.y.z" ref="i2">
The CNRP foo.com database is temporarily unreachable
</status>
<status code="x.y.z" ref="i2"> The CNRP foo.com database is temporarily unreachable </status>
4.2.4.3 Status Codes
4.2.4.3 Status Codes
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:
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:
status-code = class "." subject "." detail
class = "2"/"3"/"4"/"5"
subject = 1*3digit
detail = 1*3digit
status-code = class "." subject "." detail class = "2"/"3"/"4"/"5" subject = 1*3digit detail = 1*3digit
Popp, et. al. Standards Track [Page 19] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 19] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
The top level codes denote levels of severity of the status:
The top level codes denote levels of severity of the status:
o 1.X.X Informational
o 1.X.X Informational
* 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.
* 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 Success
* 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.
* 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 Partial Success
* 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.
* 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 Transient Failure
* 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.
* 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 Permanent Failure
* 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.
* 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:
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:
Popp, et. al. Standards Track [Page 20] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
Popp, et. al. Standards Track [Page 20] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
o X.0.X Other or Undefined Status
o X.0.X Other or Undefined Status
* No specific information is available about what subject class
this message belongs to.
* No specific information is available about what subject class this message belongs to.
o X.1.X Query Related
o X.1.X Query Related
* Any status related to some specific way in which the query was
encoded or its values with the exception of properties.
* 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 Service Related
* Any status related to the service in which this server is
cooperating in providing.
* Any status related to the service in which this server is cooperating in providing.
Appendix B contains a list of all predefined status codes
Appendix B contains a list of all predefined status codes
4.2.5 Referral
4.2.5 Referral
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.
設定された結果におけるReferralオブジェクトは異なったサービスとことによるとデータセットからの不-とって来られた結果のための場所所有者です。 CNRPサーバが関連結果を質問に提供できる別のサービスを知って、この可能性に関してクライアントに通知したがっているとき、紹介は通常起こります。 クライアントは、それがReferralオブジェクト(Serviceオブジェクトと可能な特性)の中に含まれた情報を使用することで言及しているサービスに連絡することによって紹介に続いて、付加的な結果を決議したがっているかどうか決めることができます。 Referralは階層的な解決を可能にして、複数の解決サービスを結合させるのが簡単であるメカニズムです。
Popp, et. al. Standards Track [Page 21] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[21ページ]RFC3367
<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>
<結果><がイド=を修理する、「i0"><serviceuri>http://cnrp.bar.com/</serviceuri><データセットイド=、「i1"><特性の名=、「dataseturi、「>つぼ: oid: 1.3 .6 .1 .4 .1 .782」; 1つの</特性の></データセット><データセットイドが等しい、「i2"><特性の名=、「dataseturi「>つぼ:oid:1.3.6.1.4.1.782.2の</特性の></データセット></サービス><resourcedescriptor><commonname>bmw</commonname><イド>foo。」; com: 234364 </イド><resourceuri>http://www.bmw; = 「i0"/><datasetref審判は「i1"/><記述>BMW Motorcycles、国際</記述><の特性は=を命名する」という言語と等しい」というde/</resourceuri><serviceref審判タイプ=、「iso646、「>反-DEの</特性の></resourcedescriptor><紹介><serviceref審判=、「><datasetref審判=i0"/「i2"/></紹介></結果>」
Like other CNRP objects, a referral can be further described using custom properties. Like a resourcedescriptor, a referral can have an ID attribute that is used by a status message to talk about a particular referral block.
他のCNRPオブジェクトのように、カスタム特性を使用することで紹介についてさらに説明できます。 resourcedescriptorのように、紹介はステータスメッセージによって使用される、特定の紹介ブロックに関して話すID属性を持つことができます。
4.2.5.1 Loop Detection and Dataset Handling in Servers
4.2.5.1 サーバにおける輪の検出とデータセット取り扱い
Referrals in CNRP can be handled in three ways:
3つの方法でCNRPの紹介を扱うことができます:
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
最初の2つの場合では、紹介を受けるとき、クライアントの振舞いはこのメモで定義されません。 クライアントは紹介をヒントだけとしてそれを扱うほどそのような方法で追いかけることができます。 この場合、データセットは扱われるかもしれません。 輪の検出はただ「私は以前、このホスト名と話したことがありますか?」であることができますか「3番目の紹介の後に止まってください。」 これらの2つのケースが最も申し込みそうです。
Popp, et. al. Standards Track [Page 22] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[22ページ]RFC3367
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.
クライアントとサーバが彼らの能力に関する先験的な何らかの知識を持っている簡単であるか強制的な実装。 そのような知識がなければ、クライアントが信頼できる輪の検出をするように、あまりに多くのあいまいさがサービスとデータセットと向かいあっています。
The last case is where the client expects to talk to multiple servers that may know nothing about each other. This case expresses the basic semantics of what a server should tell a client if it understands datasets or referrals. Since a referral specifies the exact dataset to which it is referring, a node in the list of visited nodes is made up of a serviceuri and a dataseturi. Both of these values need to be considered during loop detection. In the case where a service does not support datasets, the visited node is made up of the service and the 'default dataset'.
最後のケースはクライアントが互いに関して何も知らないかもしれない複数のサーバと話すと予想するところです。 データセットか紹介を理解しているなら、本件はサーバがクライアントに言うべきであることに関する基本的な意味論を言い表します。 紹介がそれが参照されている正確なデータセットを指定するので、訪問されたノードのリストのノードはserviceuriとdataseturiで作られます。 これらの値の両方が、輪の検出の間、考えられる必要があります。 サービスがデータセットをサポートしない場合では、訪問されたノードはサービスと'デフォルトデータセット'で作られます。
The major thing to remember when doing loop detection across servers is that some servers may not understand datasets at all, while others specifically rely on them. To help determine how loop detection nodes should be marked, three specific status messages have been defined:
サーバの向こう側に輪の検出をするとき思い出す主要なものはいくつかのサーバが全くデータセットを理解しないかもしれないということです、他のものが明確に彼らに頼りますが。 輪の検出ノードがどのようにマークされるべきであるかを決定するのを助けるために、3つの特定のステータスメッセージが定義されました:
The 3.1.3 (Datasets not supported) status message is used to denote that the server does not support datasets at all. It is sent in response to a query containing datasets. The client should consider that the server ignored the datasets and the client should consider this node to have been visited for all possible datasets (including the 'default' dataset).
3.1.3(サポートされなかったデータセット)ステータスメッセージは、サーバが全くデータセットをサポートしないのを指示するのに使用されます。 データセットを含む質問に対応してそれを送ります。 クライアントは、サーバがデータセットを無視したと考えるべきです、そして、クライアントはこのノードがすべての可能なデータセットのために訪問されたと考えるべきです('デフォルト'データセットを含んでいて)。
The 3.1.4 (First dataset only supported) status message is used by a server to indicate the situation where a client has included several dataseturis in its query and the server can only support one at a time. In this case, the server is explicitly stating that it used the first dataseturi only. The client should consider that only the first dataseturi specified was processed correctly. The client should consider that the remaining datasets in the query were ignored completely. They would need to be sent individually as referrals if the client really cares about those results. Only the first serviceuri/dataseturi pair should be marked as visited.
3.1.4(サポートされただけである最初のデータセット)ステータスメッセージはクライアントが質問に数個のdataseturisを含んでいた状況とサーバが一度に一つサポートすることができるだけであるのを示すサーバによって使用されます。 この場合、サーバは、最初のdataseturiだけを使用したと明らかに述べています。 クライアントは、指定された最初のdataseturiだけが正しく処理されたと考えるべきです。 クライアントは、質問における残っているデータセットが完全に無視されたと考えるべきです。 クライアントが本当にそれらの結果を心配するなら、彼らは、紹介として個別に送られる必要があるでしょう。 最初のserviceuri/dataseturi組だけが訪問されるようにマークされるべきです。
The 3.1.5 (This dataset not supported) status message is used to indicate that a specific dataseturi sent in a query by a client is not supported by the server. This serviceuri/dataseturi pair should be considered as visited by the client. If this message is sent in reply to a query specifying multiple datasets, the client should behave the same as if it received the 3.1.3 message from above. It should be considered bad form for a server to send this status message back in response to a query with multiple datasets because it is ambiguous.
クライアントによる質問はサーバで後押しされていません。3.1.5(サポートされなかったこのデータセット)ステータスメッセージは、クライアントによって訪問されるように特定のdataseturiが、このserviceuri/dataseturi組が考えられるべきであるのを送ったのを示すのに使用されます。 複数のデータセットを指定する質問に対してこのメッセージを送るなら、まるで上から3.1.3メッセージを受け取るかのようにクライアントは同じように振る舞うべきです。 それがあいまいであるのでサーバが複数のデータセットがある質問に対応してこのステータスメッセージを返送するように、それは無作法であると考えられるべきです。
Popp, et. al. Standards Track [Page 23] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[23ページ]RFC3367
While there is no exact algorithm for loop detection that clients are encouraged to support, these status messages can be used by the server to be clear about what Services and Datasets it considers to have been queried. It is up to the client to decide what to do with these messages and how closely it attempts to do loop detection.
クライアントがサポートするよう奨励される輪の検出のためのどんな正確なアルゴリズムもない間、これらのステータスメッセージはサーバによって使用されて、それが考えるServicesとDatasetsが何であるかに関して質問されて、明確にすることができます。 これらのメッセージで何をするか、そして、それが、輪の検出をするのをどれくらい密接に試みるかを決めるのは、クライアント次第です。
4.2.6 Discoverability: ServiceQuery and Schema
4.2.6 Discoverability: ServiceQueryと図式
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.
Queryのサブクラスであり、ServiceQueryオブジェクトは特定のCNRPサービスの特性のダイナミックな発見をサポートします。 CNRPコンプライアンスが、サービスがdiscoverabilityを完全に実装するのを必要としないことに注意してください。 serviceuriがあるServiceオブジェクトを返すと、特に、最小量の、しかし、十分な対応する実装は構成されます。 それにもかかわらず、私たちは、高度な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で説明されたServiceオブジェクトを返します:
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. 特性は以前は、よくServiceオブジェクト(サービス図式)について説明していました。
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--特性の参照は、与えられた図式(サービス、質問またはリソース図式)がインタフェースの中で特性を申告できるための特性の宣言の参照です。 特性の使用が必要であるか、または任意であることにかかわらず参照が指定するそのaの特性だけに注意してください。
Popp, et. al. Standards Track [Page 24] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[24ページ]RFC3367
o serviceschema -- The service schema defines the properties used to
describe the service.
o serviceschema--サービス図式はサービスについて説明するのに使用される特性を定義します。
o queryschema -- A query schema describes the structure of a query
handled by the CNRP service. The properties referred within the
query schema are part of the query interface of the resolution
service.
o queryschema--質問図式はCNRPサービスで扱われた質問の構造について説明します。 質問図式の中に述べられた特性は解決サービスの質問インタフェースの一部です。
o resourcedescriptorschema -- A ResourceDescriptor schema describes
the resource returned as a result by the CNRP service.
o resourcedescriptorschema--ResourceDescriptor図式はCNRPサービスでその結果返されたリソースについて説明します。
For example, a CNRP query to discover a service's capabilities will be in the form:
例えば、サービスの能力を発見するCNRP質問がフォームにあるでしょう:
<cnrp> <servicequery/> </cnrp>
<cnrp><servicequery/></cnrp>。
And for a CNRP service for cocktail recipes in French, the corresponding response would be:
そして、フランス語のカクテルの料理法のためのCNRPサービスのために、対応する応答は以下の通りでしょう。
<service>
<serviceuri>http://cnrp.recipe.com</serviceuri>
<propertyschema>
<propertydeclaration id="i1">
<propertyname>language</propertyname>
<propertytype>rfc1766</propertytype>
</propertydeclaration>
<propertydeclaration id="i2">
<propertyname>cocktailrecipe</propertyname>
<propertytype>freeform</propertytype>
</propertydeclaration>
</propertyschema>
<queryschema>
<propertyreference required="yes" ref="i1"/>
</queryschema>
<resourcedescriptorschema>
<propertyreference required="yes" ref="i1"/>
<propertyreference required="yes" ref="i2"/>
</resourcedescriptorschema>
</service>
<サービス><serviceuri>http://cnrp.recipe; com</serviceuri><propertyschema><propertydeclarationイド=、「i1"><propertyname>言語</propertyname><propertytype>rfc1766</propertytype></propertydeclaration><propertydeclarationイド=「i2"><propertyname>cocktailrecipe</propertyname><propertytype>自由形状</propertytype>」; 」 「propertydeclaration></propertyschema><propertyreference必要な=><queryschema</「はい」審判=「i1"/></queryschemaのresourcedescriptorschemaの>の<のpropertyreferenceの必要な><=」はい」審判=「i1"/>の<のpropertyreferenceの必要な=」はい審判=「i2"/></resourcedescriptorschema></サービス>」
This response stipulates that the service accepts the property language as part of the query interface and returns resourcedescriptors that contain both the language and cocktailRecipe properties.
この応答は、サービスが質問インタフェースの一部として特性の言語を認めて、言語とcocktailRecipeの特性の両方を含むresourcedescriptorsを返すのを規定します。
Popp, et. al. Standards Track [Page 25] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[25ページ]RFC3367
5. XML DTD for CNRP
5. CNRPのためのXML DTD
<!-- The document tag --> <!ELEMENT cnrp (query|results|servicequery)>
<!--ドキュメントタグ--><!ELEMENT cnrp(質問|結果|servicequery)>。
<!-- Used to request a Service object --> <!ELEMENT servicequery EMPTY>
<!--Serviceオブジェクトを要求するために、使用されました--><!、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)>
<!--質問は図式、--><!--イドによる特定の記録、または1セットの実体に関する特性(または、--><!--主張)が質問している一般名を要求できます。 --><!ELEMENT質問(イド| (commonname、特性*))><!ELEMENTイド(#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 commonname(#PCDATA)><!--注意、: CNRPは数個のよく知られている特性(><!)を定義して、タイプします。 詳細に関してAppendix Aを見てください。 --><!ELEMENTの特性(#PCDATA)の><!--特性の名前--><!ATTLISTの特性の名前CDATA#REQUIRED><!--特性のタイプ--><!ATTLISTの特性のタイプCDATA、「自由形状">"
<!ELEMENT results (status? |
( service+,
( status | resourcedescriptor | referral )*
)*
)>
<!ELEMENT結果(状態? | (サービス+、(状態|resourcedescriptor|紹介)*)* )>。
<!ELEMENT resourcedescriptor (commonname,id,resourceuri,
serviceref, datasetref?,
description,
property*)>
<!ATTLIST resourcedescriptor id ID #IMPLIED>
<!ELEMENT resourcedescriptor(commonname、イド、resourceuri、serviceref、datasetref?、記述、特性*)><!ATTLIST resourcedescriptorイドID#IMPLIED>。
<!-- The entire point of all this... --> <!ELEMENT resourceuri (#PCDATA)> <!ELEMENT description (#PCDATA)>
<(このすべての全体のポイント)! --><!ELEMENT resourceuri(#PCDATA)><!ELEMENT記述(#PCDATA)>。
<!ELEMENT referral (serviceref, datasetref?)> <!ATTLIST referral id ID #IMPLIED>
<!ELEMENT紹介(serviceref、datasetref?)><!ATTLIST紹介イドID#IMPLIED>。
<!ELEMENT status (#PCDATA)> <!ATTLIST status code CDATA #REQUIRED> <!ATTLIST status ref IDREF #IMPLIED>
<!ELEMENT状態(#PCDATA)><!ATTLISTステータスコードCDATA#REQUIRED><!ATTLIST状態審判IDREF#IMPLIED>。
<!-- serviceRef is used to point to one of a set of provided --> <!-- service objects. This is so that a resource can point to -->
<!--serviceRefは、1セットの提供された(><!)サービスオブジェクトの1つを示すのに使用されます。 これはリソースが示すことができるそうです--、>。
Popp, et. al. Standards Track [Page 26] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[26ページ]RFC3367
<!-- 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 serviceref EMPTY><!ATTLIST serviceref審判IDREF#IMPLIED>。
<!ELEMENT service (serviceuri, dataset*,
servers?,
description?,
property*,propertyschema?,queryschema?,resourcedescriptorschema?,
serviceschema?)>
<!-- The time to live of the schema in seconds since it was -->
<!-- retrieved -->
<!ATTLIST service ttl CDATA "0">
<!ATTLIST service id ID #IMPLIED>
<!ELEMENT serviceuri (#PCDATA)>
<!ELEMENT servers (server+)>
<!ELEMENT server (serveruri, property*)>
<!ELEMENT serveruri (#PCDATA)>
ELEMENTが調整する<(serviceuri、データセット*、サーバ(記述(特性*、propertyschema?はqueryschemaされる)、resourcedescriptorschema?はserviceschemaされます))!><!--それが検索されたので(><!)秒に図式を住ませる時間--><!ATTLISTサービスttl CDATA「0インチの><!ATTLISTサービスイドID#暗示している>の要素serviceuri(#PCDATA)><!要素<!サーバ(サーバ+)><!要素サーバ(serveruri、特性*)><!要素serveruri」(#PCDATA)>。
<!ELEMENT dataset (property*)> <!ATTLIST dataset id ID #IMPLIED>
<!ELEMENTデータセット(特性*)><!ATTLISTデータセットイドID#IMPLIED>。
<!ELEMENT datasetref EMPTY> <!ATTLIST datasetref ref IDREF #IMPLIED>
<!ELEMENT datasetref EMPTY><!ATTLIST datasetref審判IDREF#IMPLIED>。
<!ELEMENT propertyschema (propertydeclaration*)> <!ELEMENT propertydeclaration (propertyname, propertytype*)> <!ATTLIST propertydeclaration id ID #IMPLIED>
<!ELEMENT propertyschema(propertydeclaration*)><!ELEMENT propertydeclaration(propertyname、propertytype*)><!ATTLIST propertydeclarationイドID#IMPLIED>。
<!ELEMENT propertyname (#PCDATA)> <!ELEMENT propertytype (#PCDATA)> <!-- This specifies if the type is meant to be the default --> <!-- type. This is usually reserved for "freeform". --> <!ATTLIST propertytype default (no|yes) "no">
<!ELEMENT propertyname(#PCDATA)><!ELEMENT propertytype(#PCDATA)><!--これは、タイプがデフォルトであることが意味されるかどうか指定します--><--タイプしてください。 通常、これは「自由形状」のために予約されます。 --><!ATTLIST propertytypeがデフォルトとする、(いいえ| はい)「">"がありません。
<!-- The properties you can use in a query --> <!ELEMENT queryschema (propertyreference*)>
<!--あなたが質問に使用できる特性--><!ELEMENT queryschema(propertyreference*)>。
<!-- The properties you can expect to see in an Resource --> <!ELEMENT resourcedescriptorschema (propertyreference*)>
<!--Resourceのあなたが見ると予想できる特性を--><!ELEMENT resourcedescriptorschema(propertyreference*)>。
<!-- The properties you can expect to find in a Service --> <!-- definition --> <!ELEMENT serviceschema (propertyreference*)>
<!--あなたがServiceで見つけると予想できる特性--><!--定義--><!ELEMENT serviceschema(propertyreference*)>。
<!ELEMENT propertyreference EMPTY>
<!ELEMENT propertyreference EMPTY>。
Popp, et. al. Standards Track [Page 27] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[27ページ]RFC3367
<!-- This specifies if a property is required as part of --> <!-- the query. --> <!ATTLIST propertyreference ref IDREF #REQUIRED> <!ATTLIST propertyreference required (no|yes) "no">
<!--これは、特性が--><!--質問の一部として必要であるかどうか指定します。 --><!ATTLIST propertyreference審判IDREF#REQUIRED><!ATTLIST propertyreferenceが必要である、(いいえ| はい)「">"がありません。
6. Examples
6. 例
6.1 Service Description Request
6.1 サービス記述要求
This is what the client sends when it is requesting a servers schema.
サーバ図式を要求しているとき、これはクライアントが送るものです。
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<servicequery />
</cnrp>
<?xmlバージョン= 「1インチ?」><!DOCTYPE cnrp PUBLIC「-//IETF//DTD CNRP1.0//アン」、「 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.
これは結果です。 Serviceタグがサービスがあくまでもそのものとしてそれ自体について説明するのを許容するのにどう使用されるように注意してくださいか。
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service ttl="43200">
<serviceuri>urn:foo:bar</serviceuri>
<servers>
<server>
<serveruri>http://host1.acmecorp.com:4321/foo?</serveruri>
</server>
<server>
<serveruri>smtp://host2.acmecorp.com:4321/foo?</serveruri>
</server>
</servers>
<description>This is the Acme CNRP Service</description>
<!-- This property means that Acme specializes in
tradename services -->
<property name="category" type="naics">544554</property>
<property name="BannerAdServer" type="uri">
http://adserver.acmecorp.com/
</property>
<propertyschema>
<propertydeclaration id="i1">
<propertyname>workgroupID</propertyname>
<propertytype default="yes">freeform</propertytype>
<propertytype default="no">domainname</propertytype>
<?xmlバージョン= 「1インチ?」><!DOCTYPE cnrp PUBLIC「-//IETF//DTD CNRP1.0//アン」、「 http://ietf.org/dtd/cnrp-1.0.dtd 「cnrp>の<結果><サービス<>ttl=」43200「><serviceuri>つぼ:foo:バー</serviceuri><サーバ><サーバ><serveruri>http://host1。」; acmecorp.com: 4321/foo?</serveruri></サーバ><サーバ><serveruri>smtp://host2.acmecorp.com: 4321/foo?</serveruri></サーバ></サーバ><記述>ThisはAcme CNRP Service</記述><です!; この特性は、Acmeがtradenameサービスを専門に扱うことを意味します--><特性の名が「カテゴリ」タイプ=と等しい、「naics、「>544554</特性の><特性の名="BannerAdServer"が=をタイプする、「uri「> http://adserver.acmecorp 。」; 特性><propertyschema><propertydeclarationイド=com/</「i1"><propertyname>workgroupID</propertyname><propertytypeデフォルト=」はい「>自由形状</propertytype><propertytypeデフォルト=」ノー「>ドメイン名</propertytype>」
Popp, et. al. Standards Track [Page 28] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[28ページ]RFC3367
</propertydeclaration>
<propertydeclaration id="i2">
<propertyname>BannerAdServer</propertyname>
<propertytype default="yes">URI</propertytype>
</propertydeclaration>
</propertyschema>
<queryschema>
<propertyreference ref="i1" required="yes" />
</queryschema>
<resourcedescriptorschema>
<propertyreference ref="i1" required="yes" />
</resourcedescriptorschema>
<serviceschema>
<propertyreference ref="i2" required="yes" />
</serviceschema>
</service>
</results>
</cnrp>
propertydeclaration><propertydeclarationイド=</「i2"><propertyname>BannerAdServer</propertyname><propertytypeデフォルト=」はい「>URI</propertytype></propertydeclaration></propertyschema><queryschema><propertyreference審判=「i1"の必要な=」はい」; 「/></queryschema><resourcedescriptorschema><propertyreference審判=「i1"の必要な=」はい」/></resourcedescriptorschema><serviceschema><propertyreference審判=「i2"は=を必要とであった」はい」 /></serviceschema></サービス></結果></cnrp>。
6.2 Sending A Query and Getting A Response
6.2 質問を送って、返事をもらうこと。
This is the query that is sent from the client to the server:
これはクライアントからサーバに送られる質問です:
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<query>
<commonname>Fido</commonname>
<property name="geography" type="iso3166-2">
CA-QC</property>
<property name="geography" type="iso3166-1">CA</property>
<property name="language" type="rfc1766">fr-CA</property>
</query>
</cnrp>
<?xmlバージョン= 「1インチ?」><!DOCTYPE cnrp PUBLIC「-//IETF//DTD CNRP1.0//アン」「 http://ietf.org/dtd/cnrp-1.0.dtd 「><cnrp><質問><commonname>Fido</commonname><特性の名=」地理学」タイプは「iso3166-2インチの>」と等しいです; 「特性><特性名義の=</「地理学」がタイプするカリフォルニア-QCは「iso3166-1インチの>カリフォルニアの</特性の><特性の名=」言語と等しい」というタイプが等しい、「rfc1766「>frカリフォルニアの</特性の></質問></cnrpな>」
This is the result set. It is sent back in response to the query. This result set includes a referral and a non-fatal error.
これは結果セットです。 それは質問に対応して返送されます。 この結果セットは紹介と非致命的な誤りを含んでいます。
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service id="i0">
<serviceuri>http://acmecorp.com</serviceuri>
</service>
<service id="i1">
<?xmlバージョン= 「1インチ?」><!DOCTYPE cnrp PUBLIC「-//IETF//DTD CNRP1.0//アン」、「 http://ietf.org/dtd/cnrp-1.0.dtd 、「>のcnrp><結果><<がイド=を修理する、「i0"><serviceuri>http://acmecorp.com</serviceuri></サービス><サービスイド=「i1">」
Popp, et. al. Standards Track [Page 29] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[29ページ]RFC3367
<serviceuri>http://serverfarm.acmecorp.com</serviceuri>
</service>
<service id="i2">
<serviceuri>http://servers.acmecorp.co.uk</serviceuri>
</service>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://www.fidonet.ca</resourceuri>
<serviceref ref="i0" />
<description>This is ye olde Canadian Fidonet</description>
</resourcedescriptor>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://host:port/bla</resourceuri>
<serviceref ref="i1" />
<description>An old Fidonet node</description>
</resourcedescriptor>
<referral><serviceref ref="i2" /></referral>
<status code="3.1.1">
The language property 'fr-CA' was ignored
</status>
</results>
</cnrp>
<serviceuri>http://serverfarm.acmecorp.com</serviceuri></サービス><サービスイドは「i2"><serviceuri>http://servers.acmecorp.co.uk</serviceuri></サービス><resourcedescriptor><commonname>Fidonet</commonname><イド>1333459455</イド><resourceuri>http://www.fidonet」と等しいです; ca</resourceuri><serviceref審判=「i0"/><記述>Thisは>1333459455</イド><resourceuri>http://がホスティングするそのoldeのカナダのFidonet</記述></resourcedescriptor><resourcedescriptor><commonname>Fidonet</commonname><イドです」; ポート/bla</resourceuri><serviceref審判=、「resourcedescriptor i1"/>の>のAnの古いFidonetノード<記述</記述審判=>><紹介><serviceref</「i2"/></紹介><ステータスコード=」の3.1の0.1インチの>、'無視された</状態></結果は></cnrpな>言語の特性の'fr-カリフォルニアでした」。
7. Transport
7. 輸送
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は、人気への中古の支払われるべきものと他のウェブアプリケーションによる統合の容易さです。 また、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メディアTypes(そのようなものに関する例であるHTTPとSMTP)を使用する場合では、CNRPペイロードは'アプリケーション/cnrp+xml'メディアタイプを使用しなければなりません。 登録テンプレートのためにこのメディアタイプに関してセクション8を見てください。 このメディアタイプに関する1つの重要な注はCNRPがいつもUTF-8を使用するのでcharset属性が全くないということです。
7.1 HTTP Transport
7.1 HTTP輸送
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輸送はかなり簡単です。 そして、「クライアントがCNRPサーバをベースのHTTPに関連づけて、ポストメソッドを使用する要求を出す、」 /、」 文書内容がある経路、「アプリケーション/cnrp+xml」にヘッダーセットを受け入れてください。 ポスト団体の内容は送られるCNRP XMLドキュメントです。 HTTP1.1が特集するすべてが要求の間、許容されています。
Popp, et. al. Standards Track [Page 30] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[30ページ]RFC3367
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ドキュメントです。
7.2 SMTP Transport
7.2 SMTP輸送
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」に設定されたコンテントタイプがある特定のSMTP終点にCNRP XMLドキュメントを送ります。 サーバは、結果がボディーにあって、コンテントタイプが「アプリケーション/cnrp+xml」に設定されている状態で要求の創始者への応答を送ることによって、反応します。 Serviceは連絡する少なくとも1個のSMTP目標(Eメールアドレス)を指定しなければなりません。
8. Registration: application/cnrp+xml
8. 登録: アプリケーション/cnrp+xml
This is the registration template for 'application/cnrp+xml' per [6].
これは1[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と同じであるので、RFC3023[6]のXMLとMIMEの議論は適切です。
Security considerations: none specific to this media type. See
Section 9 for general CNRP considerations.
セキュリティ問題: このメディアタイプには、特定でないなにも。 一般的なCNRP問題に関してセクション9を見てください。
Interoperability considerations: 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.
広められた仕様: このメディアタイプはこのドキュメントによってタグとencodingsに置かれた制限以外のXML1.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.、このメモの「作者のアドレス」セクション
Popp, et. al. Standards Track [Page 31] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[31ページ]RFC3367
Intended usage: limited use
意図している用法: 限られた使用
Author/Change controller: the IESG
コントローラを書くか、または変えてください: IESG
9. Security Considerations
9. セキュリティ問題
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.
3つの軍事的脅威がそれによるCNRPかアプリケーションのために存在しています: Middle攻撃、Serviceオブジェクトを偽造することによってサービスのふりをしている悪意があるエージェント、およびリソースの解決のための新しいレベルの間接指定を加えることによって引き起こされたサービス不能攻撃でやれやれ。
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.
サービスがServiceオブジェクトでserviceuriを偽造することによって別のもののふりをするのを試みるところに関する場合では、Serviceオブジェクトに署名するべきです。 そして、クライアントは、署名について確かめることによって、Serviceオブジェクトの真実性について確かめることができます。 範囲の外にクライアントがどうその正式の公開鍵を得るかが、サービス発見問題によるので、あります。
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.
このドキュメントがDenial Of Service(DOS)攻撃のためにソリューションを提案できない間、新しいレベルの間接指定が作成される何時でも、DOS攻撃の機会が他の多くのケースのように作成されるのは例証できます。 サービスプロバイダーは、これを意識していて、DOS攻撃の効果を緩和するために善処するよう奨励されます。
10. IANA Considerations
10. IANA問題
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はサーバかServerオブジェクトの存在を示さないでしょう。
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」から始めなければなりません。 ステータスメッセージを地方の消費で作成して、登録できません。 このドキュメントをアップデートしない場合新しいステータスメッセージが実装するために義務的であるという要件が全くありません。 ステータスメッセージ登録証明書はさらに情報の目的のためのものです。
Popp, et. al. Standards Track [Page 32] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[32ページ]RFC3367
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.
すべての特性、タイプ、およびステータスメッセージはFirst Come First ServedベースにIANAか専門家のどんなグループによるレビューなしでも示されます。 CNRP作業部会に関するコンセンサス意見はレビューのプロトコルと実際の必要性には運用経験がいったんあると特性の登録証明書のレビューが起こるべきであるということです。 この方針が、いつかの将来の期日に変化する必要があると、このドキュメントをアップデートするでしょう。
The property and type registration templates found in Appendix A should be registered by the IANA at publication time of this document.
登録テンプレートがAppendix Aで当たった特性とタイプはこのドキュメントの公表時にIANAによって示されるはずです。
The IANA is also directed to register the Media Type specified in Section 8.
また、IANAがTypeがセクション8で指定したメディアを登録するよう指示されます。
References
参照
[1] United States, "North American Industry Classification System",
January 1997, <http://www.census.gov/epcd/www/naics.html>.
[1]合衆国、「北米の産業分類システム」、1997年1月、<http://www.census.gov/epcd/www/naics.html>。
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[2] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[3]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[4] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[4]、RFC1766、1995年3月。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[6] ムラタとM.と聖ローランとS.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[8] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup
Language (XML) 1.0", February 1998.
[8] T.とパオリとJ.とC.Sperberg-マックィーン、「拡張マークアップ言語(XML)1インチ、1998年2月」をいななかせてください。
Popp, et. al. Standards Track [Page 33] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[33ページ]RFC3367
[9] Mealling, M., "The 'go' URI Scheme for the Common Name
Resolution Protocol", RFC 3368, August 2002.
[9] 食事、M.、「'行ってください'という俗称解決プロトコルのURI体系」、RFC3368、2002年8月。
[10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
January 1996.
[10] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC1893、1996年1月。
[11] "Country and Region Codes", ISO 3166, January 1996.
[11] 「国と領域コード」、ISO3166、1996年1月。
Popp, et. al. Standards Track [Page 34] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[34ページ]RFC3367
Appendix A. Well Known Property and Type Registration Templates
付録のA.のよく知られている特性とタイプ登録テンプレート
A.1 Properties
A.1の特性
Property Name: geography Default Type: iso3166-1 Description: A geographic location
特性の名: 地理学Default Type: iso3166-1記述: 地理的な位置
Property Name: language Default Type: rfc1766 Description: A language specification
特性の名: 言語Default Type: rfc1766記述: 言語仕様
Property Name: category Default Type: freeform Description: A node in some system of semantic relationships that is considered relevant to the common-name.
特性の名: カテゴリDefault Type: 自由形状記述: 一般名に関連していると考えられる意味関係の何らかのシステムのノード。
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.
特性の名: 範囲Default Type: 範囲記述: 「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 Default Type: uri記述: URIは以前は2の間でよく同じServiceによって提供されたDatasetsのあいまいさを除いていました。
A.2 Types
A.2はタイプします。
Type: freeform Property: category Description: The value is to be interpreted by the server the best way it knows how. This value has no defined structure.
以下をタイプしてください。 自由形状Property: カテゴリ記述: 値はサーバによってそれがその方法を知っている最も良い方法で解釈されることです。 この値には、定義された構造が全くありません。
Popp, et. al. Standards Track [Page 35] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[35ページ]RFC3367
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.
以下をタイプしてください。 自由形状Property: 地理学記述: 値はサーバによってそれがその方法を知っている最も良い方法で解釈されることです。 この値には、定義された構造が全くありません。
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.
以下をタイプしてください。 自由形状Property: 言語記述: 値はサーバによってそれがその方法を知っている最も良い方法で解釈されることです。 この値には、定義された構造が全くありません。
Type: iso3166-2 Property: geography Description: The combination of country and sub-region codes found in ISO 3166-2 [11].
以下をタイプしてください。 iso3166-2 Property: 地理学記述: 国とサブリージョン・コードの組み合わせによって、ISOで3166-2が[11]であることがわかりました。
Type: iso3166-1 Property: Geography Description: Country Codes found in ISO 3166-1 [11].
以下をタイプしてください。 iso3166-1 Property: 地理学記述: 国のCodesは、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.
以下をタイプしてください。 postalcode Property: 地理学記述: 何らかの領域に、有効な郵便番号。 好例は米国で使用される郵便番号コード体系です。
Type: lat-long Property: Geography Description:
以下をタイプしてください。 lat長いProperty: 地理学記述:
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進数によって表されるものとします。 全体の度合いの経度は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.
赤道の北の地方はプラスサイン(+)、またはマイナス記号(-)の欠如で指定されるものとします、指定度合いに先行して。 Equatorの南の地方は、度合いを指定する2ケタに先行しながら、マイナス記号(-)によって指定されるものとします。 Equatorのポイントは北半球に割り当てられるものとします。
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
グリニッジ子午線の経度東は、プラスサイン(+)によって指定されるものとするか、または度合いを指定するケタに先行しながら、マイナス記号(-)によって子午線の西のLongitudesによって指定されるものとします。 グリニッジ子午線のポイントは割り当てられるものとします。
Popp, et. al. Standards Track [Page 36] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[36ページ]RFC3367
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)度合いは東Bounding Coordinateデータ要素に割り当てられるものとします。
Any spatial address with a latitude of +90 (90) or -90 degrees
will specify the position at the North or South Pole,
respectively. The component for longitude may have any legal
value.
+90(90)の緯度があるどんな空間的なアドレスか-90の度合いも北部か南極でそれぞれ位置を指定するでしょう。 経度へのコンポーネントには、どんな正当な値もあるかもしれません。
With the exception of the special condition described above, this
form is specified in Department of Commerce, 1986, Representation
of geographic point locations for information interchange (Federal
Information Processing Standard 70-1): Washington, Department of
Commerce, National Institute of Standards and Technology.
上で説明された特別な状態を除いて、このフォームは商務省、1986年に指定されます、情報交換(連邦情報処理基準70-1)のための地理的なポイント位置のRepresentation: ワシントン、商務省米国商務省標準技術局。
DEGREES = *PLUSMINUS DIGITS '.' DIGITS
PLUSMINUS = + | -
DIGITS = DIGIT *DIGIT
DIGIT = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
'度合いは*PLUSMINUSケタと等しいです'。'ケタPLUSMINUSは+と等しいです。| - ケタ*ケタケタ=ケタ=0| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Type: rfc1766 Property: Language Description: language codes as defined by RFC 1766 [4]
以下をタイプしてください。 rfc1766 Property: 言語記述: RFC1766によって定義される言語コード[4]
Type: naics Property: Category Description: North American Industry Code System [1]
以下をタイプしてください。 naics Property: カテゴリ記述: 北米の産業コード体系[1]
Type: uri Property: dataseturi Description: A URI adhering to the 'absoluteURI' production of the Collected ABNF found in [3]
以下をタイプしてください。 uri Property: dataseturi記述: 中で見つけられたCollected ABNFの'absoluteURI'生産を固く守るURI[3]
Appendix B. Status Codes
付録B.ステータスコード
B.1 Level 1 (Informative) Codes
B.1レベル1 (有益)のコード
1.0.0 -- Undefined Information
This code is used for any non-categorizable and informative
message. If, for example, the server wanted to tell the client
that the systems administrator's cat has blue hair, then this code
would be the appropriate place for this information.
1.0 .0--未定義の情報Thisコードはどんな非分類可能と通知メッセージにも使用されます。 例えば、サーバが、上級システムアドミニストレータの猫が青い髪をしているとクライアントに言いたいなら、このコードはこの情報のための適切な場所でしょうに。
Popp, et. al. Standards Track [Page 37] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[37ページ]RFC3367
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--質問関連情報Thisコードはどんな有益な情報にもクライアントが送った質問に関して使用されます。 例えば、「あなたが送った質問はかなりおもしろかったです!」
1.2.0 -- An informative message pertaining to the Service
This message concerns the Service in the general sense.
1.2 .0--Service Thisメッセージに関係する通知メッセージは一般的な意味でServiceに関係があります。
B.2 Level 2 (Success) Codes
B.2レベル2(成功) コード
2.0.0 -- Something undefined succeeded
There was success but the situation that this message concerns is
undefined.
何か未定義のものは成功しました。2.0、.0--、Thereは成功でしたが、このメッセージが関する状況は未定義です。
2.1.0 -- Query succeeded
The query succeeded. This message MUST be returned when there
were no results that matched the query. I.e., the query was
successfully handled and the correct set of results contained no
resources or referrals. The lack of results is not an error but a
successful statement about the common-name.
2.1 .0--質問は引き継がれた質問を引き継ぎました。 質問に合っていた結果が全くなかったとき、このメッセージを返さなければなりません。 すなわち、質問は首尾よく扱われました、そして、正しい結果はどんなリソースも紹介も含みませんでした。 結果の不足は誤りではなく、一般名に関するうまくいっている声明です。
Note: The apparent lack of 2.X.X level codes is caused by success usually being indicated not by a status message but by the server returning only the objects that the client requested.
以下に注意してください。 2.X.Xレベルコードの明らかな不足は通常、ステータスメッセージによって示されるのではなく、クライアントが要求したオブジェクトだけを返すサーバによって示される成功によって引き起こされます。
B.3 Level 3 (Partial Success) Codes
B.3レベル3(部分的な成功) コード
3.0.0 -- Something undefined was only partially successful
Some request by the client was only partially successful. The
exact situation or cause of that partial failure is not defined.
3.0 .0--何か未定義のものによるクライアントによる部分的にうまくいっているSome要求だけが部分的にうまくいっただけであるということでした。 その部分的な失敗の正確な状況か原因が定義されません。
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がクライアントで送った病人は、整形式ですが、無効でした。 サーバはクライアントが何に関して話していたかを理解して、いくつかの結果を返すことができるくらい賢かったです。
Popp, et. al. Standards Track [Page 38] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[38ページ]RFC3367
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 サーバは、データセットが状態がデータセットを扱わないサーバによって生成されるべきであるThisであるとサポートしません。 サーバは特にサーバがdataseturiを含むクライアントから質問を受ける時の役に立った状態でいつでもこのステータスメッセージ、しかし、それを送ることができます。 この場合、クライアントが厳しい輪の検出をしているなら、クライアントは、この全体のサービスが訪問されたと考えるべきです。
3.1.4 The first dataset in the list of datasets you gave in the
query was the only one used.
This status message is used by a server to indicate the situation
where a client has included several dataseturis in its query and
the server can only support one at a time. In this case the
server is explicitly stating that it used the first dataseturi
only. The client should consider that only the first dataseturi
specified was processed correctly. The client should consider
that the remaining datasets in the query were ignored completely.
3.1.4 あなたが質問で与えたデータセットのリストにおける最初のデータセットは使用される唯一無二でした。 このステータスメッセージはクライアントが質問に数個のdataseturisを含んでいた状況とサーバが一度に一つサポートすることができるだけであるのを示すサーバによって使用されます。 この場合、サーバは、最初のdataseturiだけを使用したと明らかに述べています。 クライアントは、指定された最初のdataseturiだけが正しく処理されたと考えるべきです。 クライアントは、質問における残っているデータセットが完全に無視されたと考えるべきです。
They would need to be sent individually as referrals if the client
really cares about those results. Only the first
serviceuri/dataseturi pair should be marked as visited if loop
detection is being handled.
クライアントが本当にそれらの結果を心配するなら、彼らは、紹介として個別に送られる必要があるでしょう。 最初のserviceuri/dataseturi組だけが輪の検出が扱われているなら訪問されるようにマークされるべきです。
3.1.5 This dataset not supported.
This message is used to indicate that a specific dataseturi sent
in a query by a client is not supported by the server. This
serviceuri/dataseturi pair should be considered as visited by the
client. If this message is sent in reply to a query specifying
multiple datasets, the client should behave the same as if it
received the 3.1.3 message from above. It should be considered
bad form for a server to send this status message back in response
to a query with multiple datasets because it is ambiguous.
3.1.5 サポートされなかったこのデータセット。 クライアントによる質問はサーバで後押しされていません。このメッセージは、クライアントによって訪問されるように特定のdataseturiが、このserviceuri/dataseturi組が考えられるべきであるのを送ったのを示すのに使用されます。 複数のデータセットを指定する質問に対してこのメッセージを送るなら、まるで上から3.1.3メッセージを受け取るかのようにクライアントは同じように振る舞うべきです。 それがあいまいであるのでサーバが複数のデータセットがある質問に対応してこのステータスメッセージを返送するように、それは無作法であると考えられるべきです。
3.2.0 -- The server caused a partially successful event
Due to some internal server error, the results returned were
incomplete.
3.2 .0--サーバは部分的にうまくいっているイベントDueを何らかの内部サーバーエラーに引き起こして、返された結果は不完全でした。
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--何らかの紹介サーバは入手できないThisステータスメッセージが通常、質問される紹介サービスの1つ以上が入手できなかったのを指示するのに使用されるということでした。 結果は生成されましたが、それらは完全な答えを代表していないかもしれません。
Popp, et. al. Standards Track [Page 39] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[39ページ]RFC3367
B.4 Level 4 (Transient Failure) Codes
B.4レベル4(一時障害) コード
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--質問は複合体に、指定されるとしての質問がこのServiceが扱うことができないくらい複雑であったということでした。
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--Serviceがリソース規制への忙し過ぎるDueであった、全体のサービスは要求を扱うことができないくらい忙しいです。 これは、また、このServiceを提供するのに協力するServersのどれかがこの同じメッセージを返したことを意味します。
4.2.2 -- The Server is in maintenance
This server is now in maintenance mode. Try another server from
this service or try again at a later time.
4.2 .2--ServerによるメインテナンスThisサーバでは、モードが現在、メインテナンス中であるということです。 このサービスから別のサーバを試みるか、または後で再試行してください。
4.2.3 -- The Server had an internal error
There was an internal error that caused the server to fail
completely.
Serverには、内部エラーがありました。4.2、.3--、Thereはサーバが完全に失敗された内部エラーでした。
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--このServiceはもう利用可能ではありません。 このServiceは、もうそれ自体を利用可能にしないと決めました。
5.2.2 -- The Server had a permanent failure.
This server has permanently failed. Try another server from this
service.
5.2 .2--Serverには、永久的な失敗がありました。 このサーバは永久に、失敗しました。 このサービスから別のサーバを試みてください。
Popp, et. al. Standards Track [Page 40] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[40ページ]RFC3367
Authors' Addresses
作者のアドレス
Nico Popp VeriSign, Inc. 487 East Middlefield Road Mountain View, CA 94043
ニコポップベリサインInc.487の東Middlefield Roadマウンテンビュー、カリフォルニア 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
ベリサインInc.21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル
EMail: michael@verisignlabs.com
メール: michael@verisignlabs.com
Marshall Moseley Netword, Inc. 702 Russell Avenue Gaithersburg, MD 20877-2606 US
マーシャルモーズリーNetword Inc.702ラッセル・Avenue MD20877-2606ゲイザースバーグ(米国)
Phone: (240) 631-1100 EMail: marshall@netword.com
以下に電話をしてください。 (240) 631-1100 メールしてください: marshall@netword.com
Popp, et. al. Standards Track [Page 41] RFC 3367 Common Name Resolution Protocol (CNRP) August 2002
etポップ、アル。 名前解決プロトコル(CNRP)2002年8月に一般的な標準化過程[41ページ]RFC3367
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Popp, et. al. Standards Track [Page 42]
etポップ、アル。 標準化過程[42ページ]
一覧
スポンサーリンク
