Network Working Group S. Sun
Request for Comments: 3652 S. Reilly
Category: Informational L. Lannom
J. Petrone
CNRI
November 2003
Network Working Group S. Sun
Request for Comments: 3652 S. Reilly
Category: Informational L. Lannom
J. Petrone
CNRI
November 2003
Handle System Protocol (ver 2.1) Specification
句柄系统协议（2.1版）规范
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
IESG Note
IESG注释
Several groups within the IETF and IRTF have discussed the Handle System and its relationship to existing systems of identifiers. The IESG wishes to point out that these discussions have not resulted in IETF consensus on the described Handle System, nor on how it might fit into the IETF architecture for identifiers. Though there has been discussion of handles as a form of URI, specifically as a URN, these documents describe an alternate view of how namespaces and identifiers might work on the Internet and include characterizations of existing systems which may not match the IETF consensus view.
IETF和IRTF中的几个小组讨论了句柄系统及其与现有标识符系统的关系。IESG希望指出，这些讨论并没有导致IETF就所述句柄系统达成共识，也没有导致IETF如何将其纳入IETF标识符体系结构。尽管已经讨论过句柄作为URI的一种形式，特别是作为URN，但这些文档描述了名称空间和标识符在Internet上如何工作的另一种视图，并包括可能与IETF一致性视图不匹配的现有系统的特征。
Abstract
摘要
The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.
Handle系统是一种通用的全局名称服务，允许通过公共互联网进行安全的名称解析和管理。本文档描述了客户端软件用于访问句柄系统以进行句柄解析和管理的协议。该协议指定客户端软件定位任何给定句柄的负责句柄服务器的过程。它还定义了客户端和服务器之间为任何句柄操作交换的消息。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Conventions. . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Data Transmission Order. . . . . . . . . . . . . 4
2.1.2. Transport Layer. . . . . . . . . . . . . . . . . 5
2.1.3. Character Case . . . . . . . . . . . . . . . . . 6
2.1.4. Standard String Type: UTF8-String. . . . . . . . 7
2.2. Common Elements. . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Message Envelope . . . . . . . . . . . . . . . . 8
2.2.2. Message Header . . . . . . . . . . . . . . . . . 11
2.2.3. Message Body . . . . . . . . . . . . . . . . . . 17
2.2.4. Message Credential . . . . . . . . . . . . . . . 18
2.3. Message Transmission . . . . . . . . . . . . . . . . . . 20
3. Handle Protocol Operations . . . . . . . . . . . . . . . . . . 21
3.1. Client Bootstrapping . . . . . . . . . . . . . . . . . . 21
3.1.1. Global Handle Registry and its Service
Information. . . . . . . . . . . . . . . . . . . 21
3.1.2. Locating the Handle System Service Component . . 22
3.1.3. Selecting the Responsible Server . . . . . . . . 23
3.2. Query Operation. . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Query Request. . . . . . . . . . . . . . . . . . 24
3.2.2. Successful Query Response. . . . . . . . . . . . 25
3.2.3. Unsuccessful Query Response. . . . . . . . . . . 26
3.3. Error Response from Server . . . . . . . . . . . . . . . 26
3.4. Service Referral . . . . . . . . . . . . . . . . . . . . 27
3.5. Client Authentication. . . . . . . . . . . . . . . . . . 28
3.5.1. Challenge from Server to Client. . . . . . . . . 29
3.5.2. Challenge-Response from Client to Server . . . . 30
3.5.3. Challenge-Response Verification-Request. . . . . 33
3.5.4. Challenge-Response Verification-Response . . . . 33
3.6. Handle Administration. . . . . . . . . . . . . . . . . . 34
3.6.1. Add Handle Value(s). . . . . . . . . . . . . . . 34
3.6.2. Remove Handle Value(s) . . . . . . . . . . . . . 35
3.6.3. Modify Handle Value(s) . . . . . . . . . . . . . 36
3.6.4. Create Handle. . . . . . . . . . . . . . . . . . 37
3.6.5. Delete Handle. . . . . . . . . . . . . . . . . . 39
3.7. Naming Authority (NA) Administration . . . . . . . . . . 40
3.7.1. List Handle(s) under a Naming Authority. . . . . 40
3.7.2. List Sub-Naming Authorities under a Naming
Authority. . . . . . . . . . . . . . . . . . . . 41
3.8. Session and Session Management . . . . . . . . . . . . . 42
3.8.1. Session Setup Request. . . . . . . . . . . . . . 43
3.8.2. Session Setup Response . . . . . . . . . . . . . 46
3.8.3. Session Key Exchange . . . . . . . . . . . . . . 47
3.8.4. Session Termination. . . . . . . . . . . . . . . 48
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Conventions. . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Data Transmission Order. . . . . . . . . . . . . 4
2.1.2. Transport Layer. . . . . . . . . . . . . . . . . 5
2.1.3. Character Case . . . . . . . . . . . . . . . . . 6
2.1.4. Standard String Type: UTF8-String. . . . . . . . 7
2.2. Common Elements. . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Message Envelope . . . . . . . . . . . . . . . . 8
2.2.2. Message Header . . . . . . . . . . . . . . . . . 11
2.2.3. Message Body . . . . . . . . . . . . . . . . . . 17
2.2.4. Message Credential . . . . . . . . . . . . . . . 18
2.3. Message Transmission . . . . . . . . . . . . . . . . . . 20
3. Handle Protocol Operations . . . . . . . . . . . . . . . . . . 21
3.1. Client Bootstrapping . . . . . . . . . . . . . . . . . . 21
3.1.1. Global Handle Registry and its Service
Information. . . . . . . . . . . . . . . . . . . 21
3.1.2. Locating the Handle System Service Component . . 22
3.1.3. Selecting the Responsible Server . . . . . . . . 23
3.2. Query Operation. . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Query Request. . . . . . . . . . . . . . . . . . 24
3.2.2. Successful Query Response. . . . . . . . . . . . 25
3.2.3. Unsuccessful Query Response. . . . . . . . . . . 26
3.3. Error Response from Server . . . . . . . . . . . . . . . 26
3.4. Service Referral . . . . . . . . . . . . . . . . . . . . 27
3.5. Client Authentication. . . . . . . . . . . . . . . . . . 28
3.5.1. Challenge from Server to Client. . . . . . . . . 29
3.5.2. Challenge-Response from Client to Server . . . . 30
3.5.3. Challenge-Response Verification-Request. . . . . 33
3.5.4. Challenge-Response Verification-Response . . . . 33
3.6. Handle Administration. . . . . . . . . . . . . . . . . . 34
3.6.1. Add Handle Value(s). . . . . . . . . . . . . . . 34
3.6.2. Remove Handle Value(s) . . . . . . . . . . . . . 35
3.6.3. Modify Handle Value(s) . . . . . . . . . . . . . 36
3.6.4. Create Handle. . . . . . . . . . . . . . . . . . 37
3.6.5. Delete Handle. . . . . . . . . . . . . . . . . . 39
3.7. Naming Authority (NA) Administration . . . . . . . . . . 40
3.7.1. List Handle(s) under a Naming Authority. . . . . 40
3.7.2. List Sub-Naming Authorities under a Naming
Authority. . . . . . . . . . . . . . . . . . . . 41
3.8. Session and Session Management . . . . . . . . . . . . . 42
3.8.1. Session Setup Request. . . . . . . . . . . . . . 43
3.8.2. Session Setup Response . . . . . . . . . . . . . 46
3.8.3. Session Key Exchange . . . . . . . . . . . . . . 47
3.8.4. Session Termination. . . . . . . . . . . . . . . 48
4. Implementation Guidelines. . . . . . . . . . . . . . . . . . . 48
4.1. Server Implementation. . . . . . . . . . . . . . . . . . 48
4.2. Client Implementation. . . . . . . . . . . . . . . . . . 49
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. Informative References . . . . . . . . . . . . . . . . . . . . 50
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 53
4. Implementation Guidelines. . . . . . . . . . . . . . . . . . . 48
4.1. Server Implementation. . . . . . . . . . . . . . . . . . 48
4.2. Client Implementation. . . . . . . . . . . . . . . . . . 49
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. Informative References . . . . . . . . . . . . . . . . . . . . 50
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 53
The Handle System provides a general-purpose, secured global name service for the Internet. It was originally conceived and described in a paper by Robert Kahn and Robert Wilensky [18] in 1995. The Handle System defines a client server protocol in which client software submits requests via a network to handle servers. Each request describes the operation to be performed on the server. The server will process the request and return a message indicating the result of the operation. This document specifies the protocol for client software to access a handle server for handle resolution and administration. It does not include the description of the protocol used to manage handle servers. A discussion of the management protocol is out of the scope of this document and will be made available in a separate document. The document assumes that readers are familiar with the basic concepts of the Handle System as introduced in the "Handle System Overview" [1], as well as the data model and service definition given in the "Handle System Namespace and Service Definition" [2].
Handle系统为Internet提供通用、安全的全局名称服务。它最初是由Robert Kahn和Robert Wilensky在1995年的一篇论文中构思和描述的[18]。Handle系统定义了一个客户端-服务器协议，在该协议中，客户端软件通过网络提交请求以处理服务器。每个请求描述要在服务器上执行的操作。服务器将处理该请求并返回一条指示操作结果的消息。本文档指定客户端软件访问句柄服务器以进行句柄解析和管理的协议。它不包括用于管理handle服务器的协议的描述。管理协议的讨论不在本文件范围内，将在单独的文件中提供。本文档假设读者熟悉“Handle System Overview”[1]中介绍的Handle系统的基本概念，以及“Handle System Namespace and service definition”[2]中给出的数据模型和服务定义。
The Handle System consists of a set of service components as defined in [2]. From the client's point of view, the Handle System is a distributed database for handles. Different handles under the Handle System may be maintained by different handle servers at different network locations. The Handle protocol specifies the procedure for a client to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.
手柄系统由[2]中定义的一组服务组件组成。从客户机的角度来看，句柄系统是一个用于句柄的分布式数据库。句柄系统下的不同句柄可由位于不同网络位置的不同句柄服务器维护。Handle协议指定客户端查找任何给定句柄的负责句柄服务器的过程。它还定义了客户端和服务器之间为任何句柄操作交换的消息。
Some key aspects of the Handle protocol include:
Handle协议的一些关键方面包括：
o The Handle protocol supports both handle resolution and administration. The protocol follows the data and service model defined in [2].
o 句柄协议支持句柄解析和管理。该协议遵循[2]中定义的数据和服务模型。
o A client may authenticate any server response based on the server's digital signature.
o 客户端可以基于服务器的数字签名对任何服务器响应进行身份验证。
o A server may authenticate its client as handle administrator via the Handle authentication protocol. The Handle authentication protocol is a challenge-response protocol that supports both public-key and secret-key based authentication.
o 服务器可以通过handle身份验证协议将其客户端身份验证为handle管理员。Handle身份验证协议是一种质询-响应协议，支持基于公钥和基于密钥的身份验证。
o A session may be established between the client and server so that authentication information and network resources (e.g., TCP connection) may be shared among multiple operations. A session key can be established to achieve data integrity and confidentiality.
o 可以在客户端和服务器之间建立会话，以便在多个操作之间共享认证信息和网络资源（例如，TCP连接）。可以建立会话密钥以实现数据完整性和机密性。
o The protocol can be extended to support new operations. Controls can be used to extend the existing operations. The protocol is defined to allow future backward compatibility.
o 该协议可以扩展以支持新的操作。控件可用于扩展现有操作。协议的定义允许将来向后兼容。
o Distributed service architecture. Support service referral among different service components.
o 分布式服务体系结构。支持不同服务组件之间的服务转介。
o Handles and their data types are based on the ISO-10646 (Unicode 2.0) character set. UTF-8 [3] is the mandated encoding under the Handle protocol.
o 句柄及其数据类型基于ISO-10646（Unicode 2.0）字符集。UTF-8[3]是Handle协议下的强制编码。
The Handle protocol (version 2.1) specified in this document has changed significantly from its earlier versions. These changes are necessary due to changes made in the Handle System data model and the service model. Servers that implement this protocol may continue to support earlier versions of the protocol by checking the protocol version specified in the Message Envelope (see section 2.2.1).
本文档中指定的句柄协议（版本2.1）与其早期版本相比发生了重大变化。由于在Handle系统数据模型和服务模型中所做的更改，这些更改是必需的。通过检查消息信封中指定的协议版本（参见第2.2.1节），实现此协议的服务器可以继续支持协议的早期版本。
The following conventions are followed by the Handle protocol to ensure interoperability among different implementations.
Handle协议遵循以下约定，以确保不同实现之间的互操作性。
The order of transmission of data packets follows the network byte order (also called the Big-Endian [11]). That is, when a data-gram consists of a group of octets, the order of transmission of those octets follows their natural order from left to right and from top to bottom, as they are read in English. For example, in the following diagram, the octets are transmitted in the order they are numbered.
数据包的传输顺序遵循网络字节顺序（也称为Big-Endian[11]）。也就是说，当一个数据包由一组八位字节组成时，这些八位字节的传输顺序遵循其自然顺序，即从左到右，从上到下，正如它们是用英语读取的那样。例如，在下图中，八位字节按编号顺序传输。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.-------------------------------.
| 1 | 2 |
|-------------------------------|
| 3 | 4 |
|-------------------------------|
| 5 | 6 |
'-------------------------------'
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.-------------------------------.
| 1 | 2 |
|-------------------------------|
| 3 | 4 |
|-------------------------------|
| 5 | 6 |
'-------------------------------'
If an octet represents a numeric quantity, the left most bit is the most significant bit. For example, the following diagram represents the value 170 (decimal).
如果八位字节表示一个数字量，则最左边的位是最高有效位。例如，下图表示值170（十进制）。
0 1 2 3 4 5 6 7
.---------------.
|1 0 1 0 1 0 1 0|
'---------------'
0 1 2 3 4 5 6 7
.---------------.
|1 0 1 0 1 0 1 0|
'---------------'
Similarly, whenever a multi-octet field represents a numeric quantity, the left most bit is the most significant bit and the most significant octet of the whole field is transmitted first.
类似地，每当多个八位字节字段表示数字量时，最左边的位是最高有效位，并且首先传输整个字段的最高有效八位字节。
The Handle protocol is designed so that messages may be transmitted either as separate data-grams over UDP or as a continuous byte stream via a TCP connection. The recommended port number for both UDP and TCP is 2641.
Handle协议的设计使得消息可以通过UDP作为单独的数据报或通过TCP连接作为连续的字节流进行传输。UDP和TCP的建议端口号均为2641。
UDP Usage
UDP使用
Messages carried by UDP are restricted to 512 bytes (not including the IP or UDP header). Longer messages must be fragmented into UDP packets where each packet carries a proper sequence number in the Message Envelope (see Section 2.2.1).
UDP承载的消息限制为512字节（不包括IP或UDP标头）。较长的消息必须分段为UDP数据包，其中每个数据包在消息信封中都带有正确的序列号（见第2.2.1节）。
The optimum retransmission policy will vary depending on the network or server performance, but the following are recommended:
最佳重传策略将根据网络或服务器性能而有所不同，但建议采取以下措施：
o The client should try other servers or service interfaces before repeating a request to the same server address.
o 在重复对同一服务器地址的请求之前，客户端应尝试其他服务器或服务接口。
o The retransmission interval should be based on prior statistics if possible. Overly aggressive retransmission should be avoided to prevent network congestion. The recommended retransmission interval is 2-5 seconds.
o 如果可能，重传间隔应基于先前的统计数据。为了防止网络拥塞，应避免过度激进的重传。建议的重新传输间隔为2-5秒。
o When transmitting large amounts of data, TCP-friendly congestion control, such as an interface to the Congestion Manager [12], should be implemented whenever possible to avoid unfair consumption of the bandwidth against TCP-based applications. Details of the congestion control will be discussed in a separate document.
o 在传输大量数据时，应尽可能实施TCP友好的拥塞控制，如拥塞管理器的接口[12]，以避免对基于TCP的应用程序不公平地消耗带宽。拥塞控制的细节将在另一份文件中讨论。
TCP Usage
TCP使用
Messages under the Handle protocol can be mapped directly into a TCP byte-stream. However, the size of each message is limited by the range of a 4-byte unsigned integer. Longer messages may be fragmented into multiple messages before the transmission and reassembled at the receiving end.
Handle协议下的消息可以直接映射到TCP字节流。但是，每条消息的大小受4字节无符号整数的范围限制。较长的消息可能在传输之前被分割成多个消息，并在接收端重新组装。
Several connection management policies are recommended:
建议使用几种连接管理策略：
o The server should support multiple connections and should not block other activities waiting for TCP data.
o 服务器应支持多个连接，并且不应阻止等待TCP数据的其他活动。
o By default, the server should close the connection after completing the request. However, if the request asks to keep the connection open, the server should assume that the client will initiate connection closing.
o 默认情况下，服务器应在完成请求后关闭连接。但是，如果请求请求保持连接打开，服务器应假定客户端将启动连接关闭。
Handles are character strings based on the ISO-10646 character set and must be encoded in UTF-8. By default, handle characters are treated as case-sensitive under the Handle protocol. A handle service, however, may be implemented in such a way that ASCII characters are processed case-insensitively. For example, the Global Handle Registry (GHR) provides a handle service where ASCII characters are processed in a case-insensitive manner. This suggests that ASCII characters in any naming authority are case-insensitive.
句柄是基于ISO-10646字符集的字符串，必须以UTF-8编码。默认情况下，句柄字符在句柄协议下视为区分大小写。然而，句柄服务的实现方式可以使ASCII字符不区分大小写。例如，全局句柄注册表（GHR）提供了一个句柄服务，其中ASCII字符以不区分大小写的方式进行处理。这表明任何命名机构中的ASCII字符都不区分大小写。
When handles are created under a case-insensitive handle server, their original case should be preserved. To avoid any confusion, the server should avoid creating any handle whose character string matches that of an existing handle, ignoring the case difference. For example, if the handle "X/Y" was already created, the server should refuse any request to create the handle "x/y" or any of its case variations.
在不区分大小写的句柄服务器下创建句柄时，应保留其原始大小写。为了避免任何混淆，服务器应该避免创建任何字符串与现有句柄字符串匹配的句柄，忽略大小写差异。例如，如果句柄“X/Y”已经创建，服务器应该拒绝任何创建句柄“X/Y”或其任何大小写变体的请求。
Handles are transmitted as UTF8-Strings under the Handle protocol. Throughout this document, UTF8-String stands for the data type that consists of a 4-byte unsigned integer followed by a character string in UTF-8 encoding. The leading integer specifies the number of octets of the character string.
句柄在句柄协议下以UTF8字符串的形式传输。在本文档中，UTF8字符串表示由4字节无符号整数后跟UTF-8编码的字符串组成的数据类型。前导整数指定字符串的八位字节数。
Each message exchanged under the system protocol consists of four sections (see Fig. 2.2). Some of these sections (e.g., the Message Body) may be empty depending on the protocol operation.
根据系统协议交换的每条消息由四个部分组成（见图2.2）。根据协议操作，其中一些部分（例如，消息正文）可能为空。
The Message Envelope must always be present. It has a fixed size of 20 octets. The Message Envelope does not carry any application layer information and is primarily used to help deliver the message. Content in the Message Envelope is not protected by the digital signature in the Message Credential.
邮件信封必须始终存在。它有20个八位组的固定大小。消息信封不携带任何应用层信息，主要用于帮助传递消息。消息信封中的内容不受消息凭据中数字签名的保护。
The Message Header must always be present as well. It has a fixed size of 24 octets and holds the common data fields of all messages exchanged between client and server. These include the operation code, the response code, and the control options for each protocol operation. Content in the Message Header is protected by the digital signature in the Message Credential.
消息头也必须始终存在。它具有24个八位字节的固定大小，并保存客户端和服务器之间交换的所有消息的公共数据字段。这些包括操作代码、响应代码和每个协议操作的控制选项。消息头中的内容受消息凭据中的数字签名保护。
The Message Body contains data specific to each protocol operation. Its format varies according to the operation code and the response code in the Message Header. The Message Body may be empty. Content in the Message Body is protected by the digital signature in the Message Credential.
消息体包含特定于每个协议操作的数据。其格式根据消息头中的操作代码和响应代码而变化。消息正文可能为空。消息正文中的内容受消息凭据中的数字签名保护。
The Message Credential provides a mechanism for transport security for any message exchanged between the client and server. A non-empty Message Credential may contain the digital signature from the originator of the message or the one-way Message Authentication Code (MAC) based on a pre-established session key. The Message Credential may be used to authenticate the message between the client and server. It can also be used to check data integrity after its transmission.
消息凭据为客户端和服务器之间交换的任何消息提供传输安全机制。非空消息凭证可包含来自消息的发起人的数字签名或基于预先建立的会话密钥的单向消息认证码（MAC）。消息凭证可用于验证客户端和服务器之间的消息。它还可用于在数据传输后检查数据完整性。
.----------------------.
| | ; Message wrapper for proper message
| Message Envelope | ; delivery. Not protected by the
| | ; digital signature in the Message
| | ; Credential.
|----------------------|
| | ; Common data fields for all handle
| Message Header | ; operations.
| |
|----------------------|
| | ; Specific data fields for each
| Message Body | ; request/response.
| |
|----------------------|
| | ; Contains digital signature or
| Message Credential | ; message authentication code (MAC)
| | ; upon Message Header and Message
'----------------------' ; Body.
.----------------------.
| | ; Message wrapper for proper message
| Message Envelope | ; delivery. Not protected by the
| | ; digital signature in the Message
| | ; Credential.
|----------------------|
| | ; Common data fields for all handle
| Message Header | ; operations.
| |
|----------------------|
| | ; Specific data fields for each
| Message Body | ; request/response.
| |
|----------------------|
| | ; Contains digital signature or
| Message Credential | ; message authentication code (MAC)
| | ; upon Message Header and Message
'----------------------' ; Body.
Fig 2.2: Message format under the Handle protocol
图2.2:Handle协议下的消息格式
Each message begins with a Message Envelope under the Handle protocol. If a message has to be truncated before its transmission, each truncated portion must also begin with a Message Envelope.
每条消息都以Handle协议下的一个消息信封开始。如果消息在传输之前必须被截断，则每个被截断的部分也必须以消息信封开头。
The Message Envelope allows the reassembly of the message at the receiving end. It has a fixed size of 20 octets and consists of seven fields:
消息信封允许在接收端重新组装消息。它的固定大小为20个八位字节，由七个字段组成：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| MajorVersion | MinorVersion | MessageFlag |
|---------------------------------------------------------------|
| SessionId |
|---------------------------------------------------------------|
| RequestId |
|---------------------------------------------------------------|
| SequenceNumber |
|---------------------------------------------------------------|
| MessageLength |
'---------------------------------------------------------------'
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| MajorVersion | MinorVersion | MessageFlag |
|---------------------------------------------------------------|
| SessionId |
|---------------------------------------------------------------|
| RequestId |
|---------------------------------------------------------------|
| SequenceNumber |
|---------------------------------------------------------------|
| MessageLength |
'---------------------------------------------------------------'
The <MajorVersion> and <MinorVersion> are used to identify the version of the Handle protocol. Each of them is defined as a one-byte unsigned integer. This specification defines the protocol version whose <MajorVersion> is 2 and <MinorVersion> is 1.
<MajorVersion>和<MinorVersion>用于标识句柄协议的版本。它们中的每一个都定义为一个单字节无符号整数。本规范定义了<MajorVersion>为2且<MinorVersion>为1的协议版本。
<MajorVersion> and <MinorVersion> are designed to allow future backward compatibility. A difference in <MajorVersion> indicates major variation in the protocol format and the party with the lower <MajorVersion> will have to upgrade its software to ensure precise communication. An increment in <MinorVersion> is made when additional capabilities are added to the protocol without any major change to the message format.
<MajorVersion>和<MinorVersion>旨在实现未来的向后兼容性。<MajorVersion>中的差异表明协议格式存在重大变化，且<MajorVersion>较低的一方必须升级其软件以确保精确通信。当向协议添加附加功能而不对消息格式进行任何重大更改时，<MinorVersion>会增加。
The <MessageFlag> consists of two octets defined as follows:
<MessageFlag>由两个八位字节组成，定义如下：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|CP |EC |TC | Reserved |
'---------------------------------------------------------------'
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|CP |EC |TC | Reserved |
'---------------------------------------------------------------'
Bit 0 is the CP (ComPressed) flag that indicates whether the message (excluding the Message Envelope) is compressed. If the CP bit is set (to 1), the message is compressed. Otherwise, the message is not compressed. The Handle protocol uses the same compression method as used by the FTP protocol[8].
位0是CP（ComPressed）标志，指示消息（不包括消息信封）是否被压缩。如果CP位设置为（1），则消息将被压缩。否则，消息不会被压缩。Handle协议使用与FTP协议相同的压缩方法[8]。
Bit 1 is the EC (EnCrypted) flag that indicates whether the message (excluding the Message Envelope) is encrypted. The EC bit should only be set under an established session where a session key is in place. If the EC bit is set (to 1), the message is encrypted using the session key. Otherwise the message is not encrypted.
位1是EC（加密）标志，指示消息（不包括消息信封）是否加密。EC位应仅在已建立的会话下设置，其中会话密钥已就位。如果EC位设置为（1），则使用会话密钥对消息进行加密。否则，消息将不加密。
Bit 2 is the TC (TrunCated) flag that indicates whether this is a truncated message. Message truncation happens most often when transmitting a large message over the UDP protocol. Details of message truncation (or fragmentation) will be discussed in section 2.3.
位2是TC（截断）标志，指示这是否为截断消息。通过UDP协议传输大型消息时，消息截断最常见。第2.3节将讨论消息截断（或分段）的详细信息。
Bits 3 to 15 are currently reserved and must be set to zero.
位3至15当前保留，必须设置为零。
The <SessionId> is a four-byte unsigned integer that identifies a communication session between the client and server.
<SessionId>是一个四字节无符号整数，用于标识客户端和服务器之间的通信会话。
Session and its <SessionId> are assigned by a server, either upon an explicit request from a client or when multiple message exchanges are expected to fulfill the client's request. For example, the server will assign a unique <SessionId> in its response if it has to authenticate the client. A client may explicitly ask the server to set up a session as a virtually private communication channel like SSL [4]. Requests from clients without an established session must have their <SessionId> set to zero. The server must assign a unique non-zero <SessionId> for each new session. It is also responsible for terminating those sessions that are not in use after some period of time.
会话及其<SessionId>由服务器分配，无论是在客户机发出明确请求时，还是在多个消息交换有望满足客户机请求时。例如，如果必须对客户端进行身份验证，服务器将在其响应中分配唯一的<SessionId>。客户端可能会明确要求服务器将会话设置为类似SSL的虚拟专用通信通道[4]。来自未建立会话的客户端的请求必须将其<SessionId>设置为零。服务器必须为每个新会话分配唯一的非零<SessionId>。它还负责在一段时间后终止未使用的会话。
Both clients and servers must maintain the same <SessionId> for messages exchanged under an established session. A message whose <SessionId> is zero indicates that no session has been established.
对于在已建立会话下交换的消息，客户端和服务器必须保持相同的<SessionId>。<SessionId>为零的消息表示未建立会话。
The session and its state information may be shared among multiple handle operations. They may also be shared over multiple TCP connections as well. Once a session is established, both client and server must maintain their state information according to the <SessionId>. The state information may include the stage of the conversation, the other party's authentication information, and the session key that was established for message encryption or authentication. Details of these are discussed in section 3.8.
会话及其状态信息可以在多个句柄操作之间共享。它们也可以通过多个TCP连接共享。一旦建立了会话，客户端和服务器都必须根据<SessionId>维护它们的状态信息。状态信息可以包括会话的阶段、另一方的认证信息以及为消息加密或认证而建立的会话密钥。第3.8节讨论了这些细节。
Each request from a client is identified by a <RequestId>, a 4-byte unsigned integer set by the client. Each <RequestId> must be unique from all other outstanding requests from the same client. The <RequestId> allows the client to keep track of its requests, and any response from the server must include the correct <RequestId>.
来自客户机的每个请求都由客户机设置的4字节无符号整数<RequestId>标识。每个<RequestId>必须与来自同一客户端的所有其他未完成请求唯一。<RequestId>允许客户端跟踪其请求，服务器的任何响应都必须包含正确的<RequestId>。
Messages under the Handle protocol may be truncated during their transmission (e.g., under UDP). The <SequenceNumber> is a 4-byte unsigned integer used as a counter to keep track of each truncated portion of the original message. The message recipient can reassemble the original message based on the <SequenceNumber>. The <SequenceNumber> must start with 0 for each message. Each truncated message must set its TC flag in the Message Envelope. Messages that are not truncated must set their <SequenceNumber> to zero.
Handle协议下的消息在传输过程中可能会被截断（例如，在UDP下）。<SequenceNumber>是一个4字节无符号整数，用作计数器，用于跟踪原始消息的每个截断部分。消息接收者可以根据<SequenceNumber>重新组合原始消息。对于每条消息，<SequenceNumber>必须以0开头。每个被截断的消息必须在消息信封中设置其TC标志。未被截断的消息必须将其<SequenceNumber>设置为零。
A 4-byte unsigned integer that specifies the total number of octets of any message, excluding those in the Message Envelope. The length of any single message exchanged under the Handle protocol is limited by the range of a 4-byte unsigned integer. Longer data can be transmitted as multiple messages with a common <RequestId>.
A 4-byte unsigned integer that specifies the total number of octets of any message, excluding those in the Message Envelope. The length of any single message exchanged under the Handle protocol is limited by the range of a 4-byte unsigned integer. Longer data can be transmitted as multiple messages with a common <RequestId>.translate error, please retry
The Message Header contains the common data elements among any protocol operation. It has a fixed size of 24 octets and consists of eight fields.
消息头包含任何协议操作中的公共数据元素。它有24个八位字节的固定大小，由八个字段组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| OpCode |
|---------------------------------------------------------------|
| ResponseCode |
|---------------------------------------------------------------|
| OpFlag |
|---------------------------------------------------------------|
| SiteInfoSerialNumber | RecursionCount| |
|---------------------------------------------------------------|
| ExpirationTime |
|---------------------------------------------------------------|
| BodyLength |
'---------------------------------------------------------------'
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| OpCode |
|---------------------------------------------------------------|
| ResponseCode |
|---------------------------------------------------------------|
| OpFlag |
|---------------------------------------------------------------|
| SiteInfoSerialNumber | RecursionCount| |
|---------------------------------------------------------------|
| ExpirationTime |
|---------------------------------------------------------------|
| BodyLength |
'---------------------------------------------------------------'
Every message that is not truncated must have a Message Header. If a message has to be truncated for its transmission, the Message Header must appear in the first truncated portion of the message.
每个未被截断的消息都必须有一个消息头。如果必须截断消息以进行传输，则消息头必须出现在消息的第一个截断部分中。
This is different from the Message Envelope, which appears in each truncated portion of the message.
这与出现在消息的每个截断部分中的消息信封不同。
The <OpCode> stands for operation code, which is a four-byte unsigned integer that specifies the intended operation. The following table lists the <OpCode>s that MUST be supported by all implementations in order to conform to the base protocol specification. Each operation code is given a symbolic name that is used throughout this document for easy reference.
<OpCode>代表操作代码，它是一个四字节无符号整数，用于指定所需的操作。下表列出了所有实现必须支持的<OpCode>s，以符合基本协议规范。每个操作代码都有一个符号名，在本文档中使用，以便于参考。
Op_Code Symbolic Name Remark
--------- ------------- ------
Op_Code Symbolic Name Remark
--------- ------------- ------
0 OC_RESERVED Reserved 1 OC_RESOLUTION Handle query 2 OC_GET_SITEINFO Get HS_SITE values
0 OC_保留保留1 OC_解析句柄查询2 OC_获取_站点信息获取HS_站点值
100 OC_CREATE_HANDLE Create new handle 101 OC_DELETE_HANDLE Delete existing handle 102 OC_ADD_VALUE Add handle value(s) 103 OC_REMOVE_VALUE Remove handle value(s) 104 OC_MODIFY_VALUE Modify handle value(s) 105 OC_LIST_HANDLE List handles 106 OC_LIST_NA List sub-naming authorities
100 OC_创建_句柄创建新句柄101 OC_删除_句柄删除现有句柄102 OC_添加_值添加句柄值103 OC_删除_值删除句柄值104 OC_修改_值修改句柄值105 OC_列表_句柄列表106 OC_列表_NA列表子命名权限
200 OC_CHALLENGE_RESPONSE Response to challenge 201 OC_VERIFY_RESPONSE Verify challenge response
200 OC_质询_响应质询201 OC_验证_响应验证质询响应
300 : { Reserved for handle server administration } 399
300:{为句柄服务器管理保留}399
400 OC_SESSION_SETUP Session setup request 401 OC_SESSION_TERMINATE Session termination request 402 OC_SESSION_EXCHANGEKEY Session key exchange
400 OC_会话设置会话设置请求401 OC_会话终止请求402 OC_会话交换密钥会话密钥交换
A detailed description of each of these <OpCode>s can be found in section 3 of this document. In general, clients use the <OpCode> to tell the server what kind of handle operation they want to accomplish. Response from the server must maintain the same <OpCode> as the original request and use the <ResponseCode> to indicate the result.
本文件第3节详细介绍了这些<OpCode>s。通常，客户机使用<OpCode>来告诉服务器他们想要完成哪种句柄操作。来自服务器的响应必须保持与原始请求相同的<OpCode>，并使用<ResponseCode>指示结果。
The <ResponseCode> is a 4-byte unsigned integer that is given by a server to indicate the result of any service request. The list of <ResponseCode>s used in the Handle protocol is defined in the following table. Each response code is given a symbolic name that is used throughout this document for easy reference.
<ResponseCode>是一个4字节无符号整数，由服务器提供，用于指示任何服务请求的结果。下表定义了Handle协议中使用的<ResponseCode>s列表。每个响应代码都有一个符号名，在本文档中使用，以便于参考。
Res. Code Symbolic Name Remark
--------- ------------- ------
Res. Code Symbolic Name Remark
--------- ------------- ------
0 RC_RESERVED Reserved for request 1 RC_SUCCESS Success response 2 RC_ERROR General error 3 RC_SERVER_BUSY Server too busy to respond 4 RC_PROTOCOL_ERROR Corrupted or unrecognizable message 5 RC_OPERATION_DENIED Unsupported operation 6 RC_RECUR_LIMIT_EXCEEDED Too many recursions for the request
0为请求保留的RC_1 RC_成功响应2 RC_错误一般错误3 RC_服务器繁忙服务器太忙无法响应4 RC_协议错误损坏或无法识别消息5 RC_操作被拒绝不支持的操作6 RC_重复次数限制\u超出了请求的太多递归次数
100 RC_HANDLE_NOT_FOUND Handle not found 101 RC_HANDLE_ALREADY_EXIST Handle already exists 102 RC_INVALID_HANDLE Encoding (or syntax) error
100 RC_句柄未找到句柄未找到101 RC_句柄已存在句柄已存在102 RC_无效句柄编码（或语法）错误
200 RC_VALUE_NOT_FOUND Value not found 201 RC_VALUE_ALREADY_EXIST Value already exists 202 RC_VALUE_INVALID Invalid handle value
200 RC_值\u未找到值未找到201 RC_值\u已存在值已存在202 RC_值\u无效句柄值
300 RC_EXPIRED_SITE_INFO SITE_INFO out of date 301 RC_SERVER_NOT_RESP Server not responsible 302 RC_SERVICE_REFERRAL Server referral 303 RC_NA_DELEGATE Naming authority delegation takes place.
300 RC_过期\u站点信息站点信息过期301 RC_服务器\u非响应服务器不负责302 RC_服务\u转介服务器转介303 RC_NA_代表命名权限转介发生。
400 RC_NOT_AUTHORIZED Not authorized/permitted 401 RC_ACCESS_DENIED No access to data 402 RC_AUTHEN_NEEDED Authentication required 403 RC_AUTHEN_FAILED Failed to authenticate 404 RC_INVALID_CREDENTIAL Invalid credential 405 RC_AUTHEN_TIMEOUT Authentication timed out 406 RC_UNABLE_TO_AUTHEN Unable to authenticate
400 RC_未授权未授权/允许401 RC_访问被拒绝不访问数据402 RC_AUTHEN_需要身份验证403 RC_AUTHEN_未能身份验证404 RC_无效凭证无效凭证405 RC_AUTHEN_超时身份验证超时406 RC_无法身份验证无法身份验证
500 RC_SESSION_TIMEOUT Session expired 501 RC_SESSION_FAILED Unable to establish session 502 RC_NO_SESSION_KEY No session yet available 503 RC_SESSION_NO_SUPPORT Session not supported 504 RC_SESSION_KEY_INVALID Invalid session key
500 RC_会话_超时会话已过期501 RC_会话_失败无法建立会话502 RC_无会话_密钥无会话尚未可用503 RC_会话_无会话支持会话不受支持504 RC_会话_密钥无效会话密钥
900 RC_TRYING Request under processing 901 RC_FORWARDED Request forwarded to another server 902 RC_QUEUED Request queued for later processing
900正在处理中的RC_尝试请求901 RC_转发请求转发到另一台服务器902 RC_排队请求排队等待稍后处理
Response codes under 10000 are reserved for system use. Any message with a response code under 10000 but not listed above should be treated as an unknown error. Response codes above 10000 are user defined and can be used for application specific purposes.
10000以下的响应代码保留供系统使用。响应代码低于10000但上面未列出的任何消息都应视为未知错误。10000以上的响应代码是用户定义的，可用于特定于应用程序的目的。
Detailed descriptions of these <ResponseCode>s can be found in section 3 of this document. In general, any request from a client must have its <ResponseCode> set to 0. The response message from the server must have a non-zero <ResponseCode> to indicate the result. For example, a response message from a server with <ResponseCode> set to RC_SUCCESS indicates that the server has successfully fulfilled the client's request.
这些<ResponseCode>的详细说明见本文件第3节。通常，来自客户端的任何请求都必须将其<ResponseCode>设置为0。来自服务器的响应消息必须具有非零的<ResponseCode>，以指示结果。例如，来自<ResponseCode>设置为RC_SUCCESS的服务器的响应消息表示该服务器已成功满足客户端的请求。
The <OpFlag> is a 32-bit bit-mask that defines various control options for protocol operation. The following figure shows the location of each option flag in the <OpFlag> field.
<OpFlag>是一个32位掩码，用于定义协议操作的各种控制选项。下图显示了<OpFlag>字段中每个选项标志的位置。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|AT |CT |ENC|REC|CA |CN |KC |PO |RD | Reserved |
|---------------------------------------------------------------|
| Reserved |
'---------------------------------------------------------------'
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|AT |CT |ENC|REC|CA |CN |KC |PO |RD | Reserved |
|---------------------------------------------------------------|
| Reserved |
'---------------------------------------------------------------'
AT - AuThoritative bit. A request with the AT bit set (to 1) indicates that the request should be directed to the primary service site (instead of any mirroring sites). A response message with the AT bit set (to 1) indicates that the message is returned from a primary server (within the primary service site).
至少有一点权威。将AT位设置为（1）的请求表示该请求应定向到主服务站点（而不是任何镜像站点）。AT位设置为（1）的响应消息表示该消息是从主服务器（主服务站点内）返回的。
CT - CerTified bit. A request with the CT bit set (to 1) asks the server to sign its response with its digital signature. A response with the CT bit set (to 1) indicates that the message is signed. The server must sign its response if the request has its CT bit set (to 1). If the server fails to provide a valid signature in its response, the client should discard the response and treat the request as failed.
CT认证钻头。CT位设置为（1）的请求要求服务器使用其数字签名对其响应进行签名。CT位设置为（1）的响应表示消息已签名。如果请求的CT位设置为（1），则服务器必须对其响应进行签名。如果服务器未能在其响应中提供有效的签名，则客户端应放弃响应并将请求视为失败。
ENC - ENCryption bit. A request with the ENC bit set (to 1) requires the server to encrypt its response using the pre-established session key.
加密位。ENC位设置为（1）的请求要求服务器使用预先建立的会话密钥加密其响应。
REC - RECursive bit. A request with the REC bit set (to 1) asks the server to forward the query on behalf of the client if the request has to be processed by another handle server. The server may honor the request by forwarding the request to the appropriate handle server and passing on any result back to the client. The server may also deny any such request by sending a response with <ResponseCode> set to RC_SERVER_NOT_RESP.
REC-递归位。REC位设置为（1）的请求要求服务器代表客户端转发查询（如果请求必须由另一个句柄服务器处理）。服务器可以通过将请求转发到适当的句柄服务器并将任何结果传递回客户端来满足请求。服务器还可以通过发送设置为RC_server_NOT_RESP的<ResponseCode>响应来拒绝任何此类请求。
CA - Cache Authentication. A request with the CA bit set (to 1) asks the caching server (if any) to authenticate any server response (e.g., verifying the server's signature) on behalf of the client. A response with the CA bit set (to 1) indicates that the response has been authenticated by the caching server.
CA-缓存身份验证。CA位设置为（1）的请求要求缓存服务器（如果有）代表客户端验证任何服务器响应（例如，验证服务器的签名）。CA位设置为（1）的响应表示该响应已通过缓存服务器的身份验证。
CN - ContiNuous bit. A message with the CN bit set (to 1) tells the message recipient that more messages that are part of the same request (or response) will follow. This happens if a request (or response) has data that is too large to fit into any single message and has to be fragmented into multiple messages.
CN-连续位。CN位设置为（1）的消息告诉消息接收者，属于同一请求（或响应）的更多消息将随之而来。如果请求（或响应）的数据太大，无法放入任何单个消息中，并且必须分段为多个消息，则会发生这种情况。
KC - Keep Connection bit. A message with the KC bit set requires the message recipient to keep the TCP connection open (after the response is sent back). This allows the same TCP connection to be used for multiple handle operations.
KC-保持连接位。设置了KC位的邮件要求邮件收件人保持TCP连接打开（在返回响应后）。这允许相同的TCP连接用于多个句柄操作。
PO - Public Only bit. Used by query operations only. A query request with the PO bit set (to 1) indicates that the client is only asking for handle values that have the PUB_READ permission. A request with PO bit set to zero asks for all the handle values regardless of their read permission. If any of the handle values require ADMIN_READ permission, the server must authenticate the client as the handle administrator.
PO-仅限公共位。仅由查询操作使用。PO位设置为（1）的查询请求表示客户端仅请求具有PUB_READ权限的句柄值。PO位设置为零的请求要求所有句柄值，而不考虑其读取权限。如果任何句柄值需要ADMIN_READ权限，服务器必须将客户端验证为句柄管理员。
RD - Request-Digest bit. A request with the RD bit set (to 1) asks the server to include in its response the message digest of the request. A response message with the RD bit set (to 1) indicates that the first field in the Message Body contains the message digest of the original request. The message digest can be used to check the integrity of the server response. Details of these are discussed later in this document.
请求摘要位。RD位设置为（1）的请求要求服务器在其响应中包含请求的消息摘要。RD位设置为（1）的响应消息表示消息正文中的第一个字段包含原始请求的消息摘要。消息摘要可用于检查服务器响应的完整性。这些细节将在本文档后面讨论。
All other bits in the <OpFlag> field are reserved and must be set to zero.
<OpFlag>字段中的所有其他位都是保留的，必须设置为零。
In general, servers must honor the <OpFlag> specified in the request. If a requested option cannot be met, the server should return an error message with the proper <ResponseCode> as defined in the previous section.
通常，服务器必须遵守请求中指定的<OpFlag>。如果无法满足请求的选项，服务器应返回一条错误消息，其中包含上一节中定义的正确的<ResponseCode>。
The <SiteInfoSerialNumber> is a two-byte unsigned integer. The <SiteInfoSerialNumber> in a request refers to the <SerialNumber> of the HS_SITE value used by the client (to access the server). Servers can check the <SiteInfoSerialNumber> in the request to find out if the client has up-to-date service information.
<SiteInfoSerialNumber>是一个双字节无符号整数。请求中的<SiteInfoSerialNumber>是指客户端（访问服务器）使用的HS\U站点值的<SerialNumber>。服务器可以检查请求中的<SiteInfoSerialNumber>，以了解客户端是否具有最新的服务信息。
When possible, the server should fulfill a client's request even if the service information used by the client is out-of-date. However, the response message should specify the latest version of service information in the <SiteInforSerialNumber> field. Clients with out-of-date service information can update the service information from the Global Handle Registry. If the server cannot fulfill a client's request due to expired service information, it should reject the request and return an error message with <ResponseCode> set to RC_EXPIRED_SITE_INFO.
如果可能，即使客户端使用的服务信息已过期，服务器也应满足客户端的请求。但是，响应消息应在<SiteInforSerialNumber>字段中指定服务信息的最新版本。具有过期服务信息的客户端可以从全局句柄注册表更新服务信息。如果服务器由于服务信息过期而无法满足客户端的请求，则应拒绝该请求并返回一条错误消息，并将<ResponseCode>设置为RC\u expired\u SITE\u INFO。
The <RecursionCount> is a one-byte unsigned integer that specifies the number of service recursions. Service recursion happens if the server has to forward the client's request to another server. Any request directly from the client must have its <RecursionCount> set to 0. If the server has to send a recursive request on behalf of the client, it must increment the <RecursionCount> by 1. Any response from the server must maintain the same <RecursionCount> as the one in the request. To prevent an infinite loop of service recursion, the server should be configurable to stop sending a recursive request when the <RecursionCount> reaches a certain value.
<RecursionCount>是一个单字节无符号整数，用于指定服务递归的数量。如果服务器必须将客户机的请求转发到另一台服务器，则会发生服务递归。直接来自客户端的任何请求必须将其<RecursionCount>设置为0。如果服务器必须代表客户端发送递归请求，则必须将<RecursionCount>增加1。来自服务器的任何响应都必须与请求中的响应保持相同的<RecursionCount>。为了防止服务递归的无限循环，服务器应该配置为在<RecursionCount>达到某个值时停止发送递归请求。
The <ExpirationTime> is a 4-byte unsigned integer that specifies the time when the message should be considered expired, relative to January 1st, 1970 GMT, in seconds. It is set to zero if no expiration is expected.
<ExpirationTime>是一个4字节的无符号整数，指定相对于1970年1月1日格林威治标准时间，消息应被视为过期的时间（以秒为单位）。如果预期不会过期，则将其设置为零。
The <BodyLength> is a 4-byte unsigned integer that specifies the number of octets in the Message Body. The <BodyLength> does not count the octets in the Message Header or those in the Message Credential.
<BodyLength>是一个4字节无符号整数，用于指定消息正文中的八位字节数。<BodyLength>不计算消息头或消息凭据中的八位字节。
The Message Body always follows the Message Header. The number of octets in the Message Body can be determined from the <BodyLength> in the Message Header. The Message Body may be empty. The exact format of the Message Body depends on the <OpCode> and the <ResponseCode> in the Message Header. Details of the Message Body under each <OpCode> and <ResponseCode> are described in section 3 of this document.
消息正文始终位于消息头之后。消息正文中的八位字节数可根据消息头中的<BodyLength>确定。消息正文可能为空。消息正文的确切格式取决于消息头中的<OpCode>和<ResponseCode>。本文件第3节描述了每个<OpCode>和<ResponseCode>下的消息正文的详细信息。
For any response message, if the Message Header has its RD bit (in <OpFlag>) set to 1, the Message Body must begin with the message digest of the original request. The message digest is defined as follows:
对于任何响应消息，如果消息头的RD位（在<OpFlag>中）设置为1，则消息正文必须以原始请求的消息摘要开头。消息摘要定义如下：
<RequestDigest> ::= <DigestAlgorithmIdentifier>
<MessageDigest>
<RequestDigest> ::= <DigestAlgorithmIdentifier>
<MessageDigest>
where
哪里
<DigestAlgorithmIdentifier> An octet that identifies the algorithm used to generate the message digest. If the octet is set to 1, the digest is generated using the MD5 [9] algorithm. If the octet is set to 2, SHA-1 [10] algorithm is used.
<DigestAlgorithmIdentifier>标识用于生成消息摘要的算法的八位字节。如果八位组设置为1，则使用MD5[9]算法生成摘要。如果八位字节设置为2，则使用SHA-1[10]算法。
<MessageDigest> The message digest itself. It is calculated upon the Message Header and the Message Body of the original request. The length of the field is fixed according to the digest algorithm. For MD5 algorithm, the length is 16 octets. For SHA-1, the length is 20 octets.
<MessageDigest>消息摘要本身。它是根据原始请求的消息头和消息体计算的。根据摘要算法，字段的长度是固定的。对于MD5算法，长度为16个八位字节。对于SHA-1，长度为20个八位字节。
The Message Body may be truncated into multiple portions during its transmission (e.g., over UDP). Recipients of such a message may reassemble the Message Body from each portion based on the <SequenceNumber> in the Message Envelope.
消息体在传输期间（例如，通过UDP）可能被截断为多个部分。此类消息的接收者可以基于消息信封中的<SequenceNumber>从每个部分重新组装消息正文。
The Message Credential is primarily used to carry any digital signatures signed by the message issuer. It may also carry the Message Authentication Code (MAC) if a session key has been established. The Message Credential is used to protect contents in the Message Header and the Message Body from being tampered with during transmission. The format of the Message Credential is designed to be semantically compatible with PKCS#7 [5]. Each Message Credential consists of the following fields:
消息凭证主要用于携带由消息颁发者签名的任何数字签名。如果建立了会话密钥，它还可能携带消息认证码（MAC）。消息凭证用于保护消息头和消息正文中的内容在传输过程中不被篡改。消息凭证的格式设计为在语义上与PKCS#7兼容[5]。每个消息凭据由以下字段组成：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| CredentialLength |
|---------------------------------------------------------------|
| Version | Reserved | Options |
|---------------------------------------------------------------|
|
| Signer: <Handle, Index>
|
|---------------------------------------------------------------|
| Type (UTF8-String) |
|---------------------------------------------------------------|
|
| SignedInfo: <Length> : 4-byte unsigned integer
| DigestAlgorithm: <UTF8-String>
| SignedData: <Length, Signature>
|
'---------------------------------------------------------------'
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| CredentialLength |
|---------------------------------------------------------------|
| Version | Reserved | Options |
|---------------------------------------------------------------|
|
| Signer: <Handle, Index>
|
|---------------------------------------------------------------|
| Type (UTF8-String) |
|---------------------------------------------------------------|
|
| SignedInfo: <Length> : 4-byte unsigned integer
| DigestAlgorithm: <UTF8-String>
| SignedData: <Length, Signature>
|
'---------------------------------------------------------------'
where
哪里
<CredentialLength> A 4-byte unsigned integer that specifies the number of octets in the Message Credential. It must be set to zero if the message has no Message Credential.
<CredentialLength>一个4字节无符号整数，指定消息凭据中的八位字节数。如果消息没有消息凭据，则必须将其设置为零。
<Version> An octet that identifies the version number of the Message Credential. The version number specified in this document is zero.
<Version>标识消息凭证版本号的八位字节。本文档中指定的版本号为零。
<Reserved> An octet that must be set to zero.
<Reserved>必须设置为零的八位字节。
<Options> Two octets reserved for various cryptography options.
<Options>为各种加密选项保留两个八位字节。
<Signer> ::= <HANDLE>
<INDEX>
A reference to a handle value in terms of the <HANDLE> and the
<INDEX> of the handle value. The handle value may contain the
public key, or the X.509 certificate, that can be used to
validate the digital signature.
<Signer> ::= <HANDLE>
<INDEX>
A reference to a handle value in terms of the <HANDLE> and the
<INDEX> of the handle value. The handle value may contain the
public key, or the X.509 certificate, that can be used to
validate the digital signature.
<Type> A UTF8-String that indicates the type of content in the <SignedInfo> field (described below). It may contain HS_DIGEST if <SignedInfo> contains the message digest, or HS_MAC if <SignedInfo> contains the Message Authentication Code (MAC). The <Type> field will specify the signature algorithm identifier if <SignedInfo> contains a digital signature. For example, with the <Type> field set to HS_SIGNED_PSS, the <SignedInfo> field will contain the digital signature generated using the RSA-PSS algorithm [16]. If the <Type> field is set to HS_SIGNED, the <SignedInfo> field will contain the digital signature generated from a DSA public key pair.
<Type>一个UTF8字符串，指示<SignedInfo>字段中的内容类型（如下所述）。如果<SignedInfo>包含消息摘要，则可能包含HS_摘要；如果<SignedInfo>包含消息身份验证码（MAC），则可能包含HS_MAC。如果<SignedInfo>包含数字签名，则<Type>字段将指定签名算法标识符。例如，当<Type>字段设置为HS_SIGNED_PSS时，<SignedInfo>字段将包含使用RSA-PSS算法生成的数字签名[16]。如果<Type>字段设置为HS_SIGNED，则<SignedInfo>字段将包含从DSA公钥对生成的数字签名。
<SignedInfo> ::= <Length>
<DigestAlgorithm>
<SignedData>
where
<SignedInfo> ::= <Length>
<DigestAlgorithm>
<SignedData>
where
<Length> A 4-byte unsigned integer that specifies the number of octets in the <SignedInfo> field.
<Length>一个4字节无符号整数，指定<SignedInfo>字段中的八位字节数。
<DigestAlgorithm> A UTF8-String that refers to the digest algorithm used to generate the digital signature. For example, the value "SHA-1" indicates that the SHA-1 algorithm is used to generate the message digest for the signature.
<DigestAlgorithm>指用于生成数字签名的摘要算法的UTF8字符串。例如，值“SHA-1”表示SHA-1算法用于生成签名的消息摘要。
<SignedData> ::= <LENGTH>
<SIGNATURE>
where
<SignedData> ::= <LENGTH>
<SIGNATURE>
where
<LENGTH> A 4-byte unsigned integer that specifies the number of octets in the <SIGNATURE>.
<LENGTH>一个4字节无符号整数，指定<SIGNATURE>中的八位字节数。
<SIGNATURE> Contains the digital signature or the MAC over the Message Header and Message Body. The syntax and semantics of the signature depend on the <Type> field
<SIGNATURE>包含消息头和消息体上的数字签名或MAC。签名的语法和语义取决于<Type>字段
and the public key referenced in the <Signer> field. For example, if the <Type> field is "HS_SIGNED" and the public key referred to by the <Signer> field is a DSA [6] public key, the signature will be the ASN.1 octet string representation of the parameter R and S as described in [7]. If the <Signer> field refers to a handle value that contains a X.509 certificate, the signature should be encoded according to RFC 3279 and RFC 3280 [14, 15].
以及<Signer>字段中引用的公钥。例如，如果<Type>字段是“HS_签名的”，并且<Signer>字段引用的公钥是DSA[6]公钥，则签名将是参数R和S的ASN.1八位字符串表示形式，如[7]所述。如果<Signer>字段引用包含X.509证书的句柄值，则应根据RFC 3279和RFC 3280[14，15]对签名进行编码。
The Message Credential may contain the message authentication code (MAC) generated using a pre-established session key. In this case, the <Signer> field must set its <HANDLE> to a zero-length UTF8-String and its <INDEX> to the <SessionId> specified in the Message Envelope. The <Signature> field must contain the MAC in its <SIGNATURE> field. The MAC is the result of the one-way hash over the concatenation of the session key, the <Message Header>, the <MessageBody>, and the session key again.
消息凭证可以包含使用预先建立的会话密钥生成的消息认证码（MAC）。在这种情况下，<Signer>字段必须将其<HANDLE>设置为长度为零的UTF8字符串，并将其<INDEX>设置为消息信封中指定的<SessionId>。<Signature>字段必须在其<Signature>字段中包含MAC。MAC是会话密钥、<messageheader>、<MessageBody>和会话密钥再次串联的单向散列的结果。
The Message Credential in a response message may contain the digital signature signed by the server. The server's public key can be found in the service information used by the client to send the request to the server. In this case, the client should ignore any reference in the <Signer> field and use the public key in the service information to verify the signature.
响应消息中的消息凭据可能包含由服务器签名的数字签名。服务器的公钥可以在客户端用于向服务器发送请求的服务信息中找到。在这种情况下，客户端应该忽略<Signer>字段中的任何引用，并使用服务信息中的公钥来验证签名。
The Message Credential can also be used for non-repudiation purposes. This happens if the Message Credential contains a server's digital signature. The signature may be used as evidence to demonstrate that the server has rendered its service in response to a client's request.
消息凭证也可用于不可否认性目的。如果消息凭据包含服务器的数字签名，则会发生这种情况。签名可用作证明服务器已响应客户请求提供其服务的证据。
The Message Credential provides a mechanism for safe transmission of any message between the client and server. Any message whose Message Header and Message Body complies with its Message Credential suggests that the message indeed comes from its originator and assures that the message has not been tampered with during its transmission.
消息凭证提供了在客户端和服务器之间安全传输任何消息的机制。消息头和消息体符合其消息凭据的任何消息都表明消息确实来自其原始发件人，并确保消息在传输过程中未被篡改。
A large message may be truncated into multiple packets during its transmission. For example, to fit the size limit of a UDP packet, the message issuer must truncate any large message into multiple UDP packets before its transmission. The message recipient must reassemble the message from these truncated packets before further processing. Message truncation must be carried out over the entire
大消息在传输过程中可能会被截断为多个数据包。例如，为了适应UDP数据包的大小限制，消息发布者必须在传输之前将任何大消息截断为多个UDP数据包。在进一步处理之前，邮件收件人必须从这些被截断的数据包中重新组装邮件。消息截断必须在整个过程中执行
message except the Message Envelope. A new Message Envelope has to be inserted in front of each truncated packet before its transmission. For example, a large message that consists of
除邮件信封外的其他邮件。在传输之前，必须在每个被截断的数据包前面插入一个新的消息信封。例如，包含以下内容的大型消息：
.--------------------------------------------------------.
| Message Envelope | Message Header, Body, Credential |
'--------------------------------------------------------'
.--------------------------------------------------------.
| Message Envelope | Message Header, Body, Credential |
'--------------------------------------------------------'
may be truncated into:
可被截断为：
.--------------------------------------------.
| Message Envelope 1 | Truncated_Packet 1 |
'--------------------------------------------'
.--------------------------------------------.
| Message Envelope 2 | Truncated_Packet 2 |
'--------------------------------------------'
.--------------------------------------------.
| Message Envelope 1 | Truncated_Packet 1 |
'--------------------------------------------'
.--------------------------------------------.
| Message Envelope 2 | Truncated_Packet 2 |
'--------------------------------------------'
......
......
.--------------------------------------------.
| Message Envelope N | Truncated Packet N |
'--------------------------------------------'
.--------------------------------------------.
| Message Envelope N | Truncated Packet N |
'--------------------------------------------'
where the "Truncated_packet 1", "Truncated_packet 2", ..., and "Truncated_packet N" result from truncating the Message Header, the Message Body and the Message Credential. Each "Message Envelope i" (inserted before each truncation) must set its TC flag to 1 and maintain the proper sequence count (in the <SequenceNumber>). Each "Message Envelope i" must also set its <MessageLength> to reflect the size of the packet. The recipient of these truncated packets can reassemble the message by concatenating these packets based on their <SequenceNumber>.
其中，“截断的_数据包1”、“截断的_数据包2”、…、和“截断的_数据包N”是截断消息头、消息正文和消息凭证的结果。每个“消息信封i”（在每次截断之前插入）必须将其TC标志设置为1，并保持正确的序列计数（在<SequenceNumber>中）。每个“消息信封i”还必须设置其<MessageLength>，以反映数据包的大小。这些被截断的数据包的接收者可以通过基于它们的<SequenceNumber>连接这些数据包来重新组合消息。
This section describes the details of each protocol operation in terms of messages exchanged between the client and server. It also defines the format of the Message Body according to each <OpCode> and <ResponseCode> in the Message Header.
本节根据客户机和服务器之间交换的消息描述每个协议操作的详细信息。它还根据消息头中的每个<OpCode>和<ResponseCode>定义消息体的格式。
The service information for the Global Handle Registry (GHR) allows clients to contact the GHR to find out the responsible service components for their handles. The service information is a set of HS_SITE values assigned to the root handle "0.NA/0.NA" and is also
全局句柄注册表（GHR）的服务信息允许客户端联系GHR，以查找其句柄的负责服务组件。服务信息是分配给根句柄“0.NA/0.NA”的一组HS_站点值，也是
called the root service information. The root service information may be distributed along with the client software, or be downloaded from the Handle System website at http://www.handle.net.
调用根服务信息。根服务信息可与客户端软件一起分发，或从Handle System网站下载，网址为http://www.handle.net.
Changes to the root service information are identified by the <SerialNumber> in the HS_SITE values. A server at GHR can find out if the root service information used by the client is outdated by checking the <SerialNumber> in the client's request. The client should update the root service information if the <ResponseCode> of the response message is RC_EXPIRED_SITE_INFO. Clients may obtain the most up-to-date root service information from the root handle. The GHR must sign the root service information using the public key specified in the outdated service information (identified in the client's request) so that the client can validate the signature.
根服务信息的更改由HS_站点值中的<SerialNumber>标识。GHR的服务器可以通过检查客户端请求中的<SerialNumber>来确定客户端使用的根服务信息是否过时。如果响应消息的<ResponseCode>是RC\u EXPIRED\u SITE\u INFO，则客户端应更新根服务信息。客户端可以从根句柄获取最新的根服务信息。GHR必须使用过期服务信息（在客户端请求中标识）中指定的公钥对根服务信息进行签名，以便客户端可以验证签名。
Each handle under the Handle System is managed by a unique handle service component (e.g., LHS). For any given handle, the responsible service component (and its service information) can be found from its naming authority handle. Before resolving any given handle, the client needs to find the responsible service component by querying the naming authority handle from the GHR.
手柄系统下的每个手柄由唯一的手柄服务组件（例如LHS）管理。对于任何给定的句柄，可以从其命名机构句柄中找到负责的服务组件（及其服务信息）。在解析任何给定句柄之前，客户机需要通过从GHR查询命名机构句柄来找到负责的服务组件。
For example, to find the responsible LHS for the handle "1000/abc", client software can query the GHR for the HS_SITE (or HS_SERV) values assigned to the naming authority handle "0.NA/1000". The set of HS_SITE values provides the service information of the LHS that manages every handle under the naming authority "1000". If no HS_SITE values are found, the client can check if there is any HS_SERV value assigned to the naming authority handle. The HS_SERV value provides the service handle that maintains the service information for the LHS. Service handles are used to manage the service information shared by different naming authorities.
例如，要查找句柄“1000/abc”的负责LHS，客户端软件可以查询GHR中分配给命名机构句柄“0.NA/1000”的HS_站点（或HS_SERV）值。HS_站点值集提供LHS的服务信息，LHS管理命名机构“1000”下的每个句柄。如果未找到HS_站点值，客户端可以检查是否有任何HS_服务值分配给命名机构句柄。HS_SERV值提供维护LHS服务信息的服务句柄。服务句柄用于管理由不同命名机构共享的服务信息。
It is possible that the naming authority handle requested by the client does not reside at the GHR. This happens when naming authority delegation takes place. Naming authority delegation happens when a naming authority delegates an LHS to manage all its child naming authorities. In this case, the delegating naming authority must contain the service information, a set of HS_NA_DELEGATE values, of the LHS that manages its child naming authorities.
客户请求的命名机构句柄可能不位于GHR。发生命名授权委托时会发生这种情况。命名机构委托LHS管理其所有子命名机构时，会发生命名机构委托。在这种情况下，委托命名机构必须包含管理其子命名机构的LHS的服务信息（一组HS_NA_委托值）。
All top-level naming authority handles must be registered and managed by the GHR. When a server at the GHR receives a request for a naming authority that has been delegated to an LHS, it must return a message with the <ResponseCode> set to RC_NA_DELEGATE, along with the
所有顶级命名机构句柄必须由GHR注册和管理。当GHR处的服务器收到已委托给LHS的命名权限请求时，它必须返回一条消息，并将<ResponseCode>设置为RC_NA_DELEGATE，以及
HS_NA_DELAGATE values from the nearest ancestor naming authority. The client can query the LHS described by the HS_NA_DELAGATE values for the delegated naming authority handle. In practice, the ancestor naming authority should make itself available to any handle server within the GHR, by replicating itself at the time of delegation. This will prevent any cross-queries among handle servers (within a service site) when the naming authority in query and the ancestor naming authority do not hash into the same handle server.
HS_NA_DELAGATE值来自最近的祖先命名机构。客户端可以查询HS_NA_DELAGATE值所描述的LHS，以获得委托命名权限句柄。实际上，祖先命名机构应该通过在委派时复制自身，使其自身可用于GHR中的任何句柄服务器。当查询中的命名机构和祖先命名机构没有散列到同一个句柄服务器中时，这将防止句柄服务器（服务站点内）之间的任何交叉查询。
Each handle service component is defined in terms of a set of HS_SITE values. Each of these HS_SITE values defines a service site within the service component. A service site may consist of a group of handle servers. For any given handle, the responsible handle server within the service component can be found following this procedure:
每个句柄服务组件都是根据一组HS_站点值定义的。这些HS_站点值中的每一个都定义了服务组件中的服务站点。服务站点可以由一组句柄服务器组成。对于任何给定的句柄，可以按照以下步骤找到服务组件中负责的句柄服务器：
1. Select a preferred service site.
1. 选择首选服务站点。
Each service site is defined in terms of an HS_SITE value. The HS_SITE value may contain a <Description> or other attributes (under the <AttributeList>) to help the selection. Clients must select the primary service site for any administrative operations.
每个服务站点都根据HS_站点值进行定义。HS_站点值可能包含<Description>或其他属性（在<AttributeList>下）以帮助选择。客户端必须为任何管理操作选择主服务站点。
2. Locate the responsible server within the service site.
2. 在服务站点中找到负责的服务器。
This can be done as follows: Convert every ASCII character in the handle to its upper case. Calculate the MD5 hash of the converted handle string according to the <HashOption> given in the HS_SITE value. Take the last 4 bytes of the hash result as a signed integer. Modulo the absolute value of the integer by the <NumOfServer> given in the HS_SITE value. The result is the sequence number of the <ServerRecord> listed in the HS_SITE value. For example, if the result of the modulation is 2, the third <ServerRecord> listed in the <HS_SITE> should be selected. The <ServerRecord> defines the responsible handle server for the given handle.
这可以按如下方式完成：将句柄中的每个ASCII字符转换为大写。根据HS_SITE值中给定的<HashOption>计算转换句柄字符串的MD5哈希。将散列结果的最后4个字节作为有符号整数。通过HS_站点值中给定的<NumOfServer>对整数的绝对值进行模化。结果是HS_站点值中列出的<ServerRecord>的序列号。例如，如果调制结果为2，则应选择<HS_站点>中列出的第三个<ServerRecord>。<ServerRecord>为给定句柄定义负责的句柄服务器。
A query operation consists of a client sending a query request to the responsible handle server and the server returning the query result to the client. Query requests are used to retrieve handle values assigned to any given handle.
查询操作包括客户端向负责的句柄服务器发送查询请求，服务器向客户端返回查询结果。查询请求用于检索分配给任何给定句柄的句柄值。
The Message Header of any query request must set its <OpCode> to OC_RESOLUTION (defined in section 2.2.2.1) and <ResponseCode> to 0.
任何查询请求的消息头必须将其<OpCode>设置为OC_分辨率（在第2.2.2.1节中定义），并将<ResponseCode>设置为0。
The Message Body for any query request is defined as follows:
任何查询请求的消息体定义如下：
<Message Body of Query Request> ::= <Handle>
<IndexList>
<TypeList>
<Message Body of Query Request> ::= <Handle>
<IndexList>
<TypeList>
where
哪里
<Handle> A UTF8-String (as defined in section 2.1.4) that specifies the handle to be resolved.
<Handle>指定要解析的句柄的UTF8字符串（如第2.1.4节所定义）。
<IndexList> A 4-byte unsigned integer followed by an array of 4-byte unsigned integers. The first integer indicates the number of integers in the integer array. Each number in the integer array is a handle value index and refers to a handle value to be retrieved. The client sets the first integer to zero (followed by an empty array) to ask for all the handle values regardless of their index.
<IndexList>一个4字节无符号整数，后跟一个4字节无符号整数数组。第一个整数表示整数数组中的整数数。整数数组中的每个数字都是句柄值索引，并引用要检索的句柄值。客户端将第一个整数设置为零（后面是一个空数组），以请求所有句柄值，而不管它们的索引如何。
<TypeList> A 4-byte unsigned integer followed by a list of UTF8- Strings. The first integer indicates the number of UTF8-Strings in the list that follows. Each UTF8-String in the list specifies a data type. This tells the server to return all handle values whose data type is listed in the list. If a UTF8-String ends with the '.' (0x2E) character, the server must return all handle values whose data type is under the type hierarchy specified in the UTF8-String. The <TypeList> may contain no UTF8-String if the first integer is 0. In this case, the server must return all handle values regardless of their data type.
<TypeList>后跟UTF8字符串列表的4字节无符号整数。第一个整数表示下面列表中UTF8字符串的数量。列表中的每个UTF8字符串指定一种数据类型。这告诉服务器返回其数据类型在列表中列出的所有句柄值。如果UTF8字符串以“.”（0x2E）字符结尾，则服务器必须返回其数据类型位于UTF8字符串中指定的类型层次结构下的所有句柄值。如果第一个整数为0，<TypeList>可能不包含UTF8字符串。在这种情况下，服务器必须返回所有句柄值，而不管其数据类型如何。
If a query request does not specify any index or data type and the PO flag (in the Message Header) is set, the server will return all the handle values that have the PUBLIC_READ permission. Clients can also send queries without the PO flag set. In this case, the server will return all the handle values with PUBLIC_READ permission and all the handle values with ADMIN_READ permission. If the query requests a specific handle value via the value index and the value does not have PUBLIC_READ permission, the server should accept the request (and authenticate the client) even if the request has its PO flag set.
如果查询请求未指定任何索引或数据类型，并且设置了PO标志（在消息头中），则服务器将返回具有PUBLIC_READ权限的所有句柄值。客户端也可以发送不设置PO标志的查询。在这种情况下，服务器将返回具有PUBLIC_READ权限的所有句柄值和具有ADMIN_READ权限的所有句柄值。如果查询通过值索引请求特定的句柄值，并且该值没有PUBLIC_READ权限，则即使请求设置了PO标志，服务器也应接受该请求（并对客户端进行身份验证）。
If a query consists of a non-empty <IndexList> but an empty <TypeList>, the server should only return those handle values whose indexes are listed in the <IndexList>. Likewise, if a query consists of a non-empty <TypeList> but an empty <IndexList>, the server should only return those handle values whose data types are listed in the <TypeList>.
如果查询由非空的<IndexList>但为空的<TypeList>组成，则服务器应仅返回索引列在<IndexList>中的句柄值。同样，如果查询由非空的<TypeList>组成，但由空的<IndexList>组成，则服务器应仅返回其数据类型在<TypeList>中列出的句柄值。
When both <IndexList> and <TypeList> fields are non-empty, the server should return all handle values whose indexes are listed in the <IndexList> AND all handle values whose data types are listed in the <TypeList>.
当<IndexList>和<TypeList>字段均为非空时，服务器应返回索引列在<IndexList>中的所有句柄值和数据类型列在<TypeList>中的所有句柄值。
The Message Header of any query response must set its <OpCode> to OC_RESOLUTION. A successful query response must set its <ResponseCode> to RC_SUCCESS.
任何查询响应的消息头都必须将其<OpCode>设置为OC\U分辨率。成功的查询响应必须将其<ResponseCode>设置为RC\u SUCCESS。
The message body of the successful query response is defined as follows:
成功查询响应的消息体定义如下：
<Message Body of Successful Query Response> ::= [<RequestDigest>]
<Handle>
<ValueList>
<Message Body of Successful Query Response> ::= [<RequestDigest>]
<Handle>
<ValueList>
where
哪里
<RequestDigest> Optional field as defined in section 2.2.3.
<RequestDigest>第2.2.3节中定义的可选字段。
<Handle> A UTF8-String that specifies the handle queried by the client.
<Handle>指定客户端查询的句柄的UTF8字符串。
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer specifies the number of handle values in the list. The encoding of each handle value follows the specification given in [2] (see section 3.1). The integer is set to zero if there is no handle value that satisfies the query.
<ValueList>后跟句柄值列表的4字节无符号整数。整数指定列表中句柄值的数目。每个句柄值的编码遵循[2]中给出的规范（见第3.1节）。如果没有满足查询的句柄值，则将整数设置为零。
If a server cannot fulfill a client's request, it must return an error message. The general format for any error message from the server is specified in section 3.3 of this document.
如果服务器无法满足客户端的请求，则必须返回错误消息。本文件第3.3节规定了来自服务器的任何错误消息的通用格式。
For example, a server must return an error message if the queried handle does not exist in its database. The error message will have an empty message body and have its <ResponseCode> set to RC_HANDLE_NOT_FOUND.
例如，如果查询的句柄在其数据库中不存在，则服务器必须返回错误消息。错误消息将有一个空消息体，并将其<ResponseCode>设置为RC\u HANDLE\u NOT\u FOUND。
Note that a server should NOT return an RC_HANDLE_NOT_FOUND message if the server is not responsible for the handle being queried. It is possible that the queried handle exists but is managed by another handle server (under some other handle service). When this happens, the server should either send a service referral (see section 3.4) or simply return an error message with <ResponseCode> set to RC_SERVER_NOT_RESP.
请注意，如果服务器不负责查询句柄，则服务器不应返回RC_HANDLE_NOT_FOUND消息。查询的句柄可能存在，但由另一个句柄服务器（在某个其他句柄服务下）管理。发生这种情况时，服务器应该发送服务引用（参见第3.4节），或者只返回一条错误消息，并将<ResponseCode>设置为RC\u server\u NOT\u RESP。
The server may return an error message with <ResponseCode> set to RC_SERVER_BUSY if the server is too busy to process the request. Like RC_HANDLE_NOT_FOUND, an RC_SERVER_BUSY message also has an empty message body.
如果服务器太忙而无法处理请求，则服务器可能会返回一条错误消息，并将<ResponseCode>设置为RC_server_BUSY。与RC_HANDLE_NOT_FOUND一样，RC_SERVER_BUSY消息也有一个空消息体。
Servers should return an RC_ACCESS_DENIED message if the request asks for a specific handle value (via the handle value index) that has neither PUBLIC_READ nor ADMIN_READ permission.
如果请求请求一个既没有公共读取权限也没有管理员读取权限的特定句柄值（通过句柄值索引），则服务器应返回一条RC\u ACCESS\u DENIED消息。
A handle Server may ask its client to authenticate itself as the handle administrator during the resolution. This happens if any handle value in query has ADMIN_READ permission, but no PUBLIC_READ permission. Details of client authentication are described later in this document.
在解析过程中，句柄服务器可能会要求其客户端将其自身验证为句柄管理员。如果查询中的任何句柄值具有ADMIN_READ权限，但没有PUBLIC_READ权限，则会发生这种情况。客户机身份验证的详细信息将在本文档后面介绍。
A handle server will return an error message if it encounters an error when processing a request. Any error response from the server must maintain the same <OpCode> (in the message header) as the one in the original request. Each error condition is identified by a unique <ResponseCode> as defined in section 2.2.2.2 of this document.
如果处理请求时遇到错误，句柄服务器将返回错误消息。来自服务器的任何错误响应必须与原始请求中的响应保持相同的<OpCode>（在消息头中）。每个错误条件由本文件第2.2.2.2节中定义的唯一<ResponseCode>标识。
The Message Body of an error message may be empty. Otherwise it consists of the following data fields (unless otherwise specified):
错误消息的消息正文可能为空。否则，它由以下数据字段组成（除非另有规定）：
<Message Body of Error Response from Server> ::= [<RequestDigest>]
<ErrorMessage>
[ <IndexList> ]
<Message Body of Error Response from Server> ::= [<RequestDigest>]
<ErrorMessage>
[ <IndexList> ]
where
哪里
<RequestDigest> Optional field as defined in section 2.2.3.
<RequestDigest>第2.2.3节中定义的可选字段。
<ErrorMessage> A UTF8-String that explains the error.
<ErrorMessage>解释错误的UTF8字符串。
<IndexList> An optional field. When not empty, it consists of a 4-byte unsigned integer followed by a list of handle value indexes. The first integer indicates the number of indexes in the list. Each index in the list is a 4-byte unsigned integer that refers to a handle value that contributed to the error. An example would be a server that is asked to add three handle values, with indexes 1, 2, and 3, and handle values with indexes of 1 and 2 already in existence. In this case, the server could return an error message with <REsponseCode> set to RC_VALUE_ALREADY_EXIST and add index 1 and 2 to the <IndexList>. Note that the server is not obligated to return the complete list of handle value indexes that may have caused the error.
<IndexList>可选字段。如果不为空，则它由一个4字节无符号整数后跟一个句柄值索引列表组成。第一个整数表示列表中的索引数。列表中的每个索引都是一个4字节无符号整数，它引用了导致错误的句柄值。例如，要求服务器添加三个句柄值（索引为1、2和3），并添加索引为1和2的句柄值。在这种情况下，服务器可能返回一条错误消息，将<REsponseCode>设置为RC\u VALUE\u已经存在，并将索引1和2添加到<IndexList>。请注意，服务器没有义务返回可能导致错误的句柄值索引的完整列表。
A handle server may receive requests for handles that are managed by some other handle server or service. When this happens, the server has the option to either return a referral message that directs the client to the proper handle service, or simply return an error message with <ResponseCode> set to RC_SERVER_NOT_RESP. Service referral also happens when ownership of handles moves from one handle service to another. It may also be used by any local handle service to delegate its service into multiple service layers.
句柄服务器可以接收由其他句柄服务器或服务管理的句柄请求。发生这种情况时，服务器可以选择返回一条将客户端指向正确句柄服务的引用消息，或者只返回一条设置为RC_server_NOT_RESP的<ResponseCode>的错误消息。当句柄的所有权从一个句柄服务转移到另一个句柄服务时，也会发生服务引用。任何本地句柄服务也可以使用它将其服务委托给多个服务层。
The Message Header of a service referral must maintain the same <OpCode> as the one in the original request and set its <ResponseCode> to RC_SERVICE_REFERRAL.
服务引用的消息头必须与原始请求中的消息头保持相同的<OpCode>，并将其<ResponseCode>设置为RC_service_Reference。
The Message Body of any service referral is defined as follows:
任何服务引用的消息正文定义如下：
<Message Body of Service Referral> ::= [ <RequestDigest> ]
<ReferralHandle>
[ <ValueList> ]
<Message Body of Service Referral> ::= [ <RequestDigest> ]
<ReferralHandle>
[ <ValueList> ]
where
哪里
<RequestDigest> Optional field as defined in section 2.2.3.
<RequestDigest>第2.2.3节中定义的可选字段。
<ReferralHandle> A UTF8-String that identifies the handle (e.g., a service handle) that maintains the referral information (i.e., the service information of the handle service in which this refers). If the <ReferralHandle> is set to "0.NA/0.NA", it is referring the client to the GHR.
<ReferralHandle>一个UTF8字符串，用于标识维护引用信息（即引用的句柄服务的服务信息）的句柄（例如，服务句柄）。如果<ReferralHandle>设置为“0.NA/0.NA”，则它将客户机引用到GHR。
<ValueList> An optional field that must be empty if the <ReferralHandle> is provided. When not empty, it consists of a 4-byte unsigned integer, followed by a list of HS_SITE values. The integer specifies the number of HS_SITE values in the list.
<ValueList>如果提供了<ReferralHandle>，则可选字段必须为空。如果不为空，则它由一个4字节无符号整数组成，后跟一个HS_站点值列表。整数指定列表中HS_站点值的数量。
Unlike regular query responses that may consist of handle values of any data type, a service referral can only have zero or more HS_SITE values in its <ValueList>. The <ReferralHandle> may contain an empty UTF8-String if the HS_SITE values in the <ValueList> are not maintained by any handle.
与可能由任何数据类型的句柄值组成的常规查询响应不同，服务引用在其<ValueList>中只能有零个或多个HS_站点值。如果<ValueList>中的HS\U站点值未由任何句柄维护，则<ReferralHandle>可能包含空UTF8字符串。
Care must be taken by clients to avoid any loops caused by service referrals. It is also the client's responsibility to authenticate the service information obtained from the service referral. A client should always use its own copy of the GHR service information if the <ReferralHandle> is set to "0.NA/0.NA".
客户必须小心谨慎，避免由服务推荐引起的任何循环。客户还应负责验证从服务推荐中获得的服务信息。如果<ReferralHandle>设置为“0.NA/0.NA”，则客户端应始终使用自己的GHR服务信息副本。
Clients are asked to authenticate themselves as handle administrators when querying for any handle value with ADMIN_READ but no PUBLIC_READ permission. Client authentication is also required for any handle administration requests that require administrator privileges. This includes adding, removing, or modifying handles or handle values.
当查询具有ADMIN_READ但没有PUBLIC_READ权限的任何句柄值时，要求客户端将自己验证为句柄管理员。任何需要管理员权限的句柄管理请求也需要客户端身份验证。这包括添加、删除或修改句柄或句柄值。
Client authentication consists of multiple messages exchanged between the client and server. Such messages include the challenge from the server to the client to authenticate the client, the challenge-response from the client in response to the server's challenge, and
客户端身份验证由客户端和服务器之间交换的多条消息组成。此类消息包括服务器向客户端发出的验证客户端的质询、客户端响应服务器质询的质询响应，以及
the verification request and response message if secret key authentication takes place. Messages exchanged during the authentication are correlated via a unique <SessionId> assigned by the server. For each authentication session, the server needs to maintain the state information that includes the server's challenge, the challenge-response from the client, as well as the original client request.
如果进行了密钥验证，则验证请求和响应消息。身份验证期间交换的消息通过服务器分配的唯一<SessionId>进行关联。对于每个身份验证会话，服务器需要维护状态信息，其中包括服务器的质询、来自客户端的质询响应以及原始客户端请求。
The authentication starts with a response message from the server that contains a challenge to the client. The client must respond to the challenge with a challenge-response message. The server validates the challenge-response, either by verifying the digital signature inside the challenge-response, or by sending a verification request to another handle server (herein referred to as the verification server), that maintains the secret key for the administrator. The purpose of the challenge and the challenge-response is to prove to the server that the client possesses the private key (or the secret key) of the handle administrator. If the authentication fails, an error response will be sent back with the <ResponseCode> set to RC_AUTHEN_FAILED.
身份验证从服务器发出的响应消息开始，该消息包含对客户端的质询。客户端必须使用质询响应消息响应质询。服务器通过验证质询响应内的数字签名，或通过向另一个句柄服务器（此处称为验证服务器）发送验证请求来验证质询响应，该句柄服务器为管理员维护密钥。质询和质询响应的目的是向服务器证明客户端拥有句柄管理员的私钥（或密钥）。如果身份验证失败，将发送一个错误响应，并将<ResponseCode>设置为RC\u AUTHEN\u FAILED。
Upon successful client authentication, the server must also make sure that the administrator is authorized for the request. If the administrator has sufficient privileges, the server will process the request and send back the result. If the administrator does not have sufficient privileges, the server will return an error message with <ResponseCode> set to RC_NOT_AUTHORIZED.
成功进行客户端身份验证后，服务器还必须确保管理员已获得请求的授权。如果管理员有足够的权限，服务器将处理请求并返回结果。如果管理员没有足够的权限，服务器将返回一条错误消息，并将<ResponseCode>设置为RC\u not\u AUTHORIZED。
The following sections provide details of each message exchanged during the authentication process.
以下各节提供了身份验证过程中交换的每条消息的详细信息。
The Message Header of the CHALLENGE must keep the same <OpCode> as the original request and set the <ResponseCode> to RC_AUTH_NEEDED. The server must assign a non-zero unique <SessionId> in the Message Envelope to keep track of the authentication. It must also set the RD flag of the <OpFlag> (see section 2.2.2.3) in the Message Header, regardless of whether the original request had the RD bit set or not.
质询的消息头必须与原始请求保持相同的<OpCode>，并将<ResponseCode>设置为所需的RC_AUTH_。服务器必须在消息信封中分配非零唯一<SessionId>，以跟踪身份验证。它还必须在消息头中设置<OpFlag>（参见第2.2.2.3节）的RD标志，无论原始请求是否设置了RD位。
The Message Body of the server's CHALLENGE is defined as follows:
服务器质询的消息体定义如下：
<Message Body of Server's Challenge> ::= <RequestDigest>
<Nonce>
where
<Message Body of Server's Challenge> ::= <RequestDigest>
<Nonce>
where
<RequestDigest> Message Digest of the request message, as defined in section 2.2.3.
<RequestDigest>第2.2.3节中定义的请求消息的消息摘要。
<Nonce> A 4-byte unsigned integer followed by a random string generated by the server via a secure random number generator. The integer specifies the number of octets in the random string. The size of the random string should be no less than 20 octets.
<Nonce>一个4字节无符号整数，后跟服务器通过安全随机数生成器生成的随机字符串。整数指定随机字符串中的八位字节数。随机字符串的大小应不小于20个八位字节。
Note that the server will not sign the challenge if the client did not request the server to do so. If the client worries about whether it is speaking to the right server, it may ask the server to sign the <Challenge>. If the client requested the server to sign the <Challenge> but failed to validate the server's signature, the client should discard the server's response and reissue the request to the server.
请注意，如果客户端没有请求服务器签名，服务器将不会对质询进行签名。如果客户端担心是否与正确的服务器对话，它可能会要求服务器签署<Challenge>。如果客户端请求服务器对<Challenge>进行签名，但未能验证服务器的签名，则客户端应放弃服务器的响应，并向服务器重新发出请求。
The Message Header of the CHALLENGE_RESPONSE must set its <OpCode> to OC_CHALLENGE_RESPONSE and its <ResponseCode> to 0. It must also keep the same <SessionId> (in the Message Envelope) as specified in the challenge from the server.
质询_响应的消息头必须将其<OpCode>设置为OC_质询_响应，并将其<ResponseCode>设置为0。它还必须保持与服务器质询中指定的相同的<SessionId>（在消息信封中）。
The Message Body of the CHALLENGE_RESPONSE request is defines as follows:
质询_响应请求的消息体定义如下：
<Message Body of CHALLENGE_RESPONSE> ::= <AuthenticationType>
<KeyHandle>
<KeyIndex>
<ChallengeResponse>
<Message Body of CHALLENGE_RESPONSE> ::= <AuthenticationType>
<KeyHandle>
<KeyIndex>
<ChallengeResponse>
where
哪里
<AuthenticationType> A UTF8-String that identifies the type of authentication key used by the client. For example, the field is set to "HS_SECKEY" if the client chooses to use a secret key for its authentication. The field is set to "HS_PUBKEY" if a public key is used instead.
<AuthenticationType>标识客户端使用的身份验证密钥类型的UTF8字符串。例如，如果客户端选择使用密钥进行身份验证，则该字段设置为“HS_SECKEY”。如果使用公钥，则该字段将设置为“HS_PUBKEY”。
<KeyHandle> A UTF8-String that identifies the handle that holds the public or secret key of the handle administrator.
<KeyHandle>一个UTF8字符串，用于标识保存句柄管理员公钥或密钥的句柄。
<KeyIndex> A 4-byte unsigned integer that specifies the index of the handle value (of the <KeyHandle>) that holds the public or secret key of the administrator.
<KeyIndex>一个4字节无符号整数，用于指定保存管理员公钥或密钥的句柄值（属于<KeyHandle>）的索引。
<ChallengeResponse> Contains either the Message Authentication Code (MAC) or the digital signature over the challenge from the server. If the <AuthenticationType> is "HS_SECKEY", the <ChallengeResponse> consists of an octet followed by the MAC. The octet identifies the algorithm used to generate the MAC. For example, if the first octet is set to 0x01, the MAC is generated by
<ChallengeResponse>包含来自服务器的质询的消息身份验证码（MAC）或数字签名。如果<AuthenticationType>是“HS_SECKEY”，<ChallengeResponse>由一个八位组和MAC组成。八位组标识用于生成MAC的算法。例如，如果第一个八位字节设置为0x01，则MAC由
MD5_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
MD5_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
where the <SecretKey> is the administrator's secret key
referenced by the <KeyHandle> and <KeyIndex>. The
<ServerChallenge> is the Message Body portion of the
server's challenge. If the first octet in the
<ChallengeResponse> is set to 0x02, the MAC is generated
using
where the <SecretKey> is the administrator's secret key
referenced by the <KeyHandle> and <KeyIndex>. The
<ServerChallenge> is the Message Body portion of the
server's challenge. If the first octet in the
<ChallengeResponse> is set to 0x02, the MAC is generated
using
SHA-1_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
SHA-1_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
A more secure approach is to use HMAC [17] for the <ChallengeResponse>. The HMAC can be generated using the <SecretKey> and <ServerChallenge>. A <ChallengeResponse> with its first octet set to 0x11 indicates that the HMAC is generated using the MD5 algorithm. Likewise, a <ChallengeResponse> with its first octet set to 0x12 indicates that the HMAC is generated using the SHA-1 algorithm.
更安全的方法是将HMAC[17]用于<ChallengeResponse>。可以使用<SecretKey>和<ServerChallenge>生成HMAC。第一个八位组设置为0x11的<ChallengeResponse>表示HMAC是使用MD5算法生成的。同样，第一个八位组设置为0x12的<ChallengeResponse>表示HMAC是使用SHA-1算法生成的。
If the <AuthenticationType> is "HS_PUBKEY", the <ChallengeResponse> contains the digital signature over the Message Body portion of the server's challenge. The signature is generated in two steps: First, a one-way hash value is computed over the blob that is to be signed. Second, the hash value is signed using the private key. The signature consists of a UTF8-String that specifies the digest algorithm used for the signature, followed by the signature over the server's challenge. The <KeyHandle> and
如果<AuthenticationType>是“HS_PUBKEY”，则<ChallengeResponse>包含服务器质询消息体部分的数字签名。签名分两步生成：首先，对要签名的blob计算单向散列值。其次，使用私钥对哈希值进行签名。签名由一个UTF8字符串组成，该字符串指定用于签名的摘要算法，然后是服务器质询上的签名。<KeyHandle>和
<KeyIndex> refers to the administrator's public key that can be used to verify the signature.
<KeyIndex>指可用于验证签名的管理员公钥。
Handle administrators are defined in terms of HS_ADMIN values assigned to the handle. Each HS_ADMIN value defines the set of privileges granted to the administrator. It also provides the reference to the authentication key that can be used to authenticate the administrator. The reference can be made directly if the <AdminRef> field of the HS_ADMIN value refers to the handle value that holds the authentication key. Indirect reference to the authentication key can also be made via administrator groups. In this case, the <AdminRef> field may refer to a handle value of type HS_VLIST. An HS_VLIST value defines an administrator group via a list of handle value references, each of which refers to the authentication key of a handle administrator.
句柄管理员是根据分配给句柄的HS_ADMIN值定义的。每个HS_ADMIN值定义授予管理员的权限集。它还提供对可用于对管理员进行身份验证的身份验证密钥的引用。如果HS_ADMIN值的<AdminRef>字段引用保存身份验证密钥的句柄值，则可以直接进行引用。还可以通过管理员组间接引用身份验证密钥。在这种情况下，<AdminRef>字段可能引用HS_VLIST类型的句柄值。HS_VLIST值通过句柄值引用列表定义管理员组，每个句柄值引用引用引用句柄管理员的身份验证密钥。
For handles with multiple HS_ADMIN values, the server will have to check each of those with sufficient privileges to see if its <AdminRef> field matches the <KeyHandle> and <KeyIndex>. If no match is found, but there are administrator groups defined, the server must check if the <KeyHandle> and <KeyIndex> belong to any of the administrator groups that have sufficient privileges. An administrator group may contain another administrator group as a member. Servers must be careful to avoid infinite loops when navigating these groups.
对于具有多个HS_ADMIN值的句柄，服务器必须检查每个具有足够权限的句柄，以查看其<AdminRef>字段是否与<KeyHandle>和<KeyIndex>匹配。如果未找到匹配项，但定义了管理员组，则服务器必须检查<KeyHandle>和<KeyIndex>是否属于任何具有足够权限的管理员组。管理员组可以包含另一个管理员组作为成员。在浏览这些组时，服务器必须小心避免无限循环。
If the <KeyHandle> and <KeyIndex> are not referenced by any of the HS_ADMIN values, or the administrator group that has sufficient privileges, the server will return an error message with <ResponseCode> set to RC_NOT_AUTHORIZED. Otherwise, the server will continue to authenticate the client as follows:
如果<KeyHandle>和<KeyIndex>未被任何HS_管理值引用，或没有足够权限的管理员组引用，服务器将返回一条错误消息，并将<ResponseCode>设置为RC_not_AUTHORIZED。否则，服务器将继续对客户端进行身份验证，如下所示：
If the <AuthenticationType> is "HS_PUBKEY", the server will retrieve the administrator's public key based on the <KeyHandle> and <KeyIndex>. The public key can be used to verify the <ChallengeResponse> against the server's <Challenge>. If the <ChallengeResponse> matches the <Challenge>, the server will continue to process the original request and return the result. Otherwise, the server will return an error message with <ResponseCode> set to RC_AUTHENTICATION_FAILED.
如果<AuthenticationType>是“HS_PUBKEY”，服务器将根据<KeyHandle>和<KeyIndex>检索管理员的公钥。公钥可用于根据服务器的<challenger>验证<ChallengeResponse>。如果<ChallengeResponse>与<challenger>匹配，服务器将继续处理原始请求并返回结果。否则，服务器将返回一条错误消息，其中<ResponseCode>设置为RC\u AUTHENTICATION\u FAILED。
If the <AuthenticationType> is "HS_SECKEY", the server will have to send a verification request to the verification server; that is, the handle server that manages the handle referenced by the <KeyHandle>. The verification request and its response are defined in the following sections. The verification server will verify the <ChallengeResponse> against the <Challenge> on behalf of the handle server.
如果<AuthenticationType>为“HS_SECKEY”，则服务器必须向验证服务器发送验证请求；即，管理<KeyHandle>引用的句柄的句柄服务器。验证请求及其响应在以下章节中定义。验证服务器将代表句柄服务器根据<challenger>验证<ChallengeResponse>。
The message header of the VERIFICATION_REQUEST must set its <OpCode> to OC_VERIFY_CHALLENGE and the <ResponseCode> to 0.
验证请求的消息头必须将其<OpCode>设置为OC\u VERIFY\u CHALLENGE，并将<ResponseCode>设置为0。
The message body of the Verification-Request is defined as follows:
验证请求的消息体定义如下：
<Message Body of VERIFICATION_REQUEST> ::= <KeyHandle>
<KeyIndex>
<Challenge>
<ChallengeResponse>
<Message Body of VERIFICATION_REQUEST> ::= <KeyHandle>
<KeyIndex>
<Challenge>
<ChallengeResponse>
where
哪里
<KeyHandle> A UTF8-String that refers to the handle that holds the secret key of the administrator.
<KeyHandle>一个UTF8字符串，它引用保存管理员密钥的句柄。
<KeyIndex> A 4-byte unsigned integer that is the index of the handle value that holds the secret key of the administrator.
<KeyIndex>一个4字节无符号整数，它是保存管理员密钥的句柄值的索引。
<Challenge> The message body of the server's challenge, as described in section 3.5.1.
<Challenge>服务器质询的消息体，如第3.5.1节所述。
<ChallengeResponse> The <ChallengeResponse> from the client in response to the server's <Challenge>, as defined in section 3.5.2.
<ChallengeResponse>客户端响应服务器的<ChallengeResponse>，如第3.5.2节所定义。
Any Challenge-Response Verification-Request must set its CT bit in the message header. This is to ensure that the verification server will sign the Verification-Response as specified in the next section.
任何质询响应验证请求必须在消息头中设置其CT位。这是为了确保验证服务器将按照下一节中的规定对验证响应进行签名。
The Verification-Response tells the requesting handle server whether the <ChallengeResponse> matches the <Challenge> in the Verification-Request.
验证响应告知请求句柄服务器<ChallengeResponse>是否与验证请求中的<Challenge>匹配。
The Message Header of the Verification-Response must set its <ResponseCode> to RC_SUCCESS whether or not the <ChallengeResponse> matches the <Challenge>. The RD flag in the <OpFlag> field should also be set (to 1) since the <RequestDigist> will be mandatory in the Message Body.
无论<ChallengeResponse>是否与<Challenge>匹配，验证响应的消息头必须将其<ResponseCode>设置为RC_SUCCESS。<OpFlag>字段中的RD标志也应设置为（1），因为<RequestDigist>在消息体中是必需的。
The Message Body of the Verification-Response is defined as follows:
验证响应的消息体定义如下：
<Challenge-Response Verification-Response>
::= <RequestDigest>
<VerificationResult>
where
<Challenge-Response Verification-Response>
::= <RequestDigest>
<VerificationResult>
where
<RequestDigest> Contains the message digest of the Verification-Request.
<RequestDigest>包含验证请求的消息摘要。
<VerificationResult> An octet that is set to 1 if the <ChallengeResponse> matches the <Challenge>. Otherwise it must be set to 0.
<VerificationResult>如果<ChallengeResponse>与<Challenge>匹配，则设置为1的八位字节。否则，它必须设置为0。
The verification server may return an error with <ResponseCode> set to RC_AUTHEN_FAILED if it cannot perform the verification (e.g., the <KeyHandle> does not exist, or the <KeyHandle> and <KeyIndex> refer to an invalid handle value). When this happens, the server that performs the client authentication should relay the same error message back to the client.
如果验证服务器无法执行验证（例如，<KeyHandle>不存在，或者<KeyHandle>和<KeyIndex>引用了无效的句柄值），则验证服务器可能返回一个错误，并将<ResponseCode>设置为RC_AUTHEN_FAILED。发生这种情况时，执行客户端身份验证的服务器应将相同的错误消息中继回客户端。
The Handle System protocol supports a set of handle administration functions that include adding, deleting, and modifying handles or handle values. Before fulfilling any administration request, the server must authenticate the client as the handle administrator that is authorized for the administrative operation. Handle administration can only be carried out by the primary handle server.
Handle系统协议支持一组句柄管理功能，包括添加、删除和修改句柄或句柄值。在完成任何管理请求之前，服务器必须将客户端验证为有权执行管理操作的句柄管理员。句柄管理只能由主句柄服务器执行。
Clients add values to existing handles by sending ADD_VALUE requests to the responsible handle server. The Message Header of the ADD_VALUE request must set its <OpCode> to OC_ADD_VALUE.
客户端通过向负责的句柄服务器发送添加值请求，向现有句柄添加值。ADD_VALUE请求的消息头必须将其<OpCode>设置为OC_ADD_VALUE。
The Message Body of the ADD_VALUE request is encoded as follows:
ADD_VALUE请求的消息体编码如下：
<Message Body of ADD_VALUE Request> ::= <Handle>
<ValueList>
<Message Body of ADD_VALUE Request> ::= <Handle>
<ValueList>
where
哪里
<Handle> A UTF8-String that specifies the handle.
<Handle>指定句柄的UTF8字符串。
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer indicates the number of handle values in the list.
<ValueList>后跟句柄值列表的4字节无符号整数。整数表示列表中句柄值的数目。
The server that receives the ADD_VALUE request must first authenticate the client as the administrator with the ADD_VALUE privilege. Upon successful authentication, the server will proceed to add each value in the <ValueList> to the <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
接收附加值请求的服务器必须首先使用附加值权限将客户端验证为管理员。验证成功后，服务器将继续将<ValueList>中的每个值添加到<Handle>。如果成功，服务器将向客户端返回一条RC_成功消息。
Each ADD_VALUE request must be carried out as a transaction. If adding any value in the <ValueList> raises an error, the entire operation must be rolled back. For any failed ADD_VALUE request, none of the values in the <ValueList> should be added to the <Handle>. The server must also send a response to the client that explains the error. For example, if a value in the <ValueList> has the same index as one of the existing handle values, the server will return an error message that has the <ResponseCode> set to RC_VALUE_ALREADY_EXISTS.
每个增值请求都必须作为事务执行。如果在<ValueList>中添加任何值会引发错误，则必须回滚整个操作。对于任何失败的添加值请求，<ValueList>中的任何值都不应添加到<Handle>。服务器还必须向客户端发送解释错误的响应。例如，如果<ValueList>中的值与现有句柄值之一具有相同的索引，则服务器将返回一条错误消息，其中<ResponseCode>设置为RC\u value\u已经存在。
ADD_VALUE requests can also be used to add handle administrators. This happens if the <ValueList> in the ADD_VALUE request contains any HS_ADMIN values. The server must authenticate the client as an administrator with the ADD_ADMIN privilege before fulfilling such requests.
添加值请求也可用于添加句柄管理员。如果ADD_VALUE请求中的<ValueList>包含任何HS_ADMIN值，则会发生这种情况。在完成此类请求之前，服务器必须使用ADD_ADMIN权限以管理员身份验证客户端。
An ADD_VALUE request will result in an error if the requested handle does not exist. When this happens, the server will return an error message with <ResponseCode> set to RC_HANDLE_NOT_EXIST.
如果请求的句柄不存在，则添加值请求将导致错误。发生这种情况时，服务器将返回一条错误消息，并将<ResponseCode>设置为RC\u HANDLE\u NOT\u EXIST。
Clients remove existing handle values by sending REMOVE_VALUE requests to the responsible handle server. The Message Header of the REMOVE_VALUE request must set its <OpCode> to OC_REMOVE_VALUE.
客户端通过向负责的句柄服务器发送删除值请求来删除现有句柄值。REMOVE_VALUE请求的消息头必须将其<OpCode>设置为OC_REMOVE_VALUE。
The Message Body of any REMOVE_VALUE request is encoded as follows:
任何REMOVE_值请求的消息体编码如下：
<Message Body of REMOVE_VALUE Request> ::= <Handle>
<IndexList>
<Message Body of REMOVE_VALUE Request> ::= <Handle>
<IndexList>
where
哪里
<Handle> A UTF8-String that specifies the handle whose value(s) needs to be removed.
<Handle>一个UTF8字符串，指定需要删除其值的句柄。
<IndexList> A 4-byte unsigned integer followed by a list of handle value indexes. Each index refers to a handle value to be removed from the <Handle>. The integer specifies the number of indexes in the list. Each index is also encoded as a 4-byte unsigned integer.
<IndexList>后跟句柄值索引列表的4字节无符号整数。每个索引都引用要从<handle>中删除的句柄值。整数指定列表中的索引数。每个索引也被编码为4字节无符号整数。
The server that receives the REMOVE_VALUE request must first authenticate the client as the administrator with the REMOVE VALUE privilege. Upon successful authentication, the server will proceed to remove the handle values specified in the <IndexList> from the <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
接收删除值请求的服务器必须首先以具有删除值权限的管理员身份验证客户端。身份验证成功后，服务器将继续从<handle>中删除<IndexList>中指定的句柄值。如果成功，服务器将向客户端返回一条RC_成功消息。
Each REMOVE_VALUE request must be carried out as a transaction. If removing any value specified in the <IndexList> raises an error, the entire operation must be rolled back. For any failed REMOVE_VALUE request, none of values referenced in the <IndexList> should be removed from the <Handle>. The server must also send a response to the client that explains the error. For example, attempts to remove any handle value with neither PUB_WRITE nor ADMIN_WRITE permission will result in an RC_ACCESS_DENIED error. Note that a REMOVE_VALUE request asking to remove a non-existing handle value will not be treated as an error.
每个删除值请求必须作为事务执行。如果删除<IndexList>中指定的任何值会引发错误，则必须回滚整个操作。对于任何失败的删除值请求，都不应从<Handle>中删除<IndexList>中引用的值。服务器还必须向客户端发送解释错误的响应。例如，尝试删除既没有发布写入权限也没有管理写入权限的任何句柄值将导致RC\U访问被拒绝错误。请注意，请求删除不存在的句柄值的REMOVE_VALUE请求不会被视为错误。
REMOVE_VALUE requests can also be used to remove handle administrators. This happens if any of the indexes in the <IndexList> refer to an HS_ADMIN value. Servers must authenticate the client as an administrator with the REMOVE_ADMIN privilege before fulfilling such requests.
移除值请求也可用于移除句柄管理员。如果<IndexList>中的任何索引引用HS_ADMIN值，就会发生这种情况。服务器必须使用REMOVE_ADMIN权限以管理员身份验证客户端，然后才能满足此类请求。
Clients can make modifications to an existing handle value by sending MODIFY_VALUE requests to the responsible handle server. The Message Header of the MODIFY_VALUE request must set its <OpCode> to OC_MODIFY_VALUE.
客户端可以通过向负责的句柄服务器发送修改值请求来修改现有句柄值。MODIFY_VALUE请求的消息头必须将其<OpCode>设置为OC_MODIFY_VALUE。
The Message Body of any MODIFY_VALUE request is defined as follows:
任何修改_值请求的消息体定义如下：
<Message Body of MODIFY_VALUE Response> ::= <Handle>
<ValueList>
<Message Body of MODIFY_VALUE Response> ::= <Handle>
<ValueList>
where
哪里
<Handle> A UTF8-String that specifies the handle whose value(s) needs to be modified.
<Handle>一个UTF8字符串，指定需要修改其值的句柄。
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer specifies the number of handle values in the list. Each value in the <ValueList> specifies a handle value that will replace the existing handle value with the same index.
<ValueList>后跟句柄值列表的4字节无符号整数。整数指定列表中句柄值的数目。<ValueList>中的每个值指定一个句柄值，该值将用相同的索引替换现有句柄值。
The server that receives the MODIFY_VALUE request must first authenticate the client as an administrator with the MODIFY_VALUE privilege. Upon successful authentication, the server will proceed to replace those handle values listed in the <ValueList>, provided each handle value has PUB_WRITE or ADMIN_WRITE permission. If successful, the server must notify the client with an RC_SUCCESS message.
接收MODIFY_VALUE请求的服务器必须首先使用MODIFY_VALUE权限将客户端验证为管理员。认证成功后，服务器将继续替换<ValueList>中列出的句柄值，前提是每个句柄值都具有PUB_WRITE或ADMIN_WRITE权限。如果成功，服务器必须用RC_成功消息通知客户端。
Each MODIFY_VALUE request must be carried out as a transaction. If replacing any value listed in the <ValueList> raises an error, the entire operation must be rolled back. For any failed MODIFY_VALUE request, none of values in the <ValueList> should be replaced. The server must also return a response to the client that explains the error. For example, if a MODIFY_VALUE requests to remove a handle value that has neither PUB_WRITE nor ADMIN_WRITE permission, the server must return an error message with the <ResponseCode> set to RC_ACCESS_DENIED. Any MODIFY_VALUE request to replace non- existing handle values is also treated as an error. In this case, the server will return an error message with <ResponseCode> set to RC_VALUE_NOT_FOUND.
每个修改_值请求必须作为事务执行。如果替换<ValueList>中列出的任何值会引发错误，则必须回滚整个操作。对于任何失败的修改值请求，<ValueList>中的任何值都不应被替换。服务器还必须向客户端返回解释错误的响应。例如，如果修改值请求删除既没有发布写入权限也没有管理写入权限的句柄值，则服务器必须返回一条错误消息，并将<ResponseCode>设置为RC\u ACCESS\u DENIED。任何用于替换不存在的句柄值的MODIFY_VALUE请求也将被视为错误。在这种情况下，服务器将返回一条错误消息，其中<ResponseCode>设置为RC\u VALUE\u NOT\u FOUND。
MODIFY_VALUE requests can also be used to update handle administrators. This happens if both the values in the <ValueList> and the value to be replaced are HS_ADMIN values. Servers must authenticate the client as an administrator with the MODIFY_ADMIN privilege before fulfilling such a request. It is an error to replace a non-HS_ADMIN value with an HS_ADMIN value. In this case, the server will return an error message with <ResponseCode> set to RC_VALUE_INVALID.
修改值请求也可用于更新句柄管理员。如果<ValueList>中的值和要替换的值都是HS_ADMIN值，则会发生这种情况。服务器必须使用MODIFY_ADMIN权限以管理员身份验证客户端，然后才能满足此类请求。将非HS_ADMIN值替换为HS_ADMIN值是错误的。在这种情况下，服务器将返回一条错误消息，并将<ResponseCode>设置为RC\u VALUE\u INVALID。
Clients can create new handles by sending CREATE_HANDLE requests to the responsible handle server. The Message Header of any CREATE_HANDLE request must set its <OpCode> to OC_CREATE_HANDLE.
客户端可以通过向负责的句柄服务器发送创建句柄请求来创建新句柄。任何CREATE_HANDLE请求的消息头必须将其<OpCode>设置为OC_CREATE_HANDLE。
The Message Body of any CREATE_HANDLE request is defined as follows:
任何CREATE_HANDLE请求的消息体定义如下：
<Message Body of CREATE_HANDLE Response> ::= <Handle>
<ValueList>
<Message Body of CREATE_HANDLE Response> ::= <Handle>
<ValueList>
where
哪里
<Handle> A UTF8-String that specifies the handle.
<Handle>指定句柄的UTF8字符串。
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer indicates the number of handle values in the list. The <ValueList> should at least include one HS_ADMIN value that defines the handle administrator.
<ValueList>后跟句柄值列表的4字节无符号整数。整数表示列表中句柄值的数目。<ValueList>应至少包含一个定义句柄管理员的HS_ADMIN值。
Only naming authority administrators with the CREATE_HANDLE privilege are allowed to create new handles under the naming authority. The server that receives a CREATE_HANDLE request must authenticate the client as the administrator of the corresponding naming authority handle and make certain that the administrator is authorized to create handles under the naming authority. This is different from the ADD_VALUE request where the server authenticates the client as an administrator of the handle. Upon successful authentication, the server will proceed to create the new handle and add each value in the <ValueList> to the new <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
只有具有“创建句柄”权限的命名机构管理员才能在命名机构下创建新句柄。接收CREATE_HANDLE请求的服务器必须将客户端验证为相应命名机构句柄的管理员，并确保管理员有权在命名机构下创建句柄。这与ADD_VALUE请求不同，在ADD_VALUE请求中，服务器将客户端验证为句柄的管理员。成功验证后，服务器将继续创建新句柄，并将<ValueList>中的每个值添加到新的<handle>。如果成功，服务器将向客户端返回一条RC_成功消息。
Each CREATE_HANDLE request must be carried out as a transaction. If any part of the CREATE_HANDLE process fails, the entire operation can be rolled back. For example, if the server fails to add values in the <ValueList> to the new handle, it must return an error message without creating the new handle. Any CREATE_HANDLE request that asks to create a handle that already exists will be treated as an error. In this case, the server will return an error message with the <ResponseCode> set to RC_HANDLE_ALREADY_EXIST.
每个CREATE_HANDLE请求必须作为事务执行。如果CREATE_HANDLE进程的任何部分失败，则可以回滚整个操作。例如，如果服务器未能将<ValueList>中的值添加到新句柄，则必须返回错误消息而不创建新句柄。任何要求创建已存在句柄的CREATE_HANDLE请求都将被视为错误。在这种情况下，服务器将返回一条错误消息，其中<ResponseCode>设置为RC\u HANDLE\u已经存在。
CREATE_HANDLE requests can also be used to create naming authorities. Naming authorities are created as naming authority handles at the GHR. Before creating a new naming authority handle, the server must authenticate the client as the administrator of the parent naming authority. Only administrators with the CREATE_NA privilege are allowed to create any sub-naming authority. Root level naming authorities may be created by the administrator of the root handle "0.NA/0.NA".
CREATE\ U HANDLE请求也可用于创建命名权限。命名机构作为GHR的命名机构句柄创建。在创建新的命名机构句柄之前，服务器必须将客户端验证为父命名机构的管理员。只有具有“创建”权限的管理员才能创建任何子命名机构。根级别命名权限可以由根句柄“0.NA/0.NA”的管理员创建。
Clients delete existing handles by sending DELETE_HANDLE requests to the responsible handle server. The Message Header of the DELETE_HANDLE request must set its <OpCode> to OC_DELETE_HANDLE.
客户端通过向负责的句柄服务器发送删除句柄请求来删除现有句柄。DELETE\u HANDLE请求的消息头必须将其<OpCode>设置为OC\u DELETE\u HANDLE。
The Message Body of any DELETE_HANDLE request is defined as follows:
任何删除句柄请求的消息体定义如下：
<Message Body of DELETE_HANDLE Request> ::= <Handle>
<Message Body of DELETE_HANDLE Request> ::= <Handle>
where
哪里
<Handle> A UTF8-String that specifies the handle.
<Handle>指定句柄的UTF8字符串。
The server that receives the DELETE_HANDLE request must first authenticate the client as the administrator with the DELETE_HANDLE privilege. Upon successful authentication, the server will proceed to delete the handle along with any handle values assigned to the handle. If successful, the server will return an RC_SUCCESS message to the client.
接收删除句柄请求的服务器必须首先以具有删除句柄权限的管理员身份验证客户端。成功身份验证后，服务器将继续删除句柄以及分配给句柄的任何句柄值。如果成功，服务器将向客户端返回一条RC_成功消息。
Each DELETE_HANDLE request must be carried out as a transaction. If any part of the DELETE_HANDLE process fails, the entire operation must be rolled back. For example, if the server fails to remove any handle values assigned to the handle (before deleting the handle), it must return an error message without deleting the handle. This may happen if the handle contains a value that has neither PUB_WRITE nor ADMIN_WRITE permission. In this case, the server will return an error message with the <ResponseCode> set to RC_PERMISSION_DENIED. A DELETE_HANDLE request that asks to delete a non-existing handle will also be treated as an error. The server will return an error message with the <ResponseCode> set to RC_HANDLE_NOT_EXIST.
每个删除句柄请求必须作为事务执行。如果DELETE_HANDLE进程的任何部分失败，则必须回滚整个操作。例如，如果服务器未能删除分配给句柄的任何句柄值（在删除句柄之前），则必须返回错误消息而不删除句柄。如果句柄包含既没有发布写入权限也没有管理写入权限的值，则可能发生这种情况。在这种情况下，服务器将返回一条错误消息，其中<ResponseCode>设置为RC\u PERMISSION\u DENIED。要求删除不存在句柄的DELETE_句柄请求也将被视为错误。服务器将返回一条错误消息，其中<ResponseCode>设置为RC\u HANDLE\u NOT\u EXIST。
DELETE_HANDLE requests can also be used to delete naming authorities. This is achieved by deleting the corresponding naming authority handle on the GHR. Before deleting a naming authority handle, the server must authenticate the client as the administrator of the naming authority handle. Only administrators with the DELETE_NA privilege are allowed to delete the naming authority. Root level naming authorities may be deleted by the administrator of the root handle "0.NA/0.NA".
DELETE\u HANDLE请求还可用于删除命名机构。这是通过删除GHR上相应的命名机构句柄来实现的。在删除命名机构句柄之前，服务器必须将客户端验证为命名机构句柄的管理员。只有具有删除权限的管理员才能删除命名机构。根句柄“0.NA/0.NA”的管理员可以删除根级别的命名权限。
The Handle System manages naming authorities via naming authority handles. Naming authority handles are managed by the GHR. Clients can change the service information of any naming authority by changing the HS_SITE values assigned to the corresponding naming authority handle. Creating or deleting naming authorities is done by creating or deleting the corresponding naming authority handles. Root level naming authorities may be created or deleted by the administrator of the root handle "0.NA/0.NA". Non-root-level naming authorities may be created by the administrator of its parent naming authority.
Handle系统通过命名权限句柄管理命名权限。命名机构句柄由GHR管理。客户端可以通过更改分配给相应命名机构句柄的HS_站点值来更改任何命名机构的服务信息。通过创建或删除相应的命名机构句柄来创建或删除命名机构。根句柄“0.NA/0.NA”的管理员可以创建或删除根级别的命名权限。非根级别的命名机构可以由其父命名机构的管理员创建。
For example, the administrator of the naming authority handle "0.NA/10" may create the naming authority "10.1000" by sending a CREATE_HANDLE request to the GHR to create the naming authority handle "0.NA/10.1000". Before fulfilling the request, the server at the GHR must authenticate the client as the administrator of the parent naming authority, that is, the administrator of the naming authority handle "0.NA/10". The server must also make sure that the administrator has the NA_CREATE privilege.
例如，命名机构句柄“0.NA/10”的管理员可以通过向GHR发送创建句柄请求来创建命名机构句柄“0.NA/10.1000”，从而创建命名机构“10.1000”。在完成请求之前，GHR的服务器必须将客户端验证为父命名机构的管理员，即命名机构的管理员处理“0.NA/10”。服务器还必须确保管理员具有NA_CREATE权限。
The Handle protocol also allows clients to list handles or sub-naming authorities under a naming authority. Details of these operations are described in the following sections.
Handle协议还允许客户端在命名机构下列出句柄或子命名机构。这些操作的详细信息将在以下章节中介绍。
Clients send LIST_HANDLE requests to handle servers to get a list of handles under a naming authority. The Message Header of the LIST_HANDLE request must set its <OpCode> to OC_LIST_HANDLE.
客户端向处理服务器发送列表句柄请求，以获取命名机构下的句柄列表。列表句柄请求的消息头必须将其<OpCode>设置为OC\u列表句柄。
The Message Body of any LIST_HANDLE request is defined as follows:
任何列表句柄请求的消息体定义如下：
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
where
哪里
<NA_Handle> A UTF8-String that specifies the naming authority handle.
<NA_Handle>指定命名机构句柄的UTF8字符串。
To obtain a complete list of the handles, the request must be sent to every handle server listed in one of the service sites of the responsible handle service. Each server within the service site will return its own list of handles under the naming authority. The Message Body of a successful LIST_HANDLE response (from each handle server) is defined as follows:
要获得句柄的完整列表，必须将请求发送到负责句柄服务的一个服务站点中列出的每个句柄服务器。服务站点中的每台服务器都将返回其自己的命名权限下的句柄列表。成功列表句柄响应（来自每个句柄服务器）的消息体定义如下：
<Message Body of LIST_HANDLE Response> ::= <Num_Handles>
<HandleList>
where
<Message Body of LIST_HANDLE Response> ::= <Num_Handles>
<HandleList>
where
<Num_Handles> Number of handles (managed by the handle server) under the naming authority.
<Num_Handles>命名权限下的句柄数（由句柄服务器管理）。
<HandleList> A list of UTF8-Strings, each of which identify a handle under the naming authority.
<HandleList>UTF8字符串的列表，每个字符串标识命名机构下的句柄。
The LIST_HANDLE request may potentially slow down the overall system performance. A handle service (or its service site) has the option of whether or not to support such request. The server will return an RC_OPERATION_DENIED message if LIST_HANDLE is not supported. The server that receives a LIST_HANDLE request should authenticate the client as a naming authority administrator with the LIST_HANDLE privilege before fulfilling the request.
列表句柄请求可能会降低总体系统性能。handle服务（或其服务站点）可以选择是否支持此类请求。如果列表句柄不受支持，服务器将返回一条RC_操作_拒绝消息。接收列表句柄请求的服务器应在完成请求之前，以具有列表句柄权限的命名机构管理员身份验证客户端。
Clients send LIST_NA requests to handle servers to get a list of sub-naming authorities under a naming authority. The Message Header of the LIST_NA request must set its <OpCode> to OC_LIST_NA.
客户端向服务器发送列表请求，以获取命名机构下的子命名机构列表。列表请求的消息头必须将其<OpCode>设置为OC\u LIST\u NA。
The Message Body of any LIST_NA request is defined as follows:
任何列表请求的消息体定义如下：
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
where
哪里
<NA_Handle> A UTF8-String that specifies the naming authority handle.
<NA_Handle>指定命名机构句柄的UTF8字符串。
To obtain a complete list of the sub-naming authorities, the request must be sent to every handle server listed in any one of the service sites of the GHR. Each server within the service site will return its own list of sub-naming authority handles under the given naming authority. The Message Body of a successful LIST_NA response (from each handle server) is defined as follows:
要获得子命名机构的完整列表，必须将请求发送到GHR任何一个服务站点中列出的每个句柄服务器。服务站点中的每台服务器都将返回其自己的子命名机构句柄列表，这些句柄位于给定命名机构下。成功列表响应（来自每个句柄服务器）的消息体定义如下：
<Message Body of LIST_HANDLE Response> ::= <Num_Handles>
<HandleList>
where
<Message Body of LIST_HANDLE Response> ::= <Num_Handles>
<HandleList>
where
<Num_Handles> Number of handles (managed by the handle server) under the naming authority.
<Num_Handles>命名权限下的句柄数（由句柄服务器管理）。
<HandleList> A list of UTF8-Strings, each of which identifies a sub-naming authority user-specified naming authority.
<HandleList>UTF8字符串的列表，每个字符串标识一个子命名机构用户指定的命名机构。
LIST_NA requests must be sent to servers under the GHR that manages all the naming authority handles. The LIST_NA request may potentially slow down the overall system performance, especially the GHS. A server (or service sites) under the GHR has the option of whether or not to support such requests. The server will return an RC_OPERATION_DENIED message if LIST_NA is not supported. The server that receives a LIST_HANDLE request should authenticate the client as a naming authority administrator with the LIST_NA privilege before fulfilling the request.
列表请求必须发送到GHR下的服务器，GHR管理所有命名机构句柄。列表请求可能会降低总体系统性能，尤其是GHS。GHR下的服务器（或服务站点）可以选择是否支持此类请求。如果列表不受支持，服务器将返回一条RC_操作_拒绝消息。接收列表句柄请求的服务器应在完成请求之前，以具有列表权限的命名机构管理员身份验证客户端。
Sessions are used to allow sharing of authentication information or network resources among multiple protocol operations. For example, a naming authority administrator may authenticate itself once through the session setup, and then register multiple handles under the session.
会话用于允许在多个协议操作之间共享身份验证信息或网络资源。例如，命名机构管理员可以通过会话设置对自己进行一次身份验证，然后在会话下注册多个句柄。
A client may ask the server to establish a session key and use it for subsequent requests. A session key is a secret key that is shared by the client and server. It can be used to authenticate or encrypt any message exchanged under the session. A session is encrypted if every message exchanged within the session is encrypted using the session key.
客户端可能会要求服务器建立会话密钥，并将其用于后续请求。会话密钥是客户端和服务器共享的密钥。它可用于对会话下交换的任何消息进行身份验证或加密。如果会话中交换的每个消息都使用会话密钥加密，则会话将被加密。
Sessions may be established as the result of an explicit OC_SESSION_SETUP request from a client. A server may also automatically setup a session when multiple message exchanges are expected to fulfill a request. For example, the server will automatically establish a session if it receives a CREATE_HANDLE request that requires client authentication.
会话可以作为来自客户端的显式OC_会话设置请求的结果建立。当期望多个消息交换来满足一个请求时，服务器也可以自动设置会话。例如，如果服务器收到需要客户端身份验证的CREATE_HANDLE请求，它将自动建立会话。
Every session is identified by a non-zero Session ID that appears in the Message Header. Servers are responsible for generating a unique Session ID for each outstanding session. Each session may have a set of state information associated with it. The state information may
每个会话都由出现在消息头中的非零会话ID标识。服务器负责为每个未完成的会话生成唯一的会话ID。每个会话可能有一组与之关联的状态信息。国家信息可能
include the session key and the information obtained from client authentication, as well as any communication options. Servers and clients are responsible for keeping the state information in sync until the session is terminated.
包括会话密钥和从客户端身份验证获得的信息，以及任何通信选项。服务器和客户端负责保持状态信息同步，直到会话终止。
A session may be terminated with an OC_SESSION_TERMINATE request from the client. Servers may also terminate a session that has been idle for a significant amount of time.
会话可以通过客户端的OC_session_TERMINATE请求来终止。服务器还可以终止已空闲很长时间的会话。
Clients establish a session with a handle server with a SESSION_SETUP request. A SESSION_SETUP request can also be used to update any state information associated to an existing session. The Message Header of the SESSION_SETUP request must have its <OpCode> set to OC_SESSION_SETUP and <ResponseCode> to 0.
客户端通过会话设置请求与句柄服务器建立会话。会话设置请求还可用于更新与现有会话关联的任何状态信息。会话设置请求的消息头必须将其<OpCode>设置为OC\u SESSION\u SETUP，并将<ResponseCode>设置为0。
The Message Body of any SESSION_SETUP request is defined as follows:
任何会话设置请求的消息正文定义如下：
<SESSION_SETUP Request Message Body> ::= <SessionAttributes>
<SESSION_SETUP Request Message Body> ::= <SessionAttributes>
where
哪里
<SessionAttributes> A 4-byte unsigned integer followed by a list of session attributes. The integer indicates the number of session attributes in the list. Possible session attributes include the <HS_SESSION_IDENTITY>, the <HS_SESSION_TIMEOUT>, and the <HS_SESSION_KEY_EXCHANGE>. Each of these attributes is defined as follows:
<SessionAttributes>后跟会话属性列表的4字节无符号整数。整数表示列表中会话属性的数量。可能的会话属性包括<HS\u session\u IDENTITY>、<HS\u session\u TIMEOUT>和<HS\u session\u KEY\u EXCHANGE>。这些属性的定义如下：
<HS_SESSION_IDENTITY> ::= <Key>
<Handle>
<ValueIndex>
where
<HS_SESSION_IDENTITY> ::= <Key>
<Handle>
<ValueIndex>
where
<Key> A UTF-8 string constant "HS_SESSION_IDENTITY".
<Key>UTF-8字符串常量“HS\u会话\u标识”。
<Handle> <ValueIndex> A UTF-8 string followed by a 4-byte unsigned integer that specifies the handle and the handle value used for client authentication. It must refer to a handle value that contains the public key of the client. The public key is used by the server to authenticate the client.
<Handle><ValueIndex>一个UTF-8字符串，后跟一个4字节无符号整数，指定用于客户端身份验证的句柄和句柄值。它必须引用包含客户端公钥的句柄值。服务器使用公钥对客户端进行身份验证。
<HS_SESSION_KEY_EXCHANGE> ::= <Key>
<KeyExchangeData>
where
<HS_SESSION_KEY_EXCHANGE> ::= <Key>
<KeyExchangeData>
where
<Key> A UTF-8 string constant "HS_SESSION_KEY_EXCHANGE".
<Key>UTF-8字符串常量“HS\u会话\u密钥交换”。
<KeyExchangeData> One of the these tuples: <ClientCipher <ClientCipher KeyExchange>, <HdlCipher KeyExchange>, or <ServerCipher KeyExchange>. Each of these tuples is defined as follows:
<KeyExchangeData>这些元组中的一个：<ClientCipher<ClientCipher KeyExchange>、<HDLCippher KeyExchange>或<ServerCipher KeyExchange>。每个元组的定义如下：
<ClientCipher KeyExchange> ::= <Key>
<PubKey>
where
<ClientCipher KeyExchange> ::= <Key>
<PubKey>
where
<Key> A UTF-8 string constant "CLIENT_CIPHER".
<Key>UTF-8字符串常量“CLIENT\u CIPHER”。
<PubKey> A public key provided by the client and used by the server to encrypt the session key.
<PubKey>由客户端提供并由服务器用于加密会话密钥的公钥。
<HdlCipher KeyExchange> ::= <Key>
<ExchangeKeyHdl>
<ExchangeKeyIndex>
where
<HdlCipher KeyExchange> ::= <Key>
<ExchangeKeyHdl>
<ExchangeKeyIndex>
where
<Key> A UTF-8 string constant "HDL_CIPHER".
<Key>UTF-8字符串常量“HDL\u密码”。
<ExchangeKeyHdl> <ExchangeKeyIndex> A UTF-8 string followed by a 4-byte unsigned integer. The <ExchangeKeyHdl> and <ExchangeKeyIndex> refers to a handle value used for session key exchange. The handle value must contain the public key of the client. The public key will be used by the server to encrypt the session key before sending it to the client.
<ExchangeKeyHdl><ExchangeKeyIndex>一个UTF-8字符串，后跟一个4字节无符号整数。<ExchangeKeyHdl>和<ExchangeKeyIndex>引用用于会话密钥交换的句柄值。句柄值必须包含客户端的公钥。在将会话密钥发送到客户端之前，服务器将使用公钥对会话密钥进行加密。
<ServerCipher KeyExchange> ::= <Key>
<ServerCipher KeyExchange> ::= <Key>
where
哪里
<Key> A UTF-8 string constant "SERVER_CIPHER". This tells the server that the client will be responsible for generating the session key. The server will have to provide its public key in the response message and set the <ResponseCode> to RC_SESSION_EXCHANGEKEY. The client can use the server's public key to encrypt the session key and send it to the server via a subsequent SESSION_EXCHANGEKEY request.
<Key>UTF-8字符串常量“SERVER\u CIPHER”。这告诉服务器客户端将负责生成会话密钥。服务器必须在响应消息中提供其公钥，并将<ResponseCode>设置为RC_SESSION_EXCHANGEKEY。客户端可以使用服务器的公钥加密会话密钥，并通过后续会话交换密钥请求将其发送到服务器。
<DiffieHellman KeyExchange> ::= <Key>
<DHParams>
where
<DiffieHellman KeyExchange> ::= <Key>
<DHParams>
where
<Key> A UTF-8 string constant "DIFFIE_HELLMAN"
<Key>UTF-8字符串常量“DIFFIE_HELLMAN”
<DHParams> The values used as input in the Diffie-Hellman algorithm. It consists of three big integers of variable length. Each big integer is encoded in terms of a 4-byte unsigned integer followed by an octet string. The octet string contains the big integer itself. The 4-byte unsigned integer specifies the number of octets of the octet string.
<DHParams>在Diffie-Hellman算法中用作输入的值。它由三个长度可变的大整数组成。每个大整数都按照一个4字节无符号整数后跟一个八位字节字符串进行编码。八进制字符串本身包含大整数。4字节无符号整数指定八位字节字符串的八位字节数。
<HS_SESSION_TIMEOUT> ::= <Key>
<TimeOut>
where
<HS_SESSION_TIMEOUT> ::= <Key>
<TimeOut>
where
<Key> A UTF-8 string constant "HS_SESSION_TIMEOUT".
<Key>UTF-8字符串常量“HS\u会话\u超时”。
<TimeOut> A 4-byte unsigned integer that specifies the desired duration of the session in seconds.
<TimeOut>一个4字节无符号整数，指定会话所需的持续时间（以秒为单位）。
Note that it should be treated as an error if the same session attribute is listed multiple times in the <SessionAttribute> field. When this happens, the server should return an error message with <ResponseCode> set to RC_PROTOCOL_ERROR.
请注意，如果同一会话属性在<SessionAttribute>字段中多次列出，则应将其视为错误。发生这种情况时，服务器应返回一条错误消息，并将<ResponseCode>设置为RC\u PROTOCOL\u error。
A SESSION_SETUP_REQUEST can be used to change session attributes of any established session. This happens if the <SessionId> is non-zero
会话设置请求可用于更改任何已建立会话的会话属性。如果<SessionId>为非零，则会发生这种情况
and matches one of the established sessions. Care must be taken by the server to prevent any unauthorized request from changing the session attributes. For example, an encrypted session may only be changed into an unencrypted session by a SESSION_SETUP_REQUEST with an appropriate MAC in its Message Credential.
并匹配其中一个已建立的会话。服务器必须注意防止任何未经授权的请求更改会话属性。例如，加密会话只能通过在其消息凭证中包含适当MAC的会话设置请求更改为未加密会话。
The Message Header of the SESSION_SETUP response must set its <OpCode> to OC_SESSION_SETUP. The <ResponseCode> of the SESSION_SETUP response varies according to the SESSION_SETUP request. It must be set to RC_SUCCESS if the SESSION_SETUP request is successful and the server does not expect a session key to be returned by the client.
会话\u设置响应的消息头必须将其<OpCode>设置为OC\u会话\u设置。会话设置响应的<ResponseCode>根据会话设置请求而变化。如果会话设置请求成功，并且服务器不希望客户端返回会话密钥，则必须将其设置为RC_SUCCESS。
The Message Body of the SESSION_SETUP response is empty unless the request is asking for <HS_SESSION_KEY_EXCHANGE>. In this case, the Message Body of the SESSION_SETUP response may contain the encrypted session key from the server, or the server's public key, to be used for session key exchange. The exact format depends on the content of the <HS_SESSION_KEY_EXCHANGE> in the SESSION_SETUP request. If <ClientCipher KeyExchange> or <HdlCipher KeyExchange> is given in the SESSION_SETUP request, the Message Body of the SESSION_SETUP response will contain the encrypted session key from the server and is defined as follows:
除非请求请求<HS\u SESSION\u KEY\u EXCHANGE>，否则会话设置响应的消息正文为空。在这种情况下，会话设置响应的消息体可能包含来自服务器的加密会话密钥或服务器的公钥，用于会话密钥交换。具体格式取决于会话设置请求中<HS\u会话密钥交换>的内容。如果会话设置请求中给出了<ClientCipher KeyExchange>或<HdlCipher KeyExchange>，会话设置响应的消息体将包含来自服务器的加密会话密钥，定义如下：
<Message Body of SESSION_SETUP Response>
::= <RequestDigest>
<EncryptedSessionKey>
[ <EncryptionAlgorithm> ]
where
<Message Body of SESSION_SETUP Response>
::= <RequestDigest>
<EncryptedSessionKey>
[ <EncryptionAlgorithm> ]
where
<RequestDigest> Message digest of the SESSION_SETUP request is as specified in section 2.2.3.
会话设置请求的消息摘要如第2.2.3节所述。
<EncryptedSessionKey> Session key is encrypted using the public key provided in the SESSION_SETUP request. The session key is a randomly generated octet string from the server. The server will only return the <EncryptedSessionKey> if the <KeyExchangeData> in the SESSION_SETUP request provides the public key from the client.
<EncryptedSessionKey>会话密钥使用会话设置请求中提供的公钥进行加密。会话密钥是从服务器随机生成的八位字节字符串。如果会话设置请求中的<KeyExchangeData>提供了来自客户端的公钥，服务器将仅返回<EncryptedSessionKey>。
<EncryptionAlgorithm> (optional) UTF-8 string that identifies the encryption algorithm used by the session key.
<EncryptionAlgorithm>（可选）标识会话密钥使用的加密算法的UTF-8字符串。
If <ServerCipher KeyExchange> is given in the SESSION_SETUP request, the server must provide its public key in the SESSION_SETUP response. The public key can be used by the client in a subsequent SESSION_EXCHANGEKEY request (defined below) for session key exchange. In this case, the Message Header of the SESSION_SETUP response must set its <ResponseCode> to RC_SESSION_EXCHANGEKEY. The Message Body of the SESSION_SETUP response must include the server's public key and is defined as follows:
如果会话设置请求中给出了<ServerCipher KeyExchange>，则服务器必须在会话设置响应中提供其公钥。客户端可以在后续会话交换密钥请求（定义见下文）中使用公钥进行会话密钥交换。在这种情况下，会话\u设置响应的消息头必须将其<ResponseCode>设置为RC\u会话\u交换键。会话设置响应的消息体必须包含服务器的公钥，定义如下：
<Message Body of SESSION_SETUP response>
::= <RequestDigest>
<Public Key for Session Key Exchange>
<Message Body of SESSION_SETUP response>
::= <RequestDigest>
<Public Key for Session Key Exchange>
where
哪里
<RequestDigest> Message digest of the SESSION_SETUP request as specified in section 2.2.3.
会话设置请求的消息摘要，如第2.2.3节所述。
<Public Key for Session Key Exchange> Public key from the server to be used for session key exchange. It is encoded in the same format as the <PublicKey> record in the HS_SITE value (see section 3.2.2 in [2]).
<Public Key for Session Key Exchange>服务器上用于会话密钥交换的公钥。其编码格式与HS_站点值中的<PublicKey>记录相同（见[2]第3.2.2节）。
If the <ResponseCode> of a SESSION_SETUP response is RC_SESSION_EXCHANGEKEY, the client is responsible for generating the session key and sending it to the server. In this case, the client can generate a session key, encrypt it with the public key provided by the server in the SESSION_SETUP response, and send the encrypted session key to the server in a SESSION_EXCHANGEKEY request.
如果会话设置响应的<ResponseCode>是RC\u SESSION\u EXCHANGEKEY，则客户端负责生成会话密钥并将其发送到服务器。在这种情况下，客户端可以生成会话密钥，使用服务器在会话设置响应中提供的公钥对其进行加密，并在会话交换密钥请求中将加密的会话密钥发送给服务器。
The Message Header of the SESSION_EXCHANGEKEY request must set its <OpCode> to OC_SESSION_EXCHANGEKEY and its <ResponseCode> to 0. The Message Body of the SESSION_EXCHANGEKEY request is defined as follows:
SESSION_EXCHANGEKEY请求的消息头必须将其<OpCode>设置为OC_SESSION_EXCHANGEKEY，并将其<ResponseCode>设置为0。会话交换密钥请求的消息体定义如下：
<Message Body of OC_SESSION_EXCHANGEKEY>
::= <Encrypted Session Key>
[ <EncryptionAlgorithm> ]
<Message Body of OC_SESSION_EXCHANGEKEY>
::= <Encrypted Session Key>
[ <EncryptionAlgorithm> ]
where
哪里
<EncryptedSessionKey> Session key encrypted using the public key provided in the SESSION_SETUP response. The session key is a randomly generated octet string by the client.
<EncryptedSessionKey>使用会话设置响应中提供的公钥加密的会话密钥。会话密钥是客户端随机生成的八位字节字符串。
<EncryptionAlgorithm> (optional) UTF-8 string that identifies the encryption algorithm used by the session key.
<EncryptionAlgorithm>（可选）标识会话密钥使用的加密算法的UTF-8字符串。
During the session key exchange, the server receiving the exchange key or session key has the responsibility of ensuring that the key meets the security requirements defined in its local policy. If the server considers the key being volunable, it must return an error message to the client with <ResponseCode> set to RC_SESSION_KEY_INVALID.
在会话密钥交换期间，接收交换密钥或会话密钥的服务器有责任确保密钥满足其本地策略中定义的安全要求。如果服务器认为密钥无法访问，则必须向客户端返回一条错误消息，并将<ResponseCode>设置为RC\u SESSION\u key\u无效。
Clients can terminate a session with a SESSION_TERMINATE request. The Message Header of a SESSION_TERMINATE request must have its <OpCode> set to OC_SESSION_TERMINATE and its <ResponseCode> to 0. The message body of any SESSION_TERMINATE request must be empty.
客户端可以使用会话终止请求终止会话。会话\u终止请求的消息头必须将其<OpCode>设置为OC\u SESSION\u TERMINATE，并将其<ResponseCode>设置为0。任何会话终止请求的消息正文必须为空。
The server must send a SESSION_TERMINATE response to the client after the session is terminated. The server should only terminate the session after it has finished processing all the requests (under the session) that were submitted before the Session Termination request.
会话终止后，服务器必须向客户端发送会话终止响应。服务器仅应在处理完会话终止请求之前提交的所有请求（在会话下）后终止会话。
The message header of the SESSION_TERMINATE response must set its <OpCode> to OC_SESSION_TERMINATE. A successful SESSION_TERMINATE response must have its <ResponseCode> set to RC_SUCCESS, and an empty message body.
会话\u终止响应的消息头必须将其<OpCode>设置为OC\u会话\u终止。成功的会话\u终止响应必须将其<ResponseCode>设置为RC\u SUCCESS，并且消息正文为空。
The optimal structure for any handle server will depend on the host operating system. This section only addresses those implementation considerations that are common to most handle servers.
任何句柄服务器的最佳结构都取决于主机操作系统。本节仅讨论大多数handle服务器常见的实现注意事项。
A good server implementation should allow easy configuration or fine-tuning. A suggested list of configurable items includes the server's network interface(s) (e.g., IP address, port number, etc.), the number of concurrent processes/threads allowed, time-out intervals for any TCP connection and/or authentication process, re-try policy under UDP connection, policies on whether to support recursive service, case-sensitivity for ASCII characters, and different levels of transaction logging, etc.
一个好的服务器实现应该允许轻松配置或微调。建议的可配置项列表包括服务器的网络接口（例如，IP地址、端口号等）、允许的并发进程/线程数、任何TCP连接和/或身份验证进程的超时间隔、UDP连接下的重试策略、是否支持递归服务的策略、，ASCII字符区分大小写，以及不同级别的事务记录等。
All handle server implementations must support all the handle data types as defined in the "Handle System Namespace and Service Definition" [2]. They should also be able to store handle values of any application defined data type.
所有句柄服务器实现必须支持“句柄系统命名空间和服务定义”[2]中定义的所有句柄数据类型。它们还应该能够存储任何应用程序定义的数据类型的句柄值。
A handle server must support multiple concurrent activities, whether they are implemented as separate processes or threads in the host's operating system, or multiplexed inside a single name server program. A handle server should not block the service of UDP requests while it waits for TCP data or other query activities. Similarly, a handle server should not attempt to provide recursive service without processing such requests in parallel, though it may choose to serialize requests from a single client, or to regard identical requests from the same client as duplicates.
句柄服务器必须支持多个并发活动，无论它们是作为主机操作系统中的单独进程或线程实现的，还是在一个单一名称的服务器程序中多路复用的。句柄服务器在等待TCP数据或其他查询活动时不应阻止UDP请求的服务。类似地，句柄服务器不应在不并行处理此类请求的情况下尝试提供递归服务，尽管它可以选择序列化来自单个客户端的请求，或者将来自同一客户端的相同请求视为重复请求。
Clients should be prepared to receive handle values of any data type. Clients may choose to implement a callback interface to allow new modules or plug-ins to be added to support any application-defined data types.
客户端应该准备好接收任何数据类型的句柄值。客户端可以选择实现回调接口，以允许添加新的模块或插件来支持任何应用程序定义的数据类型。
Clients that follow service referrals or handle aliases must avoid falling into an infinite loop. They should not repeatedly contact the same server for the same request with the same target entry. A client may choose to use a counter that is incremented each time it follows a service referral or handle alias. There should be a configurable upper limit to the counter to control the levels of service referrals or handle aliases followed by the client.
遵循服务推荐或处理别名的客户机必须避免陷入无限循环。对于具有相同目标条目的相同请求，他们不应重复联系相同的服务器。客户端可以选择使用计数器，该计数器在每次跟随服务引用或句柄别名时递增。计数器应有一个可配置的上限，以控制服务推荐的级别或处理客户机后面的别名。
Clients that provide some caching can expect much better performance than those that do not. Client implementations should always consider caching the service information associated with a naming authority. This will reduce the number of roundtrips for subsequent handle requests under the same naming authority.
提供一些缓存的客户端可以期望比不提供缓存的客户端有更好的性能。客户端实现应该始终考虑缓存与命名权限相关的服务信息。这将减少同一命名机构下后续句柄请求的往返次数。
The overall Handle System security considerations are discussed in "Handle System Overview" [1]; that discussion applies equally to this document. Security considerations regarding the Handle System data model and service model are discussed in "Handle System Namespace and Service Definition" [2].
“手柄系统概述”[1]中讨论了手柄系统的总体安全注意事项；这种讨论同样适用于本文件。有关Handle系统数据模型和服务模型的安全注意事项，请参见“Handle系统命名空间和服务定义”[2]。
For efficiency, the Handle protocol includes a simple challenge-response authentication protocol for basic client authentication. Handle servers are free to provide additional authentication mechanisms (e.g., SASL) as needed. Details of this will be discussed in a separate document.
为了提高效率，Handle协议包括用于基本客户端身份验证的简单质询-响应身份验证协议。Handle服务器可以根据需要免费提供额外的身份验证机制（如SASL）。这方面的细节将在单独的文件中讨论。
Data integrity under the Handle protocol is achieved via the server's digital signature. Care must be taken to protect the server's private key from any impersonation attack. Any change to the server's public key pair must be registered (in terms of service information) with the GHR.
Handle协议下的数据完整性是通过服务器的数字签名实现的。必须小心保护服务器的私钥免受任何模拟攻击。必须向GHR注册对服务器公钥对的任何更改（就服务信息而言）。
This work is derived from the earlier versions of the Handle System implementation. The overall digital object architecture, including the Handle System, was described in a paper by Robert Kahn and Robert Wilensky [22] in 1995. Development continued at CNRI as part of the Computer Science Technical Reports (CSTR) project, funded by the Defense Advanced Projects Agency (DARPA) under Grant Number MDA-972- 92-J-1029 and MDA-972-99-1-0018. Design ideas are based on those discussed within the Handle System development team, including David Ely, Charles Orth, Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, Stephanie Nguyen, Jason Petrone, and Helen She. Their contributions to this work are gratefully acknowledged.
这项工作源自Handle系统实现的早期版本。罗伯特·卡恩（Robert Kahn）和罗伯特·威伦斯基（Robert Wilensky）[22]在1995年的一篇论文中描述了整个数字对象体系结构，包括手柄系统。作为计算机科学技术报告（CSTR）项目的一部分，CNRI继续进行开发，该项目由国防高级项目局（DARPA）资助，资助号为MDA-972-92-J-1029和MDA-972-99-1-0018。设计理念基于Handle系统开发团队讨论的内容，包括David Ely、Charles Orth、Allison Yu、Sean Reilly、Jane Euler、Catherine Rey、Stephanie Nguyen、Jason Petrone和Helen She。感谢他们对这项工作的贡献。
The authors also thank Russ Housley (housley@vigilsec.com), Ted Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) for their extensive review and comments, as well as recommendations received from other members of the IETF/IRTF community.
作者还感谢Russ Housley(housley@vigilsec.com)，特德·哈迪(hardie@qualcomm.com)，以及马克·鲍尔(mbaugher@cisco.com)感谢他们的广泛审查和评论，以及IETF/IRTF社区其他成员提出的建议。
[1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650, November 2003.
[1] Sun，S.和L.Lannom，“手柄系统概述”，RFC 36502003年11月。
[2] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and Service Definition", RFC 3651, November 2003.
[2] Sun，S.，Reilly，S.和L.Lannom，“句柄系统名称空间和服务定义”，RFC 3651，2003年11月。
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[3] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[4] A. Freier, P. Karlton, P. Kocher "The SSL Protocol Version 3.0"
[4] A.Freier，P.Karlton，P.Kocher“SSL协议版本3.0”
[5] RSA Laboratories, "Public-Key Cryptography Standard PKCS#7"
http://www.rsasecurity.com/rsalabs/pkcs/
[5] RSA Laboratories, "Public-Key Cryptography Standard PKCS#7"
http://www.rsasecurity.com/rsalabs/pkcs/
[6] U.S. Federal Information Processing Standard: Digital Signature Standard.
[6] 美国联邦信息处理标准：数字签名标准。
[7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[7] Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[8] Braden, R., "FTP Data Compression", RFC 468, March 1973.
[8] R.Braden，“FTP数据压缩”，RFC4681973年3月。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[9] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[10] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[10] NIST，FIPS PUB 180-1：安全哈希标准，1995年4月。
[11] D. Cohen, "On Holy Wars and a Plea for Peace", Internet Experiment, Note IEN 137, 1 April 1980.
[11] D.Cohen，“关于圣战和呼吁和平”，互联网实验，IEN 137号注释，1980年4月1日。
[12] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[12] Balakrishnan，H.和S.Seshan，“拥堵管理者”，RFC3124，2001年6月。
[13] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[13] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[14] Polk, W., Housley, R. and L. Bassham, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[14] Polk，W.，Housley，R.和L.Bassham，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[15] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[15] Housley，R.，Polk，W.，Ford，W.和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[16] M. Bellare and P. Rogaway. The Exact Security of Digital Signatures - How to Sign with RSA and Rabin. In Advances in Cryptology-Eurocrypt '96, pp.399-416, Springer-Verlag, 1996.
[16] 贝拉尔先生和罗格威先生。数字签名的精确安全性-如何使用RSA和Rabin签名。《欧洲密码学进展》，96年，第399-416页，斯普林格·维拉格，1996年。
[17] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[17] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[18] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[18] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
Sam X. Sun Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
Sam X.Sun国家研究计划公司（CNRI）1895 Preston White博士，弗吉尼亚州莱斯顿100号套房，邮编20191
Phone: 703-262-5316 EMail: ssun@cnri.reston.va.us
电话：703-262-5316电子邮件：ssun@cnri.reston.va.us
Sean Reilly Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
肖恩·赖利国家研究计划公司（CNRI）1895普雷斯顿·怀特博士，弗吉尼亚州莱斯顿100号套房，邮编20191
Phone: 703-620-8990 EMail: sreilly@cnri.reston.va.us
电话：703-620-8990电子邮件：sreilly@cnri.reston.va.us
Larry Lannom Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
拉里·兰诺姆国家研究计划公司（CNRI）1895普雷斯顿·怀特博士，弗吉尼亚州莱斯顿100号套房，邮编：20191
Phone: 703-262-5307 EMail: llannom@cnri.reston.va.us
电话：703-262-5307电子邮件：llannom@cnri.reston.va.us
Jason Petrone Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
Jason Petrone国家研究计划公司（CNRI）1895 Preston White博士，弗吉尼亚州雷斯顿100号套房，邮编20191
Phone: 703-262-5340 EMail: jpetrone@cnri.reston.va.us
电话：703-262-5340电子邮件：jpetrone@cnri.reston.va.us
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。