Network Working Group A. Newton
Request for Comments: 3707 VeriSign, Inc.
Category: Informational February 2004
Cross Registry Internet Service Protocol (CRISP) Requirements
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）インターネット協会（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.
インターネットの拡大と成長は、伝統的に、集中して管理ネットワークインフォメーションセンターのレジストリ機能を見ている、自律様々な機能の異なる、およびグローバルに分散インターネットレジストリの責任になります。インターネットレジストリの広がり番号と、その管理ディレクトリサービスの用途は、その仕様の範囲外のwhoisの使用が含まれるように、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".)
本書でキャプチャ要件は、技術仕様を設計するためのものです。 RFC 2119に準拠するために、このドキュメントで使用されている単語は、[3]のみ派生技術の能力を参照するか、ポリシーを指定し、話すことはありません。たとえば、このドキュメントは、プロトコルが特定の機能をサポートする「しなければならない」と言うことがあります。実際のサービスオペレータは、常にそれを無効にして自由である（そして、そのような「許可が拒否された」などのエラーを返すように。）
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の「MUST / SHOULD」言語で指定される[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.
ドメインレジストリは、[1] DNSフォワードルックアップ（すなわち、.ARPAドメインを含まない）で使用するためのドメインの登録を担当しています。これらのレジストリは典型的には、2つの主要ドメイン機能を提供している：のgTLDのレジストリとして、またはのccTLDのレジストリとして。いくつかの例では、一方のエンティティは、複数の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のは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）の両方が含まれています。このモデルでは、レジストリは通常、ドメイン登録者へのインタフェースであるだけでなく、ドメインレジストラを通じてドメイン登録者とインタフェースすることができます。 「薄い」モデルのドメインレジストリは、ドメインのための唯一の運用データが含まれています。 「薄い」モデルでは、ドメインの連絡先データは、ドメインレジストラによって維持されます。
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.
インターネットレジストリの管理ディレクトリサービスは、多くの場合、不正なユーザーによる実践の目標です。インターネットレジストリから取得した情報を使用して、不正なユーザーは、レジストリ、レジストラ、または登録者が意図するような情報の許容可能な利用にカウンターされている特定の活動を行います。多くの場合、これらのプラクティスは、ユーザー、レジストリ、レジストラ、または登録者の管轄の法律に違反します。一つの例は、迷惑または商用電子メールを送信するのに使用のためのインターネットレジストリ情報を使用することです。
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」で識別されるそのタイプを有することができます。スペイン語ロケールで「ボブノンブル」英語ロケールまたはで：クライアント・ソフトウェアは、「ボブ名」を表示するためにこれを使用することができます。
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.
サーバーによって許可されるアクセスの種類は、最も可能性の高い1つのオペレータから次へと変化します。
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.
いくつかのサーバーオペレータは、メッシュまたは他のサーバーオペレータといくつかの他のフレームワークでサービスを調整する必要があります。しかし、CRISP準拠のサーバーを操作する能力はこれを要求してはなりません。
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.
いくつかのサーバーオペレータは、他の当事者に認証を委任または認証情報が分散されているシステムに参加する必要性を有することができます。しかし、CRISP準拠のサーバーを操作する能力はこれを要求してはなりません。
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.
しかし、CRISP準拠のサーバーを操作する能力は、任意のクエリ配信システムへの参加を要求してはなりません。
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.
クライアントは、照会の結果としてreferrantサーバーに対して行われたクエリの一部として袋を渡す必要があります。
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.
参加サーバ事業者間のサービス連携を利用する一部のモデルでは、参照サーバは参照先サーバーへの紹介とともに、オペレータ・ツー・オペレータの調整データを渡すことができるようにする必要性があるかもしれません。このようなニーズは、監査や追跡かもしれません。この機能要件は、サーバーがクライアントに、クライアントは参照先サーバーに渡すべきであると指定されていないデータのフレキシブルコンテナ（「バッグ」）を渡すことができます。バッグは、クライアントには意味がありません。
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.
プロトコルは、この目的のために他の値を定義してもよい（MAY）が、最低でも、上記定義された値を定義しなければなりません。プロトコルは、同時にこれらのラベルを取り付けることができなければなりません。
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.
正確な名前または特定のTLDの登録者への検索を絞り込むための能力を部分的に一致する名前のどちらか2.ドメイン登録者の検索。
3. Domains hosted by a nameserver given the fully-qualified host name or IP address of a nameserver.
ネームサーバの完全修飾ホスト名またはIPアドレス指定したネームサーバによってホストされている3.ドメイン。
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 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の詳細については、権限のあるサーバーは、example.comのDNSゾーンを照会することにより求めることができます。 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委任の階層にマップしないだろう場合があります。この要件は、このようなマッピングを強制するものではありません。
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.
同じドメインの連絡先データのみを別のエンティティによって運営サーバーに常駐してもよいしつつ、使用中のドメインレジストリ/レジストラモデルに応じて、ドメインのための技術データは、一つのサーバに存在してもよいです。しかし、多くの用途では、この状況ではありません。そのため、このサービスは、セクション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.
プロトコルは、この目的のために他の値を定義してもよい（MAY）が、最低でも、上記定義された値を定義しなければなりません。
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]テキスト・データに関する。具体的には、スキーマは、非構造化テキスト・データと共に使用における文字セットと言語を示すことができなければなりません。
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.、BCP 18、RFC 2277 "文字セットと言語のIETF方針"、1998年1月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
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）"、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]ウィリアムソン、S.、Kosters、M.、Blacka、D.、シン、J.及びK. Zeilstra、 "紹介フーイズ（RWhois）プロトコルV1.5"、RFC 2167、1997年6月。
[6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[6] Harrenstien、K.、スタール、M.および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.、マイヤー、D.、ベイツ、T.、Karrenberg、D.およびM.テルプストラ、「ルーティングポリシー仕様言語（RPSL） 」、RFC 2622、1999年6月。
URIs
URI
[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/最終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>
「１２」 ＜ｈっｔｐ：／／ｗっｗ。なのｇ。おｒｇ／ｍｔｇー０１１０／ぉおくｐ。ｈｔｍｌ＞
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：のためのイニシャル「トップレベルドメイン。」 [1]だけルートの下のレベルに階層的であることDNS内のドメインを指します。
o ccTLD: Initials for "country code top level domain." TLD's which use one of the two character country codes defined by ISO.
入出力のccTLD：「国別コードトップレベルドメイン」のイニシャルTLDのISOで定義された2つの文字の国コードのいずれかを使用しています。
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のための：イニシャル「一般トップレベルドメイン。」 TLDのISOで定義された2つの文字の国コードのいずれかを使用しないこと。
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.
IPアドレスがドメイン名に解決されるDNSルックアップ：O逆引き参照。
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マイニング：この文書の文脈では、この用語は、データマイニングに固有のものです。これは、通常、可能な限り、任意の即時の必要性に関連していないディレクトリサービスの内容を取得するための系統的なプロセスです。データマイニングは、多くの場合、レジストリオペレータによる歓迎の練習ではありません。
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 49 IETFのWHOIS BOF [8]。 12月10-15、2000;サンディエゴ、CA、USA
o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London, England
第51回IETFのO whoisfix BOF [9]。 8月5-10、2001;ロンドン、イギリス
o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA
OまずUWho相談[10]。 2001年8月15日;ワシントンD.C.、USA
o Second UWho Consultation; November 15, 2001; Marina del Rey, CA, USA
または第二uWHO相談。 2001年11月15日;マリナ・デル・レイ、CA、USA
o Third UWho Consultation; November 19, 2001; Washington, DC, USA
第三にUWho相談O; 2001年11月19日;ワシントンD.C.、USA
o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic
RIPE 40、10月1-5、2001年のDNR WG O;プラハ、チェコ共和国
o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech Republic
RIPE 40のOデータベースWG [11]。 10月1-5、2001;プラハ、チェコ共和国
o General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA
O NANOG 23の一般セッション[12]。 10月21-23;オークランド、CA、USA
o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
RIPE 41、1月14-18、2002年のDNR WG O;アムステルダム、オランダ
o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
RIPE 41、1月14-18、2002年のOデータベースWG。アムステルダム、オランダ
o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
O NANOG 24ユニバーサルWhoisのBOF、2月10-12、2002;マイアミ、フロリダ
o CENTR General Assembly, February 21-22, 2002; Rambouillet, France
CENTR総会、2月21-22、2002 O;ランブイエ、フランス
o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis, Minnesota, USA
O CRISP第53回IETFのBOF、月17-22、2002年、米国ミネソタ州ミネアポリス
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のアプリケーション領域にあるクロスレジストリインターネットサービスプロトコル（CRISP）ワーキンググループの作業項目です。このワーキンググループの議論は、電子メールリストietf-not43@lists.verisignlabs.comに保持されています。このメールリストを購読するには、「購読」の件名でietf-not43-request@lists.verisignlabs.comにメールを送ります。このリストのアーカイブはhttp://lists.verisignlabs.com/pipermail/ietf-not43/を発見することができます。
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、リック・ウェッソン、ヤープAkkerhuis、エリック・ホール、パトリックMevzek、マルコス・サンス、ヴィットリオBertola、ジョージによって提供されていますマイケルソン、そしてティム・クリステンセン。
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
アンドリュー・L.ニュートンベリサイン社21355 Ridgetopサークルスターリング、VA 20166 USA
Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; anewton@ecotroph.net
電話：+1 703 948 3382 Eメール：anewton@verisignlabs.com。 anewton@ecotroph.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。