RFC3707 日本語訳
3707 Cross Registry Internet Service Protocol (CRISP) Requirements. A.Newton. February 2004. (Format: TXT=52411 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Newton Request for Comments: 3707 VeriSign, Inc. Category: Informational February 2004
コメントを求めるワーキンググループA.ニュートンの要求をネットワークでつないでください: 3707年のベリサインInc.カテゴリ: 情報の2004年2月
Cross Registry Internet Service Protocol (CRISP) Requirements
登録のインターネットのサービスのプロトコルの(はっきりする)の要件に交差してください。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries.
電話番号案内を変えることを通してインターネット登録は管理の、そして、操作上のデータを露出します。 このドキュメントはドメイン登録の電話番号案内のための機能条件書とこれらのサービスの他のタイプのインターネット登録の使用を広げるための一般的なベース要件を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Scope . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements Specification . . . . . . . . . . . . . . . 3
2. Internet Registry Communities . . . . . . . . . . . . . . . . 4
2.1. Domain Name System Registries . . . . . . . . . . . . . 4
2.1.1. Domain Registries . . . . . . . . . . . . . . . 4
2.1.2. Domain Registrars . . . . . . . . . . . . . . . 5
2.2. Other Registries . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Regional Internet Registries . . . . . . . . . . 5
2.2.2. Local Internet Registries . . . . . . . . . . . 5
2.2.3. Internet Routing Registries . . . . . . . . . . 5
2.2.4. Incident Coordination Contact Registries . . . . 6
2.3. Implementers . . . . . . . . . . . . . . . . . . . . . . 6
2.4. End Users . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Internet Resource Registrants . . . . . . . . . 6
2.4.2. Service Providers and Network Operators . . . . 6
2.4.3. Intellectual Property Holders . . . . . . . . . 7
2.4.4. Law Enforcement . . . . . . . . . . . . . . . . 7
2.4.5. Certificate Authorities . . . . . . . . . . . . 7
2.4.6. DNS Users . . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 要件範囲. . . . . . . . . . . . . . . . . . . 3 1.3 要件仕様. . . . . . . . . . . . . . . 3 2 インターネット登録共同体. . . . . . . . . . . . . . . . 4 2.1。 ドメインネームシステム登録. . . . . . . . . . . . . 4 2.1.1。 ドメイン登録. . . . . . . . . . . . . . . 4 2.1.2。 ドメインレジストラ. . . . . . . . . . . . . . . 5 2.2。 他の登録. . . . . . . . . . . . . . . . . . . . 5 2.2.1。 局地的なインターネット登録. . . . . . . . . . 5 2.2.2。 地方のインターネット登録. . . . . . . . . . . 5 2.2.3。 インターネットルート設定登録. . . . . . . . . . 5 2.2.4。 付随しているコーディネート接触登録. . . . 6 2.3。 Implementers. . . . . . . . . . . . . . . . . . . . . . 6 2.4。 エンドユーザ. . . . . . . . . . . . . . . . . . . . . . . 6 2.4.1。 インターネット資料記入者. . . . . . . . . 6 2.4.2。 サービスプロバイダーとネットワーク・オペレータ. . . . 6 2.4.3。 知的所有権所有者. . . . . . . . . 7 2.4.4。 法の執行. . . . . . . . . . . . . . . . 7 2.4.5。 当局. . . . . . . . . . . . 7 2.4.6を証明してください。 DNSユーザ. . . . . . . . . . . . . . . . . . . 7
Newton Informational [Page 1] RFC 3707 CRISP Requirements February 2004
はっきりした[1ページ]RFC3707要件2004年2月の情報のニュートン
2.4.7. Abusive Users . . . . . . . . . . . . . . . . . 7
2.5. Other Actors . . . . . . . . . . . . . . . . . . . . . . 8
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 8
3.1. Base Functions . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Mining Prevention . . . . . . . . . . . . . . . 8
3.1.2. Minimal Technical Reinvention . . . . . . . . . 8
3.1.3. Standard and Extensible Schemas . . . . . . . . 9
3.1.4. Level of Access . . . . . . . . . . . . . . . . 9
3.1.5. Client Processing . . . . . . . . . . . . . . . 10
3.1.6. Entity Referencing . . . . . . . . . . . . . . . 10
3.1.7. Decentralization . . . . . . . . . . . . . . . . 10
3.1.8. Query of Access Permission . . . . . . . . . . . 11
3.1.9. Authentication Distribution . . . . . . . . . . 11
3.1.10. Base Error Responses . . . . . . . . . . . . . . 11
3.1.11. Query Distribution . . . . . . . . . . . . . . . 12
3.1.12. Protocol and Schema Versioning . . . . . . . . . 12
3.1.13. Relay Bag . . . . . . . . . . . . . . . . . . . 13
3.1.14. Privacy Labels . . . . . . . . . . . . . . . . . 14
3.2. Domain Specific Functions . . . . . . . . . . . . . . . 14
3.2.1. Lookups . . . . . . . . . . . . . . . . . . . . 14
3.2.2. Searches . . . . . . . . . . . . . . . . . . . . 15
3.2.3. Information Sets . . . . . . . . . . . . . . . . 16
3.2.4. Serialization Support . . . . . . . . . . . . . 17
3.2.5. Result Set Limits . . . . . . . . . . . . . . . 17
3.2.6. DNS Delegation Referencing . . . . . . . . . . . 17
3.2.7. Distribution for Domain Registry Types . . . . . 18
3.2.8. Data Omission . . . . . . . . . . . . . . . . . 18
3.2.9. Internationalization . . . . . . . . . . . . . . 19
4. Feature Requirements . . . . . . . . . . . . . . . . . . . . . 19
4.1. Client Authentication . . . . . . . . . . . . . . . . . 19
4.2. Referrals . . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Common Referral Mechanism . . . . . . . . . . . . . . . 20
4.4. Structured Queries and Responses . . . . . . . . . . . . 20
4.5. Existing Schema Language . . . . . . . . . . . . . . . . 20
4.6. Defined Schemas . . . . . . . . . . . . . . . . . . . . 20
5. Internationalization Considerations . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 21
URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
B.1. Forums. . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.2. Working Group . . . . . . . . . . . . . . . . . . . . . . 24
B.3. Contributions . . . . . . . . . . . . . . . . . . . . . . 25
2.4.7. 虐待的なユーザ. . . . . . . . . . . . . . . . . 7 2.5。 他の俳優. . . . . . . . . . . . . . . . . . . . . . 8 3。 機能条件書. . . . . . . . . . . . . . . . . . . 8 3.1。 .1に機能. . . . . . . . . . . . . . . . . . . . . 8 3.1を基礎づけてください。 防止. . . . . . . . . . . . . . . 8 3.1.2を採掘します。 最小量の技術的な再発明. . . . . . . . . 8 3.1.3。 標準の、そして、広げることができるSchemas. . . . . . . . 9 3.1.4。 アクセスのレベル. . . . . . . . . . . . . . . . 9 3.1.5。 クライアント処理. . . . . . . . . . . . . . . 10 3.1.6。 実体参照箇所. . . . . . . . . . . . . . . 10 3.1.7。 分散. . . . . . . . . . . . . . . . 10 3.1.8。 参照許可. . . . . . . . . . . 11 3.1.9の質問。 認証分配. . . . . . . . . . 11 3.1.10。 誤り応答. . . . . . . . . . . . . . 11 3.1.11を基礎づけてください。 分配. . . . . . . . . . . . . . . 12 3.1.12について質問してください。 プロトコルと図式Versioning. . . . . . . . . 12 3.1.13。 バッグ. . . . . . . . . . . . . . . . . . . 13 3.1.14をリレーしてください。 プライバシーは.143.2をラベルします。 ドメイン具体的な機能. . . . . . . . . . . . . . . 14 3.2.1。 ルックアップ. . . . . . . . . . . . . . . . . . . . 14 3.2.2。 .3に.153.2を捜します。 一組の情報. . . . . . . . . . . . . . . . 16 3.2.4。 連載サポート. . . . . . . . . . . . . 17 3.2.5。 結果は.6に限界. . . . . . . . . . . . . . . 17 3.2を設定しました。 DNS代表団参照箇所. . . . . . . . . . . 17 3.2.7。 ドメイン登録のための分配は.8に.183.2をタイプします。 データ省略. . . . . . . . . . . . . . . . . 18 3.2.9。 国際化. . . . . . . . . . . . . . 19 4。 要件. . . . . . . . . . . . . . . . . . . . . 19 4.1を特徴としてください。 クライアント認証. . . . . . . . . . . . . . . . . 19 4.2。 紹介. . . . . . . . . . . . . . . . . . . . . . . 20 4.3。 一般的な紹介メカニズム. . . . . . . . . . . . . . . 20 4.4。 構造化された質問と応答. . . . . . . . . . . . 20 4.5。 既存のスキーマ言語. . . . . . . . . . . . . . . . 20 4.6。 Schemas. . . . . . . . . . . . . . . . . . . . 20 5を定義しました。 国際化問題. . . . . . . . . . . . . 20 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 20 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 20引用規格. . . . . . . . . . . . . . . . . . . . . 21の有益な参照. . . . . . . . . . . . . . . . . . . . 21URI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21A.用語集. . . . . . . . . . . . . . . . . . . . . . . . . . . 23B.承認. . . . . . . . . . . . . . . . . . . . . . . 24B.1。 フォーラム… 24 B.2。 作業部会. . . . . . . . . . . . . . . . . . . . . . 24B.3。 貢献. . . . . . . . . . . . . . . . . . . . . . 25
Newton Informational [Page 2] RFC 3707 CRISP Requirements February 2004
はっきりした[2ページ]RFC3707要件2004年2月の情報のニュートン
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 26
知的所有権声明。 . . . . . . . . . . . . . . . . . 25作者のアドレスの.25の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
1. 序論
1.1. Background
1.1. バックグラウンド
The expansion and growth of the Internet has seen the registry function of a traditionally centralized and managed Network Information Center become the responsibility of various autonomous, functionally disparate, and globally distributed Internet registries. With the broadening number of Internet registries, the uses of their administrative directory services have expanded from the original and traditional use of the whois [6] protocol to include the use of whois outside the scope of its specification, formal and informal definitions of syntax, undocumented security mechanisms, the use of other protocols, such as rwhois [5], to fulfill other needs, and proposals for the use of other technologies such as LDAP [4] and XML.
インターネットの拡大と成長は、伝統的に集結されて、管理されたNetworkインフォメーション・センターの登録機能が自治の、そして、機能上異種の、そして、グローバルに分配された様々なインターネット登録の責任になるのを見ました。 インターネット登録の広くなる番号によると、それらの管理電話番号案内の用途は、仕様の範囲、構文の正式で非公式の定義、正式書類のないセキュリティー対策、使用の外でwhoisの使用を含むようにwhois[6]プロトコルのオリジナル的、そして、伝統的な使用から他のプロトコル、LDAP[4]やXMLなどの他の技術の使用のために他の必要性、および提案を実現させるrwhois[5]としてのそのようなものを広くしました。
1.2. Requirements Scope
1.2. 要件範囲
The scope of the requirements captured in this document relate to the directory services of Internet registries and their related communities (Section 2.3, Section 2.4, and Section 2.5). This scoping specifically targets the requirements of domain name registries (Section 2.1). The requirements for other registry types will be made available in other memos. The requirements are of both the current use of these directory services and the desired functionality based on input from relevant forums (Appendix B.1). These requirements are not specific to any protocol. Terms used in the definition of requirements in this document may be found in the glossary (Appendix A).
本書では得られた要件の範囲はインターネット登録とそれらの関連する共同体(セクション2.3、セクション2.4、およびセクション2.5)の電話番号案内に関連します。 この見るのは明確にドメイン名登録(セクション2.1)の要件を狙います。 他のメモで他の登録タイプのための要件を利用可能にするでしょう。 要件は関連フォーラム(付録B.1)からのこれらの電話番号案内の現在の使用と入力に基づく必要な機能性の両方のものです。 これらの要件はどんなプロトコルにも特定ではありません。 要件の定義に使用される用語は用語集(付録A)で本書では見つけられるかもしれません。
The scope of the requirements in this document are also restricted to access of data from Internet registries. Requirements for modification, addition, or provisioning of data in Internet registries are out of the scope of this document.
また、要件の範囲は本書ではインターネット登録からのデータのアクセスに制限されます。 このドキュメントの範囲の外にインターネット登録のデータの変更、添加、または食糧を供給する要件があります。
1.3. Requirements Specification
1.3. 要件仕様
The requirements captured in this document are for the purpose of designing technical specifications. The words used in this document for compliance with RFC 2119 [3] do not reference or specify policy and speak only to the capabilities in the derived technology. For instance, this document may say that the protocol "MUST" support certain features. An actual service operator is always free to disable it (and then to return an error such as "permission denied".)
本書では得られた要件は技術仕様書を設計する目的のためのものです。 本書ではRFC2119[3]への承諾に使用される言葉は、派生している技術で能力だけにどんな参照もしないか、方針を指定して、または話します。 例えば、このドキュメントには、プロトコル“MUST"が、ある特徴を支持すると書かれているかもしれません。 就航オペレータはいつも無料でそれを無能にすることができます。(そして、「否定された許可」などの誤りを返すために。)
Newton Informational [Page 3] RFC 3707 CRISP Requirements February 2004
はっきりした[3ページ]RFC3707要件2004年2月の情報のニュートン
Requirements in this document specifying the capabilities of the protocol required for proper interaction between a client and a server will be specified with the "MUST/SHOULD" language of RFC 2119 [3]. This document also contains language relating to the interaction of a client with multiple servers to form a coherent, cross-network service. Such service requirements will not be described using RFC 2119 language.
本書ではクライアントとサーバとの適切な相互作用に必要であるプロトコルの能力を指定する要件がRFC2119[3]の「/がそうするべきである必須」言語で指定されるでしょう。 また、このドキュメントは一貫性を持っていた状態でaを形成するために複数のサーバとのクライアントの相互作用に関連する言語を含んでいます、交差しているネットワーク・サービス。 そのようなサービス要件は、RFC2119言語を使用することで説明されないでしょう。
While individual servers/service operators may not support all features that the protocol can support, they must respect the semantics of the protocol queries and responses. For example, a server should not return referrals if it does not have referent data.
個々のサーバ/サービスオペレータがプロトコルが支持できるすべての特徴を支持していないかもしれない間、彼らはプロトコル質問と応答の意味論を尊敬しなければなりません。 例えば、それに指示物データがないなら、サーバは紹介を返すべきではありません。
2. Internet Registry Communities
2. インターネット登録共同体
The Internet registries are composed of various communities which provide scope for the requirements in this document. These communities can be generalized into the following categories: registries, registrars, implementers, end-users, and other actors.
インターネット登録は本書では範囲を要件に提供する様々な共同体で構成されます。 以下のカテゴリにこれらの共同体を一般化できます: 登録、記録係、implementers、エンドユーザ、および他の俳優。
2.1. Domain Name System Registries
2.1. ドメインネームシステム登録
2.1.1. Domain Registries
2.1.1. ドメイン登録
Domain registries are responsible for the registration of domains for use with DNS [1] and forward lookups (i.e., does not include the .ARPA domain). These registries have typically served two main domain functions: as the registry for a gTLD or as a registry for a ccTLD. In some instances, one entity will operate multiple TLD's, both of the gTLD and ccTLD type. A gTLD or ccTLD domain registry operator may be a governmental entity, non-governmental, non-commercial entity, or a commercial entity.
使用において、ドメイン登録はDNS[1]と前進のルックアップ(すなわち、.ARPAドメインを含んでいない)でドメインの登録に責任があります。 これらの登録は2つの主なドメイン機能に通常役立ちました: gTLDのための登録として、または、ccTLDのための登録として。 ある場合に、1つの実体がTLDのgTLDとccTLDタイプの複数のものを操作するでしょう。 gTLDかccTLDドメイン登録オペレータが、政府の実体、民間の、そして、非営利的な実体、または商業実体であるかもしれません。
Some ccTLD's have second-level domain registrations similar in nature to gTLD's or have distinctly separate entities operating second-level domain registries similar in nature to gTLD's within the ccTLD.
ccTLDの何らかのものが、ccTLDの中にgTLDのものと同様のセカンドレベルドメイン登録証明書を持っているか、またはgTLDのものと同様のセカンドレベルドメイン登録を操作する明瞭に別々の実体を持っています。
Domain registries usually follow one of two models for conducting registrations of domains. The "thick" model is the more traditional model. In a "thick" domain registry, the registry contains both the operational data for the domain and the contact data (Appendix A) for the domain. In this model, the registry is typically the interface to the domain registrant but may also interface with the domain registrant through domain registrars. The "thin" model domain registry contains only operational data for domains. In the "thin" model, contact data for the domain are maintained by a domain registrar.
通常、ドメイン登録はドメインの登録証明書を行うための2つのモデルのひとりに続きます。 「厚い」モデルは、より伝統的なモデルです。 「厚い」ドメイン登録では、登録はドメインのための両方の操作上のデータとドメインのための連絡データ(付録A)を保管しています。 このモデルでは、登録は、通常ドメイン記入者へのインタフェースですが、また、ドメインレジストラを通してドメイン記入者に連結するかもしれません。 「薄い」モデルドメイン登録はドメインのための操作上のデータだけを含んでいます。 「薄い」モデルでは、ドメインのための連絡データはドメインレジストラによって保守されます。
Newton Informational [Page 4] RFC 3707 CRISP Requirements February 2004
はっきりした[4ページ]RFC3707要件2004年2月の情報のニュートン
Domain registries not described in this section (Section 2.1.1) are not the subject of this document and may have requirements that are out of scope for this subject matter.
このセクション(セクション2.1.1)で説明されなかったドメイン登録は、このドキュメントの対象でなく、この内容のために範囲の外にある要件を持っているかもしれません。
2.1.2. Domain Registrars
2.1.2. ドメインレジストラ
Domain registrars accept domain registrations from registrants on behalf of domain registries, both "thick" and "thin". In a "thin" model registry/registrar system, a domain registrar maintains the contact data of a domain while the registry maintains the operational data of a domain. In a "thick" model registry/registrar system, a domain registrar passes both the operational data and contact data to the registry. Domain registrars may register a domain on behalf of a registrant in more than one domain registry.
ドメインレジストラはともに「厚く」て「薄い」ドメイン登録を代表して記入者からドメイン登録証明書を受け入れます。 「薄い」モデル登録/記録係システムでは、登録はドメインの操作上のデータを保守しますが、ドメインレジストラはドメインに関する連絡データを保守します。 「厚い」モデル登録/記録係システムでは、ドメインレジストラは操作上のデータと連絡データの両方を登録に向かわせます。 ドメインレジストラは1つ以上のドメイン登録の記入者を代表してドメインを登録するかもしれません。
2.2. Other Registries
2.2. 他の登録
This section describes Internet registries other than those listed in Section 2.1. These descriptions are not definitive and this list is not absolute. They are provided in this document for informational purposes only.
このセクションはセクション2.1に記載されたもの以外のインターネット登録について説明します。 これらの記述は決定的ではありません、そして、このリストは絶対ではありません。 本書では情報の目的だけにそれらを提供します。
2.2.1. Regional Internet Registries
2.2.1. 局地的なインターネット登録
Regional Internet Registries (RIR's) administer the allocation of IP address space and autonomous system numbers. Each RIR serves a specific geographic region, and collectively they service the entire Internet. Each RIR is a membership-based, non-profit organization that facilitates and implements global addressing policy based on the direction of their regional community.
地方のインターネットRegistries(RIRのもの)はIPアドレス空間と自律システム番号の配分を管理します。 各RIRは特定の地理的な領域に役立ちます、そして、彼らは全体のインターネットをまとめて、修理します。 各RIRはaです。会員資格ベースです、グローバルな記述している政策を容易にして、実施する民間非営利組織がそれらの地域社会の指示を基礎づけました。
2.2.2. Local Internet Registries
2.2.2. 地方のインターネット登録
Local Internet Registries (LIR's) and National Internet Registries (NIR's) are sub-registries of RIR's and coordinate the same functions of the RIR's for smaller, more specific geographic regions, sovereign nations, and localities.
地方のインターネットRegistries(LIRのもの)とNationalインターネットRegistries(NIRのもの)はRIRのサブ登録であり、より小さくて、より特定の地理的な領域、主権国家、および場所にRIRの同じ機能を調整します。
2.2.3. Internet Routing Registries
2.2.3. インターネットルート設定登録
Internet Routing Registries are routing policy databases. Their purpose is to provide information helpful in administering Internet routers. Frequently, the syntax and contents are defined by RPSL [7].
インターネットルート設定Registriesはルーティング方針データベースです。 それらの目的はインターネットルータを管理するのに有用な情報を提供することです。 頻繁に、構文とコンテンツはRPSL[7]によって定義されます。
IRR's are operated by academic, commercial, governmental, and other types of organizations, including several of the RIR's. The contents of the databases vary and reflect the needs of the users directly
IRRのものはRIRの数個を含むアカデミックで、商業の、そして、政府の、そして、他のタイプの組織によって運用されます。 データベースの内容は、直接ユーザの必要性を変えて、反映します。
Newton Informational [Page 5] RFC 3707 CRISP Requirements February 2004
はっきりした[5ページ]RFC3707要件2004年2月の情報のニュートン
served (e.g., an ISP may look up route entries, added by their customers, to decide whether to accept specific route advertisements they receive).
役立たれています(例えば、ISPは彼らが受け取る特定のルート広告を受け入れるかどうか決めるために彼らの顧客によって加えられたルートエントリーを見上げるかもしれません)。
Unlike RIR and domain registry data, IRR data is often duplicated between separate organizations. The IRR data has the unique characteristics of being largely available through other sources (i.e., it is advertised by the Internet routing protocols) and most often having a common data format, RPSL.
RIRとドメイン登録データと異なって、IRRデータは独立した組織団体の間にしばしばコピーされます。 IRRデータには、一般的なデータの形式を他のソース(インターネットルーティング・プロトコルはすなわち、それの広告を出す)とたいてい持ちながら主に利用可能であることのユニークな特性があります、RPSL。
2.2.4. Incident Coordination Contact Registries
2.2.4. 付随しているコーディネート接触登録
Incident coordination contact registries allow operators of network resources such as network infrastructure, network names, or network services to register contact information for the purpose of providing a means of incident notification. Using this type of registry, an operator of network resources are provided information for contacting the operator of another network resource from which an incident may be occurring.
付随しているコーディネート接触登録で、ネットワークインフラ、ネットワーク名、またはネットワーク・サービスなどのネットワーク資源のオペレータは付随している通知の手段を提供する目的のための問い合わせ先を登録できます。 このタイプの登録を使用するネットワーク資源のオペレータに事件が起こっているかもしれない別のネットワーク資源のオペレータに連絡するための情報を提供します。
2.3. Implementers
2.3. Implementers
Implementers of client software are often either affiliated with large network operators, registry operators, or commercial entities offering value-added services, or are general citizens of the Internet. Much of the client software for use with the directory services of Internet registries is either freely available, open source, or both, or available as a service. Implementers of server software are often affiliated with operators or commercial entities specializing in the out-sourcing of development for Internet registries.
クライアントソフトウェアのImplementersはしばしば付加価値が付いたサービスを提供する大きいネットワーク・オペレータ、登録オペレータ、または商業実体に加わられるか、または一般的なインターネット市民です。 インターネット登録の電話番号案内がある使用のためのクライアントソフトウェアの多くが、自由に利用可能なオープンソースか両方のどちらかです。サービスとして、利用可能です。 サーバソフトウェアのImplementersはしばしばインターネット登録のための開発のアウトソーシングを専門に扱うオペレータか商業実体に加わられます。
2.4. End Users
2.4. エンドユーザ
This section describes the many types of end-users. Individuals and organizations may have multiple roles and may concurrently occupy many of the categories.
このセクションは多くのタイプのエンドユーザについて説明します。 個人と組織は、複数の役割を持って、同時にカテゴリの多くを占領するかもしれません。
2.4.1. Internet Resource Registrants
2.4.1. インターネット資料記入者
Entities given authority over an Internet resource via purchase, lease, or grant from an Internet registry, either directly or via the services of a registrar.
実体は、インターネット登録から直接か記録係のサービスでどちらかを購買でインターネット資料の上に権威を与えるか、賃貸するか、または与えます。
2.4.2. Service Providers and Network Operators
2.4.2. サービスプロバイダーとネットワーク・オペレータ
Service providers and network operators provide connectivity, routing, and naming services to many other entities, some commercial
サービスプロバイダーとネットワーク・オペレータは接続性、ルーティング、および他の多くの実体、いくつかのコマーシャルに対する命名サービスを提供します。
Newton Informational [Page 6] RFC 3707 CRISP Requirements February 2004
はっきりした[6ページ]RFC3707要件2004年2月の情報のニュートン
and some non-commercial, both large and small. Their operational and administrative staff often interact with Internet registries on behalf of other end-users. Service providers and network operators interact with all of the Internet registry operators outlined in this document on a frequent and consistent basis. For example, network operators use the directory services of Internet registries to determine contact information for network resources that have technical problems.
いくつか、非営利的で、かつ大きく、かつ小さいです。 彼らの操作上の、そして、管理のスタッフはしばしば他のエンドユーザを代表してインターネット登録と対話します。 サービスプロバイダーとネットワーク・オペレータは本書では頻繁で一貫したベースに概説されたインターネット登録オペレータのすべてと対話します。 例えば、ネットワーク・オペレータは、技術的問題を持っているネットワーク資源のための問い合わせ先を決定するのにインターネット登録の電話番号案内を使用します。
2.4.3. Intellectual Property Holders
2.4.3. 知的所有権所有者
A number of parties, such as trademark, service mark and intellectual property holders, individuals, governments and other geopolitical entities, have some legal rights on certain alphanumeric strings.
商標などの多くのパーティー(サービスマーク、知的所有権所有者、個人、政府、および他の地政学の実体)が、ある英数字のストリングの上にいくつかの法的権利を持っています。
They use the directory services of Internet registries, mostly domain registries and registrars, for purposes of maintaining and defending claims to domain names consistent with applicable laws and regulations.
彼らはインターネット登録、ほとんどドメイン登録、および記録係の電話番号案内を使用します、関係法令と一致したドメイン名にクレームを維持して、防御する目的のために。
2.4.4. Law Enforcement
2.4.4. 法の執行
Law enforcement agencies use the directory services of Internet registries to find information used to carry out the enforcement of laws within their jurisdictions.
警察機関は、情報が以前は彼らの管内の中でよく法の執行を行っていたのがわかるのにインターネット登録の電話番号案内を使用します。
2.4.5. Certificate Authorities
2.4.5. 認証局
Certificate authorities use the directory services of Internet registries as part of their verification process when issuing certificates for Internet named hosts.
ホストというインターネットのための証明書を発行するとき、認証局はそれらの検証の過程の一部としてインターネット登録の電話番号案内を使用します。
2.4.6. DNS Users
2.4.6. DNSユーザ
Users of the Internet have client software that resolves domain names to IP addresses and IP addresses to domain names. Often when trouble occurs in the resolution process of DNS, these users trouble shoot system problems with the aid of information from the directory services of Internet registries.
インターネットのユーザはIPアドレスとIPアドレスにドメイン名を決議するクライアントソフトウェアをドメイン名に持っています。 問題が解決で起こるときにはしばしば、DNS(インターネット登録の電話番号案内からの情報の援助に関するこれらのユーザトラブルシュートシステム問題)を処理してください。
2.4.7. Abusive Users
2.4.7. 虐待的なユーザ
The administrative directory services of Internet registries are often the target of practices by abusive users. Using information obtained from Internet registries, abusive users undertake certain activities that are counter to the acceptable use of the information as intended by a registry, registrar, or registrant. Many times, these practices violate law in the jurisdiction of the user,
しばしばインターネット登録の管理電話番号案内は虐待的なユーザによる習慣の目標です。 インターネット登録から得られた情報を使用して、虐待的なユーザは意図されるとしての登録、記録係、または記入者による情報の許容できる使用にカウンタである、ある活動を引き受けます。 何回も、これらの習慣はユーザの管轄における法に違反します。
Newton Informational [Page 7] RFC 3707 CRISP Requirements February 2004
はっきりした[7ページ]RFC3707要件2004年2月の情報のニュートン
registry, registrar, or registrant. One example is the use of Internet registry information for the use of sending unsolicited bulk or commercial email.
登録、記録係、または記入者。 1つの例はインターネット登録情報の送付の求められていない嵩か商業メールの使用の使用です。
2.5. Other Actors
2.5. 他の俳優
Requirements must also consider the positions and policies of other actors on the use of Internet registry directory services. These actors include governments, non-governmental policy-setting bodies, and other non-governmental organizations.
また、要件はインターネット登録電話番号案内の使用のときに他の俳優の位置と方針を考えなければなりません。 これらの俳優は政府、民間の方針を設定するボディー、および他の非政府組織を入れます。
3. Functional Requirements
3. 機能条件書
Functional requirements describe an overall need or process for which the directory service is used by an Internet registry to fulfill its obligations to provide access to its respective customers, members, or other constituents. This section describes requirements in the manner specified in Section 1.3.
機能条件書は電話番号案内がインターネット登録によって使用される、それぞれの顧客、メンバー、または他の成分へのアクセスを提供する義務を果たす総合的な必要性か過程について説明します。 このセクションはセクション1.3で指定された方法による要件について説明します。
3.1. Base Functions
3.1. 基地の機能
This section describes basic directory service protocol requirements for Internet registries. Additional requirements, specific to domain registries, are described in Domain Specific Functions (Section 3.2).
このセクションはインターネット登録のための基本の電話番号案内プロトコル要件について説明します。 追加ドメイン登録に特定の要件はDomain Specific Functions(セクション3.2)で説明されます。
3.1.1. Mining Prevention
3.1.1. 防止を採掘します。
In order to prevent the inappropriate acquisition of data from an Internet registry's directory service, many servers will limit the amount of data that may be returned in a fixed time period from a server to a client. This will most likely be especially true for anonymous access uses (see Section 3.1.4).
インターネットレジストリの電話番号案内からデータの不適当な獲得を防ぐために、多くのサーバがサーバからクライアントまでの一定時間時代に返されるかもしれないデータ量を制限するでしょう。 これはたぶん匿名のアクセス用途に特に本当になるでしょう(セクション3.1.4を見てください)。
The limits placed on differing types of data or applied depending upon access status will most likely differ from server to server based on policy and need. Support for varying service models in the effort to limit data and prevent data mining may or may not have a direct impact on the client-to-server protocol.
異なったタイプに関するデータに置かれるか、またはアクセス状況によって、適用された限界はたぶんサーバから方針と必要性に基づくサーバまで異なるでしょう。 データを制限して、データマイニングを防ぐための努力でサービスモデルを変えるサポートはクライアントからサーバへのプロトコルに直接的な衝撃を持っているかもしれません。
3.1.2. Minimal Technical Reinvention
3.1.2. 最小量の技術的な再発明
The protocol MUST NOT employ unique technology solutions for all aspects and layers above the network and transport layers. The protocol SHOULD make use of existing technology standards where applicable. The protocol MUST employ the use of network and transport layer standards as defined by the Internet Engineering Task Force. The protocol MUST define one or more congestion-aware transport mechanisms for mandatory implementation.
プロトコルは全面の独特の技術解決とネットワークの上の層とトランスポート層を使ってはいけません。 プロトコルSHOULDは適切であるところで既存の技術規格を利用します。 インターネット・エンジニアリング・タスク・フォースによって定義されるようにプロトコルはネットワークとトランスポート層規格の使用を使わなければなりません。 プロトコルは義務的な実現のために1台以上の混雑意識している移送機構を定義しなければなりません。
Newton Informational [Page 8] RFC 3707 CRISP Requirements February 2004
はっきりした[8ページ]RFC3707要件2004年2月の情報のニュートン
3.1.3. Standard and Extensible Schemas
3.1.3. 標準の、そして、広げることができるSchemas
3.1.3.1. Protocol Requirement
3.1.3.1. プロトコル要件
The protocol MUST contain standard schemas for the exchange of data needed to implement the functionality in this document. In addition, there MUST be a means to allow the use of schemas not defined by the needs of this document. Both types of schemas MUST use the same schema language. The schemas MUST be able to express data elements with identifying tags for the purpose of localization of the meaning of the identifying tags.
プロトコルは本書では機能性を実行するのに必要であるデータの交換のための標準のschemasを含まなければなりません。 さらに、このドキュメントの必要性によって定義されなかったschemasの使用を許す手段があるに違いありません。 schemasの両方のタイプは同じスキーマ言語を使用しなければなりません。 schemasは同定標識の意味のローカライズの目的のために同定標識でデータ要素を表すことができなければなりません。
3.1.3.2. Service Description
3.1.3.2. サービス記述
The client-to-server protocol must define a standard set of data structures or schemas to be used when exchanging information. It must also poses the ability to allow for the use of newer data structures that are currently not foreseen by this specification. In both cases, the description and specification of both types of data structures or schemas must be done in the same way (i.e., the same schema language).
クライアントからサーバへのプロトコルは、情報交換するとき、使用されるためにデータ構造かschemasの標準セットを定義しなければなりません。 それは引き起こさなければなりません。また、現在この仕様で見通されないより新しいデータ構造の使用を考慮する能力を引き起こします。 どちらの場合も、同様に(すなわち、同じスキーマ言語)、データ構造かschemasの両方のタイプの記述と仕様をしなければなりません。
The schemas must also be capable of "tagging" data with a unique identifier. This identifier can then be used to localize the name of that type of data. For instance, a piece of data may have the value "Bob" and its type identified with the number "5.1". Client software could use this to display "Name: Bob" in an English locale or "Nombre: Bob" in a Spanish locale.
また、schemasはユニークな識別子でデータに「タグ付けをすることができなければなりません」。 そして、そのタイプに関するデータの名前を局所化するのにこの識別子を使用できます。 例えば、1つのデータで、値の「ボブ」とそのタイプを数の「5.1インチ」と同一視しているかもしれません。 ソフトウェアが表示するのにこれを使用できたクライアントは「以下を命名します」。 または、イギリスの現場の「ボブ」、「Nombre:」 スペインの現場の「ボブ。」
3.1.4. Level of Access
3.1.4. アクセスのレベル
3.1.4.1. Protocol Requirement
3.1.4.1. プロトコル要件
The protocol MUST NOT prohibit an operator from granularly assigning multiple types of access to data according to the policies of the operator. The protocol MUST provide an authentication mechanism and MUST NOT prohibit an operator from granting types of access based on authentication.
プロトコルはオペレータの方針によると、粒状に複数のタイプのデータへのアクセスを割り当てるのからオペレータを禁じてはいけません。 プロトコルは、認証機構を提供しなければならなくて、認証に基づくアクセスのタイプを与えるのからオペレータを禁じてはいけません。
The protocol MUST provide an anonymous access mechanism that may be turned on or off based on the policy of an operator.
プロトコルはオペレータの方針に基づいてつけたり消したりされるかもしれない匿名のアクセス機構を提供しなければなりません。
Newton Informational [Page 9] RFC 3707 CRISP Requirements February 2004
はっきりした[9ページ]RFC3707要件2004年2月の情報のニュートン
3.1.4.2. Service Description
3.1.4.2. サービス記述
Server operators will offer varying degrees of access depending on policy and need. The following are some examples:
サーバオペレータは方針と必要性による異なった度のアクセスを提供するでしょう。 ↓これはいくつかの例です:
o users will be allowed access only to data for which they have a
relationship
o それらには関係があるデータだけへのアクセスはユーザに許されるでしょう。
o unauthenticated or anonymous access status may not yield any
contact information
o 非認証されたか匿名のアクセス状況は少しの問い合わせ先ももたらさないかもしれません。
o full access may be granted to a special group of authenticated
users
o 完全なアクセスは認証されたユーザの特別なグループに承諾されるかもしれません。
The types of access allowed by a server will most likely vary from one operator to the next.
サーバによって許されたアクセスのタイプはたぶん1人のオペレータから次に異なるでしょう。
3.1.5. Client Processing
3.1.5. クライアント処理
The protocol MUST be capable of allowing machine parsable requests and responses.
プロトコルはマシン「パー-可能」要求と応答を許容できなければなりません。
3.1.6. Entity Referencing
3.1.6. 実体参照箇所
There MUST be a mechanism for an entity contained within a server to be referenced uniquely by an entry in another server.
別のサーバにはエントリーで唯一参照をつけられるためにサーバの中に含まれた実体のためのメカニズムがあるに違いありません。
3.1.7. Decentralization
3.1.7. 分散
3.1.7.1. Protocol Requirement
3.1.7.1. プロトコル要件
The protocol MUST NOT require the aggregation of data to a central repository, server, or entity. The protocol MUST NOT require aggregation of data indexes or hints to a central repository, server, or entity.
プロトコルは中央倉庫、サーバ、または実体にデータの集合を必要としてはいけません。 データインデックスの集合を必要としてはいけない、さもなければ、プロトコルは中央倉庫、サーバ、または実体をほのめかします。
3.1.7.2. Service Description
3.1.7.2. サービス記述
Some server operators may have a need to coordinate service in a mesh or some other framework with other server operators. However, the ability to operate a CRISP compliant server must not require this.
サーバオペレータの中には他のサーバオペレータと共にメッシュかある他の枠組みにおけるサービスを調整する必要性を持っている人もいるかもしれません。 しかしながら、CRISP対応することのサーバを操作する能力はこれを必要としてはいけません。
Newton Informational [Page 10] RFC 3707 CRISP Requirements February 2004
はっきりした[10ページ]RFC3707要件2004年2月の情報のニュートン
3.1.8. Query of Access Permission
3.1.8. 参照許可の質問
3.1.8.1. Protocol Requirement
3.1.8.1. プロトコル要件
The protocol MUST provide a mechanism allowing a client to determine if a query will be denied before the query is submitted according to the appropriate policies of the operator.
プロトコルはクライアントがオペレータの適切な方針によると、質問を提出する前に質問を否定するかどうかと決心できるメカニズムを提供しなければなりません。
3.1.8.2. Service Description
3.1.8.2. サービス記述
Because usage scenarios will differ depending on both policy and type of service, some server operators may want to provide the ability for a client to predetermine its ability to retrieve data from a query. However, some operators will not allow this for security reasons, policy restrictions, or other matters.
方針とサービスのタイプの両方に頼っていて、用法シナリオが異なるので、何人かのサーバオペレータがクライアントが質問からデータを検索する性能を予定する能力を提供したがっているかもしれません。 しかしながら、何人かのオペレータはセキュリティ理由、方針制限、または他の件のためにこれを許さないでしょう。
3.1.9. Authentication Distribution
3.1.9. 認証分配
3.1.9.1. Protocol Requirement
3.1.9.1. プロトコル要件
The protocol MUST NOT require any Internet registry to participate in any authentication system. The protocol MUST NOT prohibit the participation by an Internet registry in federated, distributed authentication systems.
プロトコルは、どんな認証システムにも参加するためにどんなインターネット登録も必要としてはいけません。 プロトコルは連邦化されて、分配された認証システムでのインターネット登録のそばで参加を禁止してはいけません。
3.1.9.2. Service Description
3.1.9.2. サービス記述
Some server operators may have a need to delegate authentication to another party or participate in a system where authentication information is distributed. However, the ability to operate a CRISP compliant server must not require this.
サーバオペレータの中には別のパーティーへ認証を代表として派遣するか、または認証情報が分配されているシステムに参加する必要性を持っている人もいるかもしれません。 しかしながら、CRISP対応することのサーバを操作する能力はこれを必要としてはいけません。
3.1.10. Base Error Responses
3.1.10. 基地の誤り応答
The protocol MUST be capable of returning the following types of non-result or error responses to all lookups and searches:
プロトコルは、非結果かすべてのルックアップへの誤り応答の以下のタイプを返すことができなければならなくて、探されます:
o permission denied - a response indicating that the search or
lookup has failed due to insufficient authorization.
o 応答が、検索かルックアップが不十分な承認のため失敗したのを示して、否定された許可。
o not found - the desired results do not exist.
o --見つけられないで、望み通りの成果は存在していません。
o insufficient resources - the search or lookup requires resources
that cannot be allocated.
o 不十分なリソース--検索かルックアップが割り当てることができないリソースを必要とします。
Newton Informational [Page 11] RFC 3707 CRISP Requirements February 2004
はっきりした[11ページ]RFC3707要件2004年2月の情報のニュートン
3.1.11. Query Distribution
3.1.11. 質問分配
3.1.11.1. Protocol Requirement
3.1.11.1. プロトコル要件
The protocol MUST NOT prohibit a server from participating in a query distribution system.
プロトコルは質問流通制度に参加するのからサーバを禁じてはいけません。
3.1.11.2. Service Description
3.1.11.2. サービス記述
For lookups and searches requiring distribution of queries, the client must be allowed to distribute these queries among the participants in an established mesh of server operators. It is not a requirement that the protocol enable the discovery of servers, but cooperating servers should be able to intelligently handle distribution with its established mesh. Individual server operators will respond to all queries received according to their policies for authentication, privacy, and performance.
質問の分配を必要とするルックアップと検索において、クライアントにサーバオペレータの確立したメッシュの関係者にこれらの質問を広げさせなければなりません。 それはプロトコルがサーバの発見を可能にするという要件ではありませんが、協力サーバは知的に確立したメッシュによる分配を扱うことができるべきです。 個々のサーバオペレータは認証、プライバシー、および性能のためのそれらの方針に応じて受けられたすべての質問に応じるでしょう。
However, the ability to operate a CRISP compliant server must not require the participation in any query distribution system.
しかしながら、CRISP対応することのサーバを操作する能力はどんな質問流通制度への参加も必要としてはいけません。
3.1.12. Protocol and Schema Versioning
3.1.12. プロトコルと図式Versioning
3.1.12.1. Protocol Requirements
3.1.12.1. プロトコル要件
The protocol MUST provide a means by which the end-systems can either identify or negotiate over the protocol version to be used for any query or set of queries.
プロトコルはエンドシステムがどんな質問やセットの質問にも使用されるためにプロトコルバージョンを特定するか、または交渉できる手段を提供しなければなりません。
All resource-specific schema MUST provide a version identifier attribute which uniquely and unambiguously identifies the version of the schema being returned in the answer set to a query.
すべてのリソース特有の図式が唯一、明白に答えセットで質問に返される図式のバージョンを特定するバージョン識別子属性を提供しなければなりません。
3.1.12.2. Service Description
3.1.12.2. サービス記述
The service should allow end-systems using different protocol versions to fallback to a mutually supported protocol version. If this is not possible, the service must provide a meaningful error which indicates that this is the specific case.
サービスは、互いにサポートしているプロトコルバージョンへの後退に異なったプロトコルバージョンを使用することでエンドシステムを許容するべきです。 これが可能でないなら、サービスはこれが特定のそうであることを示す重要な誤りを提供しなければなりません。
The service must suggest negotiation and/or recovery mechanisms for clients to use when an unknown schema version is received.
未知の図式バージョンが受け取られているとき、サービスはクライアントが使用する交渉、そして/または、回収機構を示さなければなりません。
Newton Informational [Page 12] RFC 3707 CRISP Requirements February 2004
はっきりした[12ページ]RFC3707要件2004年2月の情報のニュートン
3.1.13. Relay Bag
3.1.13. リレーバッグ
The term "bag" in this section describes a flexible container which may contain unspecified data.
このセクションの「バッグ」という用語は不特定のデータを含むかもしれないフレキシブル・コンテナについて説明します。
3.1.13.1. Protocol Requirement
3.1.13.1. プロトコル要件
When issuing a referral, the protocol MUST be capable of supplying a relay bag from the server to the client, and the protocol MUST be capable of allowing the client to submit this relay bag with a query to the referred server. The use of the relay bag MUST be OPTIONAL. The protocol MUST NOT make any assumptions regarding the contents of the relay bag, but the relay bag MUST be described using the schema language of the protocol.
紹介を発行するとき、プロトコルはサーバからのリレーバッグをクライアントに供給できなければなりません、そして、プロトコルはクライアントが質問でこのリレーバッグを参照されたサーバに提出するのを許容できなければなりません。リレーバッグの使用はOPTIONALであるに違いありません。 プロトコルはリレーバッグのコンテンツに関する少しの仮定もしてはいけませんが、プロトコルのスキーマ言語を使用して、リレーバッグについて説明しなければなりません。
The protocol MUST provide different error messages to indicate whether the bag is of unrecognized format (permanent failure), if it contains unacceptable data (permanent failure), or if it contains data that means processing is refused at this time (transient failure).
プロトコルはバッグが認識されていない形式(永久的な失敗)のものであるかを示すために異なったエラーメッセージを提供しなければなりません、容認できないデータ(永久的な失敗)を含んでいるか、または処理がこのとき拒否されることを意味するデータ(一時障害)を含んでいるなら。
There MUST be no more than one bag per referral. The protocol MUST NOT make an association or linkage between successive bags in a referral chain.
1紹介あたり1個未満のバッグがあるに違いありません。 プロトコルは紹介チェーンで連続したバッグの間の協会かリンケージを作ってはいけません。
The client MUST pass the bag as part of any query made to a referrant server as a result of a referral.
クライアントは紹介の結果、referrantサーバにされたどんな質問の一部としてもバッグを渡さなければなりません。
3.1.13.2. Service Description
3.1.13.2. サービス記述
In some models where service coordination among participating server
operators is utilized, there might be needs to allow a referring
server to pass operator-to-operator coordination data along with the
referral to the referent server. Such needs might be auditing or
tracking. This feature requirement allows a server to pass to the
client a flexible container of unspecified data ("bag") that the
client should pass to the referent server. The bag has no meaning to
the client.
参加しているサーバオペレータの中のサービスコーディネートが利用されている何人かのモデルには、参照サーバが紹介に伴うオペレータからオペレータへのコーディネートデータを指示物サーバに通過するのを許容する必要性があります。そのような必要性は、監査か追跡しているかもしれません。 サーバはこの特徴要件でクライアントが指示物サーバに通過するべきである不特定のデータ(「膨らむ」)のフレキシブル・コンテナをクライアントに追い抜くことができます。バッグはクライアントに意味を持っていません。
Newton Informational [Page 13] RFC 3707 CRISP Requirements February 2004
はっきりした[13ページ]RFC3707要件2004年2月の情報のニュートン
3.1.14. Privacy Labels
3.1.14. プライバシーラベル
3.1.14.1. Protocol Requirement
3.1.14.1. プロトコル要件
When a value in an answer to a query is given, the protocol MUST be capable of tagging the value with the following labels:
質問の答えにおける値を与えるとき、プロトコルは以下のラベルを値にタグ付けできなければなりません:
1. do not redistribute
1.、再配付しません。
2. special access granted
2. 承諾された特別なアクセス
The protocol MAY define other values for this purpose, but MUST define values defined above at a minimum. The protocol MUST be capable of attaching these labels concurrently.
プロトコルは、このために他の値を定義するかもしれませんが、上で最小限で定義された値を定義しなければなりません。 プロトコルは同時にこれらのラベルを取り付けることができなければなりません。
3.1.14.2. Service Description
3.1.14.2. サービス記述
Internet registries will have varying policies regarding the access to their data. Some registries may grant certain classes of users with access to data that would not normally be given to most users. In these cases, registries may want to tag the values in these entries with labels specifying the responsibilities accompanying these special user rights.
インターネット登録には、それらのデータへのアクセスに関する異なった方針があるでしょう。 いくつかの登録が通常、ほとんどのユーザに与えられていないデータへのアクセスと共にあるクラスのユーザを与えるかもしれません。 これらの場合では、登録は、これらの特別なユーザ権利に伴いながら、ラベルが責任を指定しているこれらのエントリーで値にタグ付けをしたがっているかもしれません。
3.2. Domain Specific Functions
3.2. ドメイン具体的な機能
These functions describe requirements specifically needed by domain registries (Section 2.1.1) and domain registrars (Section 2.1.2). Requirements specific to other registries (Section 2.2) MUST be specified separately. No compliant server operator is required to support the functions required by every registry type.
これらの機能はドメイン登録(セクション2.1.1)とドメインレジストラ(セクション2.1.2)によって明確に必要とされた要件について説明します。 別々に他の登録(セクション2.2)に特定の要件を指定しなければなりません。 どんな言いなりになっているサーバオペレータもすべての登録タイプによって必要とされた機能をサポートする必要はありません。
3.2.1. Lookups
3.2.1. ルックアップ
3.2.1.1. Protocol Requirement
3.2.1.1. プロトコル要件
The protocol MUST contain the following lookup functions:
プロトコルは以下のルックアップ機能を含まなければなりません:
1. Contact lookup given a unique reference to a contact of a
resource.
1. リソースの接触のユニークな参照を考えて、ルックアップに連絡してください。
2. Nameserver lookup given a fully-qualified host name or IP address
of a nameserver.
2. ネームサーバの完全に適切なホスト名かIPアドレスが与えられたネームサーバルックアップ。
3. Domain lookup given a fully-qualified domain name.
3. 完全修飾ドメイン名が与えられたドメインルックアップ。
See Section 3.2.3 for the requirements regarding the expected return values.
期待収益値に関する要件に関してセクション3.2.3を見てください。
Newton Informational [Page 14] RFC 3707 CRISP Requirements February 2004
はっきりした[14ページ]RFC3707要件2004年2月の情報のニュートン
3.2.1.2. Service Description
3.2.1.2. サービス記述
These lookups are all single index queries and should produce zero or only one entity.
これらのルックアップは、ただ一つのインデックス質問であり、ゼロか1つの実体だけを生産するべきです。
Depending on the policy and need of an Internet registry, a server operator may not allow all or any of these lookups to return part or all of the information. See Section 3.2.3.
インターネット登録の方針と必要性によって、サーバオペレータはこれらのルックアップのすべてかいずれにも情報の部分かすべてを返させないかもしれません。 セクション3.2.3を見てください。
3.2.2. Searches
3.2.2. 検索
3.2.2.1. Protocol Requirement
3.2.2.1. プロトコル要件
The protocol MUST contain the following search functions:
プロトコルは以下の検索機能を含まなければなりません:
1. Domain name search given an exact match or reasonable subset of a
name. This search SHOULD allow for parameters and qualifiers
designed to allow better matching of internationalized domain
names and SHOULD allow for both exact and partial matching within
the limits of internationalized domain names. This search SHOULD
NOT require special transformations of internationalized domain
names to accommodate this search. This search MUST provide a
means to narrow the search by names delegated under a particular
TLD.
1. 名前の完全な一致か妥当な部分集合を考えて、ドメイン名は探されます。 この検索SHOULDは国際化ドメイン名の、より良いマッチングを許すように設計されたパラメタと資格を与える人を考慮します、そして、SHOULDは国際化ドメイン名の限界の中で正確なものと同様に部分的なマッチングを考慮します。 この検索SHOULD NOTは、この検索を収容するために国際化ドメイン名の特別な変換を必要とします。 この検索は特定のTLDの下で代表として派遣された名前の検索を狭くする手段を提供しなければなりません。
2. Domain registrant search by either exact name or partial name
match with the ability to narrow the search to registrants of a
particular TLD.
2. 特定のTLDの記入者に検索を狭くする能力との正確な名前か部分的な名前マッチのどちらかによるドメイン記入者検索。
3. Domains hosted by a nameserver given the fully-qualified host name
or IP address of a nameserver.
3. ネームサーバの完全に適切なホスト名かIPアドレスを考えて、ネームサーバによって接待されたドメイン。
See Section 3.2.3 for the requirements regarding the expected return values.
期待収益値に関する要件に関してセクション3.2.3を見てください。
3.2.2.2. Service Description
3.2.2.2. サービス記述
Depending on the policy and need of an Internet registry, a server operator may not allow all or any of these searches to return part or all of the information. See Section 3.1.4. Access to information resulting from these searches may also be limited, depending on policy, by quantity. Section 3.2.5 describes these types of restrictions.
インターネット登録の方針と必要性によって、サーバオペレータはこれらの検索のすべてかいずれにも情報の部分かすべてを返させないかもしれません。 セクション3.1.4を見てください。 また、量に従って方針によって、これらからの結果になるのが捜す情報入手は制限されるかもしれません。 セクション3.2 .5 これらのタイプの制限について説明します。
Some Internet registries may also be participating in a query distribution system. See Section 3.1.11.
また、いくつかのインターネット登録が質問流通制度に参加しているかもしれません。 セクション3.1.11を見てください。
Newton Informational [Page 15] RFC 3707 CRISP Requirements February 2004
はっきりした[15ページ]RFC3707要件2004年2月の情報のニュートン
3.2.3. Information Sets
3.2.3. 一組の情報
3.2.3.1. Protocol Requirements
3.2.3.1. プロトコル要件
The data sets for contacts, nameservers, and domains MUST be able to express and represent the attributes and allowable values of registration requests in domain registration and provisioning protocols.
接触、ネームサーバ、およびドメインのためのデータセットは、ドメインの取得とプロトコルに食糧を供給することにおける、登録要求の属性と許容量を言い表して、表すことができなければなりません。
The schema MUST be capable of expressing the following information for domains:
図式はドメインのための以下の情報を言い表すことができなければなりません:
o activation status
o 起動状態
o registrant
o 記入者
o nameservers
o ネームサーバ
o technical, billing or other contacts
o 技術的であるか、請求しているかまたは他の接触
o registry delegating the domain
o ドメインを代表として派遣する登録
o registrar for the domain
o ドメインへの記録係
The data set for domains MUST be able to express arbitrary textual information for extensions on an individual operator basis. Examples of such information are license agreements, authorized use policies, extended status notifications, marketing/for sale notices, and URI references to other sources.
ドメインのためのデータセットは個々オペレータベースで拡大のための任意の文字情報を言い表すことができなければなりません。 許諾契約であり、認可されたそのような情報に関する例は方針、拡張状態通知、マーケティング/売り物の通知、および他のソースについてのURI言及を使用します。
3.2.3.2. Service Description
3.2.3.2. サービス記述
It is not expected that every Internet registry supply all of the information spelled out above, however the schemas employed by the protocol must be capable of expressing this information should a registry need to provide it.
あらゆるインターネット登録が上にスペルアウトされた情報のすべてを供給するというわけではないと予想されて、しかしながら、プロトコルによって使われたschemasはこの情報がそうするべきである言い表すことができなければなりません。それを提供する登録の必要性。
The following sections describe requirements relative to the use of schemas with respect to individual registry need and policy:
以下のセクションは個々の登録の必要性と方針に関してschemasの使用に比例して要件について説明します:
o Section 3.2.8
o セクション3.2 .8
o Section 3.2.5
o セクション3.2 .5
o Section 3.1.4
o セクション3.1 .4
o Section 3.1.1
o セクション3.1 .1
Newton Informational [Page 16] RFC 3707 CRISP Requirements February 2004
はっきりした[16ページ]RFC3707要件2004年2月の情報のニュートン
3.2.4. Serialization Support
3.2.4. 連載サポート
The schemas used by the protocol SHOULD be capable of off-line serialization
schemas、プロトコルSHOULDによって使用されて、オフライン連載ができてください。
Off-line serialization allows for implementation independent operations such as backup and recovery, load-balancing, etc. This MAY also make possible, in whole or in part, data escrow capabilities and other usages, however such usages are out of the scope of this document.
オフライン連載はバックアップや回復、負荷分散などの実装単独操業を考慮します。 また、これは可能な全体か一部データエスクロー能力の、そして、他の用法になるかもしれなくて、このドキュメントの範囲の外にしかしながら、そのような用法があります。
3.2.5. Result Set Limits
3.2.5. 結果は制限を加えました。
3.2.5.1. Protocol Requirement
3.2.5.1. プロトコル要件
The protocol MUST contain a feature, used at the discretion of a server operator, to allow a server to express to a client a limit on the number of results from searches and lookups. When returning result sets, the protocol MUST be able to make the following distinctions:
プロトコルはサーバが検索とルックアップから結果の数における限界をクライアントに言い表すのを許容するのにサーバオペレータの裁量に使用される特徴を含まなければなりません。 戻っている結果がセットするとき、プロトコルは以下の区別をすることができなければなりません:
1. an empty result set.
1. 空の結果はセットしました。
2. a result set truncated for the purpose of improving performance
bottlenecks.
2. 結果セットは向上する目的のために性能のネックに先端を切らせました。
3. a result set truncated to comply with Section 3.1.1
3. セクション3.1.1に従うために先端を切られた結果セット
3.2.5.2. Service Description
3.2.5.2. サービス記述
Client software will operate more usefully if it can understand reasons for the truncation of result sets. Of course, some Internet registries may not be able to expose their policies for the limiting of result sets, but, when it is possible, clients will have a better operational view. This may eliminate re-queries and other repeated actions that are not desirable.
結果セットのトランケーションの理由を理解できると、クライアントソフトウェアは、より有効に作動するでしょう。 もちろん、いくつかのインターネット登録は結果セットの制限のためのそれらの方針を暴露できないかもしれませんが、それが可能であるときに、クライアントには、より良い操作上の眺めがあるでしょう。 これは再質問と他の望ましくない繰り返された動作を排除するかもしれません。
3.2.6. DNS Delegation Referencing
3.2.6. DNS委譲参照箇所
3.2.6.1. Protocol Requirement
3.2.6.1. プロトコル要件
The protocol MUST use the delegation authority model available in DNS [1] as the primary means for determining the authoritative source for information regarding domains or any other objects when applicable.
[1] 予備選挙が適切であるときにドメインかいかなる他のオブジェクトの情報のためにも権威筋を決定するために意味するようにプロトコルはDNSに手があいている委譲権威モデルを使用しなければなりません。
Newton Informational [Page 17] RFC 3707 CRISP Requirements February 2004
はっきりした[17ページ]RFC3707要件2004年2月の情報のニュートン
3.2.6.2. Service Description
3.2.6.2. サービス記述
The intent of this requirement is to have clients use the DNS delegation model to find servers authoritative for resources instead of using a master or central server containing pointer information. In other words, when a resource is naturally mapped by DNS, the desired behavior is to consult the DNS to find an authoritative server containing information about that resource. Using 'example.com', the authoritative server for information about example.com according to the registrant of that domain may be found by querying the DNS zone for example.com. To find the registry information for example.com, the DNS zone for .com should be queried.
この要件の意図はクライアントにマスターを使用することの代わりにリソースか指針情報を含むセントラルサーバーに、サーバが正式であることがわかるのにDNS委譲モデルを使用させることです。 言い換えれば、望まれた行動はリソースがDNSによって自然に写像されるとき、そのリソースの情報を含む正式のサーバを見つけるためにDNSに相談することです。 'example.com'を使用して、そのドメインの記入者に従ったexample.comの情報のための正式のサーバは、DNSゾーンfor example.comについて質問することによって、見つけられるかもしれません。 登録情報がfor example.comであることがわかるために、.comのためのDNSゾーンは質問されるべきです。
There are cases where resources will not naturally map into the DNS delegation hierarchy. This requirement is not meant to force such a mapping.
ケースがリソースが自然に委譲階層構造をDNSに写像しないところにあります。 この要件はそのようなマッピングを強制することになっていません。
3.2.7. Distribution for Domain Registry Types
3.2.7. ドメイン登録タイプのための分配
3.2.7.1. Protocol Requirement
3.2.7.1. プロトコル要件
The protocol MUST NOT prohibit the distribution of data to exclude any of the registry/registrar models stated in Section 2.1.1. The protocol MUST be capable of expressing referrals and entity references between the various models described in Section 2.1.1.
プロトコルは、セクション2.1.1で述べられた登録/記録係モデルのどれかを除くためにデータの分配を禁止してはいけません。 プロトコルはセクション2.1.1で説明された様々なモデルの間の紹介と実体参照を言い表すことができなければなりません。
3.2.7.2. Service Description
3.2.7.2. サービス記述
Depending on the domain registry/registrar model in use, technical data for a domain may only reside in one server while contact data for the same domain may only reside in a server operated by a separate entity. However, in many uses, this is not the situation. Therefore, the service must accommodate for the various registration distribution models of domain registry types described in Section 2.1.1 while complying with Section 3.1.7.
同じドメインのための連絡データが別々の実体によって操作されたサーバであるだけであるかもしれない間、ドメイン登録/記録係モデルに使用中に頼っていて、ドメインのための技術データは1つのサーバであるだけであるかもしれません。 しかしながら、多くの用途で、これは状況ではありません。 したがって、サービスはドメインの様々な登録分配モデルのためにセクション3.1.7に従っている間セクション2.1.1で説明された登録タイプに対応しなければなりません。
3.2.8. Data Omission
3.2.8. データ省略
3.2.8.1. Protocol Requirement
3.2.8.1. プロトコル要件
When a value in an answer to a query cannot be given due to policy constraints, the protocol MUST be capable of expressing the value in one of three ways:
方針規制のため質問の答えにおける値を与えることができないとき、プロトコルは3つの方法の1つで値を言い表すことができなければなりません:
1. complete omission of the value without explanation
1. 説明のない価値の完全な省略
2. an indication that the value cannot be given due to insufficient
authorization
2. 不十分な承認のため値を与えることができないという指示
Newton Informational [Page 18] RFC 3707 CRISP Requirements February 2004
はっきりした[18ページ]RFC3707要件2004年2月の情報のニュートン
3. an indication that the value cannot be given due to privacy
constraints regardless of authorization status
3. プライバシー規制のため承認状態にかかわらず値を与えることができないという指示
The protocol MAY define other values for this purpose, but MUST define values defined above at a minimum.
プロトコルは、このために他の値を定義するかもしれませんが、上で最小限で定義された値を定義しなければなりません。
3.2.8.2. Service Description
3.2.8.2. サービス記述
Internet registries will have varying constraints regarding their ability to expose certain types of data, usually social information. Server operators must have the ability to accommodate this need while client software will be more useful when provided with proper explanations. Therefore, depending on policy, a server operator has a choice between not returning the data at all, signaling a permission error, or indicating a privacy constraint.
インターネット登録には、あるタイプに関するデータ、通常社会的な情報を暴露する彼らの能力に関して異なった規制があるでしょう。 サーバオペレータには、より役に立つ間に適切な説明を提供するとき、クライアントソフトウェアがなるこの必要性を収容する能力がなければなりません。 したがって、サーバオペレータには、方針によって、全くデータを返さないとき、選択があります、許可誤りに合図するか、またはプライバシー規制を示して。
3.2.9. Internationalization
3.2.9. 国際化
The schema defining domain related resources MUST conform to RFC 2277 [2] regarding textual data. In particular, the schema MUST be able to indicate the charset and language in use with unstructured textual data.
ドメイン関連するリソースを定義する図式は原文のデータに関してRFC2277[2]に従わなければなりません。 特に、図式は不統一な原文のデータで使用中のcharsetと言語を示すことができなければなりません。
The protocol MUST be able to support multiple representations of contact data, with these representations complying with the requirements in Section 3.2.3. The protocol MUST be able to provide contact data in UTF-8 and SHOULD be able to provide contact data in US-ASCII, other character sets, and capable of specifying the language of the data.
プロトコルは連絡データの複数の表現をサポートできなければなりません、これらの表現がセクション3.2.3における要件に従っていて。 プロトコルはUTF-8とSHOULDの連絡データを提供できなければなりません。米国のASCIIの、そして、他の文字集合に連絡データを提供できて、データの言語を指定できてください。
4. Feature Requirements
4. 特徴要件
Feature requirements describe the perceived need derived from the functional requirements for specific technical criteria of the directory service. This section describes requirements in the manner specified in Section 1.3.
特徴要件はディレクトリサービスの特定の技術的な評価基準のための機能条件書から得られた知覚された必要性について説明します。 このセクションはセクション1.3で指定された方法による要件について説明します。
4.1. Client Authentication
4.1. クライアント認証
Entities accessing the service (users) MUST be provided a mechanism for passing credentials to a server for the purpose of authentication. The protocol MUST provide a mechanism capable of employing many authentication types and capable of extension for future authentication types.
サービス(ユーザ)にアクセスする実体は認証の目的のために資格証明書をサーバに通過するのにメカニズムを提供しなければなりません。 プロトコルは多くの認証タイプを雇うことができて将来の認証タイプにおいて、拡大ができるメカニズムを提供しなければなりません。
Newton Informational [Page 19] RFC 3707 CRISP Requirements February 2004
はっきりした[19ページ]RFC3707要件2004年2月の情報のニュートン
4.2. Referrals
4.2. 紹介
To distribute queries for search continuations and to issue entity references, the protocol MUST provide a referral mechanism.
検索続刊のための質問を広げて、実体参照を発行するために、プロトコルは紹介メカニズムを提供しなければなりません。
4.3. Common Referral Mechanism
4.3. 一般的な紹介メカニズム
To distribute queries for search continuations and to issue entity references, the protocol MUST define a common referral scheme and syntax.
検索続刊のための質問を広げて、実体参照を発行するために、プロトコルは一般的な紹介体系と構文を定義しなければなりません。
4.4. Structured Queries and Responses
4.4. 構造化された質問と応答
To provide for machine consumption as well as human consumption, the protocol MUST employ structured queries and responses.
人間の消費と同様にマシン消費に備えるために、プロトコルは構造化された質問と応答を使わなければなりません。
4.5. Existing Schema Language
4.5. 既存のスキーマ言語
To provide structured queries and responses and allow for minimal technological reinvention, the protocol MUST employ a pre-existing schema language.
構造化された質問と応答を提供して、最小量の技術的な再発明を考慮するために、プロトコルは先在のスキーマ言語を使わなければなりません。
4.6. Defined Schemas
4.6. 定義されたSchemas
To provide for machine consumption as well as human consumption, the protocol MUST define schemas for use by the structured queries and responses.
人間の消費と同様にマシン消費に備えるために、プロトコルは使用のために構造化された質問と応答でschemasを定義しなければなりません。
5. Internationalization Considerations
5. 国際化問題
Requirements defined in this document MUST consider the best practices spelled out in [2].
本書では定義された要件は[2]に詳しく説明される中で最も良い習慣を考えなければなりません。
6. IANA Considerations
6. IANA問題
IANA consideration for any service meeting these requirements will depend upon the technologies chosen and MUST be specified by any document describing such a service.
これらの必要条件を満たすどんなサービスも技術によるので、IANAの考慮を選ばれていて、そのようなサービスについて説明するどんなドキュメントでも指定しなければなりません。
7. Security Considerations
7. セキュリティ問題
This document contains requirements for the validation of authenticated entities and the access of authenticated entities compared with the access of non-authenticated entities. This document does not define the mechanism for validation of authenticated entities. Requirements defined in this document MUST allow for the implementation of this mechanism according best common practices.
このドキュメントは非認証された実体のアクセスと比べて認証された実体の合法化と認証された実体のアクセスのための要件を含んでいます。 このドキュメントは認証された実体の合法化のためにメカニズムを定義しません。 本書では定義された要件は最も良い一般的な習慣このメカニズムの実装を考慮しなければなりません。
Newton Informational [Page 20] RFC 3707 CRISP Requirements February 2004
はっきりした[20ページ]RFC3707要件2004年2月の情報のニュートン
The requirement in Section 3.1.4 must be weighed against other requirements specifying search or lookup capabilities.
検索を指定する他の要件かルックアップ能力にセクション3.1.4における要件について比較考量しなければなりません。
This document contains requirements for referrals and entity references. Client implementations based on these requirements SHOULD take proper care in the safe-guarding of credential information when resolving referrals or entity references according to best common practices.
このドキュメントは紹介と実体参照のための要件を含んでいます。 最も良い一般的な習慣に従って紹介か実体参照を決議するとき、SHOULDが資格証明情報の保護における適切な注意を払うというこれらの要件に基づくクライアント実装。
This document contains requirements for the distribution of queries among a mesh of participating service providers. Protocols proposed to meet these requirements must be able to protect against the use of that distribution system as a vector of distributed denial of service attacks or unauthorized data mining.
このドキュメントは参加サービスプロバイダーのメッシュの中に質問の分配のための要件を含んでいます。 これらの必要条件を満たすために提案されたプロトコルは分散DoS攻撃か権限のないデータマイニングのベクトルとしてその流通制度の使用から守ることができなければなりません。
Normative References
引用規格
[1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[1]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[2] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[2]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Informative References
有益な参照
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[4] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[5] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
June 1997.
[5] ウィリアムソン、S.、Kosters、M.、Blacka、D.、シン、J.、およびK.Zeilstra、「紹介Whois(RWhois)はV1.5"について議定書の中で述べます、RFC2167、1997年6月」。
[6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
954, October 1985.
[6]HarrenstienとK.とスタールとM.とE.Feinler、「NICNAME/WHOIS」、RFC954、1985年10月。
[7] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
Policy Specification Language (RPSL)", RFC 2622, June 1999.
[7]AlaettinogluとC.とVillamizarとC.とGerichとE.とKessensとD.とマイヤーとD.とベイツとT.とKarrenbergとD.とM.テルプストラ、「ルート設定方針仕様言語(RPSL)」、RFC2622、1999年6月。
URIs
URI
[8] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
[8] <http://www.ietf.org/議事/00dec/00dec-41.htm>。
[9] <http://www.ietf.org/proceedings/01aug/51-40.htm>
[9] <http://www.ietf.org/議事/01aug/51-40.htm>。
Newton Informational [Page 21] RFC 3707 CRISP Requirements February 2004
はっきりした[21ページ]RFC3707要件2004年2月の情報のニュートン
[10] <http://www.uwho.verisignlabs.com/
Final-WhoIsPanel-Aug15-Resume.pdf>
[10] <最終的なWhoIsPanel-8月15日http://www.uwho.verisignlabs.com/Resume.pdf>。
[11] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/
min_database.html>
[11] <http://www.ripe.net/熟している/熟しているミーティング/アーカイブ/40/数分/分_database.html>。
[12] <http://www.nanog.org/mtg-0110/lookup.html>
[12] <http://www.nanog.org/mtg-0110/lookup.html>。
Newton Informational [Page 22] RFC 3707 CRISP Requirements February 2004
はっきりした[22ページ]RFC3707要件2004年2月の情報のニュートン
Appendix A. Glossary
付録A.用語集
o TLD: Initials for "top level domain." Referes to domains in DNS
[1] that are hierarchically at the level just beneath the root.
o TLD: 「トップ・レベル・ドメイン」へのイニシャル。 根のすぐ下に階層的にレベルにあるDNS[1]のドメインへのReferes。
o ccTLD: Initials for "country code top level domain." TLD's which
use one of the two character country codes defined by ISO.
o ccTLD: 「国別トップレベルドメイン」のためのイニシャル。 2つのキャラクタ国名略号の1つを使用するTLDがISOによって定義されました。
o gTLD: Initials for "generic top level domain." TLD's that do not
use one of the two character country codes defined by ISO.
o gTLD: 「一般トップレベルドメイン」のためのイニシャル。 2つのキャラクタ国名略号の1つを使用しないTLDがISOによって定義されました。
o contact data: Data containing names and contact information (i.e.,
postal addresses, phone numbers, e-mail addresses) of humans or
legal entities.
o データに連絡してください: 人間か法人の名前と問い合わせ先(すなわち、郵便の宛先、電話番号、Eメールアドレス)を含むデータ。
o operational data: Data necessary to the operation of networks and
network related services and items.
o 操作上のデータ: ネットワークとネットワークの操作に必要なデータはサービスと項目を関係づけました。
o RIR: Initials for "regional Internet registry."
o RIR: 「地方のインターネット登録」へのイニシャル。
o IRR: Initials for "Internet routing registry."
o IRR: 「インターネット・ルーティング登録」へのイニシャル。
o forward lookup: a DNS lookup where a domain name is resolved to an
IP address.
o ルックアップを進めてください: ドメイン名がIPアドレスに決議されているDNSルックアップ。
o reverse lookup: a DNS lookup where an IP address is resolved to a
domain name.
o ルックアップを逆にしてください: IPアドレスがドメイン名に決議されているDNSルックアップ。
o mining: In the context of this document, this term is specific to
data mining. This is a methodical process to obtain the contents
of directory service, usually as much as possible, not relevant to
any immediate need. Data mining is often not a practice welcomed
by registry operators.
o 採掘: このドキュメントの文脈では、今期はデータマイニングに特定です。 これはどんな即座の必要性にも通常できるだけ関連していないディレクトリサービスのコンテンツを得る入念なプロセスです。 データマイニングはしばしば登録オペレータによって歓迎された習慣であるというわけではありません。
Newton Informational [Page 23] RFC 3707 CRISP Requirements February 2004
はっきりした[23ページ]RFC3707要件2004年2月の情報のニュートン
Appendix B. Acknowledgements
付録B.承認
B.1. Forums
B.1。 フォーラム
The proceedings of the following public forums were used as input to the scope and requirements for this document:
以下の公共のフォーラムの議事はこのドキュメントのための範囲と要件に入力されるように使用されました:
o whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego,
CA, USA
o 第49IETF[8]のwhois BOF。 2000年12月10日〜15日。 サンディエゴ(カリフォルニア)(米国)
o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London,
England
o 第51IETF[9]のwhoisfix BOF。 2001年8月5日〜10日。 ロンドン(イギリス)
o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA
o 最初に、UWho相談[10]。 2001年8月15日。 ワシントン(DC)(米国)
o Second UWho Consultation; November 15, 2001; Marina del Rey, CA,
USA
o 第2UWho相談。 2001年11月15日。 マリナデルレイ、カリフォルニア、米国
o Third UWho Consultation; November 19, 2001; Washington, DC, USA
o 第3UWho相談。 2001年11月19日。 ワシントン(DC)(米国)
o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic
o 熟している40のDNR WG、2001年10月1日〜5日。 Praque、チェコ共和国
o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech
Republic
o 熟している40[11]のデータベースWG。 2001年10月1日〜5日。 Praque、チェコ共和国
o General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA
o NANOG23[12]の一般セッション。 10月21日〜23日。 オークランド(カリフォルニア)(米国)
o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
o 熟している41のDNR WG、2002年1月14日〜18日。 アムステルダム(オランダ)
o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The
Netherlands
o 熟している41のデータベースWG、2002年1月14日〜18日。 アムステルダム(オランダ)
o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
o NANOG24の普遍的なWhois転炉、2002年2月10日〜12日。 マイアミ(フロリダ)
o CENTR General Assembly, February 21-22, 2002; Rambouillet, France
o CENTR総会、2002年2月21日〜22日。 ランブイエ(フランス)
o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis,
Minnesota, USA
o 第53IETF、2002年3月17日〜22日、ミネアポリス(ミネソタ)、米国のはっきりした転炉
B.2. Working Group
B.2。 作業部会
This document is a work item of the Cross-Registry Internet Service Protocol (CRISP) Working Group in the Applications Area of the IETF. Discussions for this working group are held on the email list ietf- not43@lists.verisignlabs.com. To subscribe to this email list, send email to ietf-not43-request@lists.verisignlabs.com with a subject line of "subscribe". Archives of this list may be found out http://lists.verisignlabs.com/pipermail/ietf-not43/.
このドキュメントはIETFのApplications AreaのCross-登録インターネットのサービスプロトコル(CRISP)作業部会の仕事項目です。 このワーキンググループのための議論がメールリストietf not43@lists.verisignlabs.com で行われます。 このメールリストに加入するには、「申し込んでください」の件名がある ietf-not43-request@lists.verisignlabs.com にメールを送ってください。 このリストのアーカイブは http://lists.verisignlabs.com/pipermail/ietf-not43/ を見つけることであるかもしれません。
Newton Informational [Page 24] RFC 3707 CRISP Requirements February 2004
はっきりした[24ページ]RFC3707要件2004年2月の情報のニュートン
B.3. Contributions
B.3。 貢献
Comments, suggestions, and feedback of significant substance have been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr, Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric Hall, Patrick Mevzek, Marcos Sanz, Vittorio Bertola, George Michaelson, and Tim Christensen.
重要な物質のコメント、提案、およびフィードバックはレスリーDaigle、マークKosters、テッド・ハーディー、シェーン・カー、キャシー・マーフィー、ステファーヌBortzmeyer、リック・ウェッソン、Jaap Akkerhuis、エリックHall、パトリックMevzek、マルコス・サンス、ヴィットリオBertola、ジョージMichaelson、およびティムクリステンセンによって提供されました。
Intellectual Property Statement
知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
Author's Address
作者のアドレス
Andrew L. Newton VeriSign, Inc. 21355 Ridgetop Circle Sterling, VA 20166 USA
アンドリューL.ニュートンベリサインInc.21355屋根の頂円の英貨、ヴァージニア20166米国
Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; anewton@ecotroph.net
以下に電話をしてください。 +1 3382年の703 948メール: anewton@verisignlabs.com; anewton@ecotroph.net
Newton Informational [Page 25] RFC 3707 CRISP Requirements February 2004
はっきりした[25ページ]RFC3707要件2004年2月の情報のニュートン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Newton Informational [Page 26]
ニュートンInformationalです。[26ページ]
一覧
スポンサーリンク
