Network Working Group N. Popp
Request for Comments: 3367 M. Mealling
Category: Standards Track VeriSign, Inc.
M. Moseley
Netword, Inc.
August 2002
Network Working Group N. Popp
Request for Comments: 3367 M. Mealling
Category: Standards Track VeriSign, Inc.
M. Moseley
Netword, Inc.
August 2002
Common Name Resolution Protocol (CNRP)
通用名称解析协议（CNRP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs. Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavailable. For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource.
人们通常用一个共同的名字或短语来指代现实世界中的事物，例如商品名、公司名或书名。这些名称有时比URL更容易记忆和键入。此外，由于URL的语法有限，公司和个人发现可能对其资源最合理的URL正在其他地方使用，因此不可用。在本文档中，“通用名”是指可能与资源相关联的没有强制句法结构的单词或短语。
This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is also intended to address issues of internationalization and localization. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added.
这项工作是为客户端应用程序创建一个协议，以便与通用名称解析服务通信，如浏览器增强和搜索站点范例所示。尽管该协议的主要功能是解决问题，但它也旨在解决国际化和本地化问题。名称解析服务不是通用搜索服务，因此不需要提供复杂的布尔查询、相关性排序或类似功能。该协议是一个简单、最小的可互操作核心。提供了扩展机制，以便添加额外的功能。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Important Notes . . . . . . . . . . . . . . . . . . . . . 4
2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 DTD is Definitive . . . . . . . . . . . . . . . . . . . . 4
2.3 Uniform Resource Identifiers . . . . . . . . . . . . . . . 5
3. Interaction Model . . . . . . . . . . . . . . . . . . . . 5
3.1 Services, Servers, Datasets and Referrals . . . . . . . . 5
3.2 Requests and Responses . . . . . . . . . . . . . . . . . . 5
3.3 Transport Independence . . . . . . . . . . . . . . . . . . 6
3.4 Character encoding . . . . . . . . . . . . . . . . . . . . 6
3.5 Queries . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Hints . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Object Model . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 Core properties . . . . . . . . . . . . . . . . . . . . . 8
4.1.2 Abstract and custom properties . . . . . . . . . . . . . . 9
4.1.3 Base properties . . . . . . . . . . . . . . . . . . . . . 9
4.1.4 Common name string encoding and equivalence rules . . . . 11
4.2 Objects . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Query . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1.1 Logical operations within a Query . . . . . . . . . . . . 12
4.2.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2.1 ResourceDescriptor . . . . . . . . . . . . . . . . . . . . 13
4.2.3 Service . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3.1 Datasets . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4 Status Messages . . . . . . . . . . . . . . . . . . . . . 19
4.2.4.1 Status of CNRP, Not the Transport . . . . . . . . . . . . 19
4.2.4.2 Codes and Description . . . . . . . . . . . . . . . . . . 19
4.2.4.3 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.5 Referral . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5.1 Loop Detection and Dataset Handling in Servers . . . . . . 22
4.2.6 Discoverability: ServiceQuery and Schema . . . . . . . . . 24
5. XML DTD for CNRP . . . . . . . . . . . . . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1 Service Description Request . . . . . . . . . . . . . . . 28
6.2 Sending A Query and Getting A Response . . . . . . . . . . 29
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1 HTTP Transport . . . . . . . . . . . . . . . . . . . . . . 30
7.2 SMTP Transport . . . . . . . . . . . . . . . . . . . . . . 31
8. Registration: application/cnrp+xml . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 32
References . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Important Notes . . . . . . . . . . . . . . . . . . . . . 4
2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 DTD is Definitive . . . . . . . . . . . . . . . . . . . . 4
2.3 Uniform Resource Identifiers . . . . . . . . . . . . . . . 5
3. Interaction Model . . . . . . . . . . . . . . . . . . . . 5
3.1 Services, Servers, Datasets and Referrals . . . . . . . . 5
3.2 Requests and Responses . . . . . . . . . . . . . . . . . . 5
3.3 Transport Independence . . . . . . . . . . . . . . . . . . 6
3.4 Character encoding . . . . . . . . . . . . . . . . . . . . 6
3.5 Queries . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Hints . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Object Model . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 Core properties . . . . . . . . . . . . . . . . . . . . . 8
4.1.2 Abstract and custom properties . . . . . . . . . . . . . . 9
4.1.3 Base properties . . . . . . . . . . . . . . . . . . . . . 9
4.1.4 Common name string encoding and equivalence rules . . . . 11
4.2 Objects . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Query . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1.1 Logical operations within a Query . . . . . . . . . . . . 12
4.2.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2.1 ResourceDescriptor . . . . . . . . . . . . . . . . . . . . 13
4.2.3 Service . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3.1 Datasets . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4 Status Messages . . . . . . . . . . . . . . . . . . . . . 19
4.2.4.1 Status of CNRP, Not the Transport . . . . . . . . . . . . 19
4.2.4.2 Codes and Description . . . . . . . . . . . . . . . . . . 19
4.2.4.3 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.5 Referral . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5.1 Loop Detection and Dataset Handling in Servers . . . . . . 22
4.2.6 Discoverability: ServiceQuery and Schema . . . . . . . . . 24
5. XML DTD for CNRP . . . . . . . . . . . . . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1 Service Description Request . . . . . . . . . . . . . . . 28
6.2 Sending A Query and Getting A Response . . . . . . . . . . 29
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1 HTTP Transport . . . . . . . . . . . . . . . . . . . . . . 30
7.2 SMTP Transport . . . . . . . . . . . . . . . . . . . . . . 31
8. Registration: application/cnrp+xml . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 32
References . . . . . . . . . . . . . . . . . . . . . . . . 33
A. Appendix A: Well Known Property and Type Registration
Templates . . . . . . . . . . . . . . . . . . . . . . . . 35
A.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 35
B. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 37
B.1 Level 1 (Informative) Codes . . . . . . . . . . . . . . . 37
B.2 Level 2 (Success) Codes . . . . . . . . . . . . . . . . . 38
B.3 Level 3 (Partial Success) Codes . . . . . . . . . . . . . 38
B.4 Level 4 (Transient Failure) Codes . . . . . . . . . . . . 40
B.5 Level 5 (Permanent Failures) Codes . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . . . . 42
A. Appendix A: Well Known Property and Type Registration
Templates . . . . . . . . . . . . . . . . . . . . . . . . 35
A.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 35
B. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 37
B.1 Level 1 (Informative) Codes . . . . . . . . . . . . . . . 37
B.2 Level 2 (Success) Codes . . . . . . . . . . . . . . . . . 38
B.3 Level 3 (Partial Success) Codes . . . . . . . . . . . . . 38
B.4 Level 4 (Transient Failure) Codes . . . . . . . . . . . . 40
B.5 Level 5 (Permanent Failures) Codes . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . . . . 42
Services are arising that offer a mapping from common names to Internet resources (e.g., as identified by a URI). These services often resolve common name categories such as company names, trade names, or common keywords. Thus, such a resolution service may operate in one or a small number of categories or domains, or may expect the client to limit the resolution scope to a limited number of categories or domains. For example, the phrase "Internet Engineering Task Force" is a common name in the "organization" category, as is "Moby Dick" in the book category.
出现的服务提供了从通用名称到Internet资源的映射（例如，由URI标识）。这些服务通常解析常见名称类别，如公司名称、商品名称或常见关键字。因此，这样的解析服务可以在一个或少量类别或域中操作，或者可以期望客户端将解析范围限制在有限数量的类别或域中。例如，短语“互联网工程任务组”是“组织”类别中的一个常见名称，就像书籍类别中的“白鲸”一样。
Two classes of clients of such services are being built, browser improvements and web accessible front-end services. Browser enhancements modify the "open" or "address" field of a browser so that a common name can be entered instead of a URL. Internet search sites integrate common name resolution services as a complement to search. In both cases, these may be clients of back-end resolution services. In the browser case, the browser must talk to a service that will resolve the common name. The search sites are accessed via a browser. In some cases, the search site may also be the back-end resolution service, but in others, the search site is a front-end to a collection of back-end services.
这类服务的两类客户机正在构建中，即浏览器改进和可通过web访问的前端服务。浏览器增强功能修改浏览器的“打开”或“地址”字段，以便可以输入通用名称而不是URL。Internet搜索站点集成通用名称解析服务，作为搜索的补充。在这两种情况下，它们都可能是后端解析服务的客户端。在浏览器的情况下，浏览器必须与将解析公共名称的服务对话。可通过浏览器访问搜索网站。在某些情况下，搜索站点也可能是后端解析服务，但在其他情况下，搜索站点是后端服务集合的前端。
This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added.
这项工作是为客户端应用程序创建一个协议，以便与通用名称解析服务通信，如浏览器增强和搜索站点范例所示。名称解析服务不是通用搜索服务，因此不需要提供复杂的布尔查询、相关性排序或类似功能。该协议是一个简单、最小的可互操作核心。提供了扩展机制，以便添加额外的功能。
Several other issues, while of importance to the deployment of common name resolution services, are outside of the resolution protocol itself and are not in the initial scope of the proposed effort. These include discovery and selection of resolution service providers, administration of resolution services, name registration, name ownership, and methods for creating, identifying or insuring unique common names.
其他几个问题虽然对公共名称解析服务的部署很重要，但不在解析协议本身的范围内，也不在拟议工作的初始范围内。这些包括发现和选择解析服务提供商、管理解析服务、名称注册、名称所有权以及创建、识别或确保唯一通用名称的方法。
For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource. These common names will be used primarily by humans, as opposed to machine agents. A common name "resolution service" handles these associations between common names and data (resources, information about resources, pointers to locations, etc.). A single common name may be associated with different data records, and more than one resolution service is expected to exist. Any common name may be used in any resolution service.
在本文档中，“通用名”是指可能与资源相关联的没有强制句法结构的单词或短语。这些通用名称将主要由人类使用，而不是机器代理。公共名称“解析服务”处理公共名称和数据（资源、有关资源的信息、指向位置的指针等）之间的关联。一个通用名称可能与不同的数据记录相关联，并且应该存在多个解析服务。任何解析服务中都可以使用任何通用名称。
Common names are not URIs (Uniform Resource Identifiers) in that they lack the syntactic structure imposed by URIs; furthermore, unlike URNs, there is no requirement of uniqueness or persistence of the association between a common name and a resource. (Note: common names may be expressed in a URI, the syntax for which is described in RFC 3368 [9].)
通用名称不是URI（统一资源标识符），因为它们缺少URI强加的语法结构；此外，与URN不同，公共名称和资源之间的关联不需要唯一性或持久性。（注意：通用名称可以用URI表示，其语法在RFC 3368[9]中描述。）
This document will define a protocol for the parameterized resolution necessary to make common names useful. "Resolution" is defined as the retrieval of data associated (a priori) with descriptors that match the input request. "Parameterized" means the ability to have a multi-property descriptor. Descriptors are not required to provide unique identification, therefore 0 or more records may be returned to meet a specific input query.
本文档将为使通用名称有用所需的参数化解析定义一个协议。“分辨率”定义为检索与匹配输入请求的描述符相关的（先验）数据。“参数化”指具有多属性描述符的能力。描述符不需要提供唯一标识，因此可以返回0个或多个记录以满足特定的输入查询。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[7]中所述进行解释。
The descriptive portions of this document contain pieces of XML that are *illustrative examples only*. Section 5 of this document contains the XML DTD for CNRP, which is definitive. If any discrepancies are found, the DTD wins.
本文档的描述性部分包含XML片段，这些片段仅为*示例*。本文档的第5节包含CNRP的XML DTD，这是确定的。如果发现任何差异，DTD将获胜。
All URIs used within the CNRP protocol MUST adhere to the 'absoluteURI' production found in the ABNF of [3]. CNRP does not define the semantics of a Base and therefore is not capable of expressing the 'URI-Reference' production.
CNRP协议中使用的所有URI必须符合[3]的ABNF中的“绝对URI”产品。CNRP没有定义基的语义，因此不能表示“URI引用”产品。
CNRP assumes a particular interaction model where a generalized "service" provides common name resolution at one or more actual "servers". If the data contained in all its servers is identical (mirrors), the service need not identify any particular subset of data. If, however, the service provides different collections of data through different servers (e.g., subsets, specialized collections, etc.), it SHOULD indicate what subsets of its data that each server offers. This is done by using URIs to uniquely disambiguate one dataset from another. If the service offers a copy of a collection of data on agreement with a foreign service, the foreign service SHOULD provide a dataset URI to allow the collection to be identified as related to its own offerings.
CNRP假设一个特定的交互模型，其中一个通用的“服务”在一个或多个实际的“服务器”上提供通用名称解析。如果其所有服务器中包含的数据都相同（镜像），则服务不需要标识任何特定的数据子集。但是，如果服务通过不同的服务器提供不同的数据集合（例如，子集、专用集合等），则应指出每个服务器提供的数据子集。这是通过使用URI唯一地消除一个数据集与另一个数据集之间的歧义来实现的。如果服务提供与外部服务达成协议的数据集合的副本，则外部服务应提供数据集URI，以允许将该集合标识为与其自己的产品相关。
CNRP supports the concept of referrals. This is where a server can know that another Service exists, within the same Service or elsewhere, that can provide further answers to a particular query but decides to forward that fact onto the client instead of chaining the query for the client. A referral is sent along with the rest of the results from a server (if any). Referrals to a service SHOULD indicate the particular dataseturi that triggered the referral, if it is known. See Section 4.2.5 for details on referrals and loop detection.
CNRP支持转诊的概念。在这种情况下，服务器可以知道在同一服务内或其他地方存在另一个服务，该服务可以为特定查询提供进一步的答案，但决定将该事实转发到客户端，而不是为客户端链接查询。将从服务器（如果有）发送一个引用以及其余结果。对服务的引用应该指示触发引用的特定dataseturi（如果已知）。有关转诊和循环检测的详细信息，请参见第4.2.5节。
The protocol consists of a simple request/response mechanism. A client sends one of a few types of requests to a server which responds with the results of that request. All requests and responses are encoded with XML [8] using the DTD found in Section 5. There are two types of requests. One is a general query for a common-name. The other is a request for an object that describes the service and its capabilities. There is only one type of response which is a set of results. Results can contain actual result items, referrals and/or status messages.
该协议由一个简单的请求/响应机制组成。客户机向服务器发送几种请求中的一种，服务器用该请求的结果进行响应。所有请求和响应都使用第5节中的DTD用XML[8]编码。有两种类型的请求。一种是通用名称的通用查询。另一个是对描述服务及其功能的对象的请求。只有一种类型的响应是一组结果。结果可以包含实际结果项、推荐和/或状态消息。
CNRP is completely encapsulated within its XML definition, and is therefore transport-independent in its specification. However, clients need to have a clearly defined means of bootstrapping a connection with a server.
CNRP完全封装在其XML定义中，因此在其规范中与传输无关。但是，客户机需要有一种明确定义的方法来引导与服务器的连接。
It is possible to define special-purpose applications that use CNRP but which never need the HTTP bootstrapping method outlined below; those applications MUST define how to find the appropriate server/port/protocol. CNRP servers dedicated to those applications may provide service only on the ports/transport protocols defined by the application.
可以定义使用CNRP但不需要下面概述的HTTP引导方法的专用应用程序；这些应用程序必须定义如何找到适当的服务器/端口/协议。专用于这些应用程序的CNRP服务器只能在应用程序定义的端口/传输协议上提供服务。
All other (generic) CNRP clients and servers MUST support the HTTP (Section 7.1) transport on the default CNRP port of 1096.
所有其他（通用）CNRP客户端和服务器必须支持默认CNRP端口1096上的HTTP（第7.1节）传输。
Note that a particular service may choose to change to a different transport or port via statements within a CNRP service description request, but with initial contacts between a client and a server being over HTTP on port 1096. For a short explanation of how CNRP employs HTTP, see Section 7.1 of this document. If other transports are used, they MUST be handled over a port other than the default CNRP port.
请注意，特定服务可以通过CNRP服务描述请求中的语句选择更改为不同的传输或端口，但客户端和服务器之间的初始联系通过端口1096上的HTTP进行。有关CNRP如何使用HTTP的简要说明，请参阅本文件第7.1节。如果使用其他传输，则必须通过默认CNRP端口以外的端口处理这些传输。
To guarantee interoperability, the following provisions apply:
为保证互操作性，以下规定适用：
o XML queries and responses MUST be encoded as UTF-8.
o XML查询和响应必须编码为UTF-8。
Note: As in any XML document, numeric character references may be used.
注意：与任何XML文档一样，可以使用数字字符引用。
o The encoding of characters in the CNRP URI is based on UTF-8; for details, please see [9].
o CNRP URI中的字符编码基于UTF-8；详情请参阅[9]。
Any interfaces electing to present/accept protocol elements in other representations are responsible for accurate transcoding for use in CNRP protocol elements, per the above provisions.
根据上述规定，选择在其他表示形式中呈现/接受协议元素的任何接口负责在CNRP协议元素中使用的准确转码。
Queries are sent by the client to the server. There are two types of queries.
查询由客户端发送到服务器。有两种类型的查询。
1. A `special' initial query that establishes the schema for a particular CNRP database and communicates that to the client. The CNRP client will send this query, and in turn receive an XML document defining the query properties that the database supports. (In CNRP, XML [8] is used to define and express all objects.) This query is called the 'servicequery' in the DTD. In the case where a client does not know anything about the Service, the client MAY assume that it can at least issue the request via HTTP.
1. “特殊”初始查询，用于为特定CNRP数据库建立模式并将其传送给客户端。CNRP客户端将发送此查询，然后依次接收定义数据库支持的查询属性的XML文档。（在CNRP中，XML[8]用于定义和表示所有对象。）此查询在DTD中称为“servicequery”。在客户机不了解服务的情况下，客户机可能认为它至少可以通过HTTP发出请求。
2. A `standard' query, which is the submission of the CNRP search string to the database. The query will conform to the schema that MAY have been previously retrieved from the service.
2. “标准”查询，即向数据库提交CNRP搜索字符串。查询将符合以前可能从服务检索到的架构。
There will be a set of query properties, listed below, treated as hints by the server. Note: a CNRP database will accept any correctly encoded CNRP query property; the extent to which a query result is responsive to those properties is a service differentiator. The base properties that are always supported are common name, language, geography, category, and range (start and length of the result set). CNRP allows database service providers to create unique data types and expose them to any CNRP client via the CNRP schema XML documents.
下面列出了一组查询属性，它们被服务器视为提示。注意：CNRP数据库将接受任何正确编码的CNRP查询属性；查询结果对这些属性的响应程度是服务的一个区别。始终支持的基本属性包括通用名称、语言、地理位置、类别和范围（结果集的开始和长度）。CNRP允许数据库服务提供商创建唯一的数据类型，并通过CNRP模式XML文档将其公开给任何CNRP客户端。
A hint is an assertion by the user about himself, herself or itself and the context in which he/she/it is operating. There is no data type `hint'; a hint is expressed within the structure of the query itself and is limited or enabled by the richness of the defined query namespace. In effect, a query and any property within it is a hint.
提示是用户对自己、自己或自身以及他/她/它正在操作的上下文的断言。没有数据类型“提示”；提示是在查询本身的结构中表达的，并且受到定义的查询名称空间的丰富性的限制或启用。实际上，查询及其任何属性都是一个提示。
For example, the "language" property can be given as a hint in a query; this may be used to order search results. If one wants results first in US English followed by European French and finally South American Spanish, the following can be included in the query:
例如，“language”属性可以在查询中作为提示给出；这可用于排序搜索结果。如果希望结果首先是美国英语，然后是欧洲法语，最后是南美西班牙语，则可以在查询中包括以下内容：
<property name="language" type="rfc1766">en-US</property>
<property name="language" type="rfc1766">en-US</property>
<property name="language" type="rfc1766">fr-FR</property>
<property name="language" type="rfc1766">fr-FR</property>
<property name="language" type="rfc1766">sp-MX</property>
<property name="language" type="rfc1766">sp-MX</property>
Note that the property statements say nothing about whether the language is primary, secondary, etc. In this example, the ordering of the statement controls that--the first statement, being first, means that US English is the primary language. The second statement specifies the second region/language, and so on. *But this is only an example.* The extent to which hints are supported (or not) is a service differentiator.
注意，属性语句没有说明语言是主语言还是次语言，等等。在本例中，语句的顺序控制着——第一个语句，即第一个，意味着美国英语是主语言。第二条语句指定第二个区域/语言，依此类推*但这只是一个例子。*支持（或不支持）提示的程度是服务的一个区别。
The fact that a hint exists does not mean that a CNRP database must respond to it. This best-effort approach is similar to relevance ranking in a search engine (high precision, low recall); hints are similar to a search engine's selection criteria. CNRP services will attempt to return the results "closest" to the selection criteria. This is quite different from a SQL database approach where a SQL query returns the entire results set and each result in the set must match all the requirements expressed by the qualifier (the SQL WHERE clause).
提示存在的事实并不意味着CNRP数据库必须响应它。这种尽力而为的方法类似于搜索引擎中的相关性排序（高精度、低召回率）；提示类似于搜索引擎的选择标准。CNRP服务将尝试返回“最接近”选择标准的结果。这与SQL数据库方法截然不同，在SQL数据库方法中，SQL查询返回整个结果集，并且集中的每个结果必须匹配限定符（SQL where子句）表示的所有要求。
In CNRP, objects are property lists. A property is a named attribute. A property also has a well-defined type. Some properties can be part of the query or the results list or both. For simplicity, CNRP is limiting property values to string values.
在CNRP中，对象是特性列表。属性是一个命名属性。属性还具有定义良好的类型。某些属性可以是查询或结果列表的一部分，也可以是两者的一部分。为简单起见，CNRP将属性值限制为字符串值。
CNRP introduces a set of core properties. Core properties are the minimal set of properties that all CNRP services MUST support in order to reach CNRP compliance. Hence, the core properties define the level of interoperability between all CNRP services. The core properties are:
CNRP引入了一组核心属性。核心属性是所有CNRP服务必须支持的最小属性集，以达到CNRP合规性。因此，核心属性定义了所有CNRP服务之间的互操作性级别。核心属性是：
1. CommonName: the common name associated with a resource.
1. CommonName：与资源关联的公共名称。
2. ID: an opaque string that serves as a unique identifier for a result from a Service (typically a database ID). The ID is not globally unique, nor necessarily persistent (e.g., between queries at a given Service).
2. ID：一个不透明字符串，用作服务结果的唯一标识符（通常是数据库ID）。ID不是全局唯一的，也不一定是持久的（例如，在给定服务的查询之间）。
3. resourceURI: An 'absoluteURI' as defined in the collected ABNF found in RFC 2396 [3].
3. resourceURI:RFC 2396[3]中收集的ABNF中定义的“绝对URI”。
4. description: A free text description of the resource.
4. 描述：资源的自由文本描述。
In addition to core properties, CNRP introduces the notion of abstract properties. The abstract property element provides schema extensibility beyond the core properties. The notion of abstract property is extremely important in CNRP since it enables a wider range of CNRP based services than those based on the core properties.
除了核心属性外，CNRP还引入了抽象属性的概念。抽象属性元素提供了核心属性之外的模式扩展性。抽象属性的概念在CNRP中非常重要，因为它支持比基于核心属性的服务更广泛的基于CNRP的服务。
To create concrete custom properties, a CNRP service must define a property name and a property type. Therefore, there are really two ways to create a custom property. The first way is to create a new property name and define at least one type for it. Another way is to extend an existing property by defining a new type. The "geography" property discussed in the next section is an example of a multi-type property. Note that a type is only applicable to the property it is defined for. If a new property is defined, a new type MUST be defined even though the value set for that type may be identical to an existing type for an existing property. In other words, types are scoped to a given property. Custom properties MUST be registered with IANA. Details about the registration process for new properties can be found in Section 10.
要创建具体的自定义特性，CNRP服务必须定义特性名称和特性类型。因此，创建自定义属性实际上有两种方法。第一种方法是创建一个新的属性名称，并为其定义至少一种类型。另一种方法是通过定义新类型来扩展现有属性。下一节讨论的“地理”属性是一个多类型属性的示例。请注意，类型仅适用于为其定义的属性。如果定义了新特性，则必须定义新类型，即使该类型的值集可能与现有特性的现有类型相同。换句话说，类型的作用域是给定的属性。自定义属性必须向IANA注册。有关新房产注册流程的详细信息，请参见第10节。
For example, let us assume that a CNRP service specialized on online books would like to introduce the ISBN property of type "number". This property would encapsulate the ISBN number of the book online and would have he following XML representation:
例如，假设一个专门针对在线图书的CNRP服务想要引入类型为“number”的ISBN属性。此属性将封装在线图书的ISBN编号，并具有以下XML表示形式：
<property name="isbn" type="number">92347231</property>
<property name="isbn" type="number">92347231</property>
Illustrating the use of abstract property to extend the core schema, CNRP also defines a set of custom properties called base properties. In order to keep the requirements extremely simple, these properties are not mandatory to implement to reach CNRP compliance. Although, these properties are not required, it is expected that many services, especially large ones, will implement them. An equally important goal for introducing additional properties is to provide a results filtering mechanism. This is a requirement for large namespaces that contain several million names.
为了说明如何使用抽象属性来扩展核心模式，CNRP还定义了一组称为基本属性的自定义属性。为了使要求极其简单，这些属性不是实现CNRP合规性所必需的。虽然这些属性不是必需的，但预计许多服务，特别是大型服务，将实现它们。引入附加属性的一个同样重要的目标是提供结果过滤机制。这是包含数百万个名称的大型名称空间的要求。
The base properties and their types are defined in Appendix A but listed here for clarity:
基本属性及其类型在附录A中有定义，但为清晰起见，此处列出：
o Language: The language associated with a resource. The default type of this property is 'RFC1766' and the vocabulary is drawn from the list of languages in RFC 1766 [4]. If RFC 1766 is updated, then the values listed in the updated version are also valid for this type.
o 语言：与资源关联的语言。此属性的默认类型为“RFC1766”，词汇表取自RFC1766[4]中的语言列表。如果更新了RFC 1766，则更新版本中列出的值也适用于此类型。
o Geography: The geographical region or location associated with a resource. Some of the possible types are listed below. See Appendix A for a complete list of types specified by this document.
o 地理：与资源相关的地理区域或位置。下面列出了一些可能的类型。本文件规定的完整类型列表见附录A。
* 'freeform': a free form expression for a geographical location (e.g., "palo alto in california").
* “freeform”：表示地理位置的自由形式表达式（例如，“加利福尼亚州的帕洛阿尔托”）。
* 'ISO3166-1': geographical region expressed using a standard country code as defined by ISO3166-1 (e.g., "US").
* “ISO3166-1”：使用ISO3166-1定义的标准国家代码表示的地理区域（例如，“美国”）。
* 'ISO3166-2': value = a geographical region expressed using a standard region and country codes as defined by ISO3166-2 (e.g., "US-CA").
* “ISO3166-2”：值=使用ISO3166-2定义的标准地区和国家代码表示的地理区域（例如，“US-CA”）。
* 'lat-long': the latitude and longitude of a geographical location.
* “lat long”：地理位置的纬度和经度。
o Category: The category associated with a resource. There are large numbers of possible types for this property. Two possible ones are:
o 类别：与资源关联的类别。此属性有大量可能的类型。两种可能的情况是：
1. 'freeform': a free form expression for a category (e.g., "movies").
1. “freeform”：类别的自由形式表达式（例如，“movies”）。
2. 'NAICS': The North American Industry Code System.
2. “NAICS”：北美行业代码系统。
o Range: The range is a results set control property. The range property is used to specify the starting point and the length of a results set (e.g., I want 5 records starting at the 10th record). It should only ever have one type but, in the interest of extensibility and consistency, others can be created if there is a need. The default type is 'start-length' which takes the form of two integers separated by a dash. The first integer is the starting number and the second is the number of values to include.
o 范围：范围是结果集控件属性。range属性用于指定结果集的起点和长度（例如，我想要从第10条记录开始的5条记录）。它应该只有一种类型，但是为了扩展性和一致性，如果需要，可以创建其他类型。默认类型为“起始长度”，它采用由破折号分隔的两个整数的形式。第一个整数是起始数，第二个整数是要包含的值数。
o Dataseturi: An absoluteURI (as defined in [3] that identifies a defined set of Common Names and associated data.
o Dataseturi：一个绝对URI（定义见[3]），它标识一组已定义的通用名称和相关数据。
Note: For many properties the default "type" is "freeform". The free form type value is important because it allows very simple user interface where the user can enter a value in a text field. It is up to the service to interpret the value correctly and take advantage of it to increase the relevance of results (using specialized dictionaries for instance).
注意：对于许多属性，默认的“类型”是“自由形式”。自由格式类型值很重要，因为它允许非常简单的用户界面，用户可以在其中的文本字段中输入值。由服务来正确解释值并利用它来增加结果的相关性（例如使用专门的词典）。
CNRP specifies that common name strings should be encoded using UTF-8. CNRP does not specify any string equivalence rules for matching a common name in the query against a common name of a Resource. String equivalence rules are language and service dependent. They are specific to relevance ranking algorithms, hence treated as CNRP services. Consequently, string equivalence rules are not part of the CNRP protocol specification. For example, the query member:
CNRP指定公共名称字符串应使用UTF-8编码。CNRP没有指定任何字符串等价规则，用于将查询中的公共名称与资源的公共名称进行匹配。字符串等价规则依赖于语言和服务。它们特定于相关性排序算法，因此被视为CNRP服务。因此，字符串等价规则不是CNRP协议规范的一部分。例如，查询成员：
<commonname>bmw</commonname>
<commonname>bmw</commonname>
should be read as a selection criterion for a resource with a common name LIKE (similar to) the string "bmw" where the exact definition of the LIKE operator is intuitive, yet specific to the queried CNRP service.
应将其作为一个资源的选择标准，该资源的通用名称类似于字符串“bmw”，其中LIKE运算符的准确定义是直观的，但特定于查询的CNRP服务。
It is also important to note that XML treats whitespace as a special case in many situations. In some cases, it collapses whitespace into a single space. Both client and server Implementors are warned to reference the XML standard for the various ramifications of using whitespace in queries and/or results.
还需要注意的是，XML在许多情况下将空白视为特例。在某些情况下，它将空格压缩为单个空格。警告客户机和服务器实现者在查询和/或结果中使用空白的各种后果时都要参考XML标准。
The Query object encapsulates all the query components such as CommonName, ID, and any properties. A Query cannot be empty. A Query must contain either one and only one common name, or one and only one ID. A Query can also contain the custom properties defined by a specific CNRP service.
查询对象封装了所有查询组件，如CommonName、ID和任何属性。查询不能为空。查询必须包含一个且仅包含一个通用名称或一个且仅包含一个ID。查询还可以包含特定CNRP服务定义的自定义属性。
For example, a query for the first 5 resources whose common name is like "bmw" would be expressed as:
例如，前5个公共名称类似于“bmw”的资源的查询将表示为：
<query>
<commonname>bmw</commonname>
<property name="range" type="start-length">1-5</property>
</query>
<query>
<commonname>bmw</commonname>
<property name="range" type="start-length">1-5</property>
</query>
The Query syntax is extremely simple. CNRP does not extensively support Boolean logic operator such as OR, AND or NOT. However, there exist two implicit logical operations that can be expressed through the Query object and its properties. First, a query with multiple property-value pairs implicitly expresses an AND operation on the query terms. For instance, the CNRP query to request all the resources whose common name is like "bmw", AND whose language is "German" can be expressed as:
查询语法非常简单。CNRP不广泛支持布尔逻辑运算符，如OR、AND或not。但是，存在两个可以通过查询对象及其属性表示的隐式逻辑操作。首先，具有多个属性-值对的查询隐式表示对查询项的AND操作。例如，请求公共名称为“bmw”且语言为“德语”的所有资源的CNRP查询可以表示为：
<query>
<commonname>bmw</commonname>
<property name="language" type="rfc1766">
de-DE
</property>
</query>
<query>
<commonname>bmw</commonname>
<property name="language" type="rfc1766">
de-DE
</property>
</query>
Note however, that because the server is only trying to best match the Query criteria, there is no guarantee that all or any of the resources in the results match both requirements.
但是请注意，由于服务器只是试图最好地匹配查询条件，因此无法保证结果中的所有或任何资源都匹配这两个要求。
In addition, CNRP allows the client to express a logical OR by specifying multiple values for the same property within the Query. For example, the logical expression:
此外，CNRP允许客户端通过在查询中为同一属性指定多个值来表示逻辑OR。例如，逻辑表达式：
property = value1 OR property = value2 OR property = valueN
property = value1 OR property = value2 OR property = valueN
Will be expressed as:
将表示为：
<property>value1</property>
<property>value2</property>
<property>valueN</property>
<property>value1</property>
<property>value2</property>
<property>valueN</property>
So if there are different properties expressed, CNRP ANDs them; if there are multiples instances of the same property expressed, CNRP ORs them.
因此，如果有不同的属性表示，CNRP将对其进行排序；如果表示了同一属性的多个实例，则CNRP将对其进行排序。
It is important to underline that this form is only applicable to properties (with the exception of the CommonName itself which, even though it is a property, is the entire point of the query). In particular, logical OR operations on the common name are not supported. Note that the ordering or the property-value pairs in the query implies a precedence. As a consequence, CNRP also introduces one special string value: "*". Not surprisingly, "*" means all admissible values for the typed property. For example, the following query requests all the resources whose common name is like BMW and whose language is preferably in German or French or any other language.
请务必强调，此表单仅适用于属性（CommonName本身除外，尽管它是一个属性，但它是整个查询点）。特别是，不支持对公用名称执行逻辑或操作。请注意，查询中的排序或属性值对表示优先级。因此，CNRP还引入了一个特殊的字符串值：“*”。毫不奇怪，“*”表示类型化属性的所有允许值。例如，下面的查询请求公共名称类似于BMW、语言最好是德语、法语或任何其他语言的所有资源。
<query>
<commonname>bmw</commonname>
<property name="language" type="rfc1766">de-DE</property>
<property name="language" type="rfc1766">fr-FR</property>
<property name="language" type="rfc1766">*</property>
</query>
<query>
<commonname>bmw</commonname>
<property name="language" type="rfc1766">de-DE</property>
<property name="language" type="rfc1766">fr-FR</property>
<property name="language" type="rfc1766">*</property>
</query>
The results object is a container for CNRP results. The type of objects contained in Results can be: ResourceDescriptor, Error, Referral and Schema. Results from a CNRP service are ordered by decreasing relevance. When the results set contains results from multiple CNRP services, the results can no longer be ordered (since relevance ranking is specific to a given service). In that case, however, note that results originating from the same service remain ordered.
结果对象是CNRP结果的容器。结果中包含的对象类型可以是：ResourceDescriptor、Error、Referral和Schema。CNRP服务的结果按相关性递减排序。当结果集包含来自多个CNRP服务的结果时，无法再对结果进行排序（因为相关性排名是特定于给定服务的）。但是，在这种情况下，请注意来自同一服务的结果仍然是有序的。
The ResourceDescriptor object describes an Internet resource (e.g., a Web page, a person, any object identified by a URI). Therefore, the ResourceDescriptor MUST always include the resourceURI property. The ResourceDescriptor can also contain the commonname, URI, ID (the ID of this entry in the service's database), description, language, geography, and category of the resource. A ResourceDescriptor can also be augmented using custom properties and can reference a service object to indicate its origin (using the serviceRef element). As with referrals, a resourcedescriptor block can also contain an ID attribute that is used by a status message to refer to a particular resourcedescriptor. Be careful not to confuse this ID with the id tag itself which refers to the database id of the actual database entry.
ResourceDescriptor对象描述Internet资源（例如，网页、个人、URI标识的任何对象）。因此，ResourceDescriptor必须始终包含resourceURI属性。ResourceDescriptor还可以包含资源的commonname、URI、ID（服务数据库中此项的ID）、描述、语言、地理位置和类别。ResourceDescriptor还可以使用自定义属性进行扩充，并可以引用服务对象来指示其来源（使用serviceRef元素）。与引用一样，resourcedescriptor块还可以包含一个ID属性，状态消息使用该属性来引用特定的resourcedescriptor。注意不要将此ID与ID标记本身混淆，后者引用实际数据库条目的数据库ID。
<results>
<service id="i0">
<serviceuri>http://cnrp.bar.com/</serviceuri>
</service>
<resourcedescriptor id="i1">
<commonname>bmw</commonname>
<id>foo.com:234364</id>
<resourceuri>http://www.bmw.de/</resourceuri>
<serviceref ref="i0" />
<description>BMW Motorcycles, International</description>
<property name="language" type="rfc1766">de-DE</property>
</resourcedescriptor>
<referral>
<serviceref ref="i0" />
</referral>
</results>
<results>
<service id="i0">
<serviceuri>http://cnrp.bar.com/</serviceuri>
</service>
<resourcedescriptor id="i1">
<commonname>bmw</commonname>
<id>foo.com:234364</id>
<resourceuri>http://www.bmw.de/</resourceuri>
<serviceref ref="i0" />
<description>BMW Motorcycles, International</description>
<property name="language" type="rfc1766">de-DE</property>
</resourcedescriptor>
<referral>
<serviceref ref="i0" />
</referral>
</results>
The Service object provides an encapsulation of an instance of a CNRP service. A service is uniquely identified through the serviceuri tag which MUST be included in the Service object. A Service object MAY include a a brief textual description of the service. It MAY include datasets, servers and custom properties.
服务对象提供CNRP服务实例的封装。服务通过必须包含在服务对象中的serviceuri标记进行唯一标识。服务对象可以包括服务的简短文本描述。它可能包括数据集、服务器和自定义属性。
<service>
<serviceuri>http://cnrp.foo.com</serviceuri>
<description>foo.com is a CNRP service specialized on cocktail
recipes</description>
</service>
<service>
<serviceuri>http://cnrp.foo.com</serviceuri>
<description>foo.com is a CNRP service specialized on cocktail
recipes</description>
</service>
The service object MAY also be extended by including existing properties to further describe the service. For instance, a service that focuses on French companies could be expressed as:
还可以通过包括现有属性来扩展服务对象，以进一步描述服务。例如，专注于法国公司的服务可以表示为：
<service>
<serviceuri>http://cnrp.foo.com</serviceuri>
<property name="category" type="freeform">companies</property>
<property name="geography" type="ISO3166-1">FR</property>
</service>
<service>
<serviceuri>http://cnrp.foo.com</serviceuri>
<property name="category" type="freeform">companies</property>
<property name="geography" type="ISO3166-1">FR</property>
</service>
The dataset object represents a set of CN-to-URI mappings. For example, the database of AOL keywords and their URIs constitute a dataset. The dataset object allows a CNRP implementation to uniquely identify the database(s) of mappings that it resolves. In that respect, the notion of dataset allows a separation between resolution
dataset对象表示一组CN到URI的映射。例如，AOL关键字数据库及其URI构成了一个数据集。dataset对象允许CNRP实现唯一标识其解析的映射数据库。在这方面，数据集的概念允许分辨率之间的分离
and data, providing the mechanism for a CNRP service to resolve common-names on behalf of another CNRP service or even multiple services. Conversely, the same dataset can be served by two distinct CNRP services. Since a CNRP service can resolve names within one or more datasets, the service object can contain one or more dataset objects (zero if the dataset is not formally declared).
和数据，为CNRP服务提供代表另一个CNRP服务甚至多个服务解析公共名称的机制。相反，相同的数据集可以由两个不同的CNRP服务提供服务。由于CNRP服务可以解析一个或多个数据集中的名称，因此服务对象可以包含一个或多个数据集对象（如果未正式声明数据集，则为零）。
Within the service object, a dataset is uniquely defined using the dataseturi property. Other properties, such as language and description, can describe the dataset further. Like the service object, the dataset object has an ID attribute associated with it that is unique within a particular XML message. Like the service object's ID attribute, this ID is used by resourcedescriptors and referrals to specify which service and/or dataset they came from or are referring to.
在服务对象中，数据集是使用dataseturi属性唯一定义的。其他属性（如语言和描述）可以进一步描述数据集。与服务对象一样，dataset对象具有与之关联的ID属性，该属性在特定XML消息中是唯一的。与服务对象的ID属性类似，ResourceDescriptor和引用也使用此ID来指定它们来自或引用的服务和/或数据集。
Any service can be said to have a 'default dataset' which is the dataset that considered to have been used if a server simply responds to a client's query that didn't contain a dataset. The 'default dataset' can also be said to be the only dataset that is used by Services that don't support datasets at all. This concept is useful for clients that intend on doing rigorous loop detection by way of keeping a list of visited service/dataset nodes.
任何服务都可以说有一个“默认数据集”，如果服务器只是响应不包含数据集的客户机查询，则该数据集被认为已被使用。“默认数据集”也可以说是完全不支持数据集的服务使用的唯一数据集。此概念对于打算通过保存访问的服务/数据集节点列表来执行严格循环检测的客户机非常有用。
This example illustrates how the service object would look as it defines two datasets:
此示例说明了服务对象在定义两个数据集时的外观：
<service id="i0">
<serviceuri>http://acmecorp.com</serviceuri>
<dataset id="i1">
<property name="dataseturi">
urn:oid:1.2.3.4.666.5.4.3.1
</property>
<property name="language">en-us</property>
<property name="language">en-gb</property>
</dataset>
<dataset id="i2">
<property name="dataseturi">
urn:oid:1.2.3.4.666.10.9.8.7.6
</property>
<property name="language">fr</property>
</dataset>
</service>
<service id="i0">
<serviceuri>http://acmecorp.com</serviceuri>
<dataset id="i1">
<property name="dataseturi">
urn:oid:1.2.3.4.666.5.4.3.1
</property>
<property name="language">en-us</property>
<property name="language">en-gb</property>
</dataset>
<dataset id="i2">
<property name="dataseturi">
urn:oid:1.2.3.4.666.10.9.8.7.6
</property>
<property name="language">fr</property>
</dataset>
</service>
The dataseturi property can also be used within the query as a hint to the service for the dataset within which the commonname should be resolved:
dataseturi属性也可以在查询中用作数据集服务的提示，commonname应该在该数据集中解析：
<query>
<commonname>toys r us</commonname>
<property name="dataseturi">urn:oid:1.2.3.4.666.5.4.3.1</property>
</query>
<query>
<commonname>toys r us</commonname>
<property name="dataseturi">urn:oid:1.2.3.4.666.5.4.3.1</property>
</query>
It is important to note that resolution rules (i.e., string equivalence, relevance ranking, etc.) are likely to be dataset specific. This is true even if the resolution is provided by the same service.
需要注意的是，解析规则（即字符串等价、相关性排序等）可能是特定于数据集的。即使解决方案由同一服务提供，也是如此。
Another use of the dataseturi property is in a referral. In that case, the datasetref tag is used to pinpoint a specific dataset within the service.
dataseturi属性的另一个用途是在引用中。在这种情况下，datasetref标记用于精确定位服务中的特定数据集。
<referral>
<serviceref ref="i0" /><datasetref ref="i1" />
</referral>
<referral>
<serviceref ref="i0" /><datasetref ref="i1" />
</referral>
While the concept of datasets is important for services wishing to make their data available via other services, it is important to remember that the declaration and use of datasets is completely optional. Compliance with the CNRP protocol does not require a service object to define or reference any dataset object. The only requirement for compliance is that a client and/or server know the format of the particular XML tags and deal with them syntactically. If it chooses to ignore them, then this is well within its rights.
虽然数据集的概念对于希望通过其他服务提供数据的服务来说很重要，但重要的是要记住，数据集的声明和使用是完全可选的。遵守CNRP协议不要求服务对象定义或引用任何数据集对象。遵从性的唯一要求是客户机和/或服务器知道特定XML标记的格式，并按语法处理它们。如果它选择忽略它们，那么这完全是它的权利范围。
The service object also encapsulates a list of server objects. The server object is used to describe a CNRP server or set of servers. A server is identified through its serveruri. The URI used to identify a server is not a CNRP URI [9], but instead, is a URI of the scheme used as the CNRP transport mechanism. I.e., for a CNRP server that will communicate via the HTTP protocol to the host foo.com on port 6543, the serveruri would be http://foo.com:6543. If some other information is required in order for the correct transport to be used, then that information can be communicated via other properties. Note that a Service MUST have at least one Server that responds on the default CNRP port in order for a client to get the initial Service object.
服务对象还封装了服务器对象的列表。服务器对象用于描述CNRP服务器或一组服务器。服务器通过其serveruri进行标识。用于标识服务器的URI不是CNRP URI[9]，而是用作CNRP传输机制的方案的URI。即，对于将通过HTTP协议与端口6543上的主机foo.com通信的CNRP服务器，serveruri将为http://foo.com:6543. 如果为了使用正确的传输需要一些其他信息，那么可以通过其他属性来传递这些信息。请注意，服务必须至少有一台服务器在默认CNRP端口上响应，以便客户端获得初始服务对象。
A server can serve one or more datasets declared by its service. The served databases are specified using the dataseturi property. As for other objects, a server can be further described using descriptive properties such as geography and description. The following XML completes the service definition from the previous example by defining two CNRP servers. One server is located in the US and the
服务器可以为其服务声明的一个或多个数据集提供服务。所服务的数据库是使用dataseturi属性指定的。对于其他对象，可以使用描述属性（如地理和描述）进一步描述服务器。下面的XML通过定义两个CNRP服务器来完成上一个示例中的服务定义。一台服务器位于美国和美国
other is located in France. The US server is specialized and only serves the French dataset.
另一个位于法国。美国服务器是专门的，只为法语数据集服务。
<servers>
<server>
<serveruri>cnrp://router.us.widgetco.com:4321</serveruri>
<property name="geography" type="ISO3166-1">US</property>
</server>
<server>
<serveruri>cnrp://router.fr.acmeco.com:4321</serveruri>
<property name="geography" type="ISO3166-1">FR</property>
</server>
</servers>
<servers>
<server>
<serveruri>cnrp://router.us.widgetco.com:4321</serveruri>
<property name="geography" type="ISO3166-1">US</property>
</server>
<server>
<serveruri>cnrp://router.fr.acmeco.com:4321</serveruri>
<property name="geography" type="ISO3166-1">FR</property>
</server>
</servers>
As we will see in a following section, the Service object can contain Schema objects. These Schema objects fully describe the query and response interfaces implemented by a CNRP service. In that regard, the Service object is essential to discoverability. It constitutes the main entry point for a CNRP client to dynamically discover the capabilities of a resolution service. For that purpose, the Service object can be returned as part of the response to any resolution query. Furthermore, the Service object is the dedicated response to the specialized servicequery (see Section 4.2.6).
正如我们将在下一节中看到的，服务对象可以包含模式对象。这些模式对象完全描述了由CNRP服务实现的查询和响应接口。在这方面，服务对象对于可发现性至关重要。它构成了CNRP客户端动态发现解析服务功能的主要入口点。为此，服务对象可以作为对任何解析查询的响应的一部分返回。此外，服务对象是专用servicequery的专用响应（参见第4.2.6节）。
Another use of Service is for other objects to indicate their CNRP service of origin. System messages, referrals and resourcedescriptors can include a reference to their Service object. For example, imagine a CNRP service that acts as a proxy for multiple CNRP services. For example, it is a requirement that CNRP allows aggregation of results from different sources. Consider one such CNRP service that acts as a proxy for multiple CNRP services. In this mode, the proxy service contacts each CNRP sub-service in parallel or serially. Then, the proxy combines the individual result sets into a unique response returned to the CNRP client. Since the aggregate result set contains resourcedescriptors from different services, the proxy adds a servicereference tag within each individual result to indicate their service of origin. In the event one of the referred services resolves names within multiple datasets, it is possible for these objects to refer to a specific dataset within the service by using the datasetref tag. This example is of a hybrid result set with resourcedescriptors referencing their service and dataset of origin:
服务的另一个用途是让其他对象指示其CNRP源服务。系统消息、引用和资源描述符可以包括对其服务对象的引用。例如，假设一个CNRP服务充当多个CNRP服务的代理。例如，要求CNRP允许聚合来自不同来源的结果。考虑一个这样的CNRP服务，它充当多个CNRP服务的代理。在此模式下，代理服务并行或串行地联系每个CNRP子服务。然后，代理将各个结果集组合成返回给CNRP客户端的唯一响应。由于聚合结果集包含来自不同服务的ResourceDescriptor，因此代理在每个单独的结果中添加servicereference标记，以指示其原始服务。如果引用的服务之一解析多个数据集中的名称，则这些对象可以使用datasetref标记引用服务中的特定数据集。此示例是一个混合结果集，其中ResourceDescriptor引用其服务和原始数据集：
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service id="i0">
<serviceuri>http://acmecorp.com</serviceuri>
<dataset id="i1">
<property name="dataseturi">
urn:oid:1.2.3.4.666.5.4.3.1
</property>
</dataset>
<dataset id="i2">
<property name="dataseturi">
urn:oid:1.2.3.4.666.10.9.8.7.6
</property>
</dataset>
</service>
<service id="i3">
<serviceuri>http://serverfarm.acmecorp.com</serviceuri>
</service>
<service id="i4">
<serviceuri>http://servers.acmecorp.co.uk</serviceuri>
<dataset id="i5">
<property name="dataseturi">
urn:oid:1.2.3.4.666.5.4.3.1
</property>
</dataset>
</service>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://www.fidonet.ca</resourceuri>
<serviceref ref="i0" /><datasetref ref="i1" />
<description>This is ye olde Canadian
Fidonet</description>
</resourcedescriptor>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://host:port/bla</resourceuri>
<serviceref ref="i3" />
<description>An old Fidonet node</description>
</resourcedescriptor>
<referral>
<serviceref ref="i0" /><datasetref ref="i2" />
</referral>
</results>
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service id="i0">
<serviceuri>http://acmecorp.com</serviceuri>
<dataset id="i1">
<property name="dataseturi">
urn:oid:1.2.3.4.666.5.4.3.1
</property>
</dataset>
<dataset id="i2">
<property name="dataseturi">
urn:oid:1.2.3.4.666.10.9.8.7.6
</property>
</dataset>
</service>
<service id="i3">
<serviceuri>http://serverfarm.acmecorp.com</serviceuri>
</service>
<service id="i4">
<serviceuri>http://servers.acmecorp.co.uk</serviceuri>
<dataset id="i5">
<property name="dataseturi">
urn:oid:1.2.3.4.666.5.4.3.1
</property>
</dataset>
</service>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://www.fidonet.ca</resourceuri>
<serviceref ref="i0" /><datasetref ref="i1" />
<description>This is ye olde Canadian
Fidonet</description>
</resourcedescriptor>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://host:port/bla</resourceuri>
<serviceref ref="i3" />
<description>An old Fidonet node</description>
</resourcedescriptor>
<referral>
<serviceref ref="i0" /><datasetref ref="i2" />
</referral>
</results>
</cnrp>
</cnrp>
The status messages defined here are only applicable to operations defined by CNRP itself. If some feature or operation is defined by the transport (security via HTTP, mail failure via SMTP, etc.), then any status messages about that operation MUST be sent in accordance with that transport's reporting mechanism and not via CNRP.
此处定义的状态消息仅适用于CNRP本身定义的操作。如果传输定义了某些功能或操作（通过HTTP的安全性、通过SMTP的邮件故障等），则必须根据该传输的报告机制而不是通过CNRP发送有关该操作的任何状态消息。
A Status object indicates a message to the client in the results set. The object encapsulates two values: a status code and a description. The description can contain a textual description of the status being communicated. In many cases, additional diagnostic information can also be included. No attempt is made to standardize the description of a given status code since the only programmatic element that matters is the actual code.
状态对象在结果集中向客户端指示消息。该对象封装了两个值：状态代码和描述。描述可以包含正在通信的状态的文本描述。在许多情况下，还可以包括其他诊断信息。没有尝试标准化给定状态代码的描述，因为唯一重要的编程元素是实际代码。
A status message can also specify which other CNRP element it refers to by including a reference to the ID of the element in question. For example, if a Service block has an ID of "i2" and a status message refers to that block, then it can put that ID in its ref attribute.
状态消息还可以通过包含对相关元素ID的引用来指定它引用的其他CNRP元素。例如，如果服务块的ID为“i2”，并且状态消息引用该块，那么它可以将该ID放入其ref属性中。
<status code="x.y.z" ref="i2">
The CNRP foo.com database is temporarily unreachable
</status>
<status code="x.y.z" ref="i2">
The CNRP foo.com database is temporarily unreachable
</status>
The organization of status codes is taken from RFC 1893 [10] which structures its codes in the form of x.yyy.zzz. Taken from RFC 1893 is the ABNF for the codes:
状态代码的组织取自RFC 1893[10]，其代码的结构形式为x.yyy.zzz。取自RFC 1893的是代码的ABNF：
status-code = class "." subject "." detail
class = "2"/"3"/"4"/"5"
subject = 1*3digit
detail = 1*3digit
status-code = class "." subject "." detail
class = "2"/"3"/"4"/"5"
subject = 1*3digit
detail = 1*3digit
The top level codes denote levels of severity of the status:
顶层代码表示状态的严重程度：
o 1.X.X Informational
o 1.X.X信息
* The information conveyed by the code has no bearing or indication of the success or failure of any request. It is strictly for informational purposes only.
* 守则所传达的资料，并不表示任何要求的成功或失败。它仅用于提供信息。
o 2.X.X Success
o 2.X.X成功
* The request was processed and results were returned. In most cases, this status class won't be sent since actual results themselves denote success. In other cases, results were returned but some information needs to be returned to the client.
* 已处理请求并返回结果。在大多数情况下，不会发送此状态类，因为实际结果本身表示成功。在其他情况下，返回结果，但需要将一些信息返回给客户端。
o 3.X.X Partial Success
o 3.X.X部分成功
* The request was processed and results were returned. In this case though, some values sent with the request were either invalid or ignored but in a way that the server still considers the response to be a successful one and not indicative of any true error condition.
* 已处理请求并返回结果。不过，在这种情况下，随请求发送的某些值无效或被忽略，但服务器仍然认为响应是成功的，并且不指示任何真正的错误情况。
o 4.X.X Transient Failure
o 4.X.X瞬态故障
* The request was valid as sent, but some temporary event prevents the successful completion of the request and/or sending of the results. Sending in the future may be possible.
* 请求在发送时有效，但某些临时事件会阻止请求的成功完成和/或结果的发送。将来可能会发送。
o 5.X.X Permanent Failure
o 5.X.X永久性故障
* A permanent failure is one which is not likely to be resolved by re-sending the request in its current form. Some change to the request or the destination must be made for successful request.
* 永久性故障是指不可能通过以当前形式重新发送请求来解决的故障。为了请求成功，必须对请求或目的地进行一些更改。
The second level codes denote the subject of the status messages. This value applies to each of the five classifications. The subject sub-code, if recognized, must be reported even if the additional detail provided by the detail sub-code is not recognized. The enumerated values for the subject sub-code are:
第二级代码表示状态消息的主题。此值适用于五个分类中的每一个。即使无法识别明细子代码提供的附加明细，也必须报告主题子代码（如果已识别）。主题子代码的枚举值为：
o X.0.X Other or Undefined Status
o X.0.X其他或未定义状态
* No specific information is available about what subject class this message belongs to.
* 没有关于此邮件所属主题类别的特定信息。
o X.1.X Query Related
o X.1.X查询相关
* Any status related to some specific way in which the query was encoded or its values with the exception of properties.
* 与查询的特定编码方式或其值（属性除外）相关的任何状态。
o X.2.X Service Related
o X.2.X与服务相关
* Any status related to the service in which this server is cooperating in providing.
* 与此服务器协同提供的服务相关的任何状态。
Appendix B contains a list of all predefined status codes
附录B包含所有预定义状态代码的列表
A Referral object in the results set is a place holder for un-fetched results from a different service and possibly dataset. Referrals typically occur when a CNRP server knows of another service capable of providing relevant results for the query and wants to notify the client about this possibility. The client can decide whether it wants to follow the referral and resolve the extra results by contacting the referred-to service using the information contained within the Referral object (a Service object and possible properties). The Referral is a simple mechanism to enable hierarchical resolution as well as to join multiple resolution services together.
结果集中的引用对象是从不同服务（可能是数据集）获取的结果的占位符。推荐通常发生在CNRP服务器知道另一个能够为查询提供相关结果的服务，并希望将这种可能性通知客户端时。客户端可以通过使用引用对象（服务对象和可能的属性）中包含的信息联系引用的服务来决定是否要遵循引用并解决额外结果。引用是一种简单的机制，用于启用分层解析以及将多个解析服务连接在一起。
<results>
<service id="i0">
<serviceuri>http://cnrp.bar.com/</serviceuri>
<dataset id="i1">
<property name="dataseturi">
urn:oid:1.3.6.1.4.1.782.1
</property>
</dataset>
<dataset id="i2">
<property name="dataseturi">
urn:oid:1.3.6.1.4.1.782.2
</property>
</dataset>
</service>
<resourcedescriptor>
<commonname>bmw</commonname>
<id>foo.com:234364</id>
<resourceuri>http://www.bmw.de/</resourceuri>
<serviceref ref="i0" /><datasetref ref="i1" />
<description>BMW Motorcycles, International</description>
<property name="language" type="iso646">de-DE</property>
</resourcedescriptor>
<referral>
<serviceref ref="i0" /><datasetref ref="i2" />
</referral>
</results>
<results>
<service id="i0">
<serviceuri>http://cnrp.bar.com/</serviceuri>
<dataset id="i1">
<property name="dataseturi">
urn:oid:1.3.6.1.4.1.782.1
</property>
</dataset>
<dataset id="i2">
<property name="dataseturi">
urn:oid:1.3.6.1.4.1.782.2
</property>
</dataset>
</service>
<resourcedescriptor>
<commonname>bmw</commonname>
<id>foo.com:234364</id>
<resourceuri>http://www.bmw.de/</resourceuri>
<serviceref ref="i0" /><datasetref ref="i1" />
<description>BMW Motorcycles, International</description>
<property name="language" type="iso646">de-DE</property>
</resourcedescriptor>
<referral>
<serviceref ref="i0" /><datasetref ref="i2" />
</referral>
</results>
Like other CNRP objects, a referral can be further described using custom properties. Like a resourcedescriptor, a referral can have an ID attribute that is used by a status message to talk about a particular referral block.
与其他CNRP对象一样，可以使用自定义属性进一步描述引用。与resourcedescriptor类似，引用可以具有ID属性，状态消息使用该属性来谈论特定的引用块。
Referrals in CNRP can be handled in three ways:
CNRP中的转介可通过三种方式处理：
o application specific,
o 特定于应用程序，
o as hints only,
o 仅作为提示，
o rigorous loop detection.
o 严格的环路检测。
In the first two cases, the behavior of the client, when it receives a referral, is not defined in this memo. The client can chase the referral in such a way as to treat it as a hint only. In this case, datasets may or may not be handled. Loop detection can be nothing more than, "Have I talked to this hostname before?" or "Stop after the 3rd referral". These two cases are most likely to apply to
在前两种情况下，客户收到转介时的行为未在本备忘录中定义。客户可以以这样一种方式追踪推荐，即仅将其视为提示。在这种情况下，可以处理数据集，也可以不处理数据集。循环检测只能是“我以前是否与此主机名交谈过？”或“在第三次引用后停止”。这两种情况最有可能适用于
simple or constrained implementations where the clients and servers have some a priori knowledge of their capabilities. Without such knowledge there is too much ambiguity vis-a-vis services and datasets for clients to do reliable loop detection.
简单或受限的实现，其中客户端和服务器对其功能有一些先验知识。如果没有这些知识，客户机对服务和数据集的模糊性太大，无法进行可靠的循环检测。
The last case is where the client expects to talk to multiple servers that may know nothing about each other. This case expresses the basic semantics of what a server should tell a client if it understands datasets or referrals. Since a referral specifies the exact dataset to which it is referring, a node in the list of visited nodes is made up of a serviceuri and a dataseturi. Both of these values need to be considered during loop detection. In the case where a service does not support datasets, the visited node is made up of the service and the 'default dataset'.
最后一种情况是，客户机希望与多个可能互不了解的服务器进行对话。这个案例表达了服务器应该告诉客户机它是否理解数据集或引用的基本语义。由于引用指定了它所引用的确切数据集，所以访问节点列表中的节点由serviceuri和dataseturi组成。在循环检测期间，需要考虑这两个值。在服务不支持数据集的情况下，访问的节点由服务和“默认数据集”组成。
The major thing to remember when doing loop detection across servers is that some servers may not understand datasets at all, while others specifically rely on them. To help determine how loop detection nodes should be marked, three specific status messages have been defined:
在跨服务器执行循环检测时，需要记住的主要一点是，一些服务器可能根本不理解数据集，而另一些服务器则具体依赖于它们。为了帮助确定应如何标记循环检测节点，定义了三条特定的状态消息：
The 3.1.3 (Datasets not supported) status message is used to denote that the server does not support datasets at all. It is sent in response to a query containing datasets. The client should consider that the server ignored the datasets and the client should consider this node to have been visited for all possible datasets (including the 'default' dataset).
The 3.1.3 (Datasets not supported) status message is used to denote that the server does not support datasets at all. It is sent in response to a query containing datasets. The client should consider that the server ignored the datasets and the client should consider this node to have been visited for all possible datasets (including the 'default' dataset).translate error, please retry
The 3.1.4 (First dataset only supported) status message is used by a server to indicate the situation where a client has included several dataseturis in its query and the server can only support one at a time. In this case, the server is explicitly stating that it used the first dataseturi only. The client should consider that only the first dataseturi specified was processed correctly. The client should consider that the remaining datasets in the query were ignored completely. They would need to be sent individually as referrals if the client really cares about those results. Only the first serviceuri/dataseturi pair should be marked as visited.
服务器使用3.1.4（仅支持第一个数据集）状态消息来指示客户机在其查询中包含多个数据集，并且服务器一次只能支持一个数据集的情况。在本例中，服务器显式声明它只使用了第一个dataseturi。客户端应该考虑只有指定的第一个数据集被正确处理。客户端应该考虑查询中的其余数据集被完全忽略。如果客户真的关心这些结果，他们需要作为推荐人单独发送。只有第一个serviceuri/dataseturi对应标记为已访问。
The 3.1.5 (This dataset not supported) status message is used to indicate that a specific dataseturi sent in a query by a client is not supported by the server. This serviceuri/dataseturi pair should be considered as visited by the client. If this message is sent in reply to a query specifying multiple datasets, the client should behave the same as if it received the 3.1.3 message from above. It should be considered bad form for a server to send this status message back in response to a query with multiple datasets because it is ambiguous.
3.1.5（此数据集不受支持）状态消息用于指示服务器不支持客户端在查询中发送的特定数据集URI。此serviceuri/dataseturi对应被视为已被客户端访问。如果此消息是针对指定多个数据集的查询发送的，则客户端的行为应与从上面收到的3.1.3消息相同。服务器将此状态消息发送回以响应具有多个数据集的查询应被视为不正确的形式，因为它是不明确的。
While there is no exact algorithm for loop detection that clients are encouraged to support, these status messages can be used by the server to be clear about what Services and Datasets it considers to have been queried. It is up to the client to decide what to do with these messages and how closely it attempts to do loop detection.
虽然没有鼓励客户端支持的循环检测的精确算法，但服务器可以使用这些状态消息来明确它认为查询了哪些服务和数据集。由客户机决定如何处理这些消息以及它尝试执行循环检测的距离。
A subclass of Query, the ServiceQuery object supports the dynamic discovery of a specific CNRP service's characteristics. Note that CNRP compliance does not require that a service fully implements discoverability. In particular, returning the Service object with its serviceuri constitutes a minimal yet sufficient compliant implementation. Nevertheless, we expect that advanced CNRP services will choose to return a full description of their supported interfaces.
作为查询的一个子类，ServiceQuery对象支持动态发现特定CNRP服务的特征。请注意，CNRP合规性并不要求服务完全实现可发现性。特别是，返回带有serviceuri的服务对象构成了一个最小但足够兼容的实现。然而，我们希望高级CNRP服务将选择返回其支持接口的完整描述。
The complete response to a servicequery returns the Service object described in section 5.3.2 with the following schema information:
对servicequery的完整响应返回第5.3.2节中描述的服务对象，其中包含以下模式信息：
1. The base and custom properties used by the CNRP service (Property schema),
1. CNRP服务使用的基本属性和自定义属性（属性架构），
2. The properties used to describe the Service object (Service schema),
2. 用于描述服务对象（服务架构）的属性，
3. The properties that belong to the query interface (Query schema),
3. 属于查询接口（查询架构）的属性，
4. The properties that belong to a resource within the results (Resource schema).
4. 结果（资源架构）中属于资源的属性。
These leads to the following new object definitions:
这些将导致以下新的对象定义：
o propertyschema -- A property schema describes all the custom properties that are part of the service.
o propertyschema——属性模式描述作为服务一部分的所有自定义属性。
o propertydeclaration -- A property declaration describes a base or custom property used by the CNRP service. A property declaration has a name and a type (the name and the type of the property that it refers to). Note that as part of the property schema, one MUST declare both existing and newly defined properties.
o propertydeclaration——属性声明描述CNRP服务使用的基本或自定义属性。属性声明具有名称和类型（它所引用的属性的名称和类型）。注意，作为属性模式的一部分，必须声明现有和新定义的属性。
o propertyreference -- A property reference is a reference to a property declaration so that a given schema (a service, query or resource schema) can declare the property within its interface. Note that a property reference specify whether the use of the property is required or optional only.
o propertyreference——属性引用是对属性声明的引用，以便给定模式（服务、查询或资源模式）可以在其接口内声明属性。请注意，属性引用指定属性的使用是必需的还是可选的。
o serviceschema -- The service schema defines the properties used to describe the service.
o serviceschema——服务模式定义了用于描述服务的属性。
o queryschema -- A query schema describes the structure of a query handled by the CNRP service. The properties referred within the query schema are part of the query interface of the resolution service.
o queryschema——查询模式描述由CNRP服务处理的查询的结构。查询架构中引用的属性是解析服务的查询接口的一部分。
o resourcedescriptorschema -- A ResourceDescriptor schema describes the resource returned as a result by the CNRP service.
o resourcedescriptorschema——ResourceDescriptor模式描述CNRP服务返回的资源。
For example, a CNRP query to discover a service's capabilities will be in the form:
例如，用于发现服务功能的CNRP查询将采用以下形式：
<cnrp> <servicequery/> </cnrp>
<cnrp> <servicequery/> </cnrp>
And for a CNRP service for cocktail recipes in French, the corresponding response would be:
对于法国鸡尾酒配方的CNRP服务，相应的响应是：
<service>
<serviceuri>http://cnrp.recipe.com</serviceuri>
<propertyschema>
<propertydeclaration id="i1">
<propertyname>language</propertyname>
<propertytype>rfc1766</propertytype>
</propertydeclaration>
<propertydeclaration id="i2">
<propertyname>cocktailrecipe</propertyname>
<propertytype>freeform</propertytype>
</propertydeclaration>
</propertyschema>
<queryschema>
<propertyreference required="yes" ref="i1"/>
</queryschema>
<resourcedescriptorschema>
<propertyreference required="yes" ref="i1"/>
<propertyreference required="yes" ref="i2"/>
</resourcedescriptorschema>
</service>
<service>
<serviceuri>http://cnrp.recipe.com</serviceuri>
<propertyschema>
<propertydeclaration id="i1">
<propertyname>language</propertyname>
<propertytype>rfc1766</propertytype>
</propertydeclaration>
<propertydeclaration id="i2">
<propertyname>cocktailrecipe</propertyname>
<propertytype>freeform</propertytype>
</propertydeclaration>
</propertyschema>
<queryschema>
<propertyreference required="yes" ref="i1"/>
</queryschema>
<resourcedescriptorschema>
<propertyreference required="yes" ref="i1"/>
<propertyreference required="yes" ref="i2"/>
</resourcedescriptorschema>
</service>
This response stipulates that the service accepts the property language as part of the query interface and returns resourcedescriptors that contain both the language and cocktailRecipe properties.
此响应规定服务接受属性语言作为查询接口的一部分，并返回包含该语言和cocktailRecipe属性的ResourceDescriptor。
<!-- The document tag -->
<!ELEMENT cnrp (query|results|servicequery)>
<!-- The document tag -->
<!ELEMENT cnrp (query|results|servicequery)>
<!-- Used to request a Service object -->
<!ELEMENT servicequery EMPTY>
<!-- Used to request a Service object -->
<!ELEMENT servicequery EMPTY>
<!-- A query can either request a schema, a specific record by -->
<!-- id, or a common-name with a set of properties (or -->
<!-- assertions) about the entity doing the query. -->
<!ELEMENT query (id|(commonname,property*))>
<!ELEMENT id (#PCDATA)>
<!-- A query can either request a schema, a specific record by -->
<!-- id, or a common-name with a set of properties (or -->
<!-- assertions) about the entity doing the query. -->
<!ELEMENT query (id|(commonname,property*))>
<!ELEMENT id (#PCDATA)>
<!ELEMENT commonname (#PCDATA)>
<!-- NOTE: CNRP defines several well known properties -->
<!-- and types. See Appendix A for details. -->
<!ELEMENT property (#PCDATA)>
<!-- The name of the property -->
<!ATTLIST property name CDATA #REQUIRED>
<!-- The type of the property -->
<!ATTLIST property type CDATA "freeform">
<!ELEMENT commonname (#PCDATA)>
<!-- NOTE: CNRP defines several well known properties -->
<!-- and types. See Appendix A for details. -->
<!ELEMENT property (#PCDATA)>
<!-- The name of the property -->
<!ATTLIST property name CDATA #REQUIRED>
<!-- The type of the property -->
<!ATTLIST property type CDATA "freeform">
<!ELEMENT results (status? | ( service+, ( status | resourcedescriptor | referral )* )* )>
<!元素结果（状态？|（服务+，（状态|资源描述符|参考）**）>
<!ELEMENT resourcedescriptor (commonname,id,resourceuri,
serviceref, datasetref?,
description,
property*)>
<!ATTLIST resourcedescriptor id ID #IMPLIED>
<!ELEMENT resourcedescriptor (commonname,id,resourceuri,
serviceref, datasetref?,
description,
property*)>
<!ATTLIST resourcedescriptor id ID #IMPLIED>
<!-- The entire point of all this... -->
<!ELEMENT resourceuri (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!-- The entire point of all this... -->
<!ELEMENT resourceuri (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT referral (serviceref, datasetref?)>
<!ATTLIST referral id ID #IMPLIED>
<!ELEMENT referral (serviceref, datasetref?)>
<!ATTLIST referral id ID #IMPLIED>
<!ELEMENT status (#PCDATA)>
<!ATTLIST status code CDATA #REQUIRED>
<!ATTLIST status ref IDREF #IMPLIED>
<!ELEMENT status (#PCDATA)>
<!ATTLIST status code CDATA #REQUIRED>
<!ATTLIST status ref IDREF #IMPLIED>
<!-- serviceRef is used to point to one of a set of provided -->
<!-- service objects. This is so that a resource can point to -->
<!-- serviceRef is used to point to one of a set of provided -->
<!-- service objects. This is so that a resource can point to -->
<!-- which service it came from. We could include the entire -->
<!-- service object but then we would be repeating large -->
<!-- amounts of information. -->
<!-- which service it came from. We could include the entire -->
<!-- service object but then we would be repeating large -->
<!-- amounts of information. -->
<!ELEMENT serviceref EMPTY>
<!ATTLIST serviceref ref IDREF #IMPLIED>
<!ELEMENT serviceref EMPTY>
<!ATTLIST serviceref ref IDREF #IMPLIED>
<!ELEMENT service (serviceuri, dataset*,
servers?,
description?,
property*,propertyschema?,queryschema?,resourcedescriptorschema?,
serviceschema?)>
<!-- The time to live of the schema in seconds since it was -->
<!-- retrieved -->
<!ATTLIST service ttl CDATA "0">
<!ATTLIST service id ID #IMPLIED>
<!ELEMENT serviceuri (#PCDATA)>
<!ELEMENT servers (server+)>
<!ELEMENT server (serveruri, property*)>
<!ELEMENT serveruri (#PCDATA)>
<!ELEMENT service (serviceuri, dataset*,
servers?,
description?,
property*,propertyschema?,queryschema?,resourcedescriptorschema?,
serviceschema?)>
<!-- The time to live of the schema in seconds since it was -->
<!-- retrieved -->
<!ATTLIST service ttl CDATA "0">
<!ATTLIST service id ID #IMPLIED>
<!ELEMENT serviceuri (#PCDATA)>
<!ELEMENT servers (server+)>
<!ELEMENT server (serveruri, property*)>
<!ELEMENT serveruri (#PCDATA)>
<!ELEMENT dataset (property*)>
<!ATTLIST dataset id ID #IMPLIED>
<!ELEMENT dataset (property*)>
<!ATTLIST dataset id ID #IMPLIED>
<!ELEMENT datasetref EMPTY>
<!ATTLIST datasetref ref IDREF #IMPLIED>
<!ELEMENT datasetref EMPTY>
<!ATTLIST datasetref ref IDREF #IMPLIED>
<!ELEMENT propertyschema (propertydeclaration*)>
<!ELEMENT propertydeclaration (propertyname, propertytype*)>
<!ATTLIST propertydeclaration id ID #IMPLIED>
<!ELEMENT propertyschema (propertydeclaration*)>
<!ELEMENT propertydeclaration (propertyname, propertytype*)>
<!ATTLIST propertydeclaration id ID #IMPLIED>
<!ELEMENT propertyname (#PCDATA)>
<!ELEMENT propertytype (#PCDATA)>
<!-- This specifies if the type is meant to be the default -->
<!-- type. This is usually reserved for "freeform". -->
<!ATTLIST propertytype default (no|yes) "no">
<!ELEMENT propertyname (#PCDATA)>
<!ELEMENT propertytype (#PCDATA)>
<!-- This specifies if the type is meant to be the default -->
<!-- type. This is usually reserved for "freeform". -->
<!ATTLIST propertytype default (no|yes) "no">
<!-- The properties you can use in a query -->
<!ELEMENT queryschema (propertyreference*)>
<!-- The properties you can use in a query -->
<!ELEMENT queryschema (propertyreference*)>
<!-- The properties you can expect to see in an Resource -->
<!ELEMENT resourcedescriptorschema (propertyreference*)>
<!-- The properties you can expect to see in an Resource -->
<!ELEMENT resourcedescriptorschema (propertyreference*)>
<!-- The properties you can expect to find in a Service -->
<!-- definition -->
<!ELEMENT serviceschema (propertyreference*)>
<!-- The properties you can expect to find in a Service -->
<!-- definition -->
<!ELEMENT serviceschema (propertyreference*)>
<!ELEMENT propertyreference EMPTY>
<!ELEMENT propertyreference EMPTY>
<!-- This specifies if a property is required as part of -->
<!-- the query. -->
<!ATTLIST propertyreference ref IDREF #REQUIRED>
<!ATTLIST propertyreference required (no|yes) "no">
<!-- This specifies if a property is required as part of -->
<!-- the query. -->
<!ATTLIST propertyreference ref IDREF #REQUIRED>
<!ATTLIST propertyreference required (no|yes) "no">
This is what the client sends when it is requesting a servers schema.
这是客户端在请求服务器模式时发送的内容。
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<servicequery />
</cnrp>
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<servicequery />
</cnrp>
This is the result. Notice how the Service tag is used to allow the service to describe itself in its own terms.
这就是结果。请注意如何使用服务标签来允许服务用自己的术语描述自己。
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service ttl="43200">
<serviceuri>urn:foo:bar</serviceuri>
<servers>
<server>
<serveruri>http://host1.acmecorp.com:4321/foo?</serveruri>
</server>
<server>
<serveruri>smtp://host2.acmecorp.com:4321/foo?</serveruri>
</server>
</servers>
<description>This is the Acme CNRP Service</description>
<!-- This property means that Acme specializes in
tradename services -->
<property name="category" type="naics">544554</property>
<property name="BannerAdServer" type="uri">
http://adserver.acmecorp.com/
</property>
<propertyschema>
<propertydeclaration id="i1">
<propertyname>workgroupID</propertyname>
<propertytype default="yes">freeform</propertytype>
<propertytype default="no">domainname</propertytype>
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service ttl="43200">
<serviceuri>urn:foo:bar</serviceuri>
<servers>
<server>
<serveruri>http://host1.acmecorp.com:4321/foo?</serveruri>
</server>
<server>
<serveruri>smtp://host2.acmecorp.com:4321/foo?</serveruri>
</server>
</servers>
<description>This is the Acme CNRP Service</description>
<!-- This property means that Acme specializes in
tradename services -->
<property name="category" type="naics">544554</property>
<property name="BannerAdServer" type="uri">
http://adserver.acmecorp.com/
</property>
<propertyschema>
<propertydeclaration id="i1">
<propertyname>workgroupID</propertyname>
<propertytype default="yes">freeform</propertytype>
<propertytype default="no">domainname</propertytype>
</propertydeclaration>
<propertydeclaration id="i2">
<propertyname>BannerAdServer</propertyname>
<propertytype default="yes">URI</propertytype>
</propertydeclaration>
</propertyschema>
<queryschema>
<propertyreference ref="i1" required="yes" />
</queryschema>
<resourcedescriptorschema>
<propertyreference ref="i1" required="yes" />
</resourcedescriptorschema>
<serviceschema>
<propertyreference ref="i2" required="yes" />
</serviceschema>
</service>
</results>
</cnrp>
</propertydeclaration>
<propertydeclaration id="i2">
<propertyname>BannerAdServer</propertyname>
<propertytype default="yes">URI</propertytype>
</propertydeclaration>
</propertyschema>
<queryschema>
<propertyreference ref="i1" required="yes" />
</queryschema>
<resourcedescriptorschema>
<propertyreference ref="i1" required="yes" />
</resourcedescriptorschema>
<serviceschema>
<propertyreference ref="i2" required="yes" />
</serviceschema>
</service>
</results>
</cnrp>
This is the query that is sent from the client to the server:
这是从客户端发送到服务器的查询：
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<query>
<commonname>Fido</commonname>
<property name="geography" type="iso3166-2">
CA-QC</property>
<property name="geography" type="iso3166-1">CA</property>
<property name="language" type="rfc1766">fr-CA</property>
</query>
</cnrp>
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<query>
<commonname>Fido</commonname>
<property name="geography" type="iso3166-2">
CA-QC</property>
<property name="geography" type="iso3166-1">CA</property>
<property name="language" type="rfc1766">fr-CA</property>
</query>
</cnrp>
This is the result set. It is sent back in response to the query. This result set includes a referral and a non-fatal error.
这是结果集。它被发送回以响应查询。此结果集包括一个引用和一个非致命错误。
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service id="i0">
<serviceuri>http://acmecorp.com</serviceuri>
</service>
<service id="i1">
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service id="i0">
<serviceuri>http://acmecorp.com</serviceuri>
</service>
<service id="i1">
<serviceuri>http://serverfarm.acmecorp.com</serviceuri>
</service>
<service id="i2">
<serviceuri>http://servers.acmecorp.co.uk</serviceuri>
</service>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://www.fidonet.ca</resourceuri>
<serviceref ref="i0" />
<description>This is ye olde Canadian Fidonet</description>
</resourcedescriptor>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://host:port/bla</resourceuri>
<serviceref ref="i1" />
<description>An old Fidonet node</description>
</resourcedescriptor>
<referral><serviceref ref="i2" /></referral>
<status code="3.1.1">
The language property 'fr-CA' was ignored
</status>
</results>
</cnrp>
<serviceuri>http://serverfarm.acmecorp.com</serviceuri>
</service>
<service id="i2">
<serviceuri>http://servers.acmecorp.co.uk</serviceuri>
</service>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://www.fidonet.ca</resourceuri>
<serviceref ref="i0" />
<description>This is ye olde Canadian Fidonet</description>
</resourcedescriptor>
<resourcedescriptor>
<commonname>Fidonet</commonname>
<id>1333459455</id>
<resourceuri>http://host:port/bla</resourceuri>
<serviceref ref="i1" />
<description>An old Fidonet node</description>
</resourcedescriptor>
<referral><serviceref ref="i2" /></referral>
<status code="3.1.1">
The language property 'fr-CA' was ignored
</status>
</results>
</cnrp>
Two CNRP transport protocols are specified. HTTP is used due to its popularity and ease of integration with other web applications. SMTP is also used as a way to illustrate a protocol that has a much different range of latency than most protocols.
指定了两个CNRP传输协议。HTTP之所以被使用，是因为它很受欢迎，并且易于与其他web应用程序集成。SMTP还被用作说明协议的一种方式，该协议的延迟范围与大多数协议大不相同。
In the cases where transports use MIME Media Types (HTTP and SMTP being examples of such), the CNRP payload MUST use the 'application/cnrp+xml' media type. See Section 8 for the registration template for this media type. One important note about this media type is that, since CNRP always uses UTF-8, there is no charset attribute.
在传输使用MIME媒体类型的情况下（HTTP和SMTP就是这样的例子），CNRP负载必须使用“应用程序/CNRP+xml”媒体类型。有关此媒体类型的注册模板，请参见第8节。关于此媒体类型的一个重要注意事项是，由于CNRP始终使用UTF-8，因此没有字符集属性。
The HTTP transport is fairly simple. The client connects to an HTTP based CNRP server and issues a request using the POST method to the "/" path with the Content-type and Accept header set to "application/cnrp+xml". The content of the POST body is the CNRP XML document that is being sent. All HTTP 1.1 features are allowed during the request.
HTTP传输相当简单。客户端连接到基于HTTP的CNRP服务器，并使用POST方法向“/”路径发出请求，内容类型和接受头设置为“application/CNRP+xml”。帖子正文的内容是正在发送的CNRP XML文档。请求期间允许使用所有HTTP 1.1功能。
The results are sent back to the client with a Content-Type of "application/cnrp+xml". The body of the result is the CNRP XML document being sent to the client.
结果以“application/cnrp+xml”的内容类型发送回客户端。结果的主体是发送给客户机的CNRP XML文档。
The SMTP transport is very similar to the HTTP transport. Since there is no method to specify, the CNRP XML document is simply sent to a particular SMTP endpoint with its Content-Type set to "application/cnrp+xml". The server responds by sending a response to the originator of the request with the results in the body and the Content-Type set to "application/cnrp+xml". The Service MUST specify at least one SMTP target (email address) to contact.
SMTP传输与HTTP传输非常相似。由于没有指定的方法，CNRP XML文档只会发送到特定的SMTP端点，其内容类型设置为“application/CNRP+XML”。服务器通过向请求的发起人发送一个响应，响应结果在正文中，内容类型设置为“application/cnrp+xml”。服务必须指定至少一个要联系的SMTP目标（电子邮件地址）。
This is the registration template for 'application/cnrp+xml' per [6].
根据[6]，这是“应用程序/cnrp+xml”的注册模板。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: cnrp+xml
MIME子类型名称：cnrp+xml
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: This media type consists of 8bit text which may necessitate the use of an appropriate content transfer encoding on some transports. Since these considerations are the same as XML in general, RFC3023's [6] discussion of XML and MIME is applicable.
编码注意事项：此媒体类型由8位文本组成，可能需要在某些传输上使用适当的内容传输编码。由于这些注意事项一般与XML相同，因此RFC3023[6]对XML和MIME的讨论是适用的。
Security considerations: none specific to this media type. See Section 9 for general CNRP considerations.
安全注意事项：没有特定于此媒体类型的。关于CNRP的一般注意事项，请参见第9节。
Interoperability considerations: n/a
互操作性注意事项：不适用
Published specification: This media type is a proper subset of the the XML 1.0 specification [8] except for the limitations placed on tags and encodings by this document.
已发布规范：该媒体类型是XML1.0规范[8]的适当子集，但本文档对标记和编码的限制除外。
Applications which use this media type: any CNRP client/server wishing to send or receive CNRP requests or responses
使用此媒体类型的应用程序：任何希望发送或接收CNRP请求或响应的CNRP客户端/服务器
Additional Information: none
其他信息：无
Contact for further information: c.f., the "Author's Address" section of this memo
联系方式：c.f.，本备忘录“作者地址”部分
Intended usage: limited use
预期用途：有限用途
Author/Change controller: the IESG
作者/变更控制员：IESG
Three security threats exist for CNRP or applications that depend on it: Man in the Middle attacks, malicious agents posing as a service by spoofing a Service object, and denial of service attacks caused by adding a new level of indirection for resolution of a resource.
CNRP或依赖于它的应用存在三种安全威胁：中间人攻击、欺骗服务对象的恶意代理，以及通过添加新的间接级别来解决资源引起的拒绝服务攻击。
The proposed solution for man in the middle attacks is to utilize transport level authentication and encryption, where available. In the case where the transport can't provide the level of required authentication, individual entries or the entire response can be signed/encrypted using XML signature methods being developed by the XMLDSIG Working Group.
提出的中间人攻击的解决方案是利用可用的传输级认证和加密。在传输无法提供所需身份验证级别的情况下，可以使用XMLDSIG工作组开发的XML签名方法对单个条目或整个响应进行签名/加密。
In the case of where a service attempts to pose as another by spoofing the serviceuri in the Service object, the Service object should be signed. A client can then verify the Service object's veracity by verifying the signature. How the client obtains that authoritative public key is out of scope since it depends on the service discovery problem.
如果一个服务试图通过欺骗服务对象中的serviceuri来伪装成另一个服务，则应该对该服务对象进行签名。然后，客户机可以通过验证签名来验证服务对象的准确性。客户机获取权威公钥的方式超出范围，因为它取决于服务发现问题。
While this document cannot propose a solution for Denial Of Service (DOS) attacks, it can illustrate that, like many other cases, any time a new level of indirection is created, an opportunity for a DOS attack is created. Service providers are encouraged to be aware of this and to act accordingly to mitigate the effects of a DOS attack.
虽然本文档无法提出拒绝服务（DOS）攻击的解决方案，但它可以说明，与许多其他情况一样，每当创建新级别的间接寻址时，都会创建DOS攻击的机会。我们鼓励服务提供商意识到这一点，并相应采取行动，以减轻DOS攻击的影响。
The major consideration for the IANA is that the IANA will be registering well known properties, property types and status messages. It will not register values. Since this document does not discuss CNRP service discovery, the IANA will not be registering the existence of servers or Server objects.
IANA的主要考虑因素是，IANA将注册众所周知的属性、属性类型和状态消息。它不会注册值。由于本文档未讨论CNRP服务发现，IANA不会注册服务器或服务器对象的存在。
There are three types of entities the IANA can register: properties, property types, and status messages. If a property or type is not registered with the IANA, then they must start with "x-". Status messages can be created for local consumption and not registered. There is no requirement that new status messages are mandatory to implement unless this document is updated. Status message registrations are more for informational purposes.
IANA可以注册三种类型的实体：属性、属性类型和状态消息。如果属性或类型未向IANA注册，则它们必须以“x-”开头。可以为本地消费创建状态消息，而不进行注册。除非更新本文档，否则不要求强制执行新的状态消息。状态消息注册更多用于提供信息。
The required information for the registration of a new property is the property's name, its default type, and a general description. A new type requires the type's name, what properties it is valid for, and a description. A new status message requires the X.Y.ZZZ code and a brief description of the state being communicated.
注册新财产所需的信息包括财产名称、默认类型和一般说明。新类型需要类型的名称、有效属性以及描述。新的状态消息需要X.Y.ZZZ代码和正在通信状态的简要说明。
All properties, types and status messages are registered on a First Come First Served basis with no review by the IANA or any group of experts. The consensus opinion of the CNRP Working Group is that review of property registrations should occur once there is operational experience with the protocol and an actual need for the review. If, at some future date, this policy needs to change, this document will be updated.
所有属性、类型和状态信息均以先到先得的方式进行注册，IANA或任何专家组均不进行审查。CNRP工作组的一致意见是，一旦有议定书的运作经验和审查的实际需要，就应当对财产登记进行审查。如果在未来某个日期，此政策需要更改，则将更新此文档。
The property and type registration templates found in Appendix A should be registered by the IANA at publication time of this document.
附录A中的财产和类型注册模板应由IANA在本文件发布时进行注册。
The IANA is also directed to register the Media Type specified in Section 8.
IANA还应注册第8节规定的媒体类型。
References
工具书类
[1] United States, "North American Industry Classification System", January 1997, <http://www.census.gov/epcd/www/naics.html>.
[1] 美国，“北美行业分类体系”，1997年1月<http://www.census.gov/epcd/www/naics.html>.
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[2] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[3] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[4] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[4] Alvestrand，H.，“语言识别标签”，RFC1766，1995年3月。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Murata，M.，St.Laurent，S.和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", February 1998.
[8] Bray，T.，Paoli，J.和C.Sperberg McQueen，“可扩展标记语言（XML）1.0”，1998年2月。
[9] Mealling, M., "The 'go' URI Scheme for the Common Name Resolution Protocol", RFC 3368, August 2002.
[9] Mealling，M.“通用名称解析协议的‘go’URI方案”，RFC 3368，2002年8月。
[10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[10] Vaudreuil，G.“增强邮件系统状态代码”，RFC 1893，1996年1月。
[11] "Country and Region Codes", ISO 3166, January 1996.
[11] “国家和地区代码”，ISO 3166，1996年1月。
Property Name: geography Default Type: iso3166-1 Description: A geographic location
属性名称：地理默认类型：iso3166-1说明：地理位置
Property Name: language Default Type: rfc1766 Description: A language specification
属性名称：语言默认类型：rfc1766说明：语言规范
Property Name: category Default Type: freeform Description: A node in some system of semantic relationships that is considered relevant to the common-name.
属性名称：类别默认类型：自由形式描述：某些语义关系系统中被认为与公共名称相关的节点。
Property Name: range Default Type: range Description: A range given in the format "x,y" where x is the starting point and y is the length. This property is used by the client to tell the server that is is requesting a subrange of the results.
特性名称：范围默认类型：范围说明：以“x，y”格式给定的范围，其中x是起点，y是长度。客户机使用此属性通知正在请求结果子范围的服务器。
Property Name: dataseturi Default Type: uri Description: A URI used to disambiguate between two Datasets offered by the same Service.
属性名称：dataseturi默认类型：uri描述：用于消除同一服务提供的两个数据集之间歧义的uri。
Type: freeform Property: category Description: The value is to be interpreted by the server the best way it knows how. This value has no defined structure.
Type:freeform属性：category Description：服务器将以其知道的最佳方式解释该值。此值没有定义的结构。
Type: freeform Property: geography Description: The value is to be interpreted by the server the best way it knows how. This value has no defined structure.
类型：freeform属性：地理描述：服务器将以其知道的最佳方式解释该值。此值没有定义的结构。
Type: freeform Property: language Description: The value is to be interpreted by the server the best way it knows how. This value has no defined structure.
Type:freeform属性：语言描述：服务器将以其知道的最佳方式解释该值。此值没有定义的结构。
Type: iso3166-2 Property: geography Description: The combination of country and sub-region codes found in ISO 3166-2 [11].
类型：iso3166-2属性：地理描述：ISO 3166-2[11]中的国家和地区代码组合。
Type: iso3166-1 Property: Geography Description: Country Codes found in ISO 3166-1 [11].
类型：iso3166-1属性：地理描述：国家代码见ISO 3166-1[11]。
Type: postalcode Property: Geography Description: A postal code that is valid for some region. A good example is the Zip code system used in the US.
类型：postalcode属性：地理描述：对某些地区有效的邮政编码。美国使用的邮政编码系统就是一个很好的例子。
Type: lat-long Property: Geography Description:
类型：横向长度特性：地理描述：
Values for latitude and longitude shall be expressed as decimal fractions of degrees. Whole degrees of latitude shall be represented by a two-digit decimal number ranging from 0 through 90. Whole degrees of longitude shall be represented by a decimal number ranging from 0 through 180. When a decimal fraction of a degree is specified, it shall be separated from the whole number of degrees by a decimal point. Decimal fractions of a degree may be expressed to the precision desired.
纬度和经度值应以度的小数表示。整个纬度应由0到90之间的两位十进制数字表示。整个经度应由0到180之间的十进制数字表示。如果规定了度数的小数点，则应以小数点将其与度数的整数分开。度的小数可以表示为所需的精度。
Latitudes north of the equator shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the designating degrees. Latitudes south of the Equator shall be designated by a minus sign (-) preceding the two digits designating degrees. A point on the Equator shall be assigned to the Northern Hemisphere.
赤道以北的纬度应在指定度数之前用加号（+）或减号（-）表示。赤道以南的纬度应在表示度数的两位数字之前用减号（-）表示。赤道上的一点应指定给北半球。
Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the Longitudes west of the meridian shall be designated by minus sign (-) preceding the digits designating degrees. A point on the prime meridian shall be assigned to the
本初子午线以东的经度用加号（+）表示，子午线以西的经度用表示度数的数字前面的减号（-）表示。本初子午线上的一点应指定给
Eastern Hemisphere. A point on the 180th meridian shall be assigned to the Western Hemisphere. One exception to this last convention is permitted. For the special condition of describing a band of latitude around the earth, the East Bounding Coordinate data element shall be assigned the value +180 (180) degrees.
东半球。第180子午线上的一个点应指定给西半球。最后一项公约允许有一个例外。对于描述地球周围纬度带的特殊条件，应为东边界坐标数据元素指定+180（180）度的值。
Any spatial address with a latitude of +90 (90) or -90 degrees will specify the position at the North or South Pole, respectively. The component for longitude may have any legal value.
任何纬度为+90（90）或-90度的空间地址将分别指定北极或南极的位置。经度组件可能具有任何合法值。
With the exception of the special condition described above, this form is specified in Department of Commerce, 1986, Representation of geographic point locations for information interchange (Federal Information Processing Standard 70-1): Washington, Department of Commerce, National Institute of Standards and Technology.
除上述特殊条件外，本表在商务部1986年《信息交换地理点位置表示》（联邦信息处理标准70-1）：华盛顿商务部国家标准与技术研究所中规定。
DEGREES = *PLUSMINUS DIGITS '.' DIGITS
PLUSMINUS = + | -
DIGITS = DIGIT *DIGIT
DIGIT = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
DEGREES = *PLUSMINUS DIGITS '.' DIGITS
PLUSMINUS = + | -
DIGITS = DIGIT *DIGIT
DIGIT = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Type: rfc1766 Property: Language Description: language codes as defined by RFC 1766 [4]
类型：rfc1766属性：语言描述：rfc1766定义的语言代码[4]
Type: naics Property: Category Description: North American Industry Code System [1]
类型：naics属性：类别说明：北美行业代码系统[1]
Type: uri Property: dataseturi Description: A URI adhering to the 'absoluteURI' production of the Collected ABNF found in [3]
Type:uri属性：dataseturi描述：一个uri，它依附于[3]中收集的ABNF的“绝对uri”产品
1.0.0 -- Undefined Information This code is used for any non-categorizable and informative message. If, for example, the server wanted to tell the client that the systems administrator's cat has blue hair, then this code would be the appropriate place for this information.
1.0.0 --未定义信息此代码用于任何不可分类和信息性消息。例如，如果服务器想告诉客户机系统管理员的cat有蓝头发，那么此代码将是该信息的适当位置。
1.1.0 -- Query related information This code is used for any informative information concerning the query that client sent. For example, "The query you sent was rather interesting!".
1.1.0 --查询相关信息此代码用于有关客户端发送的查询的任何信息性信息。例如，“您发送的查询非常有趣！”。
1.2.0 -- An informative message pertaining to the Service This message concerns the Service in the general sense.
1.2.0 --与服务相关的信息性消息该消息涉及一般意义上的服务。
2.0.0 -- Something undefined succeeded There was success but the situation that this message concerns is undefined.
2.0.0 --未定义的内容成功了成功了，但此消息所涉及的情况尚未定义。
2.1.0 -- Query succeeded The query succeeded. This message MUST be returned when there were no results that matched the query. I.e., the query was successfully handled and the correct set of results contained no resources or referrals. The lack of results is not an error but a successful statement about the common-name.
2.1.0 --查询成功查询成功。当没有与查询匹配的结果时，必须返回此消息。即，查询已成功处理，并且正确的结果集不包含任何资源或引用。缺少结果不是一个错误，而是一个关于通用名称的成功声明。
Note: The apparent lack of 2.X.X level codes is caused by success usually being indicated not by a status message but by the server returning only the objects that the client requested.
注意：明显缺少2.X.X级别代码是由于成功通常不是由状态消息指示的，而是由服务器仅返回客户端请求的对象指示的。
3.0.0 -- Something undefined was only partially successful Some request by the client was only partially successful. The exact situation or cause of that partial failure is not defined.
3.0.0 --某些未定义的内容仅部分成功客户端的某些请求仅部分成功。部分故障的确切情况或原因尚未确定。
3.1.0 -- The query was only partially successful.
3.1.0 --查询仅部分成功。
3.1.1 -- The query contained invalid or unsupported properties The query contained invalid or unsupported property names, types or values. The invalid properties were ignored and the query processed.
3.1.1 --查询包含无效或不受支持的属性查询包含无效或不受支持的属性名称、类型或值。已忽略无效属性并处理查询。
3.1.2 -- The XML was well formed but invalid The XML sent by the client was well formed but invalid. The server was smart enough to figure out what the client was talking about and return some results.
3.1.2 --XML格式正确但无效客户端发送的XML格式正确但无效。服务器足够聪明，能够理解客户机在谈论什么，并返回一些结果。
3.1.3 Server does not support datasets This status should be generated by servers that do not handle datasets. A server can send this status message at any time, but it especially useful for when a server receives a query from a client that contains a dataseturi. In this case and if the client is doing rigorous loop detection, the client should consider this entire service to have been visited.
3.1.3 服务器不支持数据集此状态应由不处理数据集的服务器生成。服务器可以随时发送此状态消息，但当服务器从包含dataseturi的客户端接收到查询时，它特别有用。在这种情况下，如果客户端正在进行严格的循环检测，客户端应该认为已经访问了整个服务。
3.1.4 The first dataset in the list of datasets you gave in the query was the only one used. This status message is used by a server to indicate the situation where a client has included several dataseturis in its query and the server can only support one at a time. In this case the server is explicitly stating that it used the first dataseturi only. The client should consider that only the first dataseturi specified was processed correctly. The client should consider that the remaining datasets in the query were ignored completely.
3.1.4 您在查询中提供的数据集列表中的第一个数据集是唯一使用的数据集。服务器使用此状态消息来指示客户机在其查询中包含多个DataSetUri，并且服务器一次只能支持一个DataSetUri的情况。在这种情况下，服务器显式地声明它只使用了第一个dataseturi。客户端应该考虑只有指定的第一个数据集被正确处理。客户端应该考虑查询中的其余数据集被完全忽略。
They would need to be sent individually as referrals if the client really cares about those results. Only the first serviceuri/dataseturi pair should be marked as visited if loop detection is being handled.
如果客户真的关心这些结果，他们需要作为推荐人单独发送。如果正在处理循环检测，则只应将第一个serviceuri/dataseturi对标记为已访问。
3.1.5 This dataset not supported. This message is used to indicate that a specific dataseturi sent in a query by a client is not supported by the server. This serviceuri/dataseturi pair should be considered as visited by the client. If this message is sent in reply to a query specifying multiple datasets, the client should behave the same as if it received the 3.1.3 message from above. It should be considered bad form for a server to send this status message back in response to a query with multiple datasets because it is ambiguous.
3.1.5 不支持此数据集。此消息用于指示服务器不支持客户端在查询中发送的特定dataseturi。此serviceuri/dataseturi对应被视为已被客户端访问。如果此消息是针对指定多个数据集的查询发送的，则客户端的行为应与从上面收到的3.1.3消息相同。服务器将此状态消息发送回以响应具有多个数据集的查询应被视为不正确的形式，因为它是不明确的。
3.2.0 -- The server caused a partially successful event Due to some internal server error, the results returned were incomplete.
3.2.0 --由于某些内部服务器错误，服务器导致事件部分成功，返回的结果不完整。
3.2.1 -- Some referral server was unavailable This status message is used to denote that one or more of the referral services that are normally queried was unavailable. Results were generated, but they may not be representative of a complete answer.
3.2.1 --某些转介服务器不可用此状态消息用于表示正常查询的一个或多个转介服务不可用。结果已生成，但它们可能无法代表完整的答案。
4.0.0 -- Something undefined caused a persistent transient failure.
4.0.0 --未定义的内容导致了持续的瞬时故障。
4.1.0 -- There was an error in the query that made it unable to be interpreted.
4.1.0 --查询中出现错误，无法对其进行解释。
4.2.0 -- The query was to complex The query as specified was too complex for this Service to handle.
4.2.0 --查询太复杂指定的查询太复杂，此服务无法处理。
4.2.1 -- The Service was too busy Due to resource constraints, the entire service is too busy to handle requests. This means that any of the Servers cooperating in providing this Service would have also returned this same message.
4.2.1 --由于资源限制，服务太忙，整个服务太忙，无法处理请求。这意味着合作提供此服务的任何服务器也会返回相同的消息。
4.2.2 -- The Server is in maintenance This server is now in maintenance mode. Try another server from this service or try again at a later time.
4.2.2 --服务器处于维护状态此服务器现在处于维护模式。请从此服务中尝试其他服务器，或稍后再试。
4.2.3 -- The Server had an internal error There was an internal error that caused the server to fail completely.
4.2.3 --服务器有一个内部错误有一个内部错误导致服务器完全失败。
B.5 Level 5 (Permanent Failures) Codes.
B.5第5级（永久性故障）代码。
5.0.0 -- Something undefined caused a permanent failure.
5.0.0 --未定义的东西导致了永久性的失败。
5.1.0 -- The query permanently failed.
5.1.0 --查询永久失败。
5.2.0 -- The service had a permanent failure.
5.2.0 --这项服务永久性地失败了。
5.2.1 -- This Service is no longer available. This Service has decided to no longer make itself available.
5.2.1 --此服务不再可用。此服务已决定不再提供。
5.2.2 -- The Server had a permanent failure. This server has permanently failed. Try another server from this service.
5.2.2 --服务器出现永久性故障。此服务器已永久失败。尝试此服务中的其他服务器。
Authors' Addresses
作者地址
Nico Popp VeriSign, Inc. 487 East Middlefield Road Mountain View, CA 94043
Nico Popp VeriSign，Inc.加利福尼亚州东米德菲尔德路487号山景城，邮编94043
Phone: (650) 426-3291 EMail: npopp@verisign.com
电话：（650）426-3291电子邮件：npopp@verisign.com
Michael Mealling VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling VeriSign，Inc.美国弗吉尼亚州斯特林Ridgetop Circle 21345邮编20166
EMail: michael@verisignlabs.com
EMail: michael@verisignlabs.com
Marshall Moseley Netword, Inc. 702 Russell Avenue Gaithersburg, MD 20877-2606 US
美国马里兰州盖瑟斯堡拉塞尔大道702号马歇尔·莫斯利网络公司，邮编：20877-2606
Phone: (240) 631-1100 EMail: marshall@netword.com
电话：（240）631-1100电子邮件：marshall@netword.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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 assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。