Network Working Group A. Newton
Request for Comments: 3707 VeriSign, Inc.
Category: Informational February 2004
Network Working Group A. Newton
Request for Comments: 3707 VeriSign, Inc.
Category: Informational February 2004
Cross Registry Internet Service Protocol (CRISP) Requirements
跨注册表Internet服务协议（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）互联网协会（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.
Internet注册表通过不同的目录服务公开管理和操作数据。本文档定义了域注册表的目录服务的功能要求以及扩展这些服务在其他类型的Internet注册表中的使用的通用基本要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Scope . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements Specification . . . . . . . . . . . . . . . 3
2. Internet Registry Communities . . . . . . . . . . . . . . . . 4
2.1. Domain Name System Registries . . . . . . . . . . . . . 4
2.1.1. Domain Registries . . . . . . . . . . . . . . . 4
2.1.2. Domain Registrars . . . . . . . . . . . . . . . 5
2.2. Other Registries . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Regional Internet Registries . . . . . . . . . . 5
2.2.2. Local Internet Registries . . . . . . . . . . . 5
2.2.3. Internet Routing Registries . . . . . . . . . . 5
2.2.4. Incident Coordination Contact Registries . . . . 6
2.3. Implementers . . . . . . . . . . . . . . . . . . . . . . 6
2.4. End Users . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Internet Resource Registrants . . . . . . . . . 6
2.4.2. Service Providers and Network Operators . . . . 6
2.4.3. Intellectual Property Holders . . . . . . . . . 7
2.4.4. Law Enforcement . . . . . . . . . . . . . . . . 7
2.4.5. Certificate Authorities . . . . . . . . . . . . 7
2.4.6. DNS Users . . . . . . . . . . . . . . . . . . . 7
1. 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
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
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[6]协议的原始和传统使用扩展到包括规范范围外whois的使用、语法的正式和非正式定义、未记录的安全机制、，使用其他协议（如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.
本文件中要求的范围也仅限于从互联网登记处获取数据。修改、添加或提供Internet注册表中数据的要求不在本文档的范围内。
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[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的注册表。在某些情况下，一个实体将操作多个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性质相似的二级域注册，或者在ccTLD内具有明显独立的实体，运营与gTLD性质相似的二级域注册。
Domain registries usually follow one of two models for conducting registrations of domains. The "thick" model is the more traditional model. In a "thick" domain registry, the registry contains both the operational data for the domain and the contact data (Appendix A) for the domain. In this model, the registry is typically the interface to the domain registrant but may also interface with the domain registrant through domain registrars. The "thin" model domain registry contains only operational data for domains. In the "thin" model, contact data for the domain are maintained by a domain registrar.
域注册通常遵循两种模式之一进行域注册。“厚”模型是更传统的模型。在“厚”域注册表中，注册表包含域的操作数据和域的联系数据（附录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].
Internet路由注册表是路由策略数据库。他们的目的是提供有助于管理互联网路由器的信息。通常，语法和内容由RPSL定义[7]。
IRR's are operated by academic, commercial, governmental, and other types of organizations, including several of the RIR's. The contents of the databases vary and reflect the needs of the users directly
IRR由学术、商业、政府和其他类型的组织（包括几个RIR）运营。数据库的内容各不相同，直接反映了用户的需求
served (e.g., an ISP may look up route entries, added by their customers, to decide whether to accept specific route advertisements they receive).
已服务（例如，ISP可查找其客户添加的路由条目，以决定是否接受其收到的特定路由广告）。
Unlike RIR and domain registry data, IRR data is often duplicated between separate organizations. The IRR data has the unique characteristics of being largely available through other sources (i.e., it is advertised by the Internet routing protocols) and most often having a common data format, RPSL.
与RIR和域注册表数据不同，IRR数据通常在不同的组织之间重复。IRR数据具有独特的特点，主要可通过其他来源获得（即，通过互联网路由协议公布），并且通常具有通用数据格式RPSL。
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.
客户端软件的实现者通常隶属于大型网络运营商、注册运营商或提供增值服务的商业实体，或者是互联网的普通公民。与Internet注册中心的目录服务一起使用的许多客户端软件要么免费提供，要么开源，要么两者兼而有之，要么作为服务提供。服务器软件的实现者通常隶属于专门从事互联网注册中心开发外包的运营商或商业实体。
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.
证书颁发机构在为Internet命名主机颁发证书时，使用Internet注册中心的目录服务作为其验证过程的一部分。
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解析过程中出现问题时，这些用户借助Internet注册中心目录服务提供的信息来解决系统问题。
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.
要求还必须考虑其他参与者在使用Internet注册表目录服务时的位置和策略。这些行动者包括政府、非政府政策制定机构和其他非政府组织。
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).
本节介绍Internet注册表的基本目录服务协议要求。特定于域注册表的其他要求在特定于域的功能（第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).
为了防止从Internet注册表的目录服务中不当获取数据，许多服务器将限制在固定时间段内从服务器返回到客户端的数据量。对于匿名访问使用而言，这很可能尤其如此（见第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.
协议不得为网络和传输层之上的所有方面和层采用独特的技术解决方案。议定书应在适用的情况下利用现有的技术标准。协议必须使用互联网工程任务组定义的网络和传输层标准。协议必须定义一个或多个拥塞感知传输机制，以便强制实施。
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.
模式还必须能够使用唯一标识符“标记”数据。然后可以使用该标识符来本地化该类型数据的名称。例如，一段数据的值可能为“Bob”，其类型用数字“5.1”标识。客户端软件可以使用它在英语区域显示“Name:Bob”，或者在西班牙语区域显示“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.
一些服务器运营商可能需要与其他服务器运营商协调mesh或其他框架中的服务。但是，运行符合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.
协议不得要求任何Internet注册表参与任何身份验证系统。该协议不得禁止Internet注册中心参与联邦、分布式身份验证系统。
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 permission denied（权限被拒绝）—表示由于授权不足而导致搜索或查找失败的响应。
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.
每次推荐不得超过一件行李。协议不得在转诊链中的连续行李之间建立关联或链接。
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.
协议可为此定义其他值，但必须至少定义上述定义的值。协议必须能够同时附加这些标签。
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.
这些查询都是单索引查询，应该只生成一个实体或零个实体。
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.
根据Internet注册表的策略和需要，服务器运营商可能不允许所有或任何这些查找返回部分或全部信息。见第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.
根据Internet注册表的策略和需要，服务器运营商可能不允许所有或任何这些搜索返回部分或全部信息。见第3.1.4节。根据政策和数量，对这些搜索产生的信息的访问也可能受到限制。第3.2.5节描述了这些类型的限制。
Some Internet registries may also be participating in a query distribution system. See Section 3.1.11.
一些Internet注册中心也可能参与查询分发系统。见第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.
不期望每个Internet注册中心都提供上述所有信息，但是如果注册中心需要提供这些信息，协议使用的模式必须能够表达这些信息。
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.
如果客户机软件能够理解结果集被截断的原因，那么它的运行将更加有效。当然，一些Internet注册中心可能无法公开其限制结果集的策略，但是，如果可能，客户端将拥有更好的操作视图。这可以消除不需要的重新查询和其他重复操作。
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区域找到根据该域注册人获取example.com信息的权威服务器。要查找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.
根据使用的域注册表/注册器模型，域的技术数据可能仅驻留在一台服务器中，而同一域的联系人数据可能仅驻留在由单独实体操作的服务器中。然而，在许多用途中，情况并非如此。因此，服务必须适应第2.1.1节中描述的域注册表类型的各种注册分布模型，同时遵守第3.1.7节的规定。
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:
当由于策略约束而无法给出查询答案中的值时，协议必须能够以以下三种方式之一表示该值：
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]。特别是，模式必须能够指示用于非结构化文本数据的字符集和语言。
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 10351987年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.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] Williamson，S.，Kosters，M.，Blacka，D.，Singh，J.和K.Zeilstra，“转诊Whois（RWhois）协议V1.5”，RFC 2167，1997年6月。
[6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[6] K.Harrenstien，Stahl，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.，Meyer，D.，Bates，T.，Karrenberg，D.和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 2622，1999年6月。
URIs
URI
[8] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
[8] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
[9] <http://www.ietf.org/proceedings/01aug/51-40.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>
[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：“国家代码顶级域”的首字母缩写。TLD使用ISO定义的两个字符国家代码之一。
o gTLD: Initials for "generic top level domain." TLD's that do not use one of the two character country codes defined by ISO.
o gTLD：“通用顶级域”的首字母缩写。不使用ISO定义的两个字符国家代码之一的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：“Internet路由注册表”的首字母缩写
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的BOF是谁[8]；二○○○年十二月十日至十五日；美国加利福尼亚州圣地亚哥
o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London, England
o 谁是第51届IETF的固定转炉[9]；二○○一年八月五日至十日；英国伦敦
o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA
o 第一次UWho咨询[10]；二〇〇一年八月十五日;；华盛顿特区，美国
o Second UWho Consultation; November 15, 2001; Marina del Rey, CA, USA
o 第二次UWho咨询；2001年11月15日；玛丽娜·德雷，加利福尼亚州，美国
o Third UWho Consultation; November 19, 2001; Washington, DC, USA
o 第三次世卫组织协商；2001年11月19日；华盛顿特区，美国
o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic
o DNR工作组，2001年10月1日至5日；捷克共和国普拉克
o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech Republic
o 数据库WG-40[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 DNR工作组，2002年1月14日至18日；荷兰阿姆斯特丹
o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
o 2002年1月14日至18日，第41号数据库；荷兰阿姆斯特丹
o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
o NANOG 24环球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的CRISP 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. 要订阅此电子邮件列表，请向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.
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和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.美国弗吉尼亚州斯特林Ridgetop Circle 21355，邮编20166
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
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）互联网协会（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编辑功能的资金目前由互联网协会提供。