[要約] RFC 3707は、CRISP（Cross Registry Internet Service Protocol）の要件についての要約です。CRISPは、異なるレジストリ間でのインターネットサービスの提供を可能にするプロトコルです。このRFCの目的は、CRISPの要件を明確にし、異なるレジストリ間でのシームレスなサービス提供を実現することです。
Network Working Group A. Newton
Request for Comments: 3707 VeriSign, Inc.
Category: Informational February 2004
Cross Registry Internet Service Protocol (CRISP) Requirements
クロスレジストリインターネットサービスプロトコル（CRISP）要件
Status of this 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.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
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
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
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 26
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.
インターネットの拡大と成長により、伝統的に集中化され管理されていたネットワーク情報センターのレジストリ機能が、さまざまな自律的、機能的に異なっており、グローバルに分散されたインターネットレジストリの責任となりました。インターネットレジストリの拡大により、管理ディレクトリサービスの使用は、その仕様の範囲外であるWOHISの使用を含むWHOIS [6]プロトコルの元の従来の使用から拡大しました。文書化されていないセキュリティメカニズム、RWhois [5]などの他のプロトコルの使用、他のニーズを満たすため、およびLDAP [4]やXMLなどの他のテクノロジーの使用に関する提案。
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.
このドキュメントの要件の範囲は、インターネットレジストリからのデータへのアクセスにも制限されています。インターネットレジストリでのデータの変更、追加、またはプロビジョニングの要件は、このドキュメントの範囲外です。
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".) 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.
このドキュメントでキャプチャされた要件は、技術仕様を設計するためのものです。RFC 2119 [3]のコンプライアンスのためにこのドキュメントで使用されている単語は、ポリシーを参照または指定せず、派生したテクノロジーの機能のみを話します。たとえば、このドキュメントでは、プロトコルが特定の機能を「」サポートする必要があると言う場合があります。実際のサービスオペレーターは常に自由に無効になります（そして、「許可拒否」などのエラーを返すために）このドキュメントの要件クライアントとサーバー間の適切な相互作用に必要なプロトコルの機能を指定します。RFC 2119の「必須/すべき」言語[3]。このドキュメントには、複数のサーバーを使用したクライアントの相互作用に関する言語も含まれています。このようなサービス要件は、RFC 2119言語を使用して説明されません。
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.
個々のサーバー/サービスオペレーターは、プロトコルがサポートできるすべての機能をサポートするわけではありませんが、プロトコルクエリと応答のセマンティクスを尊重する必要があります。たとえば、参照データがない場合、サーバーは紹介を返すべきではありません。
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.
インターネットレジストリは、このドキュメントの要件の範囲を提供するさまざまなコミュニティで構成されています。これらのコミュニティは、レジストリ、レジストラ、実装者、エンドユーザー、およびその他のアクターの次のカテゴリに一般化できます。
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ドメインは含まれません）。これらのレジストリは通常、GTLDのレジストリとして、またはCCTLDのレジストリとして、通常、2つの主要なドメイン関数を提供しています。場合によっては、1つのエンティティがGTLDタイプとCCTLDタイプの両方の複数のTLDを運用します。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には、GTLDと同様の2番目のレベルのドメイン登録があります。または、CCTLD内のGTLDと同様の2レベルのドメインレジストリを運用するエンティティを明確に分離しています。
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）の両方が含まれています。このモデルでは、レジストリは通常、ドメイン登録者へのインターフェイスですが、ドメインレジストラを介してドメイン登録者とのインターフェイスもあります。「Thin」モデルドメインレジストリには、ドメインの動作データのみが含まれています。「薄い」モデルでは、ドメインの連絡先データがドメインレジストラによって維持されます。
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）で説明されていないドメインレジストリは、このドキュメントの主題ではなく、この主題の範囲外の要件がある場合があります。
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.
ドメインレジストラは、「厚い」および「薄い」の両方で、ドメインレジストリに代わって登録者からドメイン登録を受け入れます。「薄い」モデルレジストラ/レジストラシステムでは、ドメインレジストラはドメインの連絡先データを維持し、レジストリはドメインの運用データを維持します。「厚い」モデルレジストリ/レジストラシステムでは、ドメインレジストラが運用データと連絡先データの両方をレジストリに渡します。ドメインレジストラは、複数のドメインレジストリに登録者に代わってドメインを登録できます。
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にリストされているもの以外のインターネットレジストリについて説明します。これらの説明は決定的ではなく、このリストは絶対的ではありません。これらは、情報目的のみでこのドキュメントで提供されています。
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.
地域のインターネットレジストリ（RIR）は、IPアドレススペースと自律システム番号の割り当てを管理します。各RIRは特定の地理的領域にサービスを提供しており、集合的にインターネット全体にサービスを提供しています。各RIRは、地域コミュニティの方向に基づいてグローバルアドレス指定ポリシーを促進および実施するメンバーシップベースの非営利組織です。
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.
ローカルインターネットレジストリ（LIR）および全国的なインターネットレジストリ（NIR）は、RIRのサブレジストリであり、より小さく、より具体的な地理的地域、主権国家、地域についてRIRの同じ機能を調整しています。
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].
インターネットルーティングレジストリは、ルーティングポリシーデータベースです。彼らの目的は、インターネットルーターの管理に役立つ情報を提供することです。多くの場合、構文と内容は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 served (e.g., an ISP may look up route entries, added by their customers, to decide whether to accept specific route advertisements they receive).
IRRは、RIRのいくつかを含む、学術、商業、政府、およびその他の種類の組織によって運営されています。データベースのコンテンツはさまざまであり、ユーザーのニーズが直接サービスを提供します（たとえば、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があります。
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.
インシデント調整の連絡先レジストリにより、ネットワークインフラストラクチャ、ネットワーク名、ネットワークサービスなどのネットワークリソースのオペレーターが、インシデント通知の手段を提供する目的で連絡先情報を登録することができます。このタイプのレジストリを使用して、ネットワークリソースのオペレーターには、インシデントが発生する可能性のある別のネットワークリソースのオペレーターに連絡するための情報が提供されます。
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.
クライアントソフトウェアの実装者は、多くの場合、大規模なネットワークオペレーター、レジストリオペレーター、または付加価値サービスを提供する商用エンティティと提携するか、インターネットの一般的な市民です。インターネットレジストリのディレクトリサービスで使用するクライアントソフトウェアの多くは、自由に利用できる、オープンソース、またはその両方、またはサービスとして利用可能です。サーバーソフトウェアの実装者は、多くの場合、インターネットレジストリの開発のアウトソースを専門とするオペレーターまたは商業エンティティと提携しています。
This section describes the many types of end-users. Individuals and organizations may have multiple roles and may concurrently occupy many of the categories.
このセクションでは、多くのタイプのエンドユーザーについて説明します。個人や組織には複数の役割があり、多くのカテゴリを同時に占有する場合があります。
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.
インターネットレジストリからの購入、リース、または付与を介して、インターネットリソースに対する権限を直接またはレジストラのサービスを通じて与えたエンティティ。
Service providers and network operators provide connectivity, routing, and naming services to many other entities, some commercial 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.
サービスプロバイダーとネットワークオペレーターは、他の多くのエンティティ、いくつかのコマーシャルおよび一部の非営利目的の両方に、接続、ルーティング、および命名サービスを提供します。彼らの運用スタッフと管理スタッフは、他のエンドユーザーに代わってインターネットレジストリとやり取りすることがよくあります。サービスプロバイダーとネットワークオペレーターは、このドキュメントで概説したすべてのインターネットレジストリオペレーターと頻繁かつ一貫したベースで対話します。たとえば、ネットワークオペレーターは、インターネットレジストリのディレクトリサービスを使用して、技術的な問題があるネットワークリソースの連絡先情報を決定します。
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.
彼らは、該当する法律や規制と一致するドメイン名に対する請求を維持および防御するために、インターネットレジストリ（主にドメインレジストリとレジストラ）のディレクトリサービスを使用します。
Law enforcement agencies use the directory services of Internet registries to find information used to carry out the enforcement of laws within their jurisdictions.
法執行機関は、インターネットレジストリのディレクトリサービスを使用して、管轄区域内の法律の執行を実行するために使用される情報を見つけます。
Certificate authorities use the directory services of Internet registries as part of their verification process when issuing certificates for Internet named hosts.
証明書当局は、インターネット指名されたホストの証明書を発行する際に、インターネットレジストリのディレクトリサービスを検証プロセスの一部として使用します。
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の解決プロセスでトラブルが発生した場合、これらのユーザーは、インターネットレジストリのディレクトリサービスからの情報の助けを借りてシステムの問題を撮影するのに苦労します。
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, registry, registrar, or registrant. One example is the use of Internet registry information for the use of sending unsolicited bulk or commercial email.
インターネットレジストリの管理ディレクトリサービスは、多くの場合、虐待的なユーザーによるプラクティスのターゲットです。インターネットレジストリから取得した情報を使用して、虐待的なユーザーは、レジストリ、レジストラ、または登録者が意図した情報の許容可能な使用に対抗する特定のアクティビティを引き受けます。多くの場合、これらの慣行は、ユーザー、レジストリ、レジストラ、または登録者の管轄区域の法律に違反しています。1つの例は、未承諾のバルクまたはコマーシャルメールを送信するためのインターネットレジストリ情報の使用です。
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.
要件は、インターネットレジストリディレクトリサービスの使用に関する他のアクターのポジションとポリシーも考慮する必要があります。これらの関係者には、政府、非政府政策設定機関、およびその他の非政府組織が含まれます。
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で指定された方法の要件について説明します。
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).
このセクションでは、インターネットレジストリの基本的なディレクトリサービスプロトコル要件について説明します。ドメインレジストリに固有の追加要件は、ドメイン固有の関数で説明されています（セクション3.2）。
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.
さまざまな種類のデータに配置されている制限は、アクセスステータスに応じて適用される制限は、ポリシーとニーズに基づいてサーバーごとにサーバーごとに異なる可能性が最も高くなります。データを制限し、データマイニングを防ぐためのさまざまなサービスモデルのサポートは、クライアントからサーバーへのプロトコルに直接的な影響を与える場合とそうでない場合があります。
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.
プロトコルは、ネットワークおよび輸送層の上のすべての側面とレイヤーにユニークなテクノロジーソリューションを使用してはなりません。プロトコルは、該当する場合は既存のテクノロジー標準を利用する必要があります。プロトコルは、インターネットエンジニアリングタスクフォースによって定義されているように、ネットワークおよび輸送層標準の使用を採用する必要があります。プロトコルは、強制実装のために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.
プロトコルには、このドキュメントで機能を実装するために必要なデータ交換のための標準スキーマを含める必要があります。さらに、このドキュメントのニーズによって定義されていないスキーマの使用を許可する手段が必要です。両方のタイプのスキーマは、同じスキーマ言語を使用する必要があります。スキーマは、識別タグの意味のローカリゼーションを目的として、識別タグでデータ要素を表現できる必要があります。
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).
クライアント間プロトコルは、情報を交換するときに使用するデータ構造またはスキーマの標準セットを定義する必要があります。また、この仕様では現在予見されていない新しいデータ構造の使用を可能にする機能をもたらす必要があります。どちらの場合も、両方のタイプのデータ構造またはスキーマの説明と仕様を同じ方法で実行する必要があります（つまり、同じスキーマ言語）。
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.
スキーマは、一意の識別子を使用してデータを「タグ付け」できる必要があります。この識別子を使用して、そのタイプのデータの名前をローカライズできます。たとえば、データには値「ボブ」とそのタイプが「5.1」という数字で識別される場合があります。クライアントソフトウェアはこれを使用して、英語のロケールに「名前：ボブ」またはスペイン語のロケールに「nombre：bob」を表示できます。
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.
プロトコルは、オペレーターのポリシーに基づいてオンまたはオフにできる匿名アクセスメカニズムを提供する必要があります。
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.
サーバーが許可するアクセスの種類は、おそらくオペレーターから次のオペレーターまで異なります。
The protocol MUST be capable of allowing machine parsable requests and responses.
プロトコルは、マシンの対応可能なリクエストと応答を許可することができなければなりません。
There MUST be a mechanism for an entity contained within a server to be referenced uniquely by an entry in another server.
サーバー内に含まれるエンティティが別のサーバーのエントリによって一意に参照されるメカニズムが必要です。
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.
プロトコルは、中央リポジトリ、サーバー、またはエンティティへのデータの集約を必要としないでください。プロトコルは、データインデックスの集約や中央リポジトリ、サーバー、またはエンティティへのヒントを必要としないでください。
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.
一部のサーバーオペレーターは、メッシュまたは他のサーバーオペレーターと他のフレームワークでサービスを調整する必要がある場合があります。ただし、鮮明なコンプライアントサーバーを操作する機能は、これを必要としないはずです。
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.
プロトコルは、クエリがオペレーターの適切なポリシーに従って提出される前にクエリが拒否されるかどうかをクライアントが判断できるメカニズムを提供する必要があります。
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.
使用法のシナリオは、ポリシーとサービスの種類の両方によって異なるため、一部のサーバーオペレーターは、クライアントがクエリからデータを取得する能力を事前に決定する能力を提供したい場合があります。ただし、一部のオペレーターは、セキュリティ上の理由、ポリシーの制限、またはその他の問題のためにこれを許可しません。
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.
プロトコルは、認証システムに参加するためにインターネットレジストリを要求してはなりません。プロトコルは、フェデレート、分散認証システムのインターネットレジストリによる参加を禁止してはなりません。
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.
一部のサーバーオペレーターは、認証を他の当事者に委任する必要がある場合や、認証情報が配布されるシステムに参加する必要がある場合があります。ただし、鮮明なコンプライアントサーバーを操作する機能は、これを必要としないはずです。
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 不十分なリソース - 検索または検索には、割り当てられないリソースが必要です。
The protocol MUST NOT prohibit a server from participating in a query distribution system.
プロトコルは、サーバーがクエリ配布システムに参加することを禁止してはなりません。
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.
ただし、鮮明な準拠サーバーを操作する機能は、クエリ配信システムへの参加を必要としないはずです。
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.
すべてのリソース固有のスキーマは、クエリに応答セットで返されるスキーマのバージョンを一意に明確に識別するバージョン識別子属性を提供する必要があります。
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.
このサービスは、不明なスキーマバージョンを受け取ったときにクライアントが使用する交渉および/または回復メカニズムを提案する必要があります。
The term "bag" in this section describes a flexible container which may contain unspecified data.
このセクションの「バッグ」という用語は、不特定のデータを含む可能性のある柔軟な容器について説明しています。
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.
紹介を発行する場合、プロトコルはサーバーからクライアントにリレーバッグを供給できる必要があり、プロトコルはクライアントがクエリを備えたリレーバッグを参照サーバーに送信できるようにする必要があります。リレーバッグの使用はオプションでなければなりません。プロトコルは、リレーバッグの内容に関して仮定を立ててはなりませんが、リレーバッグはプロトコルのスキーマ言語を使用して説明する必要があります。
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袋以上のバッグが必要です。プロトコルは、紹介チェーン内の連続したバッグ間の関連またはリンクを作成してはなりません。
The client MUST pass the bag as part of any query made to a referrant server as a result of a referral.
クライアントは、紹介の結果としてリファラントサーバーに作成されたクエリの一部としてバッグを渡す必要があります。
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.
参加サーバーオペレーター間のサービス調整が利用されているいくつかのモデルでは、参照サーバーがオペレーターからオペレーターへの調整データを渡すことと、参照サーバーへの紹介とともに、オペレーターからオペレーターへの調整データを渡す必要があるかもしれません。このようなニーズは監査または追跡である可能性があります。この機能要件により、サーバーは、クライアントがリファレントサーバーに渡す必要がある不特定のデータ（「bag」）の柔軟なコンテナをクライアントに渡すことができます。バッグはクライアントに意味がありません。
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.
プロトコルは、この目的のために他の値を定義する場合がありますが、上記の値を最小限に定義する必要があります。プロトコルは、これらのラベルを同時に添付できる必要があります。
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.
インターネットレジストリには、データへのアクセスに関するさまざまなポリシーがあります。一部のレジストリは、通常、ほとんどのユーザーには与えられないデータにアクセスできる特定のクラスのユーザーを付与する場合があります。これらの場合、レジストリはこれらのエントリの値に、これらの特別なユーザーの権利に伴う責任を指定するラベルを使用してタグを付けたい場合があります。
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）を個別に指定する必要があります。すべてのレジストリタイプで必要な関数をサポートするために、準拠サーバーオペレーターは必要ありません。
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を参照してください。
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を参照してください。
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. ドメイン名検索正確な一致または名前の合理的なサブセットを与えられます。この検索では、国際化されたドメイン名のより良いマッチングを可能にするように設計されたパラメーターと修飾子が可能になり、国際化されたドメイン名の制限内で正確な一致と部分的な一致を可能にする必要があります。この検索は、この検索に対応するために国際化されたドメイン名の特別な変換を必要としないはずです。この検索は、特定の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を参照してください。
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を参照してください。
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参照です。
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.
すべてのインターネットレジストリが上記のすべての情報を提供することは予想されませんが、プロトコルで採用されているスキーマは、レジストリがそれを提供する必要がある場合にこの情報を表現できる必要があります。
The following sections describe requirements relative to the use of schemas with respect to individual registry need and policy:
次のセクションでは、個々のレジストリのニーズとポリシーに関するスキーマの使用に関する要件について説明します。
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
The schemas used by the protocol SHOULD be capable of off-line serialization
プロトコルで使用されるスキーマは、オフラインのシリアル化を可能にする必要があります
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.
オフラインのシリアル化により、バックアップやリカバリ、負荷分散などの実装独立操作が可能になります。これは、データエスクロー機能やその他の使用法全体または部分的に可能になる場合がありますが、このような使用法はこれの範囲外です。書類。
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に準拠するように切り捨てられました
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.
クライアントソフトウェアは、結果セットの切り捨ての理由を理解できれば、より有用に動作します。もちろん、一部のインターネットレジストリは、結果セットの制限のためにポリシーを公開できない場合がありますが、可能な場合、クライアントはより良い運用ビューを持っています。これは、望ましくない再販売やその他の繰り返しのアクションを排除する可能性があります。
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.
プロトコルは、該当する場合、ドメインまたはその他のオブジェクトに関する情報の権威ある情報源を決定するための主要な手段として、DNS [1]で利用可能な委任当局モデルを使用する必要があります。
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ゾーンを照会することで見つけることができます。たとえば、レジストリ情報を見つけるには、.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委任階層に自然にマッピングされない場合があります。この要件は、そのようなマッピングを強制することを意図したものではありません。
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で説明したさまざまなモデル間で紹介とエンティティの参照を表現できる必要があります。
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で説明されているドメインレジストリタイプのさまざまな登録配布モデルにサービスは対応する必要があります。
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. complete omission of the value without explanation
1. 説明なしで価値を完全に省略します
2. an indication that the value cannot be given due to insufficient authorization
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.
プロトコルは、この目的のために他の値を定義する場合がありますが、上記の値を最小限に定義する必要があります。
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.
インターネットレジストリには、特定の種類のデータ、通常はソーシャル情報を公開する能力に関するさまざまな制約があります。サーバーオペレーターは、このニーズに対応する機能を備えている必要がありますが、クライアントソフトウェアは適切な説明を提供するとより便利になります。したがって、ポリシーに応じて、サーバーオペレーターは、データをまったく返さないか、許可エラーを通知するか、プライバシーの制約を示すかを選択できます。
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.
ドメイン関連のリソースを定義するスキーマは、テキストデータに関してRFC 2277 [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で連絡先データを提供できる必要があり、US-ASCII、その他の文字セット、およびデータの言語を指定できる連絡先データを提供できる必要があります。
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で指定された方法の要件について説明します。
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.
サービスにアクセスするエンティティ（ユーザー）には、認証を目的として資格情報をサーバーに渡すメカニズムを提供する必要があります。プロトコルは、多くの認証タイプを採用し、将来の認証タイプのために拡張できるメカニズムを提供する必要があります。
To distribute queries for search continuations and to issue entity references, the protocol MUST provide a referral mechanism.
検索継続のクエリを配布し、エンティティ参照を発行するには、プロトコルは紹介メカニズムを提供する必要があります。
To distribute queries for search continuations and to issue entity references, the protocol MUST define a common referral scheme and syntax.
検索継続のクエリを配布し、エンティティ参照を発行するには、プロトコルは共通の紹介スキームと構文を定義する必要があります。
To provide for machine consumption as well as human consumption, the protocol MUST employ structured queries and responses.
マシンの消費と人間の消費を提供するには、プロトコルは構造化されたクエリと応答を採用する必要があります。
To provide structured queries and responses and allow for minimal technological reinvention, the protocol MUST employ a pre-existing schema language.
構造化されたクエリと応答を提供し、最小限の技術的再発明を可能にするために、プロトコルは既存のスキーマ言語を採用する必要があります。
To provide for machine consumption as well as human consumption, the protocol MUST define schemas for use by the structured queries and responses.
マシンの消費と人間の消費を提供するために、プロトコルは構造化されたクエリと応答によって使用するスキーマを定義する必要があります。
Requirements defined in this document MUST consider the best practices spelled out in [2].
このドキュメントで定義されている要件は、[2]で説明されているベストプラクティスを考慮する必要があります。
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の考慮事項は、選択されたテクノロジーに依存し、そのようなサービスを説明するドキュメントで指定する必要があります。
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.
このドキュメントには、認証されたエンティティの検証に関する要件と、認証されていないエンティティのアクセスと比較して、認証されたエンティティのアクセスが含まれています。このドキュメントは、認証されたエンティティの検証のメカニズムを定義しません。このドキュメントで定義されている要件は、最良の共通慣行に従ってこのメカニズムの実装を許可する必要があります。
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.
このドキュメントには、紹介およびエンティティ参照の要件が含まれています。これらの要件に基づいたクライアントの実装は、紹介またはエンティティの紹介を最良の共通慣行に従って解決する際に、資格情報の安全なガードに適切な注意を払う必要があります。
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.
このドキュメントには、参加サービスプロバイダーのメッシュ間でクエリの配布に関する要件が含まれています。これらの要件を満たすために提案されたプロトコルは、分散型サービス攻撃または不正なデータマイニングのベクトルとしてのその流通システムの使用から保護できる必要があります。
Normative References
引用文献
[1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[1] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[2] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[2] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Informative References
参考引用
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[4] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、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] Williamson、S.、Kosters、M.、Blacka、D.、Singh、J。and K. Zeilstra、「紹介Whois（rwhois）Protocol v1.5」、RFC 2167、1997年6月。
[6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[6] Harrenstien、K.、Stahl、M。and E. Feinler、「Nicname/Whois」、RFC 954、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.、Meyer、D.、Bates、T.、Karrenberg、D.、M。Terpsstra、「ルーティングポリシー仕様言語（RPSL）」、RFC2622、1999年6月。
URIs
ウリス
[8] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
[9] <http://www.ietf.org/proceedings/01aug/51-40.htm>
[10] <http://www.uwho.verisignlabs.com/ Final-WhoIsPanel-Aug15-Resume.pdf>
[10] <http://www.uwho.verisignlabs.com/ final-whoispanel-aug15-resume.pdf>
[11] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/ min_database.html>
[11] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/ min_database.html>
[12] <http://www.nanog.org/mtg-0110/lookup.html>
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]のドメインを参照します。
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：「カントリーコードトップレベルドメイン」のイニシャル。ISOで定義された2つのキャラクターカントリーコードのいずれかを使用するTLD。
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：「一般的なトップレベルドメイン」のイニシャル。ISOで定義された2つのキャラクターカントリーコードのいずれかを使用しないTLD。
o contact data: Data containing names and contact information (i.e., postal addresses, phone numbers, e-mail addresses) of humans or legal entities.
o 連絡先データ：人間または法人の名前と連絡先情報（つまり、郵便アドレス、電話番号、電子メールアドレス）を含むデータ。
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 マイニング：このドキュメントのコンテキストでは、この用語はデータマイニングに固有です。これは、ディレクトリサービスの内容を取得するための系統的なプロセスであり、通常は可能な限り、即時のニーズとは関係ありません。データマイニングは、レジストリオペレーターが歓迎する慣行ではないことがよくあります。
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 49番目のIETF [8]のWHOIS BOF;2000年12月10〜15日。米国カリフォルニア州サンディエゴ
o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London, England
o 51st IETF [9]のWHOISFIX BOF;2001年8月5〜10日。ロンドン、イギリス
o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA
o 最初のuwho Consultation [10];2001年8月15日;ワシントンDC、米国
o Second UWho Consultation; November 15, 2001; Marina del Rey, CA, USA
o 2番目のuwho相談。2001年11月15日。米国カリフォルニア州マリーナデルレイ
o Third UWho Consultation; November 19, 2001; Washington, DC, USA
o 3回目のUWHO相談。2001年11月19日。ワシントンDC、米国
o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic
o 2001年10月1〜5日、RIPE 40のDNR WG;プラケ、チェコ共和国
o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech Republic
o RIPE 40のデータベースWG [11];2001年10月1〜5日。プラケ、チェコ共和国
o General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA
o Nanog 23の一般セッション[12];10月21〜23日;米国カリフォルニア州オークランド
o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
o Ripe 41のDNR WG、2002年1月14〜18日。アムステルダム、オランダ
o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
o Ripe 41のデータベースWG、2002年1月14〜18日。アムステルダム、オランダ
o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
o Nanog 24 Universal Whois Bof、2002年2月10〜12日。マイアミ、フロリダ
o CENTR General Assembly, February 21-22, 2002; Rambouillet, France
o センター総会、2002年2月21〜22日。フランス、ランブイエレット
o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis, Minnesota, USA
o 2002年3月17〜22日、第53 IETFの鮮明なBOF、米国ミネソタ州ミネアポリス
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のアプリケーションエリアにおけるクロスレジストリインターネットサービスプロトコル（CRISP）ワーキンググループの作業項目です。このワーキンググループの議論は、メーリングリストietf-not43@lists.verisignlabs.comに記載されています。このメーリングリストを購読するには、「subscribe」の件名を使用して、ietf-not43-request@lists.verisignlabs.comにメールを送信します。このリストのアーカイブは、http：//lists.verisignlabs.com/pipermail/ietf-not43/で見つけることができます。
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.
重要な物質のコメント、提案、およびフィードバックは、レスリー・デイグル、マーク・コースターズ、テッド・ハーディ、シェーン・カー、キャシー・マーフィー、ステッド・ボルツマイヤー、リック・ウェッソン、ジャープ・アクケルヒュイス、エリック・ホール、パトリック・メフェク、マルコス・サンツ、ヴィトリオ・ベルトラ、ジョージによって提供されています。マイケルソン、ティム・クリステンセン。
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は、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができます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
Andrew L. Newton Verisign、Inc。21355 Ridgetop Circle Sterling、VA 20166 USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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エディター機能の資金は現在、インターネット協会によって提供されています。