Network Working Group J. Sermersheim, Ed.
Request for Comments: 4511 Novell, Inc.
Obsoletes: 2251, 2830, 3771 June 2006
Category: Standards Track
Network Working Group J. Sermersheim, Ed.
Request for Comments: 4511 Novell, Inc.
Obsoletes: 2251, 2830, 3771 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP): The Protocol
轻量级目录访问协议（LDAP）：该协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP).
本文档描述轻量级目录访问协议（LDAP）的协议元素及其语义和编码。LDAP提供对按照X.500数据和服务模型运行的分布式目录服务的访问。这些协议元素基于X.500目录访问协议（DAP）中描述的内容。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Relationship to Other LDAP Specifications ..................3
2. Conventions .....................................................3
3. Protocol Model ..................................................4
3.1. Operation and LDAP Message Layer Relationship ..............5
4. Elements of Protocol ............................................5
4.1. Common Elements ............................................5
4.1.1. Message Envelope ....................................6
4.1.2. String Types ........................................7
4.1.3. Distinguished Name and Relative Distinguished Name ..8
4.1.4. Attribute Descriptions ..............................8
4.1.5. Attribute Value .....................................8
4.1.6. Attribute Value Assertion ...........................9
4.1.7. Attribute and PartialAttribute ......................9
4.1.8. Matching Rule Identifier ...........................10
4.1.9. Result Message .....................................10
4.1.10. Referral ..........................................12
1. Introduction ....................................................3
1.1. Relationship to Other LDAP Specifications ..................3
2. Conventions .....................................................3
3. Protocol Model ..................................................4
3.1. Operation and LDAP Message Layer Relationship ..............5
4. Elements of Protocol ............................................5
4.1. Common Elements ............................................5
4.1.1. Message Envelope ....................................6
4.1.2. String Types ........................................7
4.1.3. Distinguished Name and Relative Distinguished Name ..8
4.1.4. Attribute Descriptions ..............................8
4.1.5. Attribute Value .....................................8
4.1.6. Attribute Value Assertion ...........................9
4.1.7. Attribute and PartialAttribute ......................9
4.1.8. Matching Rule Identifier ...........................10
4.1.9. Result Message .....................................10
4.1.10. Referral ..........................................12
4.1.11. Controls ..........................................14
4.2. Bind Operation ............................................16
4.2.1. Processing of the Bind Request .....................17
4.2.2. Bind Response ......................................18
4.3. Unbind Operation ..........................................18
4.4. Unsolicited Notification ..................................19
4.4.1. Notice of Disconnection ............................19
4.5. Search Operation ..........................................20
4.5.1. Search Request .....................................20
4.5.2. Search Result ......................................27
4.5.3. Continuation References in the Search Result .......28
4.6. Modify Operation ..........................................31
4.7. Add Operation .............................................33
4.8. Delete Operation ..........................................34
4.9. Modify DN Operation .......................................34
4.10. Compare Operation ........................................36
4.11. Abandon Operation ........................................36
4.12. Extended Operation .......................................37
4.13. IntermediateResponse Message .............................39
4.13.1. Usage with LDAP ExtendedRequest and
ExtendedResponse ..................................40
4.13.2. Usage with LDAP Request Controls ..................40
4.14. StartTLS Operation .......................................40
4.14.1. StartTLS Request ..................................40
4.14.2. StartTLS Response .................................41
4.14.3. Removal of the TLS Layer ..........................41
5. Protocol Encoding, Connection, and Transfer ....................42
5.1. Protocol Encoding .........................................42
5.2. Transmission Control Protocol (TCP) .......................43
5.3. Termination of the LDAP session ...........................43
6. Security Considerations ........................................43
7. Acknowledgements ...............................................45
8. Normative References ...........................................46
9. Informative References .........................................48
10. IANA Considerations ...........................................48
Appendix A. LDAP Result Codes .....................................49
A.1. Non-Error Result Codes ....................................49
A.2. Result Codes ..............................................49
Appendix B. Complete ASN.1 Definition .............................54
Appendix C. Changes ...............................................60
C.1. Changes Made to RFC 2251 ..................................60
C.2. Changes Made to RFC 2830 ..................................66
C.3. Changes Made to RFC 3771 ..................................66
4.1.11. Controls ..........................................14
4.2. Bind Operation ............................................16
4.2.1. Processing of the Bind Request .....................17
4.2.2. Bind Response ......................................18
4.3. Unbind Operation ..........................................18
4.4. Unsolicited Notification ..................................19
4.4.1. Notice of Disconnection ............................19
4.5. Search Operation ..........................................20
4.5.1. Search Request .....................................20
4.5.2. Search Result ......................................27
4.5.3. Continuation References in the Search Result .......28
4.6. Modify Operation ..........................................31
4.7. Add Operation .............................................33
4.8. Delete Operation ..........................................34
4.9. Modify DN Operation .......................................34
4.10. Compare Operation ........................................36
4.11. Abandon Operation ........................................36
4.12. Extended Operation .......................................37
4.13. IntermediateResponse Message .............................39
4.13.1. Usage with LDAP ExtendedRequest and
ExtendedResponse ..................................40
4.13.2. Usage with LDAP Request Controls ..................40
4.14. StartTLS Operation .......................................40
4.14.1. StartTLS Request ..................................40
4.14.2. StartTLS Response .................................41
4.14.3. Removal of the TLS Layer ..........................41
5. Protocol Encoding, Connection, and Transfer ....................42
5.1. Protocol Encoding .........................................42
5.2. Transmission Control Protocol (TCP) .......................43
5.3. Termination of the LDAP session ...........................43
6. Security Considerations ........................................43
7. Acknowledgements ...............................................45
8. Normative References ...........................................46
9. Informative References .........................................48
10. IANA Considerations ...........................................48
Appendix A. LDAP Result Codes .....................................49
A.1. Non-Error Result Codes ....................................49
A.2. Result Codes ..............................................49
Appendix B. Complete ASN.1 Definition .............................54
Appendix C. Changes ...............................................60
C.1. Changes Made to RFC 2251 ..................................60
C.2. Changes Made to RFC 2830 ..................................66
C.3. Changes Made to RFC 3771 ..................................66
The Directory is "a collection of open systems cooperating to provide directory services" [X.500]. A directory user, which may be a human or other entity, accesses the Directory through a client (or Directory User Agent (DUA)). The client, on behalf of the directory user, interacts with one or more servers (or Directory System Agents (DSA)). Clients interact with servers using a directory access protocol.
该目录是“合作提供目录服务的开放系统集合”[X.500]。目录用户可以是人或其他实体，通过客户端（或目录用户代理（DUA））访问目录。客户端代表目录用户与一个或多个服务器（或目录系统代理（DSA））交互。客户端使用目录访问协议与服务器交互。
This document details the protocol elements of the Lightweight Directory Access Protocol (LDAP), along with their semantics. Following the description of protocol elements, it describes the way in which the protocol elements are encoded and transferred.
本文档详细介绍了轻量级目录访问协议（LDAP）的协议元素及其语义。在描述协议元素之后，它描述了协议元素的编码和传输方式。
This document is an integral part of the LDAP Technical Specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety.
本文档是LDAP技术规范[RFC4510]不可分割的一部分，该规范完全废除了先前定义的LDAP技术规范RFC 3377。
This document, together with [RFC4510], [RFC4513], and [RFC4512], obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by [RFC4510]. Sections 4.2.1 (portions) and 4.2.2 are obsoleted by [RFC4513]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) are obsoleted by [RFC4512]. The remainder of RFC 2251 is obsoleted by this document. Appendix C.1 summarizes substantive changes in the remainder.
本文件连同[RFC4510]、[RFC4513]和[RFC4512]完全废弃了RFC 2251。第3.3节已被[RFC4510]废除。[RFC4513]废除了第4.2.1节（部分）和第4.2.2节。第3.2节、第3.4节、第4.1.3节（最后一段）、第4.1.4节、第4.1.5节、第4.1.5.1节、第4.1.9节（最后一段）、第5.1节、第6.1节和第6.2节（最后一段）已被[RFC4512]废除。RFC 2251的其余部分已被本文件淘汰。附录C.1总结了其余部分的实质性变化。
This document obsoletes RFC 2830, Sections 2 and 4. The remainder of RFC 2830 is obsoleted by [RFC4513]. Appendix C.2 summarizes substantive changes to the remaining sections.
本文件废除了RFC 2830第2节和第4节。RFC 2830的其余部分被[RFC4513]淘汰。附录C.2总结了对其余章节的实质性修改。
This document also obsoletes RFC 3771 in entirety.
本文件还完全废弃了RFC 3771。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”和“可”应按照[RFC2119]中的说明进行解释。
Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
本文档中的字符名称使用Unicode标准[Unicode]中的代码点和名称表示法。例如，字母“a”可以表示为<U+0061>或<拉丁文小写字母a>。
Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].
注：Unicode中使用的术语表可在[glossary]中找到。有关Unicode字符编码模型的信息可在[CharModel]中找到。
The term "transport connection" refers to the underlying transport services used to carry the protocol exchange, as well as associations established by these services.
术语“传输连接”指用于承载协议交换的底层传输服务，以及由这些服务建立的关联。
The term "TLS layer" refers to Transport Layer Security (TLS) services used in providing security services, as well as associations established by these services.
术语“TLS层”指用于提供安全服务的传输层安全（TLS）服务，以及由这些服务建立的关联。
The term "SASL layer" refers to Simply Authentication and Security Layer (SASL) services used in providing security services, as well as associations established by these services.
术语“SASL层”仅指用于提供安全服务的身份验证和安全层（SASL）服务，以及由这些服务建立的关联。
The term "LDAP message layer" refers to the LDAP Message Protocol Data Unit (PDU) services used in providing directory services, as well as associations established by these services.
术语“LDAP消息层”指用于提供目录服务的LDAP消息协议数据单元（PDU）服务，以及由这些服务建立的关联。
The term "LDAP session" refers to combined services (transport connection, TLS layer, SASL layer, LDAP message layer) and their associations.
术语“LDAP会话”是指组合服务（传输连接、TLS层、SASL层、LDAP消息层）及其关联。
See the table in Section 5 for an illustration of these four terms.
有关这四个术语的说明，请参见第5节中的表格。
The general model adopted by this protocol is one of clients performing protocol operations against servers. In this model, a client transmits a protocol request describing the operation to be performed to a server. The server is then responsible for performing the necessary operation(s) in the Directory. Upon completion of an operation, the server typically returns a response containing appropriate data to the requesting client.
该协议采用的通用模型是对服务器执行协议操作的客户端之一。在此模型中，客户机向服务器发送描述要执行的操作的协议请求。然后，服务器负责在目录中执行必要的操作。操作完成后，服务器通常会向请求客户端返回包含适当数据的响应。
Protocol operations are generally independent of one another. Each operation is processed as an atomic action, leaving the directory in a consistent state.
协议操作通常相互独立。每个操作都作为一个原子操作处理，使目录保持一致状态。
Although servers are required to return responses whenever such responses are defined in the protocol, there is no requirement for synchronous behavior on the part of either clients or servers. Requests and responses for multiple operations generally may be exchanged between a client and server in any order. If required, synchronous behavior may be controlled by client applications.
尽管在协议中定义响应时，服务器需要返回响应，但客户端或服务器都不需要同步行为。多个操作的请求和响应通常可以在客户机和服务器之间以任意顺序交换。如果需要，同步行为可以由客户端应用程序控制。
The core protocol operations defined in this document can be mapped to a subset of the X.500 (1993) Directory Abstract Service [X.511]. However, there is not a one-to-one mapping between LDAP operations and X.500 Directory Access Protocol (DAP) operations. Server implementations acting as a gateway to X.500 directories may need to make multiple DAP requests to service a single LDAP request.
本文档中定义的核心协议操作可以映射到X.500（1993）目录抽象服务[X.511]的子集。但是，LDAP操作和X.500目录访问协议（DAP）操作之间没有一对一的映射。充当X.500目录网关的服务器实现可能需要发出多个DAP请求来服务单个LDAP请求。
Protocol operations are exchanged at the LDAP message layer. When the transport connection is closed, any uncompleted operations at the LDAP message layer are abandoned (when possible) or are completed without transmission of the response (when abandoning them is not possible). Also, when the transport connection is closed, the client MUST NOT assume that any uncompleted update operations have succeeded or failed.
协议操作在LDAP消息层交换。当传输连接关闭时，LDAP消息层上任何未完成的操作都将被放弃（如果可能）或在不传输响应的情况下完成（如果不可能放弃）。此外，当传输连接关闭时，客户端不得假定任何未完成的更新操作已成功或失败。
The protocol is described using Abstract Syntax Notation One ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding Rules ([BER]). Section 5 specifies how the protocol elements are encoded and transferred.
该协议使用抽象语法符号1（[ASN.1]）进行描述，并使用ASN.1基本编码规则（[BER]）的子集进行传输。第5节规定了协议元素的编码和传输方式。
In order to support future extensions to this protocol, extensibility is implied where it is allowed per ASN.1 (i.e., sequence, set, choice, and enumerated types are extensible). In addition, ellipses (...) have been supplied in ASN.1 types that are explicitly extensible as discussed in [RFC4520]. Because of the implied extensibility, clients and servers MUST (unless otherwise specified) ignore trailing SEQUENCE components whose tags they do not recognize.
为了支持对该协议的未来扩展，在ASN.1允许的地方暗示了可扩展性（即序列、集合、选择和枚举类型是可扩展的）。此外，ASN.1类型中提供了省略号（…），如[RFC4520]中所述，这些类型可以显式扩展。由于隐含的可扩展性，客户机和服务器必须（除非另有规定）忽略其标记不可识别的尾部序列组件。
Changes to the protocol other than through the extension mechanisms described here require a different version number. A client indicates the version it is using as part of the BindRequest, described in Section 4.2. If a client has not sent a Bind, the server MUST assume the client is using version 3 or later.
除了通过此处描述的扩展机制之外，对协议的更改需要不同的版本号。客户机指示其作为BindRequest的一部分使用的版本，如第4.2节所述。如果客户端未发送绑定，服务器必须假定客户端使用的是版本3或更高版本。
Clients may attempt to determine the protocol versions a server supports by reading the 'supportedLDAPVersion' attribute from the root DSE (DSA-Specific Entry) [RFC4512].
客户端可以尝试通过从根DSE（DSA特定条目）[RFC4512]读取“supportedLDAPVersion”属性来确定服务器支持的协议版本。
This section describes the LDAPMessage envelope Protocol Data Unit (PDU) format, as well as data type definitions, which are used in the protocol operations.
本节介绍协议操作中使用的LDAPMessage信封协议数据单元（PDU）格式以及数据类型定义。
For the purposes of protocol exchanges, all protocol operations are encapsulated in a common envelope, the LDAPMessage, which is defined as follows:
出于协议交换的目的，所有协议操作都封装在一个公共信封中，即LDAPMessage，其定义如下：
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
...,
intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
...,
intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
The ASN.1 type Controls is defined in Section 4.1.11.
ASN.1类型控制在第4.1.11节中定义。
The function of the LDAPMessage is to provide an envelope containing common fields required in all protocol exchanges. At this time, the only common fields are the messageID and the controls.
LDAPMessage的功能是提供包含所有协议交换所需公共字段的信封。此时，唯一的公共字段是messageID和控件。
If the server receives an LDAPMessage from the client in which the LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot be parsed, the tag of the protocolOp is not recognized as a request, or the encoding structures or lengths of data fields are found to be incorrect, then the server SHOULD return the Notice of Disconnection
如果服务器从客户端接收到一条无法识别LDAPMessage序列标记的LDAPMessage，无法解析messageID，无法将protocolOp的标记识别为请求，或者发现数据字段的编码结构或长度不正确，则服务器应返回断开连接通知
described in Section 4.4.1, with the resultCode set to protocolError, and MUST immediately terminate the LDAP session as described in Section 5.3.
如第4.4.1节所述，resultCode设置为protocolError，并且必须立即终止LDAP会话，如第5.3节所述。
In other cases where the client or server cannot parse an LDAP PDU, it SHOULD abruptly terminate the LDAP session (Section 5.3) where further communication (including providing notice) would be pernicious. Otherwise, server implementations MUST return an appropriate response to the request, with the resultCode set to protocolError.
在客户机或服务器无法解析LDAP PDU的其他情况下，它应突然终止LDAP会话（第5.3节），因为进一步的通信（包括提供通知）将是有害的。否则，服务器实现必须返回对请求的适当响应，并将resultCode设置为protocolError。
All LDAPMessage envelopes encapsulating responses contain the messageID value of the corresponding request LDAPMessage.
封装响应的所有LDAPMessage信封都包含相应请求LDAPMessage的messageID值。
The messageID of a request MUST have a non-zero value different from the messageID of any other request in progress in the same LDAP session. The zero value is reserved for the unsolicited notification message.
请求的messageID必须具有与同一LDAP会话中正在进行的任何其他请求的messageID不同的非零值。零值保留给未经请求的通知消息。
Typical clients increment a counter for each request.
典型的客户端为每个请求增加一个计数器。
A client MUST NOT send a request with the same messageID as an earlier request in the same LDAP session unless it can be determined that the server is no longer servicing the earlier request (e.g., after the final response is received, or a subsequent Bind completes). Otherwise, the behavior is undefined. For this purpose, note that Abandon and successfully abandoned operations do not send responses.
除非可以确定服务器不再为早期请求提供服务（例如，在接收到最终响应或后续绑定完成后），否则客户端不得在同一LDAP会话中发送与早期请求具有相同messageID的请求。否则，行为是未定义的。为此，请注意放弃和成功放弃的操作不会发送响应。
The LDAPString is a notational convenience to indicate that, although strings of LDAPString type encode as ASN.1 OCTET STRING types, the [ISO10646] character set (a superset of [Unicode]) is used, encoded following the UTF-8 [RFC3629] algorithm. Note that Unicode characters U+0000 through U+007F are the same as ASCII 0 through 127, respectively, and have the same single octet UTF-8 encoding. Other Unicode characters have a multiple octet UTF-8 encoding.
LDAPString是一种方便的符号，用于表示虽然LDAPString类型的字符串编码为ASN.1八位字符串类型，但使用[ISO10646]字符集（Unicode的超集）并按照UTF-8[RFC3629]算法进行编码。请注意，Unicode字符U+0000到U+007F分别与ASCII 0到127相同，并且具有相同的单八位UTF-8编码。其他Unicode字符具有多个八位UTF-8编码。
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
The LDAPOID is a notational convenience to indicate that the permitted value of this string is a (UTF-8 encoded) dotted-decimal representation of an OBJECT IDENTIFIER. Although an LDAPOID is
LDAPOID是一种方便的符号，用于指示此字符串的允许值是对象标识符的（UTF-8编码）点十进制表示形式。虽然LDAPOID是
encoded as an OCTET STRING, values are limited to the definition of <numericoid> given in Section 1.4 of [RFC4512].
编码为八位字节字符串，值仅限于[RFC4512]第1.4节中给出的<numericoid>定义。
LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-- [RFC4512]
LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-- [RFC4512]
For example,
例如
1.3.6.1.4.1.1466.1.2.3
1.3.6.1.4.1.1466.1.2.3
An LDAPDN is defined to be the representation of a Distinguished Name (DN) after encoding according to the specification in [RFC4514].
LDAPDN定义为根据[RFC4514]中的规范编码后的可分辨名称（DN）的表示。
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [RFC4514]
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [RFC4514]
A RelativeLDAPDN is defined to be the representation of a Relative Distinguished Name (RDN) after encoding according to the specification in [RFC4514].
RelativeLDAPDN定义为根据[RFC4514]中的规范编码后的相对可分辨名称（RDN）的表示。
RelativeLDAPDN ::= LDAPString
-- Constrained to <name-component> [RFC4514]
RelativeLDAPDN ::= LDAPString
-- Constrained to <name-component> [RFC4514]
The definition and encoding rules for attribute descriptions are defined in Section 2.5 of [RFC4512]. Briefly, an attribute description is an attribute type and zero or more options.
[RFC4512]第2.5节定义了属性描述的定义和编码规则。简而言之，属性描述是一种属性类型和零个或多个选项。
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
A field of type AttributeValue is an OCTET STRING containing an encoded attribute value. The attribute value is encoded according to the LDAP-specific encoding definition of its corresponding syntax. The LDAP-specific encoding definitions for different syntaxes and attribute types may be found in other documents and in particular [RFC4517].
AttributeValue类型的字段是包含编码属性值的八位字节字符串。属性值根据其相应语法的LDAP特定编码定义进行编码。不同语法和属性类型的LDAP特定编码定义可以在其他文档中找到，尤其是[RFC4517]。
AttributeValue ::= OCTET STRING
AttributeValue ::= OCTET STRING
Note that there is no defined limit on the size of this encoding; thus, protocol values may include multi-megabyte attribute values (e.g., photographs).
请注意，此编码的大小没有定义的限制；因此，协议值可包括多兆字节属性值（例如，照片）。
Attribute values may be defined that have arbitrary and non-printable syntax. Implementations MUST NOT display or attempt to decode an attribute value if its syntax is not known. The implementation may attempt to discover the subschema of the source entry and to retrieve the descriptions of 'attributeTypes' from it [RFC4512].
可以定义具有任意和不可打印语法的属性值。如果属性值的语法未知，则实现不得显示或尝试解码属性值。实现可能会尝试发现源条目的子模式，并从中检索“AttributeType”的描述[RFC4512]。
Clients MUST only send attribute values in a request that are valid according to the syntax defined for the attributes.
根据为属性定义的语法，客户端只能在请求中发送有效的属性值。
The AttributeValueAssertion (AVA) type definition is similar to the one in the X.500 Directory standards. It contains an attribute description and a matching rule ([RFC4512], Section 4.1.3) assertion value suitable for that type. Elements of this type are typically used to assert that the value in assertionValue matches a value of an attribute.
AttributeValueAssertion（AVA）类型定义类似于X.500目录标准中的定义。它包含适合该类型的属性描述和匹配规则（[RFC4512]，第4.1.3节）断言值。此类型的元素通常用于断言assertionValue中的值与属性的值匹配。
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
AssertionValue ::= OCTET STRING
The syntax of the AssertionValue depends on the context of the LDAP operation being performed. For example, the syntax of the EQUALITY matching rule for an attribute is used when performing a Compare operation. Often this is the same syntax used for values of the attribute type, but in some cases the assertion syntax differs from the value syntax. See objectIdentiferFirstComponentMatch in [RFC4517] for an example.
AssertionValue的语法取决于正在执行的LDAP操作的上下文。例如，在执行比较操作时使用属性的相等匹配规则的语法。这通常与属性类型的值使用的语法相同，但在某些情况下，断言语法与值语法不同。有关示例，请参见[RFC4517]中的ObjectIdentifierFirstComponentMatch。
Attributes and partial attributes consist of an attribute description and attribute values. A PartialAttribute allows zero values, while Attribute requires at least one value.
属性和部分属性由属性描述和属性值组成。PartialAttribute允许零值，而属性至少需要一个值。
PartialAttribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF value AttributeValue }
PartialAttribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF value AttributeValue }
Attribute ::= PartialAttribute(WITH COMPONENTS {
...,
vals (SIZE(1..MAX))})
Attribute ::= PartialAttribute(WITH COMPONENTS {
...,
vals (SIZE(1..MAX))})
No two of the attribute values may be equivalent as described by Section 2.2 of [RFC4512]. The set of attribute values is unordered. Implementations MUST NOT rely upon the ordering being repeatable.
如[RFC4512]第2.2节所述，任何两个属性值都不得等效。属性值集是无序的。实现不能依赖于可重复的顺序。
Matching rules are defined in Section 4.1.3 of [RFC4512]. A matching rule is identified in the protocol by the printable representation of either its <numericoid> or one of its short name descriptors [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'.
[RFC4512]第4.1.3节定义了匹配规则。协议中的匹配规则通过其<numericoid>或其一个短名称描述符[RFC4512]的可打印表示来识别，例如，“caseIgnoreMatch”或“2.5.13.2”。
MatchingRuleId ::= LDAPString
MatchingRuleId ::= LDAPString
The LDAPResult is the construct used in this protocol to return success or failure indications from servers to clients. To various requests, servers will return responses containing the elements found in LDAPResult to indicate the final status of the protocol operation request.
LDAPResult是此协议中用于将成功或失败指示从服务器返回到客户端的构造。对于各种请求，服务器将返回包含在LDAPResult中找到的元素的响应，以指示协议操作请求的最终状态。
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80),
... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80),
... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
The resultCode enumeration is extensible as defined in Section 3.8 of [RFC4520]. The meanings of the listed result codes are given in Appendix A. If a server detects multiple errors for an operation, only one result code is returned. The server should return the result code that best indicates the nature of the error encountered. Servers may return substituted result codes to prevent unauthorized disclosures.
resultCode枚举是可扩展的，如[RFC4520]第3.8节所定义。附录A中给出了所列结果代码的含义。如果服务器检测到一个操作的多个错误，则只返回一个结果代码。服务器应返回最能指示所遇到错误性质的结果代码。服务器可能会返回替换的结果代码，以防止未经授权的披露。
The diagnosticMessage field of this construct may, at the server's option, be used to return a string containing a textual, human-readable diagnostic message (terminal control and page formatting characters should be avoided). As this diagnostic message is not standardized, implementations MUST NOT rely on the values returned. Diagnostic messages typically supplement the resultCode with additional information. If the server chooses not to return a textual diagnostic, the diagnosticMessage field MUST be empty.
根据服务器的选择，此构造的diagnosticMessage字段可用于返回包含文本、人类可读诊断消息的字符串（应避免使用终端控件和页面格式化字符）。由于此诊断消息未标准化，因此实现不能依赖于返回的值。诊断消息通常用附加信息补充resultCode。如果服务器选择不返回文本诊断，则diagnosticMessage字段必须为空。
For certain result codes (typically, but not restricted to noSuchObject, aliasProblem, invalidDNSyntax, and aliasDereferencingProblem), the matchedDN field is set (subject to access controls) to the name of the last entry (object or alias) used in finding the target (or base) object. This will be a truncated form of the provided name or, if an alias was dereferenced while attempting to locate the entry, of the resulting name. Otherwise, the matchedDN field is empty.
对于某些结果代码（通常但不限于noSuchObject、aliasProblem、invalidDNSyntax和AliasDeReferenceProblem），matchedDN字段设置为（根据访问控制）查找目标（或基本）对象时使用的最后一个条目（对象或别名）的名称。这将是所提供名称的截断形式，或者，如果在尝试查找条目时取消了对别名的引用，则为结果名称的截断形式。否则，matchedDN字段为空。
The referral result code indicates that the contacted server cannot or will not perform the operation and that one or more other servers may be able to. Reasons for this include:
参考结果代码表示联系的服务器无法或不会执行该操作，并且一个或多个其他服务器可能能够执行该操作。原因包括：
- The target entry of the request is not held locally, but the server has knowledge of its possible existence elsewhere.
- 请求的目标条目不是本地保存的，但服务器知道它可能存在于其他地方。
- The operation is restricted on this server -- perhaps due to a read-only copy of an entry to be modified.
- 该操作在此服务器上受到限制——可能是由于要修改的条目的只读副本。
The referral field is present in an LDAPResult if the resultCode is set to referral, and it is absent with all other result codes. It contains one or more references to one or more servers or services that may be accessed via LDAP or other protocols. Referrals can be returned in response to any operation request (except Unbind and Abandon, which do not have responses). At least one URI MUST be present in the Referral.
如果resultCode设置为referral，则在LDAPResult中会出现referral字段，并且所有其他结果代码都不存在该字段。它包含对可通过LDAP或其他协议访问的一个或多个服务器或服务的一个或多个引用。可以返回转介以响应任何操作请求（取消绑定和放弃除外，它们没有响应）。引用中必须至少存在一个URI。
During a Search operation, after the baseObject is located, and entries are being evaluated, the referral is not returned. Instead, continuation references, described in Section 4.5.3, are returned when other servers would need to be contacted to complete the operation.
在搜索操作期间，在找到baseObject并计算条目后，不会返回引用。相反，当需要联系其他服务器以完成操作时，将返回第4.5.3节中描述的继续引用。
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
URI ::= LDAPString -- limited to characters permitted in
-- URIs
URI ::= LDAPString -- limited to characters permitted in
-- URIs
If the client wishes to progress the operation, it contacts one of the supported services found in the referral. If multiple URIs are present, the client assumes that any supported URI may be used to progress the operation.
如果客户希望推进操作，则会联系转介中的一个支持服务。如果存在多个URI，则客户端会假定任何受支持的URI都可用于执行操作。
Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters. Some clients use a
遵循引用的客户端必须确保它们不会在服务器之间循环。对于具有相同参数的相同请求，他们不得重复联系同一服务器。一些客户使用
counter that is incremented each time referral handling occurs for an operation, and these kinds of clients MUST be able to handle at least ten nested referrals while progressing the operation.
计数器，该计数器在每次操作的引用处理发生时递增，并且这些类型的客户端在执行操作时必须能够处理至少十个嵌套引用。
A URI for a server implementing LDAP and accessible via TCP/IP (v4 or v6) [RFC793][RFC791] is written as an LDAP URL according to [RFC4516].
实现LDAP并可通过TCP/IP（v4或v6）[RFC793][RFC791]访问的服务器的URI根据[RFC4516]写入为LDAP URL。
Referral values that are LDAP URLs follow these rules:
作为LDAP URL的引用值遵循以下规则：
- If an alias was dereferenced, the <dn> part of the LDAP URL MUST be present, with the new target object name.
- 如果取消引用别名，则LDAP URL的<dn>部分必须存在，并带有新的目标对象名称。
- It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
- 建议出现<dn>部分，以避免歧义。
- If the <dn> part is present, the client uses this name in its next request to progress the operation, and if it is not present the client uses the same name as in the original request.
- 如果存在<dn>部分，则客户端在其下一个请求中使用此名称来进行操作，如果不存在，则客户端使用与原始请求中相同的名称。
- Some servers (e.g., participating in distributed indexing) may provide a different filter in a URL of a referral for a Search operation.
- 一些服务器（例如，参与分布式索引）可能在搜索操作的参考URL中提供不同的过滤器。
- If the <filter> part of the LDAP URL is present, the client uses this filter in its next request to progress this Search, and if it is not present the client uses the same filter as it used for that Search.
- 如果LDAP URL的<filter>部分存在，则客户端在其下一个请求中使用此筛选器来进行此搜索，如果不存在此筛选器，则客户端使用与该搜索相同的筛选器。
- For Search, it is RECOMMENDED that the <scope> part be present to avoid ambiguity.
- 对于搜索，建议显示<scope>部分以避免歧义。
- If the <scope> part is missing, the scope of the original Search is used by the client to progress the operation.
- 如果缺少<scope>部分，则客户端将使用原始搜索的范围来进行操作。
- Other aspects of the new request may be the same as or different from the request that generated the referral.
- 新请求的其他方面可能与生成转介的请求相同或不同。
Other kinds of URIs may be returned. The syntax and semantics of such URIs is left to future specifications. Clients may ignore URIs that they do not support.
可能会返回其他类型的URI。此类URI的语法和语义留待将来的规范决定。客户端可能会忽略它们不支持的URI。
UTF-8 encoded characters appearing in the string representation of a DN, search filter, or other fields of the referral value may not be legal for URIs (e.g., spaces) and MUST be escaped using the % method in [RFC3986].
DN、搜索筛选器或引用值的其他字段的字符串表示形式中出现的UTF-8编码字符对于URI（例如空格）可能不合法，必须使用[RFC3986]中的%方法进行转义。
Controls provide a mechanism whereby the semantics and arguments of existing LDAP operations may be extended. One or more controls may be attached to a single LDAP message. A control only affects the semantics of the message it is attached to.
控件提供了一种机制，通过该机制可以扩展现有LDAP操作的语义和参数。可以将一条或多条LDAP消息附加到一个LDAP控件。控件只影响其附加到的消息的语义。
Controls sent by clients are termed 'request controls', and those sent by servers are termed 'response controls'.
客户端发送的控件称为“请求控件”，服务器发送的控件称为“响应控件”。
Controls ::= SEQUENCE OF control Control
Controls ::= SEQUENCE OF control Control
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
The controlType field is the dotted-decimal representation of an OBJECT IDENTIFIER that uniquely identifies the control. This provides unambiguous naming of controls. Often, response control(s) solicited by a request control share controlType values with the request control.
controlType字段是唯一标识控件的对象标识符的点十进制表示形式。这为控件提供了明确的命名。通常，请求控件请求的响应控件与请求控件共享controlType值。
The criticality field only has meaning in controls attached to request messages (except UnbindRequest). For controls attached to response messages and the UnbindRequest, the criticality field SHOULD be FALSE, and MUST be ignored by the receiving protocol peer. A value of TRUE indicates that it is unacceptable to perform the operation without applying the semantics of the control. Specifically, the criticality field is applied as follows:
关键性字段仅在附加到请求消息的控件中有意义（取消绑定请求除外）。对于附加到响应消息和取消绑定请求的控件，临界值字段应为FALSE，并且接收协议对等方必须忽略该字段。如果值为TRUE，则表示不应用控件的语义就执行操作是不可接受的。具体而言，关键性字段应用如下：
- If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and if the criticality field is TRUE, the server MUST NOT perform the operation, and for operations that have a response message, it MUST return with the resultCode set to unavailableCriticalExtension.
- 如果服务器不识别控件类型，确定其不适合操作，或者不愿意使用控件执行操作，并且如果临界值字段为TRUE，则服务器不得执行操作，并且对于具有响应消息的操作，它必须返回并将resultCode设置为unavailableCriticalExtension。
- If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and if the criticality field is FALSE, the server MUST ignore the control.
- 如果服务器不识别控件类型，确定它不适合操作，或者不愿意使用控件执行操作，并且如果临界值字段为FALSE，则服务器必须忽略该控件。
- Regardless of criticality, if a control is applied to an operation, it is applied consistently and impartially to the entire operation.
- 无论关键程度如何，如果控制应用于某个操作，则它将始终如一且公正地应用于整个操作。
The controlValue may contain information associated with the controlType. Its format is defined by the specification of the control. Implementations MUST be prepared to handle arbitrary contents of the controlValue octet string, including zero bytes. It is absent only if there is no value information that is associated with a control of its type. When a controlValue is defined in terms of ASN.1, and BER-encoded according to Section 5.1, it also follows the extensibility rules in Section 4.
controlValue可能包含与controlType关联的信息。其格式由控件的规范定义。实现必须准备好处理controlValue八位字节字符串的任意内容，包括零字节。只有当没有与其类型的控件相关联的值信息时，才会缺少该属性。当根据ASN.1定义控制值，并根据第5.1节进行BER编码时，它也遵循第4节中的扩展性规则。
Servers list the controlType of request controls they recognize in the 'supportedControl' attribute in the root DSE (Section 5.1 of [RFC4512]).
服务器在根DSE的“supportedControl”属性（RFC4512的第5.1节）中列出它们识别的请求控件的控制类型。
Controls SHOULD NOT be combined unless the semantics of the combination has been specified. The semantics of control combinations, if specified, are generally found in the control specification most recently published. When a combination of controls is encountered whose semantics are invalid, not specified (or not known), the message is considered not well-formed; thus, the operation fails with protocolError. Controls with a criticality of FALSE may be ignored in order to arrive at a valid combination. Additionally, unless order-dependent semantics are given in a specification, the order of a combination of controls in the SEQUENCE is ignored. Where the order is to be ignored but cannot be ignored by the server, the message is considered not well-formed, and the operation fails with protocolError. Again, controls with a criticality of FALSE may be ignored in order to arrive at a valid combination.
除非已指定组合的语义，否则不应组合控件。如果指定了控件组合的语义，通常可以在最近发布的控件规范中找到。当遇到语义无效、未指定（或未知）的控件组合时，消息被视为格式不正确；因此，操作会因protocolError而失败。临界值为FALSE的控件可以忽略，以获得有效的组合。此外，除非规范中给出了顺序相关语义，否则将忽略序列中控件组合的顺序。如果订单将被忽略但服务器无法忽略，则认为消息格式不正确，并且操作失败，出现protocolError。同样，为了得到有效的组合，可能会忽略临界值为FALSE的控件。
This document does not specify any controls. Controls may be specified in other documents. Documents detailing control extensions are to provide for each control:
本文档未指定任何控件。控制措施可在其他文件中规定。详细说明控制扩展的文件应为每个控制提供：
- the OBJECT IDENTIFIER assigned to the control,
- 分配给控件的对象标识符，
- direction as to what value the sender should provide for the criticality field (note: the semantics of the criticality field are defined above should not be altered by the control's specification),
- 关于发送方应为关键性字段提供什么值的指示（注：上文定义的关键性字段的语义不应因控制规范而改变），
- whether the controlValue field is present, and if so, the format of its contents,
- controlValue字段是否存在，如果存在，其内容的格式，
- the semantics of the control, and
- 控件的语义，以及
- optionally, semantics regarding the combination of the control with other controls.
- （可选）关于控件与其他控件组合的语义。
The function of the Bind operation is to allow authentication information to be exchanged between the client and server. The Bind operation should be thought of as the "authenticate" operation. Operational, authentication, and security-related semantics of this operation are given in [RFC4513].
绑定操作的功能是允许在客户端和服务器之间交换身份验证信息。绑定操作应被视为“身份验证”操作。[RFC4513]中给出了此操作的操作、身份验证和安全相关语义。
The Bind request is defined as follows:
绑定请求定义如下：
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
Fields of the BindRequest are:
BindRequest的字段包括：
- version: A version number indicating the version of the protocol to be used at the LDAP message layer. This document describes version 3 of the protocol. There is no version negotiation. The client sets this field to the version it desires. If the server does not support the specified version, it MUST respond with a BindResponse where the resultCode is set to protocolError.
- 版本：一个版本号，指示LDAP消息层要使用的协议版本。本文件描述了协议的第3版。没有版本协商。客户端将此字段设置为所需的版本。如果服务器不支持指定的版本，则必须使用BindResponse进行响应，其中resultCode设置为protocolError。
- name: If not empty, the name of the Directory object that the client wishes to bind as. This field may take on a null value (a zero-length string) for the purposes of anonymous binds ([RFC4513], Section 5.1) or when using SASL [RFC4422] authentication ([RFC4513], Section 5.2). Where the server attempts to locate the named object, it SHALL NOT perform alias dereferencing.
- 名称：如果不为空，则为客户端希望绑定为的目录对象的名称。出于匿名绑定（[RFC4513]，第5.1节）或使用SASL[RFC4422]身份验证（[RFC4513]，第5.2节）的目的，此字段可能采用空值（零长度字符串）。如果服务器试图定位命名对象，则不应执行别名取消引用。
- authentication: Information used in authentication. This type is extensible as defined in Section 3.7 of [RFC4520]. Servers that do not support a choice supplied by a client return a BindResponse with the resultCode set to authMethodNotSupported.
- 身份验证：用于身份验证的信息。该类型可根据[RFC4520]第3.7节的规定进行扩展。不支持客户端提供的选项的服务器返回BindResponse，resultCode设置为authMethodNotSupported。
Textual passwords (consisting of a character sequence with a known character set and encoding) transferred to the server using the simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629] encoded [Unicode]. Prior to transfer, clients SHOULD prepare text passwords as "query" strings by applying the SASLprep [RFC4013] profile of the stringprep [RFC3454] algorithm. Passwords consisting of other data (such as random octets) MUST NOT be altered. The determination of whether a password is textual is a local client matter.
使用simple AuthenticationChoice传输到服务器的文本密码（由具有已知字符集和编码的字符序列组成）应作为UTF-8[RFC3629]编码的[Unicode]传输。在传输之前，客户端应通过应用stringprep[RFC3454]算法的SASLprep[RFC4013]配置文件，准备文本密码作为“查询”字符串。由其他数据（如随机八位字节）组成的密码不得更改。确定密码是否为文本密码是本地客户端的问题。
Before processing a BindRequest, all uncompleted operations MUST either complete or be abandoned. The server may either wait for the uncompleted operations to complete, or abandon them. The server then proceeds to authenticate the client in either a single-step or multi-step Bind process. Each step requires the server to return a BindResponse to indicate the status of authentication.
在处理BindRequest之前，必须完成或放弃所有未完成的操作。服务器可以等待未完成的操作完成，也可以放弃这些操作。然后，服务器通过单步或多步绑定过程对客户端进行身份验证。每个步骤都要求服务器返回一个BindResponse，以指示身份验证的状态。
After sending a BindRequest, clients MUST NOT send further LDAP PDUs until receiving the BindResponse. Similarly, servers SHOULD NOT process or respond to requests received while processing a BindRequest.
发送BindRequest后，客户端在收到BindRequest响应之前不得再发送LDAP PDU。同样，服务器不应处理或响应在处理BindRequest时收到的请求。
If the client did not bind before sending a request and receives an operationsError to that request, it may then send a BindRequest. If this also fails or the client chooses not to bind on the existing LDAP session, it may terminate the LDAP session, re-establish it, and begin again by first sending a BindRequest. This will aid in interoperating with servers implementing other versions of LDAP.
如果客户端在发送请求之前未绑定，并且收到该请求的operationsError，则可能会发送BindRequest。如果此操作也失败，或者客户端选择不绑定现有LDAP会话，它可能会终止LDAP会话，重新建立它，然后通过首先发送BindRequest重新开始。这将有助于与实现其他版本LDAP的服务器进行互操作。
Clients may send multiple Bind requests to change the authentication and/or security associations or to complete a multi-stage Bind process. Authentication from earlier binds is subsequently ignored.
客户端可以发送多个绑定请求以更改身份验证和/或安全关联，或完成多阶段绑定过程。来自早期绑定的身份验证随后被忽略。
For some SASL authentication mechanisms, it may be necessary for the client to invoke the BindRequest multiple times ([RFC4513], Section 5.2). Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage Bind.
对于某些SASL身份验证机制，客户端可能需要多次调用BindRequest（[RFC4513]，第5.2节）。客户端不得在作为多级绑定的一部分发出的两个绑定请求之间调用操作。
A client may abort a SASL bind negotiation by sending a BindRequest with a different value in the mechanism field of SaslCredentials, or an AuthenticationChoice other than sasl.
客户端可以通过在SaslCredentials的mechanism字段中发送具有不同值的BindRequest或SASL以外的AuthenticationChoice来中止SASL绑定协商。
If the client sends a BindRequest with the sasl mechanism field as an empty string, the server MUST return a BindResponse with the resultCode set to authMethodNotSupported. This will allow the client to abort a negotiation if it wishes to try again with the same SASL mechanism.
如果客户端以空字符串形式发送带有sasl机制字段的BindRequest，则服务器必须返回一个BindResponse，并将resultCode设置为authMethodNotSupported。这将允许客户端在希望使用相同的SASL机制重试时中止协商。
The Bind response is defined as follows.
绑定响应的定义如下。
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse consists simply of an indication from the server of the status of the client's request for authentication.
BindResponse只包含服务器对客户端身份验证请求状态的指示。
A successful Bind operation is indicated by a BindResponse with a resultCode set to success. Otherwise, an appropriate result code is set in the BindResponse. For BindResponse, the protocolError result code may be used to indicate that the version number supplied by the client is unsupported.
成功的绑定操作由resultCode设置为success的BindResponse指示。否则，将在BindResponse中设置适当的结果代码。对于BindResponse，protocolError结果代码可用于指示客户端提供的版本号不受支持。
If the client receives a BindResponse where the resultCode is set to protocolError, it is to assume that the server does not support this version of LDAP. While the client may be able proceed with another version of this protocol (which may or may not require closing and re-establishing the transport connection), how to proceed with another version of this protocol is beyond the scope of this document. Clients that are unable or unwilling to proceed SHOULD terminate the LDAP session.
如果客户端接收到一个BindResponse，其中resultCode设置为protocolError，则假定服务器不支持此版本的LDAP。虽然客户端可以继续使用本协议的另一版本（可能需要也可能不需要关闭和重新建立传输连接），但如何继续使用本协议的另一版本超出了本文档的范围。无法或不愿意继续的客户端应终止LDAP会话。
The serverSaslCreds field is used as part of a SASL-defined bind mechanism to allow the client to authenticate the server to which it is communicating, or to perform "challenge-response" authentication. If the client bound with the simple choice, or the SASL mechanism does not require the server to return information to the client, then this field SHALL NOT be included in the BindResponse.
ServerSASLCLEDS字段用作SASL定义的绑定机制的一部分，以允许客户端对其通信的服务器进行身份验证，或执行“质询-响应”身份验证。如果客户端绑定了简单选项，或者SASL机制不要求服务器向客户端返回信息，则该字段不应包含在BindResponse中。
The function of the Unbind operation is to terminate an LDAP session. The Unbind operation is not the antithesis of the Bind operation as the name implies. The naming of these operations are historical. The Unbind operation should be thought of as the "quit" operation.
解除绑定操作的功能是终止LDAP会话。取消绑定操作并不是顾名思义的绑定操作的对立面。这些操作的命名是历史性的。解除绑定操作应视为“退出”操作。
The Unbind operation is defined as follows:
解除绑定操作的定义如下：
UnbindRequest ::= [APPLICATION 2] NULL
UnbindRequest ::= [APPLICATION 2] NULL
The client, upon transmission of the UnbindRequest, and the server, upon receipt of the UnbindRequest, are to gracefully terminate the LDAP session as described in Section 5.3. Uncompleted operations are handled as specified in Section 3.1.
客户端在传输解除绑定请求时，服务器在接收到解除绑定请求时，将按照第5.3节所述正常终止LDAP会话。未完成的操作按照第3.1节的规定进行处理。
An unsolicited notification is an LDAPMessage sent from the server to the client that is not in response to any LDAPMessage received by the server. It is used to signal an extraordinary condition in the server or in the LDAP session between the client and the server. The notification is of an advisory nature, and the server will not expect any response to be returned from the client.
未经请求的通知是从服务器发送到客户端的LDAPMessage，它不响应服务器接收到的任何LDAPMessage。它用于表示服务器中或客户端与服务器之间的LDAP会话中出现异常情况。通知具有咨询性质，服务器不希望从客户端返回任何响应。
The unsolicited notification is structured as an LDAPMessage in which the messageID is zero and protocolOp is set to the extendedResp choice using the ExtendedResponse type (See Section 4.12). The responseName field of the ExtendedResponse always contains an LDAPOID that is unique for this notification.
未经请求的通知被构造为LDAPMessage，其中messageID为零，protocolOp使用ExtendedResponse类型设置为extendedResp选项（参见第4.12节）。ExtendedResponse的responseName字段始终包含此通知唯一的LDAPOID。
One unsolicited notification (Notice of Disconnection) is defined in this document. The specification of an unsolicited notification consists of:
本文件中定义了一个未经请求的通知（断开通知）。非邀约通知的说明包括：
- the OBJECT IDENTIFIER assigned to the notification (to be specified in the responseName,
- 分配给通知的对象标识符（将在响应名称中指定，
- the format of the contents of the responseValue (if any),
- 响应值内容的格式（如有），
- the circumstances which will cause the notification to be sent, and
- 导致发送通知的情况，以及
- the semantics of the message.
- 消息的语义。
This notification may be used by the server to advise the client that the server is about to terminate the LDAP session on its own initiative. This notification is intended to assist clients in distinguishing between an exceptional server condition and a transient network failure. Note that this notification is not a response to an Unbind requested by the client. Uncompleted operations are handled as specified in Section 3.1.
服务器可以使用此通知通知客户端服务器将主动终止LDAP会话。此通知旨在帮助客户端区分异常服务器状况和瞬时网络故障。请注意，此通知不是对客户端请求的解除绑定的响应。未完成的操作按照第3.1节的规定进行处理。
The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field is absent, and the resultCode is used to indicate the reason for the disconnection. When the strongerAuthRequired resultCode is returned with this message, it indicates that the server has detected that an established security association between the client and server has unexpectedly failed or been compromised.
responseName为1.3.6.1.4.1.1466.20036，responseValue字段不存在，resultCode用于指示断开连接的原因。当此消息返回strongerAuthRequired resultCode时，表示服务器已检测到客户端和服务器之间建立的安全关联意外失败或受损。
Upon transmission of the Notice of Disconnection, the server gracefully terminates the LDAP session as described in Section 5.3.
在发送断开连接通知后，服务器会按照第5.3节中的说明正常终止LDAP会话。
The Search operation is used to request a server to return, subject to access controls and other restrictions, a set of entries matching a complex search criterion. This can be used to read attributes from a single entry, from entries immediately subordinate to a particular entry, or from a whole subtree of entries.
搜索操作用于请求服务器根据访问控制和其他限制返回一组匹配复杂搜索条件的条目。这可用于从单个条目、直接从属于特定条目的条目或整个条目子树中读取属性。
The Search request is defined as follows:
搜索请求定义如下：
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
AttributeSelection ::= SEQUENCE OF selector LDAPString
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.8
AttributeSelection ::= SEQUENCE OF selector LDAPString
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.8
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] MatchingRuleAssertion, ... }
equalityMatch[3]AttributeValueAssertion，Substring[4]SubstringFilter，GreaterEqual[5]AttributeValueAssertion，lessOrEqual[6]AttributeValueAssertion，present[7]AttributeDescription，ApproverMatch[8]AttributeValueAssertion，ExtensionalMatch[9]Matching RuleAssertion，…}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue, -- can occur at most once
any [1] AssertionValue,
final [2] AssertionValue } -- can occur at most once
}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue, -- can occur at most once
any [1] AssertionValue,
final [2] AssertionValue } -- can occur at most once
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
Note that an X.500 "list"-like operation can be emulated by the client requesting a singleLevel Search operation with a filter checking for the presence of the 'objectClass' attribute, and that an X.500 "read"-like operation can be emulated by a baseObject Search operation with the same filter. A server that provides a gateway to X.500 is not required to use the Read or List operations, although it may choose to do so, and if it does, it must provide the same semantics as the X.500 Search operation.
请注意，请求单级搜索操作的客户端可以模拟类似X.500“列表”的操作，并使用筛选器检查“objectClass”属性的存在情况，而类似X.500“读取”的操作可以由具有相同筛选器的baseObject搜索操作模拟。提供X.500网关的服务器不需要使用读取或列表操作，尽管它可以选择这样做，如果选择，它必须提供与X.500搜索操作相同的语义。
The name of the base object entry (or possibly the root) relative to which the Search is to be performed.
要执行搜索的基础对象项（或根）的名称。
Specifies the scope of the Search to be performed. The semantics (as described in [X.511]) of the defined values of this field are:
指定要执行的搜索的范围。该字段定义值的语义（如[X.511]所述）为：
baseObject: The scope is constrained to the entry named by baseObject.
baseObject：范围被约束到由baseObject命名的条目。
singleLevel: The scope is constrained to the immediate subordinates of the entry named by baseObject.
singleLevel：范围被约束到由baseObject命名的条目的直接下级。
wholeSubtree: The scope is constrained to the entry named by baseObject and to all its subordinates.
批发性子目录树：范围被约束到由baseObject命名的条目及其所有下级。
An indicator as to whether or not alias entries (as defined in [RFC4512]) are to be dereferenced during stages of the Search operation.
关于在搜索操作的各个阶段是否取消引用别名条目（如[RFC4512]中定义）的指示符。
The act of dereferencing an alias includes recursively dereferencing aliases that refer to aliases.
取消引用别名的行为包括递归取消引用引用别名的别名。
Servers MUST detect looping while dereferencing aliases in order to prevent denial-of-service attacks of this nature.
服务器在解引用别名时必须检测循环，以防止这种性质的拒绝服务攻击。
The semantics of the defined values of this field are:
该字段定义值的语义如下：
neverDerefAliases: Do not dereference aliases in searching or in locating the base object of the Search.
Neverderefalias：在搜索或定位搜索的基本对象时不要取消引用别名。
derefInSearching: While searching subordinates of the base object, dereference any alias within the search scope. Dereferenced objects become the vertices of further search scopes where the Search operation is also applied. If the search scope is wholeSubtree, the Search continues in the subtree(s) of any dereferenced object. If the search scope is singleLevel, the search is applied to any dereferenced objects and is not applied to their subordinates. Servers SHOULD eliminate duplicate entries that arise due to alias dereferencing while searching.
解引用搜索：在搜索基础对象的从属对象时，解引用搜索范围内的任何别名。解引用对象将成为进一步搜索范围的顶点，搜索操作也将应用于此范围。如果搜索范围为整子树，则搜索将在任何未引用对象的子树中继续。如果搜索范围为singleLevel，则搜索将应用于任何取消引用的对象，而不应用于其下属对象。服务器应消除搜索时由于别名取消引用而产生的重复条目。
derefFindingBaseObj: Dereference aliases in locating the base object of the Search, but not when searching subordinates of the base object.
解除引用BaseObj：在定位搜索的基础对象时解除对别名的引用，但在搜索基础对象的从属对象时不解除对别名的引用。
derefAlways: Dereference aliases both in searching and in locating the base object of the Search.
取消引用别名：在搜索和定位搜索的基本对象时取消引用别名。
A size limit that restricts the maximum number of entries to be returned as a result of the Search. A value of zero in this field indicates that no client-requested size limit restrictions are in effect for the Search. Servers may also enforce a maximum number of entries to return.
限制搜索结果返回的最大条目数的大小限制。此字段中的值为零表示没有对搜索生效的客户端请求的大小限制。服务器还可以强制执行要返回的最大条目数。
A time limit that restricts the maximum time (in seconds) allowed for a Search. A value of zero in this field indicates that no client-requested time limit restrictions are in effect for the Search. Servers may also enforce a maximum time limit for the Search.
限制允许搜索的最长时间（以秒为单位）的时间限制。此字段中的值为零表示客户端请求的时间限制对搜索无效。服务器还可能强制执行搜索的最长时间限制。
An indicator as to whether Search results are to contain both attribute descriptions and values, or just attribute descriptions. Setting this field to TRUE causes only attribute descriptions (and not values) to be returned. Setting this field to FALSE causes both attribute descriptions and values to be returned.
指示搜索结果是同时包含属性描述和值，还是仅包含属性描述。将此字段设置为TRUE将只返回属性描述（而不是值）。将此字段设置为FALSE会导致返回属性描述和值。
A filter that defines the conditions that must be fulfilled in order for the Search to match a given entry.
一个筛选器，定义搜索匹配给定条目所必须满足的条件。
The 'and', 'or', and 'not' choices can be used to form combinations of filters. At least one filter element MUST be present in an 'and' or 'or' choice. The others match against individual attribute values of entries in the scope of the Search. (Implementor's note: the 'not' filter is an example of a tagged choice in an implicitly-tagged module. In BER this is treated as if the tag were explicit.)
“and”、“or”和“not”选项可用于形成过滤器的组合。“和”或“或”选项中必须至少有一个滤芯。其他属性值与搜索范围内条目的单个属性值匹配。（实施者注意：'not'过滤器是隐式标记模块中标记选项的一个示例。在BER中，这被视为标记是显式的。）
A server MUST evaluate filters according to the three-valued logic of [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for a particular entry, then the attributes of that entry are returned as part of the Search result (subject to any applicable access control restrictions). If the filter evaluates to FALSE or Undefined, then the entry is ignored for the Search.
服务器必须根据[X.511]（1993）第7.8.1条中的三值逻辑对过滤器进行评估。总之，过滤器的计算结果为“真”、“假”或“未定义”。如果特定条目的筛选结果为TRUE，则该条目的属性将作为搜索结果的一部分返回（受任何适用的访问控制限制的约束）。如果筛选器的计算结果为FALSE或Undefined，则将忽略该条目进行搜索。
A filter of the "and" choice is TRUE if all the filters in the SET OF evaluate to TRUE, FALSE if at least one filter is FALSE, and Undefined otherwise. A filter of the "or" choice is FALSE if all the filters in the SET OF evaluate to FALSE, TRUE if at least one filter is TRUE, and Undefined otherwise. A filter of the 'not' choice is TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and Undefined if it is Undefined.
如果集合中的所有筛选器都计算为TRUE，则选择“和”的筛选器为TRUE；如果至少有一个筛选器为FALSE，则选择FALSE；否则选择“未定义”。如果集合中的所有筛选器都计算为FALSE，则“或”选项的筛选器为FALSE；如果至少有一个筛选器为TRUE，则为TRUE；否则为未定义。如果要求反的筛选器为FALSE，则“not”选项的筛选器为TRUE；如果为TRUE，则为FALSE；如果未定义，则为Undefined。
A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. Examples include:
当服务器无法确定断言值是否与条目匹配时，筛选器项的计算结果为未定义。例子包括：
- An attribute description in an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter is not recognized by the server.
- 服务器无法识别equalityMatch、Substring、GreaterEqual、lessOrEqual、approxMatch或ExtensionMatch筛选器中的属性描述。
- The attribute type does not define the appropriate matching rule.
- 属性类型未定义适当的匹配规则。
- A MatchingRuleId in the extensibleMatch is not recognized by the server or is not valid for the attribute type.
- 服务器无法识别ExtensionMatch中的MatchingRuleId，或者该RuleId对于属性类型无效。
- The type of filtering requested is not implemented.
- 未实现请求的筛选类型。
- The assertion value is invalid.
- 断言值无效。
For example, if a server did not recognize the attribute type shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12), and (shoeSize<=12) would each evaluate to Undefined.
例如，如果服务器无法识别属性类型shoeSize，则过滤器（shoeSize=*）、（shoeSize=12）、（shoeSize>=12）和（shoeSize<=12）的计算结果都将为未定义。
Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, assertion values are invalid, or the assertion syntax is not supported. More details of filter processing are given in Clause 7.8 of [X.511].
如果无法识别属性描述或匹配规则ID、断言值无效或不支持断言语法，则服务器不得返回错误。[X.511]第7.8条给出了滤波器处理的更多细节。
The matching rule for an equalityMatch filter is defined by the EQUALITY matching rule for the attribute type or subtype. The filter is TRUE when the EQUALITY rule returns TRUE as applied to the attribute or subtype and the asserted value.
equalityMatch筛选器的匹配规则由属性类型或子类型的相等匹配规则定义。当应用于属性或子类型以及断言值的相等规则返回TRUE时，筛选器为TRUE。
There SHALL be at most one 'initial' and at most one 'final' in the 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL be the first element of 'substrings'. If 'final' is present, it SHALL be the last element of 'substrings'.
子字符串过滤器的“子字符串”中最多应有一个“初始”和一个“最终”。如果存在“首字母”，则应为“子字符串”的第一个元素。如果存在“final”，则应为“substring”的最后一个元素。
The matching rule for an AssertionValue in a substrings filter item is defined by the SUBSTR matching rule for the attribute type or subtype. The filter is TRUE when the SUBSTR rule returns TRUE as applied to the attribute or subtype and the asserted value.
子字符串筛选器项中AssertionValue的匹配规则由属性类型或子类型的SUBSTR匹配规则定义。当SUBSTR规则返回应用于属性或子类型以及断言值的TRUE时，过滤器为TRUE。
Note that the AssertionValue in a substrings filter item conforms to the assertion syntax of the EQUALITY matching rule for the attribute type rather than to the assertion syntax of the SUBSTR matching rule for the attribute type. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule.
请注意，子字符串筛选器项中的AssertionValue符合属性类型的相等匹配规则的断言语法，而不是符合属性类型的子字符串匹配规则的断言语法。从概念上讲，在应用子字符串匹配规则之前，将整个子字符串筛选器转换为子字符串匹配规则的断言值。
The matching rule for a greaterOrEqual filter is defined by the ORDERING matching rule for the attribute type or subtype. The filter is TRUE when the ORDERING rule returns FALSE as applied to the attribute or subtype and the asserted value.
GreaterEqual筛选器的匹配规则由属性类型或子类型的排序匹配规则定义。当应用于属性或子类型以及断言值的排序规则返回FALSE时，过滤器为TRUE。
The matching rules for a lessOrEqual filter are defined by the ORDERING and EQUALITY matching rules for the attribute type or subtype. The filter is TRUE when either the ORDERING or EQUALITY rule returns TRUE as applied to the attribute or subtype and the asserted value.
lessOrEqual筛选器的匹配规则由属性类型或子类型的排序和相等匹配规则定义。当应用于属性或子类型以及断言值的排序规则或相等规则返回TRUE时，筛选器为TRUE。
A present filter is TRUE when there is an attribute or subtype of the specified attribute description present in an entry, FALSE when no attribute or subtype of the specified attribute description is present in an entry, and Undefined otherwise.
当条目中存在指定属性描述的属性或子类型时，当前筛选器为TRUE；当条目中不存在指定属性描述的属性或子类型时，当前筛选器为FALSE，否则未定义。
An approxMatch filter is TRUE when there is a value of the attribute type or subtype for which some locally-defined approximate matching algorithm (e.g., spelling variations, phonetic match, etc.) returns TRUE. If a value matches for equality, it also satisfies an approximate match. If approximate matching is not supported for the attribute, this filter item should be treated as an equalityMatch.
当某个本地定义的近似匹配算法（例如拼写变体、语音匹配等）返回的属性类型或子类型值为TRUE时，approxMatch筛选器为TRUE。如果某个值匹配相等，则它也满足近似匹配。如果属性不支持近似匹配，则应将此筛选器项视为equalityMatch。
The fields of the extensibleMatch filter item are evaluated as follows:
extensibleMatch筛选器项的字段计算如下：
- If the matchingRule field is absent, the type field MUST be present, and an equality match is performed for that type.
- 如果不存在matchingRule字段，则类型字段必须存在，并对该类型执行相等匹配。
- If the type field is absent and the matchingRule is present, the matchValue is compared against all attributes in an entry that support that matchingRule.
- 如果缺少类型字段且存在matchingRule，则会将MatchingValue与支持该matchingRule的条目中的所有属性进行比较。
- If the type field is present and the matchingRule is present, the matchValue is compared against the specified attribute type and its subtypes.
- 如果存在类型字段且存在匹配规则，则会将匹配值与指定的属性类型及其子类型进行比较。
- If the dnAttributes field is set to TRUE, the match is additionally applied against all the AttributeValueAssertions in an entry's distinguished name, and it evaluates to TRUE if there is at least one attribute or subtype in the distinguished name for which the filter item evaluates to TRUE. The dnAttributes field is present to alleviate the need for multiple versions of generic matching rules (such as word matching), where one applies to entries and another applies to entries and DN attributes as well.
- 如果dnAttributes字段设置为TRUE，则会对条目的可分辨名称中的所有AttributeValueAssertions应用匹配，如果可分辨名称中至少有一个属性或子类型的筛选项计算结果为TRUE，则匹配结果为TRUE。dnAttributes字段的存在是为了减少对多个版本的通用匹配规则（如单词匹配）的需要，其中一个适用于条目，另一个也适用于条目和DN属性。
The matchingRule used for evaluation determines the syntax for the assertion value. Once the matchingRule and attribute(s) have been determined, the filter item evaluates to TRUE if it matches at least one attribute type or subtype in the entry, FALSE if it does not match any attribute type or subtype in the entry, and Undefined if the matchingRule is not recognized, the matchingRule is unsuitable for use with the specified type, or the assertionValue is invalid.
用于求值的matchingRule确定断言值的语法。确定matchingRule和属性后，如果筛选项与条目中的至少一个属性类型或子类型匹配，则筛选项的计算结果为TRUE；如果筛选项与条目中的任何属性类型或子类型不匹配，则为FALSE；如果未识别matchingRule，则未定义筛选项，则matchingRule不适合与指定类型一起使用，或者断言值无效。
A selection list of the attributes to be returned from each entry that matches the search filter. Attributes that are subtypes of listed attributes are implicitly included. LDAPString values of this field are constrained to the following Augmented Backus-Naur Form (ABNF) [RFC4234]:
要从与搜索筛选器匹配的每个条目返回的属性的选择列表。作为所列属性的子类型的属性将隐式包含。此字段的LDAPString值被限制为以下扩展的Backus Naur形式（ABNF）[RFC4234]：
attributeSelector = attributedescription / selectorspecial
attributeSelector = attributedescription / selectorspecial
selectorspecial = noattrs / alluserattrs
selectorspecial = noattrs / alluserattrs
noattrs = %x31.2E.31 ; "1.1"
noattrs = %x31.2E.31 ; "1.1"
alluserattrs = %x2A ; asterisk ("*")
alluserattrs = %x2A ; asterisk ("*")
The <attributedescription> production is defined in Section 2.5 of [RFC4512].
[RFC4512]第2.5节定义了<attributedescription>生产。
There are three special cases that may appear in the attributes selection list:
属性选择列表中可能出现三种特殊情况：
1. An empty list with no attributes requests the return of all user attributes.
1. 没有属性的空列表请求返回所有用户属性。
2. A list containing "*" (with zero or more attribute descriptions) requests the return of all user attributes in addition to other listed (operational) attributes.
2. 包含“*”（具有零个或多个属性描述）的列表请求返回所有用户属性以及其他列出的（操作）属性。
3. A list containing only the OID "1.1" indicates that no attributes are to be returned. If "1.1" is provided with other attributeSelector values, the "1.1" attributeSelector is ignored. This OID was chosen because it does not (and can not) correspond to any attribute in use.
3. 仅包含OID“1.1”的列表表示不返回任何属性。如果为“1.1”提供了其他属性选择器值，“1.1”属性选择器将被忽略。选择此OID是因为它不（也不能）对应于正在使用的任何属性。
Client implementors should note that even if all user attributes are requested, some attributes and/or attribute values of the entry may not be included in Search results due to access controls or other restrictions. Furthermore, servers will not return operational attributes, such as objectClasses or attributeTypes, unless they are listed by name. Operational attributes are described in [RFC4512].
客户机实现人员应该注意，即使请求了所有用户属性，由于访问控制或其他限制，条目的某些属性和/或属性值也可能不包括在搜索结果中。此外，服务器不会返回操作属性，如ObjectClass或AttributeType，除非它们按名称列出。[RFC4512]中描述了操作属性。
Attributes are returned at most once in an entry. If an attribute description is named more than once in the list, the subsequent names are ignored. If an attribute description in the list is not recognized, it is ignored by the server.
属性在条目中最多返回一次。如果属性描述在列表中多次命名，则忽略后续名称。如果列表中的属性描述无法识别，则服务器将忽略该属性描述。
The results of the Search operation are returned as zero or more SearchResultEntry and/or SearchResultReference messages, followed by a single SearchResultDone message.
搜索操作的结果返回为零条或多条SearchResultEntry和/或SearchResultReference消息，然后是一条SearchResultOne消息。
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone ::= [APPLICATION 5] LDAPResult
Each SearchResultEntry represents an entry found during the Search. Each SearchResultReference represents an area not yet explored during the Search. The SearchResultEntry and SearchResultReference messages may come in any order. Following all the SearchResultReference and SearchResultEntry responses, the server returns a SearchResultDone response, which contains an indication of success or details any errors that have occurred.
每个SearchResultEntry表示在搜索过程中找到的条目。每个SearchResultReference表示搜索期间尚未探索的区域。SearchResultEntry和SearchResultReference消息可能以任何顺序出现。在所有SearchResultReference和SearchResultEntry响应之后，服务器返回一个SearchResultOne响应，其中包含成功的指示或已发生的任何错误的详细信息。
Each entry returned in a SearchResultEntry will contain all appropriate attributes as specified in the attributes field of the Search Request, subject to access control and other administrative policy. Note that the PartialAttributeList may hold zero elements.
SearchResultEntry中返回的每个条目都将包含搜索请求的属性字段中指定的所有适当属性，并受访问控制和其他管理策略的约束。请注意，PartialAttributeList可能包含零个元素。
This may happen when none of the attributes of an entry were requested or could be returned. Note also that the partialAttribute vals set may hold zero elements. This may happen when typesOnly is requested, access controls prevent the return of values, or other reasons.
当没有请求或无法返回条目的任何属性时，可能会发生这种情况。还要注意，partialAttribute VAL集合可能包含零个元素。这可能发生在仅请求类型、访问控制阻止返回值或其他原因时。
Some attributes may be constructed by the server and appear in a SearchResultEntry attribute list, although they are not stored attributes of an entry. Clients SHOULD NOT assume that all attributes can be modified, even if this is permitted by access control.
有些属性可能由服务器构造并显示在SearchResultEntry属性列表中，尽管它们不是条目的存储属性。客户端不应假定所有属性都可以修改，即使访问控制允许这样做。
If the server's schema defines short names [RFC4512] for an attribute type, then the server SHOULD use one of those names in attribute descriptions for that attribute type (in preference to using the <numericoid> [RFC4512] format of the attribute type's object identifier). The server SHOULD NOT use the short name if that name is known by the server to be ambiguous, or if it is otherwise likely to cause interoperability problems.
如果服务器的架构为属性类型定义了短名称[RFC4512]，则服务器应在该属性类型的属性描述中使用这些名称之一（优先于使用属性类型的对象标识符的<numericoid>[RFC4512]格式）。如果服务器知道短名称不明确，或者可能导致互操作性问题，则服务器不应使用该短名称。
If the server was able to locate the entry referred to by the baseObject but was unable or unwilling to search one or more non-local entries, the server may return one or more SearchResultReference messages, each containing a reference to another set of servers for continuing the operation. A server MUST NOT return any SearchResultReference messages if it has not located the baseObject and thus has not searched any entries. In this case, it would return a SearchResultDone containing either a referral or noSuchObject result code (depending on the server's knowledge of the entry named in the baseObject).
如果服务器能够找到baseObject引用的条目，但无法或不愿意搜索一个或多个非本地条目，则服务器可能会返回一个或多个SearchResultReference消息，每个消息都包含对另一组服务器的引用，以便继续操作。如果服务器未找到baseObject，因此未搜索任何条目，则不得返回任何SearchResultReference消息。在这种情况下，它将返回一个SearchResultOne，其中包含一个引用或noSuchObject结果代码（取决于服务器对baseObject中指定的条目的了解）。
If a server holds a copy or partial copy of the subordinate naming context (Section 5 of [RFC4512]), it may use the search filter to determine whether or not to return a SearchResultReference response. Otherwise, SearchResultReference responses are always returned when in scope.
如果服务器持有从属命名上下文（RFC4512）的副本或部分副本，则可以使用搜索筛选器确定是否返回SearchResultReference响应。否则，SearchResultReference响应总是在范围内返回。
The SearchResultReference is of the same data type as the Referral.
SearchResultReference与引用的数据类型相同。
If the client wishes to progress the Search, it issues a new Search operation for each SearchResultReference that is returned. If multiple URIs are present, the client assumes that any supported URI may be used to progress the operation.
如果客户端希望进行搜索，则会对返回的每个SearchResultReference发出新的搜索操作。如果存在多个URI，则客户端会假定任何受支持的URI都可用于执行操作。
Clients that follow search continuation references MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters. Some clients use a counter that is incremented each time search result reference handling occurs for an operation, and these kinds of clients MUST be able to handle at least ten nested referrals while progressing the operation.
遵循搜索继续引用的客户端必须确保它们不会在服务器之间循环。对于具有相同参数的相同请求，他们不得重复联系同一服务器。某些客户端使用的计数器在每次操作的搜索结果引用处理时递增，并且这些类型的客户端必须能够在执行操作时处理至少十个嵌套引用。
Note that the Abandon operation described in Section 4.11 applies only to a particular operation sent at the LDAP message layer between a client and server. The client must individually abandon subsequent Search operations it wishes to.
请注意，第4.11节中描述的放弃操作仅适用于在客户端和服务器之间的LDAP消息层发送的特定操作。客户端必须单独放弃其希望执行的后续搜索操作。
A URI for a server implementing LDAP and accessible via TCP/IP (v4 or v6) [RFC793][RFC791] is written as an LDAP URL according to [RFC4516].
实现LDAP并可通过TCP/IP（v4或v6）[RFC793][RFC791]访问的服务器的URI根据[RFC4516]写入为LDAP URL。
SearchResultReference values that are LDAP URLs follow these rules:
作为LDAP URL的SearchResultReference值遵循以下规则：
- The <dn> part of the LDAP URL MUST be present, with the new target object name. The client uses this name when following the reference.
- LDAP URL的<dn>部分必须存在，并且具有新的目标对象名称。客户端在遵循引用时使用此名称。
- Some servers (e.g., participating in distributed indexing) may provide a different filter in the LDAP URL.
- 某些服务器（例如，参与分布式索引）可能在LDAP URL中提供不同的筛选器。
- If the <filter> part of the LDAP URL is present, the client uses this filter in its next request to progress this Search, and if it is not present the client uses the same filter as it used for that Search.
- 如果LDAP URL的<filter>部分存在，则客户端在其下一个请求中使用此筛选器来进行此搜索，如果不存在此筛选器，则客户端使用与该搜索相同的筛选器。
- If the originating search scope was singleLevel, the <scope> part of the LDAP URL will be "base".
- 如果原始搜索范围是单级的，LDAP URL的<scope>部分将是“base”。
- It is RECOMMENDED that the <scope> part be present to avoid ambiguity. In the absence of a <scope> part, the scope of the original Search request is assumed.
- 建议出现<scope>部分，以避免歧义。如果没有<scope>部分，则假定原始搜索请求的范围。
- Other aspects of the new Search request may be the same as or different from the Search request that generated the SearchResultReference.
- 新搜索请求的其他方面可能与生成SearchResultReference的搜索请求相同或不同。
- The name of an unexplored subtree in a SearchResultReference need not be subordinate to the base object.
- SearchResultReference中未探索子树的名称不必从属于基对象。
Other kinds of URIs may be returned. The syntax and semantics of such URIs is left to future specifications. Clients may ignore URIs that they do not support.
可能会返回其他类型的URI。此类URI的语法和语义留待将来的规范决定。客户端可能会忽略它们不支持的URI。
UTF-8-encoded characters appearing in the string representation of a DN, search filter, or other fields of the referral value may not be legal for URIs (e.g., spaces) and MUST be escaped using the % method in [RFC3986].
DN、搜索筛选器或引用值的其他字段的字符串表示形式中出现的UTF-8编码字符对于URI（例如空格）可能不合法，必须使用[RFC3986]中的%方法进行转义。
For example, suppose the contacted server (hosta) holds the entry <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It knows that both LDAP servers (hostb) and (hostc) hold <OU=People,DC=Example,DC=NET> (one is the master and the other server a shadow), and that LDAP-capable server (hostd) holds the subtree <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of <DC=Example,DC=NET> is requested to the contacted server, it may return the following:
例如，假设联系的服务器（hosta）持有条目<DC=example，DC=NET>和条目<CN=Manager，DC=example，DC=NET>。它知道LDAP服务器（hostb）和（hostc）都持有<OU=People，DC=Example，DC=NET>（一个是主服务器，另一个是影子服务器），并且支持LDAP的服务器（hostd）持有子树<OU=Roles，DC=Example，DC=NET>。如果向联系的服务器请求<DC=Example，DC=NET>的整体子树搜索，它可能会返回以下内容：
SearchResultEntry for DC=Example,DC=NET
SearchResultEntry for CN=Manager,DC=Example,DC=NET
SearchResultReference {
ldap://hostb/OU=People,DC=Example,DC=NET??sub
ldap://hostc/OU=People,DC=Example,DC=NET??sub }
SearchResultReference {
ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
SearchResultDone (success)
SearchResultEntry for DC=Example,DC=NET
SearchResultEntry for CN=Manager,DC=Example,DC=NET
SearchResultReference {
ldap://hostb/OU=People,DC=Example,DC=NET??sub
ldap://hostc/OU=People,DC=Example,DC=NET??sub }
SearchResultReference {
ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
SearchResultDone (success)
Client implementors should note that when following a SearchResultReference, additional SearchResultReference may be generated. Continuing the example, if the client contacted the server (hostb) and issued the Search request for the subtree <OU=People,DC=Example,DC=NET>, the server might respond as follows:
客户机实现者应该注意，当遵循SearchResultReference时，可能会生成额外的SearchResultReference。继续该示例，如果客户端联系服务器（hostb）并发出子树的搜索请求<OU=People，DC=example，DC=NET>，则服务器可能会做出如下响应：
SearchResultEntry for OU=People,DC=Example,DC=NET
SearchResultReference {
ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
SearchResultReference {
ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
SearchResultDone (success)
SearchResultEntry for OU=People,DC=Example,DC=NET
SearchResultReference {
ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
SearchResultReference {
ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
SearchResultDone (success)
Similarly, if a singleLevel Search of <DC=Example,DC=NET> is requested to the contacted server, it may return the following:
类似地，如果向联系的服务器请求单级搜索<DC=Example，DC=NET>，它可能会返回以下内容：
SearchResultEntry for CN=Manager,DC=Example,DC=NET
SearchResultReference {
ldap://hostb/OU=People,DC=Example,DC=NET??base
ldap://hostc/OU=People,DC=Example,DC=NET??base }
SearchResultReference {
ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
SearchResultDone (success)
SearchResultEntry for CN=Manager,DC=Example,DC=NET
SearchResultReference {
ldap://hostb/OU=People,DC=Example,DC=NET??base
ldap://hostc/OU=People,DC=Example,DC=NET??base }
SearchResultReference {
ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
SearchResultDone (success)
If the contacted server does not hold the base object for the Search, but has knowledge of its possible location, then it may return a referral to the client. In this case, if the client requests a subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a SearchResultDone containing a referral.
如果联系的服务器不持有搜索的基本对象，但知道其可能的位置，则可能会向客户端返回引用。在这种情况下，如果客户端向hosta请求一个<DC=Example，DC=ORG>的子树搜索，服务器将返回一个包含引用的SearchResultDone。
SearchResultDone (referral) {
ldap://hostg/DC=Example,DC=ORG??sub }
SearchResultDone (referral) {
ldap://hostg/DC=Example,DC=ORG??sub }
The Modify operation allows a client to request that a modification of an entry be performed on its behalf by a server. The Modify Request is defined as follows:
修改操作允许客户端请求由服务器代表其执行对条目的修改。修改请求定义如下：
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
Fields of the Modify Request are:
修改请求的字段包括：
- object: The value of this field contains the name of the entry to be modified. The server SHALL NOT perform any alias dereferencing in determining the object to be modified.
- 对象：此字段的值包含要修改的条目的名称。在确定要修改的对象时，服务器不得执行任何别名解引用。
- changes: A list of modifications to be performed on the entry. The entire list of modifications MUST be performed in the order they are listed as a single atomic operation. While individual modifications may violate certain aspects of the directory schema (such as the object class definition and Directory Information Tree (DIT) content rule), the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory model and controlling schema [RFC4512].
- 更改：要对条目执行的修改列表。必须按照单个原子列表的顺序执行修改。虽然个别修改可能会违反目录模式的某些方面（如对象类定义和目录信息树（DIT）内容规则），但在执行整个修改列表后生成的条目必须符合目录模型和控制模式[RFC4512]的要求。
- operation: Used to specify the type of modification being performed. Each operation type acts on the following modification. The values of this field have the following semantics, respectively:
- 操作：用于指定正在执行的修改类型。每种操作类型都作用于以下修改。此字段的值分别具有以下语义：
add: add values listed to the modification attribute, creating the attribute if necessary.
添加：将列出的值添加到修改属性，必要时创建属性。
delete: delete values listed from the modification attribute. If no values are listed, or if all current values of the attribute are listed, the entire attribute is removed.
删除：删除修改属性中列出的值。如果未列出任何值，或者列出了属性的所有当前值，则将删除整个属性。
replace: replace all existing values of the modification attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and it is ignored if the attribute does not exist.
替换：使用列出的新值替换修改属性的所有现有值，如果该属性不存在，则创建该属性。如果属性存在，则替换为无值将删除整个属性，如果属性不存在，则忽略该替换。
- modification: A PartialAttribute (which may have an empty SET of vals) used to hold the attribute type or attribute type and values being modified.
- 修改：PartialAttribute（可能有一组空的VAL），用于保存要修改的属性类型或属性类型和值。
Upon receipt of a Modify Request, the server attempts to perform the necessary modifications to the DIT and returns the result in a Modify Response, defined as follows:
收到修改请求后，服务器尝试对DIT执行必要的修改，并在修改响应中返回结果，定义如下：
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse ::= [APPLICATION 7] LDAPResult
The server will return to the client a single Modify Response indicating either the successful completion of the DIT modification, or the reason that the modification failed. Due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIT have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify operation. Whether or not the modification was applied cannot be determined by the client if the Modify Response was not received (e.g., the LDAP session was terminated or the Modify operation was abandoned).
服务器将向客户端返回单个修改响应，指示DIT修改成功完成或修改失败的原因。由于在修改请求中应用修改列表的原子性要求，如果收到的修改响应表明存在任何类型的错误，则客户可能认为未对DIT进行修改，并且，如果修改响应指示修改操作成功完成，则已执行所有请求的修改。如果未收到修改响应（例如，LDAP会话已终止或修改操作已放弃），则客户端无法确定是否应用了修改。
Servers MUST ensure that entries conform to user and system schema rules or other data model constraints. The Modify operation cannot be used to remove from an entry any of its distinguished values, i.e., those values which form the entry's relative distinguished name. An attempt to do so will result in the server returning the notAllowedOnRDN result code. The Modify DN operation described in Section 4.9 is used to rename an entry.
服务器必须确保条目符合用户和系统架构规则或其他数据模型约束。“修改”操作不能用于从条目中删除其任何可分辨值，即构成条目相对可分辨名称的值。尝试这样做将导致服务器返回notAllowedOnRDN结果代码。第4.9节中描述的修改DN操作用于重命名条目。
For attribute types that specify no equality matching, the rules in Section 2.5.1 of [RFC4512] are followed.
对于未指定相等匹配的属性类型，遵循[RFC4512]第2.5.1节中的规则。
Note that due to the simplifications made in LDAP, there is not a direct mapping of the changes in an LDAP ModifyRequest onto the changes of a DAP ModifyEntry operation, and different implementations
请注意，由于在LDAP中进行了简化，因此没有将LDAP ModifyRequest中的更改直接映射到DAP ModifyEntry操作的更改以及不同的实现
of LDAP-DAP gateways may use different means of representing the change. If successful, the final effect of the operations on the entry MUST be identical.
不同的LDAP-DAP网关可能使用不同的方法来表示更改。如果成功，操作对条目的最终效果必须相同。
The Add operation allows a client to request the addition of an entry into the Directory. The Add Request is defined as follows:
添加操作允许客户端请求将条目添加到目录中。添加请求的定义如下：
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF attribute Attribute
AttributeList ::= SEQUENCE OF attribute Attribute
Fields of the Add Request are:
添加请求的字段包括：
- entry: the name of the entry to be added. The server SHALL NOT dereference any aliases in locating the entry to be added.
- 条目：要添加的条目的名称。在查找要添加的条目时，服务器不得取消引用任何别名。
- attributes: the list of attributes that, along with those from the RDN, make up the content of the entry being added. Clients MAY or MAY NOT include the RDN attribute(s) in this list. Clients MUST NOT supply NO-USER-MODIFICATION attributes such as the createTimestamp or creatorsName attributes, since the server maintains these automatically.
- 属性：与RDN中的属性一起构成要添加的条目内容的属性列表。客户端可能包括也可能不包括此列表中的RDN属性。客户端不能提供诸如createTimestamp或creatorsName等非用户修改属性，因为服务器会自动维护这些属性。
Servers MUST ensure that entries conform to user and system schema rules or other data model constraints. For attribute types that specify no equality matching, the rules in Section 2.5.1 of [RFC4512] are followed (this applies to the naming attribute in addition to any multi-valued attributes being added).
服务器必须确保条目符合用户和系统架构规则或其他数据模型约束。对于未指定相等匹配的属性类型，遵循[RFC4512]第2.5.1节中的规则（除添加的任何多值属性外，这适用于命名属性）。
The entry named in the entry field of the AddRequest MUST NOT exist for the AddRequest to succeed. The immediate superior (parent) of an object or alias entry to be added MUST exist. For example, if the client attempted to add <CN=JS,DC=Example,DC=NET>, the <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did exist, then the server would return the noSuchObject result code with the matchedDN field containing <DC=NET>.
AddRequest的条目字段中指定的条目必须不存在，AddRequest才能成功。要添加的对象或别名项的直接上级（父级）必须存在。例如，如果客户端试图添加<CN=JS，DC=example，DC=NET>，<DC=example，DC=NET>条目不存在，并且<DC=NET>条目确实存在，那么服务器将返回noSuchObject结果代码，其中matchedDN字段包含<DC=NET>。
Upon receipt of an Add Request, a server will attempt to add the requested entry. The result of the Add attempt will be returned to the client in the Add Response, defined as follows:
在收到添加请求后，服务器将尝试添加请求的条目。添加尝试的结果将在添加响应中返回给客户端，定义如下：
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse ::= [APPLICATION 9] LDAPResult
A response of success indicates that the new entry has been added to the Directory.
成功响应表示新条目已添加到目录中。
The Delete operation allows a client to request the removal of an entry from the Directory. The Delete Request is defined as follows:
删除操作允许客户端请求从目录中删除条目。删除请求的定义如下：
DelRequest ::= [APPLICATION 10] LDAPDN
DelRequest ::= [APPLICATION 10] LDAPDN
The Delete Request consists of the name of the entry to be deleted. The server SHALL NOT dereference aliases while resolving the name of the target entry to be removed.
删除请求由要删除的条目的名称组成。解析要删除的目标条目的名称时，服务器不得取消引用别名。
Only leaf entries (those with no subordinate entries) can be deleted with this operation.
此操作只能删除叶条目（没有从属条目的条目）。
Upon receipt of a Delete Request, a server will attempt to perform the entry removal requested and return the result in the Delete Response defined as follows:
在收到删除请求后，服务器将尝试执行请求的条目删除，并在定义如下的删除响应中返回结果：
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse ::= [APPLICATION 11] LDAPResult
The Modify DN operation allows a client to change the Relative Distinguished Name (RDN) of an entry in the Directory and/or to move a subtree of entries to a new location in the Directory. The Modify DN Request is defined as follows:
Modify DN操作允许客户端更改目录中条目的相对可分辨名称（RDN）和/或将条目子树移动到目录中的新位置。修改DN请求定义如下：
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
Fields of the Modify DN Request are:
修改DN请求的字段包括：
- entry: the name of the entry to be changed. This entry may or may not have subordinate entries.
- 条目：要更改的条目的名称。此条目可能有也可能没有从属条目。
- newrdn: the new RDN of the entry. The value of the old RDN is supplied when moving the entry to a new superior without changing its RDN. Attribute values of the new RDN not matching any attribute value of the entry are added to the entry, and an appropriate error is returned if this fails.
- newrdn：条目的新RDN。将条目移动到新上级而不更改其RDN时，将提供旧RDN的值。将与条目的任何属性值不匹配的新RDN的属性值添加到条目中，如果失败，将返回相应的错误。
- deleteoldrdn: a boolean field that controls whether the old RDN attribute values are to be retained as attributes of the entry or deleted from the entry.
- deleteoldrdn：一个布尔字段，用于控制旧RDN属性值是作为条目的属性保留还是从条目中删除。
- newSuperior: if present, this is the name of an existing object entry that becomes the immediate superior (parent) of the existing entry.
- newSuperior：如果存在，这是现有对象项的名称，该对象项将成为现有项的直接上级（父项）。
The server SHALL NOT dereference any aliases in locating the objects named in entry or newSuperior.
在查找entry或newSuperior中命名的对象时，服务器不得取消引用任何别名。
Upon receipt of a ModifyDNRequest, a server will attempt to perform the name change and return the result in the Modify DN Response, defined as follows:
收到ModifyDN请求后，服务器将尝试执行名称更改，并在Modify DN响应中返回结果，定义如下：
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
For example, if the entry named in the entry field was <cn=John Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the newSuperior field was absent, then this operation would attempt to rename the entry as <cn=John Cougar Smith,c=US>. If there was already an entry with that name, the operation would fail with the entryAlreadyExists result code.
例如，如果条目字段中命名的条目是<cn=John Smith，c=US>，newrdn字段是<cn=John Cougar Smith>，而newSuperior字段不存在，则此操作将尝试将条目重命名为<cn=John Cougar Smith，c=US>。如果已经存在具有该名称的条目，则操作将失败，结果代码为entryAlreadyExists。
Servers MUST ensure that entries conform to user and system schema rules or other data model constraints. For attribute types that specify no equality matching, the rules in Section 2.5.1 of [RFC4512] are followed (this pertains to newrdn and deleteoldrdn).
服务器必须确保条目符合用户和系统架构规则或其他数据模型约束。对于未指定相等匹配的属性类型，遵循[RFC4512]第2.5.1节中的规则（这适用于newrdn和deleteoldrdn）。
The object named in newSuperior MUST exist. For example, if the client attempted to add <CN=JS,DC=Example,DC=NET>, the <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did exist, then the server would return the noSuchObject result code with the matchedDN field containing <DC=NET>.
newSuperior中命名的对象必须存在。例如，如果客户端试图添加<CN=JS，DC=example，DC=NET>，<DC=example，DC=NET>条目不存在，并且<DC=NET>条目确实存在，那么服务器将返回noSuchObject结果代码，其中matchedDN字段包含<DC=NET>。
If the deleteoldrdn field is TRUE, the attribute values forming the old RDN (but not the new RDN) are deleted from the entry. If the deleteoldrdn field is FALSE, the attribute values forming the old RDN will be retained as non-distinguished attribute values of the entry.
如果deleteoldrdn字段为TRUE，则从条目中删除构成旧RDN（而不是新RDN）的属性值。如果deleteoldrdn字段为FALSE，则构成旧RDN的属性值将保留为条目的非可分辨属性值。
Note that X.500 restricts the ModifyDN operation to affect only entries that are contained within a single server. If the LDAP server is mapped onto DAP, then this restriction will apply, and the affectsMultipleDSAs result code will be returned if this error occurred. In general, clients MUST NOT expect to be able to perform arbitrary movements of entries and subtrees between servers or between naming contexts.
请注意，X.500限制ModifyDN操作仅影响单个服务器中包含的条目。如果LDAP服务器映射到DAP，则将应用此限制，如果发生此错误，将返回affectsMultipleDSAs结果代码。通常，客户端不能期望能够在服务器之间或命名上下文之间执行条目和子树的任意移动。
The Compare operation allows a client to compare an assertion value with the values of a particular attribute in a particular entry in the Directory. The Compare Request is defined as follows:
比较操作允许客户端将断言值与目录中特定项中特定属性的值进行比较。比较请求定义如下：
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
Fields of the Compare Request are:
比较请求的字段包括：
- entry: the name of the entry to be compared. The server SHALL NOT dereference any aliases in locating the entry to be compared.
- 条目：要比较的条目的名称。服务器在定位要比较的条目时不得取消引用任何别名。
- ava: holds the attribute value assertion to be compared.
- ava：保存要比较的属性值断言。
Upon receipt of a Compare Request, a server will attempt to perform the requested comparison and return the result in the Compare Response, defined as follows:
收到比较请求后，服务器将尝试执行请求的比较，并在比较响应中返回结果，定义如下：
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse ::= [APPLICATION 15] LDAPResult
The resultCode is set to compareTrue, compareFalse, or an appropriate error. compareTrue indicates that the assertion value in the ava field matches a value of the attribute or subtype according to the attribute's EQUALITY matching rule. compareFalse indicates that the assertion value in the ava field and the values of the attribute or subtype did not match. Other result codes indicate either that the result of the comparison was Undefined (Section 4.5.1.7), or that some error occurred.
resultCode设置为compareTrue、CompareValse或适当的错误。compareTrue表示ava字段中的断言值根据属性的相等匹配规则匹配属性或子类型的值。CompareValse表示ava字段中的断言值与属性或子类型的值不匹配。其他结果代码表明比较结果未定义（第4.5.1.7节），或者出现了一些错误。
Note that some directory systems may establish access controls that permit the values of certain attributes (such as userPassword) to be compared but not interrogated by other means.
注意，一些目录系统可能建立访问控制，允许比较某些属性（如userPassword）的值，但不通过其他方式进行查询。
The function of the Abandon operation is to allow a client to request that the server abandon an uncompleted operation. The Abandon Request is defined as follows:
放弃操作的功能是允许客户端请求服务器放弃未完成的操作。放弃请求的定义如下：
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID is that of an operation that was requested earlier at this LDAP message layer. The Abandon request itself has its own MessageID. This is distinct from the MessageID of the earlier operation being abandoned.
MessageID是在此LDAP消息层上先前请求的操作的ID。放弃请求本身有自己的MessageID。这与先前被放弃的操作的MessageID不同。
There is no response defined in the Abandon operation. Upon receipt of an AbandonRequest, the server MAY abandon the operation identified by the MessageID. Since the client cannot tell the difference between a successfully abandoned operation and an uncompleted operation, the application of the Abandon operation is limited to uses where the client does not require an indication of its outcome.
放弃操作中未定义响应。在收到放弃请求后，服务器可以放弃MessageID标识的操作。由于客户无法区分成功放弃的操作和未完成的操作，因此放弃操作的应用仅限于客户不需要指示其结果的用途。
Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
不能放弃放弃、绑定、解除绑定和开始TLS操作。
In the event that a server receives an Abandon Request on a Search operation in the midst of transmitting responses to the Search, that server MUST cease transmitting entry responses to the abandoned request immediately, and it MUST NOT send the SearchResultDone. Of course, the server MUST ensure that only properly encoded LDAPMessage PDUs are transmitted.
如果服务器在发送搜索响应的过程中收到搜索操作的放弃请求，则该服务器必须立即停止发送放弃请求的条目响应，并且不得发送SearchResultDone。当然，服务器必须确保仅传输正确编码的LDAPMessage PDU。
The ability to abandon other (particularly update) operations is at the discretion of the server.
放弃其他（特别是更新）操作的能力由服务器决定。
Clients should not send Abandon requests for the same operation multiple times, and they MUST also be prepared to receive results from operations they have abandoned (since these might have been in transit when the Abandon was requested or might not be able to be abandoned).
客户端不应多次发送同一操作的放弃请求，还必须准备好接收已放弃操作的结果（因为请求放弃时这些操作可能正在传输中，或者无法放弃）。
Servers MUST discard Abandon requests for messageIDs they do not recognize, for operations that cannot be abandoned, and for operations that have already been abandoned.
对于无法识别的MessageID、无法放弃的操作以及已经放弃的操作，服务器必须放弃放弃请求。
The Extended operation allows additional operations to be defined for services not already available in the protocol; for example, to Add operations to install transport layer security (see Section 4.14).
扩展操作允许为协议中尚不可用的服务定义附加操作；例如，添加操作以安装传输层安全性（请参阅第4.14节）。
The Extended operation allows clients to make requests and receive responses with predefined syntaxes and semantics. These may be defined in RFCs or be private to particular implementations.
扩展操作允许客户端使用预定义的语法和语义发出请求和接收响应。这些可以在RFC中定义，也可以是特定实现的专用。
Each Extended operation consists of an Extended request and an Extended response.
每个扩展操作由一个扩展请求和一个扩展响应组成。
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
The requestName is a dotted-decimal representation of the unique OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING.
requestName是对应于请求的唯一对象标识符的点十进制表示形式。requestValue是由该请求定义的形式的信息，封装在八位字节字符串中。
The server will respond to this with an LDAPMessage containing an ExtendedResponse.
服务器将使用包含ExtendedResponse的LDAPMessage对此进行响应。
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
The responseName field, when present, contains an LDAPOID that is unique for this extended operation or response. This field is optional (even when the extension specification defines an LDAPOID for use in this field). The field will be absent whenever the server is unable or unwilling to determine the appropriate LDAPOID to return, for instance, when the requestName cannot be parsed or its value is not recognized.
responseName字段（如果存在）包含此扩展操作或响应唯一的LDAPOID。此字段是可选的（即使扩展规范定义了用于此字段的LDAPOID）。当服务器无法或不愿意确定要返回的适当LDAPOID时（例如，当无法解析requestName或无法识别其值时），该字段将不存在。
Where the requestName is not recognized, the server returns protocolError. (The server may return protocolError in other cases.)
如果无法识别requestName，服务器将返回protocolError。（在其他情况下，服务器可能会返回协议错误。）
The requestValue and responseValue fields contain information associated with the operation. The format of these fields is defined by the specification of the Extended operation. Implementations MUST be prepared to handle arbitrary contents of these fields, including zero bytes. Values that are defined in terms of ASN.1 and BER-encoded according to Section 5.1 also follow the extensibility rules in Section 4.
requestValue和responseValue字段包含与操作相关的信息。这些字段的格式由扩展操作的规范定义。实现必须准备好处理这些字段的任意内容，包括零字节。根据ASN.1和根据第5.1节编码的BER定义的值也遵循第4节中的扩展性规则。
Servers list the requestName of Extended Requests they recognize in the 'supportedExtension' attribute in the root DSE (Section 5.1 of [RFC4512]).
服务器在根DSE的“supportedExtension”属性中列出它们识别的扩展请求的requestName（RFC4512的第5.1节）。
Extended operations may be specified in other documents. The specification of an Extended operation consists of:
扩展操作可在其他文件中指定。扩展操作的规范包括：
- the OBJECT IDENTIFIER assigned to the requestName,
- 分配给requestName的对象标识符，
- the OBJECT IDENTIFIER (if any) assigned to the responseName (note that the same OBJECT IDENTIFIER may be used for both the requestName and responseName),
- 分配给responseName的对象标识符（如果有）（请注意，相同的对象标识符可用于requestName和responseName），
- the format of the contents of the requestValue and responseValue (if any), and
- requestValue和responseValue（如果有）的内容格式，以及
- the semantics of the operation.
- 操作的语义。
While the Search operation provides a mechanism to return multiple response messages for a single Search request, other operations, by nature, do not provide for multiple response messages.
虽然搜索操作提供了一种机制来为单个搜索请求返回多个响应消息，但其他操作本质上不提供多个响应消息。
The IntermediateResponse message provides a general mechanism for defining single-request/multiple-response operations in LDAP. This message is intended to be used in conjunction with the Extended operation to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return Intermediate response information.
IntermediateResponse消息提供了在LDAP中定义单个请求/多个响应操作的通用机制。此消息旨在与扩展操作结合使用，以定义新的单请求/多响应操作，或者在扩展现有LDAP操作时与控件结合使用，以要求它们返回中间响应信息。
It is intended that the definitions and descriptions of Extended operations and controls that make use of the IntermediateResponse message will define the circumstances when an IntermediateResponse message can be sent by a server and the associated meaning of an IntermediateResponse message sent in a particular circumstance.
意图是，利用中间响应消息的扩展操作和控制的定义和描述将定义服务器可以发送中间响应消息的情况以及在特定情况下发送的中间响应消息的相关含义。
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse messages SHALL NOT be returned to the client unless the client issues a request that specifically solicits their return. This document defines two forms of solicitation: Extended operation and request control. IntermediateResponse messages are specified in documents describing the manner in which they are solicited (i.e., in the Extended operation or request control specification that uses them). These specifications include:
除非客户发出特别要求返回的请求，否则不得将中间响应消息返回给客户。本文档定义了两种形式的请求：扩展操作和请求控制。中间响应消息在描述请求方式的文档中指定（即，在使用它们的扩展操作或请求控制规范中）。这些规格包括：
- the OBJECT IDENTIFIER (if any) assigned to the responseName,
- 分配给响应名称的对象标识符（如果有），
- the format of the contents of the responseValue (if any), and
- 响应值内容的格式（如有），以及
- the semantics associated with the IntermediateResponse message.
- 与中间响应消息关联的语义。
Extensions that allow the return of multiple types of IntermediateResponse messages SHALL identify those types using unique responseName values (note that one of these may specify no value).
允许返回多种中间响应消息类型的扩展应使用唯一的responseName值标识这些类型（请注意，其中一个可能未指定任何值）。
Sections 4.13.1 and 4.13.2 describe additional requirements on the inclusion of responseName and responseValue in IntermediateResponse messages.
第4.13.1节和第4.13.2节描述了在中间响应消息中包含responseName和responseValue的附加要求。
A single-request/multiple-response operation may be defined using a single ExtendedRequest message to solicit zero or more IntermediateResponse messages of one or more kinds, followed by an ExtendedResponse message.
可以使用单个ExtendedRequest消息来定义单个请求/多个响应操作，以请求零个或多个一种或多种中间响应消息，然后是ExtendedResponse消息。
A control's semantics may include the return of zero or more IntermediateResponse messages prior to returning the final result code for the operation. One or more kinds of IntermediateResponse messages may be sent in response to a request control.
控件的语义可能包括在返回操作的最终结果代码之前返回零条或多条中间响应消息。可以发送一种或多种中间响应消息以响应请求控制。
All IntermediateResponse messages associated with request controls SHALL include a responseName. This requirement ensures that the client can correctly identify the source of IntermediateResponse messages when:
与请求控制相关的所有中间响应消息应包括响应名称。此要求可确保客户机在以下情况下能够正确识别中间响应消息的来源：
- two or more controls using IntermediateResponse messages are included in a request for any LDAP operation or
- 任何LDAP操作或请求中都包含两个或多个使用IntermediateResponse消息的控件
- one or more controls using IntermediateResponse messages are included in a request with an LDAP Extended operation that uses IntermediateResponse messages.
- 使用中间响应消息的一个或多个控件包含在使用中间响应消息的LDAP扩展操作的请求中。
The Start Transport Layer Security (StartTLS) operation's purpose is to initiate installation of a TLS layer. The StartTLS operation is defined using the Extended operation mechanism described in Section 4.12.
启动传输层安全性（StartTLS）操作的目的是启动TLS层的安装。StartTLS操作使用第4.12节所述的扩展操作机制进行定义。
A client requests TLS establishment by transmitting a StartTLS request message to the server. The StartTLS request is defined in terms of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", and the requestValue field is always absent.
客户端通过向服务器发送StartTLS请求消息来请求TLS建立。StartTLS请求是根据ExtendedRequest定义的。requestName为“1.3.6.1.4.1.1466.20037”，并且始终不存在requestValue字段。
The client MUST NOT send any LDAP PDUs at this LDAP message layer following this request until it receives a StartTLS Extended response and, in the case of a successful response, completes TLS negotiations.
在收到StartTLS扩展响应并在成功响应的情况下完成TLS协商之前，客户端不得在此请求之后在此LDAP消息层发送任何LDAP PDU。
Detected sequencing problems (particularly those detailed in Section 3.1.1 of [RFC4513]) result in the resultCode being set to operationsError.
检测到的排序问题（特别是[RFC4513]第3.1.1节中详述的问题）导致resultCode设置为operationsError。
If the server does not support TLS (whether by design or by current configuration), it returns with the resultCode set to protocolError as described in Section 4.12.
如果服务器不支持TLS（无论是通过设计还是通过当前配置），它将返回resultCode并将其设置为protocolError，如第4.12节所述。
When a StartTLS request is received, servers supporting the operation MUST return a StartTLS response message to the requestor. The responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section 4.12). The responseValue is always absent.
收到StartTLS请求时，支持该操作的服务器必须向请求者返回StartTLS响应消息。提供时，响应名称为“1.3.6.1.4.1.1466.20037”（见第4.12节）。响应值总是不存在。
If the server is willing and able to negotiate TLS, it returns the StartTLS response with the resultCode set to success. Upon client receipt of a successful StartTLS response, protocol peers may commence with TLS negotiation as discussed in Section 3 of [RFC4513].
如果服务器愿意并且能够协商TLS，它将返回StartTLS响应，并将resultCode设置为success。客户收到成功的StartTLS响应后，协议对等方可开始TLS协商，如[RFC4513]第3节所述。
If the server is otherwise unwilling or unable to perform this operation, the server is to return an appropriate result code indicating the nature of the problem. For example, if the TLS subsystem is not presently available, the server may indicate this by returning with the resultCode set to unavailable. In cases where a non-success result code is returned, the LDAP session is left without a TLS layer.
如果服务器不愿意或无法执行此操作，则服务器将返回适当的结果代码，指示问题的性质。例如，如果TLS子系统当前不可用，服务器可能会通过返回并将resultCode设置为unavailable来指示这一点。在返回未成功结果代码的情况下，LDAP会话没有TLS层。
Either the client or server MAY remove the TLS layer and leave the LDAP message layer intact by sending and receiving a TLS closure alert.
客户机或服务器都可以通过发送和接收TLS关闭警报来删除TLS层并保持LDAP消息层完整。
The initiating protocol peer sends the TLS closure alert and MUST wait until it receives a TLS closure alert from the other peer before sending further LDAP PDUs.
发起协议的对等方发送TLS关闭警报，并且在发送进一步的LDAP PDU之前，必须等待从另一对等方接收到TLS关闭警报。
When a protocol peer receives the initial TLS closure alert, it may choose to allow the LDAP message layer to remain intact. In this case, it MUST immediately transmit a TLS closure alert. Following this, it MAY send and receive LDAP PDUs.
当协议对等方收到初始TLS关闭警报时，它可以选择允许LDAP消息层保持完整。在这种情况下，必须立即发送TLS关闭警报。然后，它可以发送和接收LDAP PDU。
Protocol peers MAY terminate the LDAP session after sending or receiving a TLS closure alert.
协议对等方可以在发送或接收TLS关闭警报后终止LDAP会话。
This protocol is designed to run over connection-oriented, reliable transports, where the data stream is divided into octets (8-bit units), with each octet and each bit being significant.
该协议设计用于运行面向连接的可靠传输，其中数据流分为八位字节（8位单元），每个八位字节和每个位都是有效的。
One underlying service, LDAP over TCP, is defined in Section 5.2. This service is generally applicable to applications providing or consuming X.500-based directory services on the Internet. This specification was generally written with the TCP mapping in mind. Specifications detailing other mappings may encounter various obstacles.
第5.2节定义了一个底层服务，即TCP上的LDAP。此服务通常适用于在Internet上提供或使用基于X.500的目录服务的应用程序。本规范通常是在考虑TCP映射的情况下编写的。详细说明其他映射的规范可能会遇到各种障碍。
Implementations of LDAP over TCP MUST implement the mapping as described in Section 5.2.
通过TCP实现LDAP必须实现第5.2节所述的映射。
This table illustrates the relationship among the different layers involved in an exchange between two protocol peers:
此表说明了两个协议对等方之间交换所涉及的不同层之间的关系：
+----------------------+
| LDAP message layer |
+----------------------+ > LDAP PDUs
+----------------------+ < data
| SASL layer |
+----------------------+ > SASL-protected data
+----------------------+ < data
| TLS layer |
Application +----------------------+ > TLS-protected data
------------+----------------------+ < data
Transport | transport connection |
+----------------------+
+----------------------+
| LDAP message layer |
+----------------------+ > LDAP PDUs
+----------------------+ < data
| SASL layer |
+----------------------+ > SASL-protected data
+----------------------+ < data
| TLS layer |
Application +----------------------+ > TLS-protected data
------------+----------------------+ < data
Transport | transport connection |
+----------------------+
The protocol elements of LDAP SHALL be encoded for exchange using the Basic Encoding Rules [BER] of [ASN.1] with the following restrictions:
LDAP的协议元素应使用[ASN.1]的基本编码规则[BER]进行编码，以进行交换，但有以下限制：
- Only the definite form of length encoding is used.
- 仅使用长度编码的确定形式。
- OCTET STRING values are encoded in the primitive form only.
- 八位字节字符串值仅以原语形式编码。
- If the value of a BOOLEAN type is true, the encoding of the value octet is set to hex "FF".
- 如果布尔类型的值为真，则值八位字节的编码设置为十六进制“FF”。
- If a value of a type is its default value, it is absent. Only some BOOLEAN and INTEGER types have default values in this protocol definition.
- 如果类型的值是其默认值，则不存在该值。在此协议定义中，只有某些布尔和整数类型具有默认值。
These restrictions are meant to ease the overhead of encoding and decoding certain elements in BER.
这些限制旨在减轻BER中某些元素的编码和解码开销。
These restrictions do not apply to ASN.1 types encapsulated inside of OCTET STRING values, such as attribute values, unless otherwise stated.
除非另有说明，否则这些限制不适用于封装在八位字节字符串值（如属性值）内的ASN.1类型。
The encoded LDAPMessage PDUs are mapped directly onto the TCP [RFC793] bytestream using the BER-based encoding described in Section 5.1. It is recommended that server implementations running over the TCP provide a protocol listener on the Internet Assigned Numbers Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may instead provide a listener on a different port number. Clients MUST support contacting servers on any valid TCP port.
编码的LDAPMessage PDU通过TestStream直接映射到TCP[RFC793]，使用第5.1节中描述的基于BER的编码。建议通过TCP运行的服务器实现在Internet Assigned Numbers Authority（IANA）分配的LDAP端口389[PortReg]上提供协议侦听器。服务器可以在不同的端口号上提供侦听器。客户端必须支持在任何有效的TCP端口上联系服务器。
Termination of the LDAP session is typically initiated by the client sending an UnbindRequest (Section 4.3), or by the server sending a Notice of Disconnection (Section 4.4.1). In these cases, each protocol peer gracefully terminates the LDAP session by ceasing exchanges at the LDAP message layer, tearing down any SASL layer, tearing down any TLS layer, and closing the transport connection.
LDAP会话的终止通常由发送取消绑定请求的客户端（第4.3节）或发送断开连接通知的服务器（第4.4.1节）发起。在这些情况下，每个协议对等方通过停止LDAP消息层的交换、拆下任何SASL层、拆下任何TLS层并关闭传输连接来优雅地终止LDAP会话。
A protocol peer may determine that the continuation of any communication would be pernicious, and in this case, it may abruptly terminate the session by ceasing communication and closing the transport connection.
协议对等方可以确定任何通信的继续将是有害的，并且在这种情况下，它可以通过停止通信和关闭传输连接来突然终止会话。
In either case, when the LDAP session is terminated, uncompleted operations are handled as specified in Section 3.1.
在这两种情况下，当LDAP会话终止时，将按照第3.1节的规定处理未完成的操作。
This version of the protocol provides facilities for simple authentication using a cleartext password, as well as any SASL [RFC4422] mechanism. Installing SASL and/or TLS layers can provide integrity and other data security services.
此版本的协议提供了使用明文密码以及任何SASL[RFC4422]机制进行简单身份验证的工具。安装SASL和/或TLS层可以提供完整性和其他数据安全服务。
It is also permitted that the server can return its credentials to the client, if it chooses to do so.
还允许服务器将其凭据返回给客户端（如果它选择这样做的话）。
Use of cleartext password is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.
如果基础传输服务无法保证机密性，并且可能导致密码泄露给未经授权的方，则强烈建议不要使用明文密码。
Servers are encouraged to prevent directory modifications by clients that have authenticated anonymously [RFC4513].
鼓励服务器防止匿名身份验证的客户端修改目录[RFC4513]。
Security considerations for authentication methods, SASL mechanisms, and TLS are described in [RFC4513].
[RFC4513]中描述了认证方法、SASL机制和TL的安全注意事项。
Note that SASL authentication exchanges do not provide data confidentiality or integrity protection for the version or name fields of the BindRequest or the resultCode, diagnosticMessage, or referral fields of the BindResponse, nor for any information contained in controls attached to Bind requests or responses. Thus, information contained in these fields SHOULD NOT be relied on unless it is otherwise protected (such as by establishing protections at the transport layer).
请注意，SASL身份验证交换不为BindRequest的版本或名称字段或BindResponse的resultCode、diagnosticMessage或referral字段提供数据机密性或完整性保护，也不为Bind请求或响应附带的控件中包含的任何信息提供数据机密性或完整性保护。因此，不应依赖这些字段中包含的信息，除非它受到其他保护（例如通过在传输层建立保护）。
Implementors should note that various security factors (including authentication and authorization information and data security services) may change during the course of the LDAP session or even during the performance of a particular operation. For instance, credentials could expire, authorization identities or access controls could change, or the underlying security layer(s) could be replaced or terminated. Implementations should be robust in the handling of changing security factors.
实现者应该注意，各种安全因素（包括身份验证和授权信息以及数据安全服务）可能在LDAP会话过程中，甚至在执行特定操作过程中发生变化。例如，凭据可能会过期，授权标识或访问控制可能会更改，或者底层安全层可能会被替换或终止。在处理不断变化的安全因素时，实现应该是健壮的。
In some cases, it may be appropriate to continue the operation even in light of security factor changes. For instance, it may be appropriate to continue an Abandon operation regardless of the change, or to continue an operation when the change upgraded (or maintained) the security factor. In other cases, it may be appropriate to fail or alter the processing of the operation. For instance, if confidential protections were removed, it would be appropriate either to fail a request to return sensitive data or, minimally, to exclude the return of sensitive data.
在某些情况下，即使考虑到安全因素的变化，也可以继续操作。例如，无论更改如何，都可以继续放弃操作，或者在更改升级（或维护）安全系数时继续操作。在其他情况下，操作的处理可能会失败或改变。例如，如果删除了机密保护，则可以拒绝退回敏感数据的请求，或者至少排除退回敏感数据。
Implementations that cache attributes and entries obtained via LDAP MUST ensure that access controls are maintained if that information is to be provided to multiple clients, since servers may have access control policies that prevent the return of entries or attributes in Search results except to particular authenticated clients. For example, caches could serve result information only to the client whose request caused it to be in the cache.
缓存通过LDAP获得的属性和条目的实现必须确保，如果要将该信息提供给多个客户端，则必须维护访问控制，因为服务器可能具有访问控制策略，这些策略可防止搜索结果中的条目或属性返回到特定的经过身份验证的客户端。例如，缓存只能向其请求导致结果信息位于缓存中的客户端提供结果信息。
Servers may return referrals or Search result references that redirect clients to peer servers. It is possible for a rogue application to inject such referrals into the data stream in an attempt to redirect a client to a rogue server. Clients are advised to be aware of this and possibly reject referrals when confidentiality measures are not in place. Clients are advised to reject referrals from the StartTLS operation.
服务器可能返回将客户端重定向到对等服务器的引用或搜索结果引用。流氓应用程序有可能将此类引用注入数据流，试图将客户端重定向到流氓服务器。建议客户意识到这一点，并在保密措施不到位时拒绝转介。建议客户拒绝StartTLS操作的推荐。
The matchedDN and diagnosticMessage fields, as well as some resultCode values (e.g., attributeOrValueExists and entryAlreadyExists), could disclose the presence or absence of specific data in the directory that is subject to access and other administrative controls. Server implementations should restrict access to protected information equally under both normal and error conditions.
matchedDN和diagnosticMessage字段以及一些resultCode值（例如attributeOrValueExists和entryAlreadyExists）可能会显示目录中是否存在特定数据，这些数据受访问和其他管理控制。服务器实现应在正常和错误情况下平等地限制对受保护信息的访问。
Protocol peers MUST be prepared to handle invalid and arbitrary-length protocol encodings. Invalid protocol encodings include: BER encoding exceptions, format string and UTF-8 encoding exceptions, overflow exceptions, integer value exceptions, and binary mode on/off flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides excellent examples of these exceptions and test cases used to discover flaws.
协议对等方必须准备好处理无效和任意长度的协议编码。无效协议编码包括：BER编码异常、格式字符串和UTF-8编码异常、溢出异常、整数值异常和二进制模式开/关标志异常。LDAPv3 PROTOS[PROTOS-LDAP]测试套件提供了这些异常的优秀示例和用于发现缺陷的测试用例。
In the event that a protocol peer senses an attack that in its nature could cause damage due to further communication at any layer in the LDAP session, the protocol peer should abruptly terminate the LDAP session as described in Section 5.3.
如果协议对等方感觉到攻击本质上可能由于LDAP会话中任何层的进一步通信而造成损害，则协议对等方应按照第5.3节所述突然终止LDAP会话。
This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve Kille. RFC 2251 was a product of the IETF ASID Working Group.
本文档基于Mark Wahl、Tim Howes和Steve Kille的RFC 2251。RFC2251是IETF ASID工作组的产品。
It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
它还基于杰夫·霍奇斯、RL“鲍勃·摩根”和马克·沃尔的RFC 2830。RFC 2830是IETF LDAPEXT工作组的产品。
It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga. RFC 3771 was an individual submission to the IETF.
它也是基于罗杰·哈里森和库尔特·泽林加的RFC3771。RFC 3771是向IETF提交的个人资料。
This document is a product of the IETF LDAPBIS Working Group. Significant contributors of technical review and content include Kurt Zeilenga, Steven Legg, and Hallvard Furuseth.
本文件是IETF LDAPBIS工作组的成果。技术评论和内容的重要贡献者包括Kurt Zeilenga、Steven Legg和Hallvard Furuseth。
[ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824- 1:2002 "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation".
[ASN.1]ITU-T建议X.680（07/2002）| ISO/IEC 8824-1:2002“信息技术-抽象语法符号一（ASN.1）：基本符号规范”。
[BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2002.
[BER]ITU-T Rec.X.690（07/2002）| ISO/IEC 8825-1:2002，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，2002年。
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.
[ISO10646]通用多八位编码字符集（UCS）-体系结构和基本多语言平面，ISO/IEC 10646-1:1993。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3454] Hoffman P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002.
[RFC3454]Hoffman P.和M.Blanchet，“国际化字符串的准备（'stringprep'）”，RFC 3454，2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, March 2006.
2006年3月，第34C.46版和第34RFC.46版。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[RFC4512] Zeilenga, K., Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512]Zeilenga，K.，轻量级目录访问协议（LDAP）：目录信息模型”，RFC4512，2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]Harrison，R.，Ed.“轻量级目录访问协议（LDAP）：身份验证方法和安全机制”，RFC4513，2006年6月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4514，2006年6月。
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516]Smith，M.，Ed.和T.Howes，“轻量级目录访问协议（LDAP）：统一资源定位器”，RFC4516，2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]Legg，S.，Ed.，“轻量级目录访问协议（LDAP）：语法和匹配规则”，RFC4517，2006年6月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 4520，2006年6月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[Unicode]Unicode联盟“Unicode标准，版本3.2.0”由“Unicode标准，版本3.0”（雷丁，马萨诸塞州，Addison-Wesley，2000.ISBN 0-201-61633-5）定义，并由“Unicode标准附录27:Unicode 3.1”修订(http://www.unicode.org/reports/tr27/)根据“Unicode标准附录28:Unicode 3.2”(http://www.unicode.org/reports/tr28/).
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993.
[X.500]ITU-T Rec.X.500，“目录：概念、模型和服务概述”，1993年。
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
[X.511]ITU-T Rec.X.511，“目录：抽象服务定义”，1993年。
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.
[CharModel]Whistler，K.和M.Davis，“Unicode技术报告#17，字符编码模型”，UTR17<http://www.unicode.org/unicode/reports/tr17/>，2000年8月。
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[词汇表]Unicode联盟，“Unicode词汇表”<http://www.unicode.org/glossary/>.
[PortReg] IANA, "Port Numbers", <http://www.iana.org/assignments/port-numbers>.
[PortReg]IANA，“端口号”<http://www.iana.org/assignments/port-numbers>.
[PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3" <http://www.ee.oulu.fi/research/ouspg/protos/testing/ c06/ldapv3/>.
奥卢大学PROSTS LDAP：“PROTOS测试套件：C06LDAPv3”http://www.ee.oulu.fi/research/ouspg/protos/testing/ c06/ldapv3/>。
The Internet Assigned Numbers Authority (IANA) has updated the LDAP result code registry to indicate that this document provides the definitive technical specification for result codes 0-36, 48-54, 64- 70, 80-90. It is also noted that one resultCode value (strongAuthRequired) has been renamed (to strongerAuthRequired).
Internet Assigned Numbers Authority（IANA）已更新LDAP结果代码注册表，以表明本文档提供了结果代码0-36、48-54、64-70、80-90的最终技术规范。还需要注意的是，一个resultCode值（strongAuthRequired）已重命名（为strongerAuthRequired）。
The IANA has also updated the LDAP Protocol Mechanism registry to indicate that this document and [RFC4513] provides the definitive technical specification for the StartTLS (1.3.6.1.4.1.1466.20037) Extended operation.
IANA还更新了LDAP协议机制注册表，表明本文件和[RFC4513]提供了StartTLS（1.3.6.1.4.1.1466.20037）扩展操作的最终技术规范。
IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the ASN.1 module defined in this document.
IANA已分配LDAP对象标识符18[RFC4520]来标识本文档中定义的ASN.1模块。
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Jim Sermersheim <jimse@novell.com>
Specification: RFC 4511
Author/Change Controller: IESG
Comments:
Identifies the LDAP ASN.1 module
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Jim Sermersheim <jimse@novell.com>
Specification: RFC 4511
Author/Change Controller: IESG
Comments:
Identifies the LDAP ASN.1 module
This normative appendix details additional considerations regarding LDAP result codes and provides a brief, general description of each LDAP result code enumerated in Section 4.1.9.
附录4.1中的每个规范性代码的简要说明和其他LDAP代码的详细说明。
Additional result codes MAY be defined for use with extensions [RFC4520]. Client implementations SHALL treat any result code that they do not recognize as an unknown error condition.
可定义额外的结果代码，以用于扩展[RFC4520]。客户机实现应将其无法识别的任何结果代码视为未知错误条件。
The descriptions provided here do not fully account for result code substitutions used to prevent unauthorized disclosures (such as substitution of noSuchObject for insufficientAccessRights, or invalidCredentials for insufficientAccessRights).
此处提供的说明未充分说明用于防止未经授权的披露的结果代码替换（例如，将noSuchObject替换为UnficientAccessRights，或将invalidCredentials替换为UnficientAccessRights）。
These result codes (called "non-error" result codes) do not indicate an error condition:
这些结果代码（称为“非错误”结果代码）不表示错误情况：
success (0), compareFalse (5), compareTrue (6), referral (10), and saslBindInProgress (14).
成功（0）、比较法（5）、比较法（6）、推荐（10）和saslBindInProgress（14）。
The success, compareTrue, and compareFalse result codes indicate successful completion (and, hence, are referred to as "successful" result codes).
success、compareTrue和CompareValse结果代码表示成功完成（因此称为“成功”结果代码）。
The referral and saslBindInProgress result codes indicate the client needs to take additional action to complete the operation.
转诊和saslBindInProgress结果代码表明客户需要采取额外的操作来完成操作。
Existing LDAP result codes are described as follows:
现有LDAP结果代码描述如下：
success (0) Indicates the successful completion of an operation. Note: this code is not used with the Compare operation. See compareFalse (5) and compareTrue (6).
成功（0）表示操作成功完成。注意：此代码不用于比较操作。请参阅CompareValse（5）和compareTrue（6）。
operationsError (1) Indicates that the operation is not properly sequenced with relation to other operations (of same or different type).
operationsError（1）表示该操作与其他操作（相同或不同类型）的顺序不正确。
For example, this code is returned if the client attempts to StartTLS [RFC4346] while there are other uncompleted operations or if a TLS layer was already installed.
例如，如果客户机试图启动TTLS[RFC4346]，而存在其他未完成的操作，或者如果已经安装了TLS层，则返回此代码。
protocolError (2) Indicates the server received data that is not well-formed.
protocolError（2）表示服务器接收到的数据格式不正确。
For Bind operation only, this code is also used to indicate that the server does not support the requested protocol version.
仅对于绑定操作，此代码还用于指示服务器不支持请求的协议版本。
For Extended operations only, this code is also used to indicate that the server does not support (by design or configuration) the Extended operation associated with the requestName.
仅对于扩展操作，此代码还用于指示服务器不支持（通过设计或配置）与requestName关联的扩展操作。
For request operations specifying multiple controls, this may be used to indicate that the server cannot ignore the order of the controls as specified, or that the combination of the specified controls is invalid or unspecified.
对于指定多个控件的请求操作，这可用于指示服务器无法忽略指定控件的顺序，或者指定控件的组合无效或未指定。
timeLimitExceeded (3) Indicates that the time limit specified by the client was exceeded before the operation could be completed.
timeLimitExceeded（3）表示在操作完成之前已超过客户端指定的时间限制。
sizeLimitExceeded (4) Indicates that the size limit specified by the client was exceeded before the operation could be completed.
SizeLimitExceed（4）表示在操作完成之前已超过客户端指定的大小限制。
compareFalse (5) Indicates that the Compare operation has successfully completed and the assertion has evaluated to FALSE or Undefined.
CompareValse（5）表示比较操作已成功完成，并且断言的计算结果为FALSE或Undefined。
compareTrue (6) Indicates that the Compare operation has successfully completed and the assertion has evaluated to TRUE.
compareTrue（6）表示比较操作已成功完成，并且断言的计算结果为TRUE。
authMethodNotSupported (7) Indicates that the authentication method or mechanism is not supported.
authMethodNotSupported（7）表示不支持身份验证方法或机制。
strongerAuthRequired (8) Indicates the server requires strong(er) authentication in order to complete the operation.
strongerAuthRequired（8）表示服务器需要强（er）身份验证才能完成操作。
When used with the Notice of Disconnection operation, this code indicates that the server has detected that an established security association between the client and server has unexpectedly failed or been compromised.
当与断开连接操作通知一起使用时，此代码表示服务器已检测到客户端和服务器之间已建立的安全关联意外失败或受到破坏。
referral (10) Indicates that a referral needs to be chased to complete the operation (see Section 4.1.10).
转诊（10）表示需要追踪转诊以完成操作（见第4.1.10节）。
adminLimitExceeded (11) Indicates that an administrative limit has been exceeded.
AdminLimitExceed（11）表示已超过管理限制。
unavailableCriticalExtension (12) Indicates a critical control is unrecognized (see Section 4.1.11).
unavailableCriticalExtension（12）表示无法识别关键控制（见第4.1.11节）。
confidentialityRequired (13) Indicates that data confidentiality protections are required.
机密性要求（13）表示需要数据保密保护。
saslBindInProgress (14) Indicates the server requires the client to send a new bind request, with the same SASL mechanism, to continue the authentication process (see Section 4.2).
saslBindInProgress（14）表示服务器要求客户端使用相同的SASL机制发送新的绑定请求，以继续身份验证过程（参见第4.2节）。
noSuchAttribute (16) Indicates that the named entry does not contain the specified attribute or attribute value.
noSuchAttribute（16）表示命名条目不包含指定的属性或属性值。
undefinedAttributeType (17) Indicates that a request field contains an unrecognized attribute description.
undefinedAttributeType（17）表示请求字段包含无法识别的属性描述。
inappropriateMatching (18) Indicates that an attempt was made (e.g., in an assertion) to use a matching rule not defined for the attribute type concerned.
不适当匹配（18）表示试图（例如，在断言中）使用未为相关属性类型定义的匹配规则。
constraintViolation (19) Indicates that the client supplied an attribute value that does not conform to the constraints placed upon it by the data model.
constraintViolation（19）表示客户机提供的属性值不符合数据模型对其施加的约束。
For example, this code is returned when multiple values are supplied to an attribute that has a SINGLE-VALUE constraint.
例如，当向具有单值约束的属性提供多个值时，将返回此代码。
attributeOrValueExists (20) Indicates that the client supplied an attribute or value to be added to an entry, but the attribute or value already exists.
attributeOrValueExists（20）表示客户端提供了要添加到条目的属性或值，但该属性或值已存在。
invalidAttributeSyntax (21) Indicates that a purported attribute value does not conform to the syntax of the attribute.
InvalidateTributesyntax（21）表示声称的属性值不符合该属性的语法。
noSuchObject (32) Indicates that the object does not exist in the DIT.
noSuchObject（32）表示DIT中不存在该对象。
aliasProblem (33) Indicates that an alias problem has occurred. For example, the code may used to indicate an alias has been dereferenced that names no object.
别名问题（33）表示出现了别名问题。例如，代码可用于指示已取消引用的别名未命名任何对象。
invalidDNSyntax (34) Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search base, target entry, ModifyDN newrdn, etc.) of a request does not conform to the required syntax or contains attribute values that do not conform to the syntax of the attribute's type.
invalidDNSyntax（34）表示请求的LDAPDN或RelativeLDAPDN字段（例如，搜索库、目标条目、ModifyDN newrdn等）不符合所需语法，或包含不符合属性类型语法的属性值。
aliasDereferencingProblem (36) Indicates that a problem occurred while dereferencing an alias. Typically, an alias was encountered in a situation where it was not allowed or where access was denied.
别名取消引用问题（36）表示取消引用别名时出现问题。通常，在不允许别名或访问被拒绝的情况下会遇到别名。
inappropriateAuthentication (48) Indicates the server requires the client that had attempted to bind anonymously or without supplying credentials to provide some form of credentials.
不适当的身份验证（48）表示服务器要求尝试匿名绑定或未提供凭据的客户端提供某种形式的凭据。
invalidCredentials (49) Indicates that the provided credentials (e.g., the user's name and password) are invalid.
invalidCredentials（49）表示提供的凭据（例如用户名和密码）无效。
insufficientAccessRights (50) Indicates that the client does not have sufficient access rights to perform the operation.
insufficientAccessRights（50）表示客户端没有足够的访问权限来执行该操作。
busy (51) Indicates that the server is too busy to service the operation.
忙（51）表示服务器太忙，无法为操作提供服务。
unavailable (52) Indicates that the server is shutting down or a subsystem necessary to complete the operation is offline.
不可用（52）表示服务器正在关闭，或者完成操作所需的子系统处于脱机状态。
unwillingToPerform (53) Indicates that the server is unwilling to perform the operation.
不愿意操作（53）表示服务器不愿意执行该操作。
loopDetect (54) Indicates that the server has detected an internal loop (e.g., while dereferencing aliases or chaining an operation).
loopDetect（54）表示服务器已检测到内部循环（例如，在取消引用别名或链接操作时）。
namingViolation (64) Indicates that the entry's name violates naming restrictions.
namingViolation（64）表示条目的名称违反命名限制。
objectClassViolation (65) Indicates that the entry violates object class restrictions.
objectClassViolation（65）表示条目违反了对象类限制。
notAllowedOnNonLeaf (66) Indicates that the operation is inappropriately acting upon a non-leaf entry.
notAllowedOnNonLeaf（66）表示操作对非叶条目的作用不适当。
notAllowedOnRDN (67) Indicates that the operation is inappropriately attempting to remove a value that forms the entry's relative distinguished name.
notAllowedOnRDN（67）表示该操作不适当地试图删除构成条目相对可分辨名称的值。
entryAlreadyExists (68) Indicates that the request cannot be fulfilled (added, moved, or renamed) as the target entry already exists.
entryAlreadyExists（68）表示无法满足请求（添加、移动或重命名），因为目标条目已经存在。
objectClassModsProhibited (69) Indicates that an attempt to modify the object class(es) of an entry's 'objectClass' attribute is prohibited.
objectClassModsProhibited（69）表示禁止尝试修改条目“objectClass”属性的对象类。
For example, this code is returned when a client attempts to modify the structural object class of an entry.
例如，当客户端试图修改条目的结构对象类时，将返回此代码。
affectsMultipleDSAs (71) Indicates that the operation cannot be performed as it would affect multiple servers (DSAs).
affectsMultipleDSAs（71）表示无法执行该操作，因为它会影响多个服务器（DSA）。
other (80) Indicates the server has encountered an internal error.
other（80）表示服务器遇到内部错误。
This appendix is normative.
本附录为规范性附录。
Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
-- Copyright (C) The Internet Society (2006). This version of
-- this ASN.1 module is part of RFC 4511; see the RFC itself
-- for full legal notices.
DEFINITIONS
IMPLICIT TAGS
EXTENSIBILITY IMPLIED ::=
Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
-- Copyright (C) The Internet Society (2006). This version of
-- this ASN.1 module is part of RFC 4511; see the RFC itself
-- for full legal notices.
DEFINITIONS
IMPLICIT TAGS
EXTENSIBILITY IMPLIED ::=
BEGIN
开始
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
...,
intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
...,
intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-- [RFC4512]
LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-- [RFC4512]
LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
-- [RFC4514]
LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
-- [RFC4514]
RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
-- [RFC4514]
RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
-- [RFC4514]
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
AttributeValue ::= OCTET STRING
AttributeValue ::= OCTET STRING
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
AssertionValue ::= OCTET STRING
PartialAttribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF value AttributeValue }
PartialAttribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF value AttributeValue }
Attribute ::= PartialAttribute(WITH COMPONENTS {
...,
vals (SIZE(1..MAX))})
Attribute ::= PartialAttribute(WITH COMPONENTS {
...,
vals (SIZE(1..MAX))})
MatchingRuleId ::= LDAPString
MatchingRuleId ::= LDAPString
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80),
... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80),
... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
URI ::= LDAPString -- limited to characters permitted in
-- URIs
URI ::= LDAPString -- limited to characters permitted in
-- URIs
Controls ::= SEQUENCE OF control Control
Controls ::= SEQUENCE OF control Control
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
Control ::= SEQUENCE {
controlType LDAPOID,
criticality BOOLEAN DEFAULT FALSE,
controlValue OCTET STRING OPTIONAL }
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
UnbindRequest ::= [APPLICATION 2] NULL
UnbindRequest ::= [APPLICATION 2] NULL
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
AttributeSelection ::= SEQUENCE OF selector LDAPString
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.8
AttributeSelection ::= SEQUENCE OF selector LDAPString
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.8
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] MatchingRuleAssertion, ... }
子字符串[4]子字符串筛选器、GreaterEqual[5]AttributeValueAssertion、lessOrEqual[6]AttributeValueAssertion、present[7]AttributeDescription、approxMatch[8]AttributeValueAssertion、ExtensionableMatch[9]MatchingRuleAssertion，…}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue, -- can occur at most once
any [1] AssertionValue,
final [2] AssertionValue } -- can occur at most once
}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue, -- can occur at most once
any [1] AssertionValue,
final [2] AssertionValue } -- can occur at most once
}
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone ::= [APPLICATION 5] LDAPResult
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
ModifyResponse ::= [APPLICATION 7] LDAPResult
ModifyResponse ::= [APPLICATION 7] LDAPResult
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF attribute Attribute
AttributeList ::= SEQUENCE OF attribute Attribute
AddResponse ::= [APPLICATION 9] LDAPResult
AddResponse ::= [APPLICATION 9] LDAPResult
DelRequest ::= [APPLICATION 10] LDAPDN
DelRequest ::= [APPLICATION 10] LDAPDN
DelResponse ::= [APPLICATION 11] LDAPResult
DelResponse ::= [APPLICATION 11] LDAPResult
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }
CompareResponse ::= [APPLICATION 15] LDAPResult
CompareResponse ::= [APPLICATION 15] LDAPResult
AbandonRequest ::= [APPLICATION 16] MessageID
AbandonRequest ::= [APPLICATION 16] MessageID
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
END
终止
This appendix is non-normative.
本附录为非规范性附录。
This appendix summarizes substantive changes made to RFC 2251, RFC 2830, and RFC 3771.
本附录总结了对RFC 2251、RFC 2830和RFC 3771所做的实质性更改。
This section summarizes the substantive changes made to Sections 1, 2, 3.1, and 4, and the remainder of RFC 2251. Readers should consult [RFC4512] and [RFC4513] for summaries of changes to other sections.
本节总结了对第1、2、3.1和4节以及RFC 2251其余部分所做的实质性更改。读者应参考[RFC4512]和[RFC4513]了解其他章节的变更摘要。
- Removed IESG note. Post publication of RFC 2251, mandatory LDAP authentication mechanisms have been standardized which are sufficient to remove this note. See [RFC4513] for authentication mechanisms.
- 删除IESG注释。RFC 2251发布后，强制性LDAP身份验证机制已标准化，足以删除此注释。有关身份验证机制，请参见[RFC4513]。
- Removed notes giving history between LDAP v1, v2, and v3. Instead, added sufficient language so that this document can stand on its own.
- 删除了在LDAP v1、v2和v3之间提供历史记录的注释。相反，添加了足够的语言，以便该文档能够独立运行。
- Clarified where the extensibility features of ASN.1 apply to the protocol. This change affected various ASN.1 types by the inclusion of ellipses (...) to certain elements. - Removed the requirement that servers that implement version 3 or later MUST provide the 'supportedLDAPVersion' attribute. This statement provided no interoperability advantages.
- 阐明了ASN.1的可扩展性特性在协议中的应用。这一变化通过在某些元素中加入椭圆（…）影响了各种ASN.1类型删除了实现版本3或更高版本的服务器必须提供“supportedLDAPVersion”属性的要求。该声明没有提供互操作性优势。
- There was a mandatory requirement for the server to return a Notice of Disconnection and drop the transport connection when a PDU is malformed in a certain way. This has been updated such that the server SHOULD return the Notice of Disconnection, and it MUST terminate the LDAP Session.
- 当PDU以某种方式出现错误时，服务器必须返回断开连接通知并断开传输连接。这已经更新，服务器应该返回断开连接的通知，并且必须终止LDAP会话。
- Required that the messageID of requests MUST be non-zero as the zero is reserved for Notice of Disconnection.
- 要求请求的messageID必须为非零，因为零是为断开连接通知保留的。
- Specified when it is and isn't appropriate to return an already used messageID. RFC 2251 accidentally imposed synchronous server behavior in its wording of this.
- 当返回已使用的messageID是合适的和不合适的时指定。RFC2251在其措辞中意外地强加了同步服务器行为。
- Stated that LDAPOID is constrained to <numericoid> from [RFC4512].
- 说明LDAPOID从[RFC4512]被约束为<numericoid>。
- Removed the Binary Option from the specification. There are numerous interoperability problems associated with this method of alternate attribute type encoding. Work to specify a suitable replacement is ongoing.
- 从规范中删除了二进制选项。这种交替属性类型编码方法存在许多互操作性问题。指定合适替代品的工作正在进行中。
- Combined the definitions of PartialAttribute and Attribute here, and defined Attribute in terms of PartialAttribute.
- 这里结合了PartialAttribute和Attribute的定义，并根据PartialAttribute定义了Attribute。
- Renamed "errorMessage" to "diagnosticMessage" as it is allowed to be sent for non-error results. - Moved some language into Appendix A, and referred the reader there. - Allowed matchedDN to be present for other result codes than those listed in RFC 2251. - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to clarify that this code may often be returned to indicate that a stronger authentication is needed to perform a given operation.
- 将“errorMessage”重命名为“diagnosticMessage”，因为允许发送非错误结果。-将一些语言移到附录A中，并向那里的读者介绍。-对于RFC 2251中列出的结果代码以外的其他结果代码，允许存在matchedDN。-将代码“strongAuthRequired”重命名为“strongerAuthRequired”，以澄清此代码可能经常返回以指示执行给定操作需要更强的身份验证。
- Defined referrals in terms of URIs rather than URLs. - Removed the requirement that all referral URIs MUST be equally capable of progressing the operation. The statement was ambiguous and provided no instructions on how to carry it out. - Added the requirement that clients MUST NOT loop between servers. - Clarified the instructions for using LDAPURLs in referrals, and in doing so added a recommendation that the scope part be present. - Removed imperatives which required clients to use URLs in specific ways to progress an operation. These did nothing for interoperability.
- 根据URI而不是URL定义的引用。-删除了所有转介URI必须同样能够进行操作的要求。该声明模棱两可，没有说明如何执行。-增加了客户端不得在服务器之间循环的要求。-阐明了在转介中使用LDAPURL的说明，并在此过程中添加了范围部分的建议。-删除了要求客户端以特定方式使用URL来执行操作的命令。这些对互操作性没有任何作用。
- Specified how control values defined in terms of ASN.1 are to be encoded. - Noted that the criticality field is only applied to request messages (except UnbindRequest), and must be ignored when present on response messages and UnbindRequest. - Specified that non-critical controls may be ignored at the server's discretion. There was confusion in the original wording which led some to believe that recognized controls may not be ignored as long as they were associated with a proper request. - Added language regarding combinations of controls and the ordering of controls on a message. - Specified that when the semantics of the combination of controls is undefined or unknown, it results in a protocolError. - Changed "The server MUST be prepared" to "Implementations MUST be prepared" in paragraph 8 to reflect that both client and server implementations must be able to handle this (as both parse controls).
- 指定如何对ASN.1中定义的控制值进行编码。-注意，临界性字段仅适用于请求消息（解除绑定请求除外），并且在响应消息和解除绑定请求中出现时必须忽略。-指定非关键控件可由服务器自行忽略。在最初的措辞中存在混乱，这导致一些人相信，只要与适当的请求相关，就不能忽视公认的控制措施。-添加了有关控件组合和消息控件顺序的语言。-指定当控件组合的语义未定义或未知时，将导致协议错误。-将第8段中的“服务器必须准备好”更改为“实现必须准备好”，以反映客户端和服务器实现都必须能够处理此问题（作为解析控件）。
- Mandated that servers return protocolError when the version is not supported. - Disambiguated behavior when the simple authentication is used, the name is empty, and the password is non-empty. - Required servers to not dereference aliases for Bind. This was added for consistency with other operations and to help ensure data consistency. - Required that textual passwords be transferred as UTF-8 encoded Unicode, and added recommendations on string preparation. This was to help ensure interoperability of passwords being sent from different clients.
- 强制服务器在版本不受支持时返回协议错误。-使用简单身份验证、名称为空且密码为非空时的消歧行为。-要求服务器不取消绑定别名的引用。这是为了与其他操作保持一致，并帮助确保数据一致性而添加的。-要求将文本密码传输为UTF-8编码的Unicode，并添加了关于字符串准备的建议。这有助于确保从不同客户端发送的密码的互操作性。
- This section was largely reorganized for readability, and language was added to clarify the authentication state of failed and abandoned Bind operations. - Removed: "If a SASL transfer encryption or integrity mechanism has been negotiated, that mechanism does not support the changing of credentials from one identity to another, then the client MUST instead establish a new connection." If there are dependencies between multiple negotiations of a particular SASL mechanism, the technical specification for that SASL mechanism details how applications are to deal with them. LDAP should not require any special handling. - Dropped MUST imperative in paragraph 3 to align with [RFC2119].
- 为了可读性，对本节进行了大量重组，并添加了语言以澄清失败和放弃的绑定操作的身份验证状态。-删除：“如果已协商SASL传输加密或完整性机制，则该机制不支持将凭据从一个标识更改为另一个标识，则客户端必须建立新连接。”如果特定SASL机制的多次协商之间存在依赖关系，SASL机制的技术规范详细说明了应用程序如何处理它们。LDAP不应要求任何特殊处理。-第3段中的删除必须与[RFC2119]一致。
- Mandated that clients not send non-Bind operations while a Bind is in progress, and suggested that servers not process them if they are received. This is needed to ensure proper sequencing of the Bind in relationship to other operations.
- 强制客户端在绑定过程中不发送非绑定操作，并建议服务器在收到非绑定操作时不进行处理。这是确保绑定与其他操作相关的正确顺序所必需的。
- Moved most error-related text to Appendix A, and added text regarding certain errors used in conjunction with the Bind operation. - Prohibited the server from specifying serverSaslCreds when not appropriate.
- 将大多数与错误相关的文本移至附录A，并添加了与绑定操作一起使用的某些错误相关的文本。-禁止服务器在不合适时指定ServersAllCreds。
- Specified that both peers are to cease transmission and terminate the LDAP session for the Unbind operation.
- 指定两个对等方停止传输并终止解除绑定操作的LDAP会话。
- Added instructions for future specifications of Unsolicited Notifications.
- 添加了有关未经请求通知的未来规范的说明。
- SearchRequest attributes is now defined as an AttributeSelection type rather than AttributeDescriptionList, and an ABNF is provided. - SearchRequest attributes may contain duplicate attribute descriptions. This was previously prohibited. Now servers are instructed to ignore subsequent names when they are duplicated. This was relaxed in order to allow different short names and also OIDs to be requested for an attribute. - The present search filter now evaluates to Undefined when the specified attribute is not known to the server. It used to evaluate to FALSE, which caused behavior inconsistent with what most would expect, especially when the 'not' operator was used. - The Filter choice SubstringFilter substrings type is now defined with a lower bound of 1. - The SubstringFilter substrings 'initial, 'any', and 'final' types are now AssertionValue rather than LDAPString. Also, added imperatives stating that 'initial' (if present) must be listed first, and 'final' (if present) must be listed last. - Disambiguated the semantics of the derefAliases choices. There was question as to whether derefInSearching applied to the base object in a wholeSubtree Search. - Added instructions for equalityMatch, substrings, greaterOrEqual, lessOrEqual, and approxMatch.
- SearchRequest属性现在定义为AttributeSelection类型，而不是AttributeDescriptionList，并提供了ABNF。-SearchRequest属性可能包含重复的属性描述。这是以前禁止的。现在，服务器被指示在复制后续名称时忽略它们。为了允许为属性请求不同的短名称和OID，这一点被放宽了。-当服务器不知道指定的属性时，当前搜索筛选器现在计算为未定义。它用于计算为FALSE，这会导致与大多数人预期的行为不一致，尤其是在使用“not”运算符时。-筛选器选择子字符串筛选器子字符串类型现在定义为下限1。-SubstringFilter子字符串“initial”、“any”和“final”类型现在是AssertionValue而不是LDAPString。此外，增加了说明“初始”（如果存在）必须首先列出，“最终”（如果存在）必须最后列出的命令。-消除了derefAliases选项的语义歧义。有一个问题是，在整体子树搜索中，是否对基础对象应用了derefInSearching。-增加了equalityMatch、Substring、GreaterEqual、lessOrEqual和approxMatch的说明。
- Recommended that servers not use attribute short names when it knows they are ambiguous or may cause interoperability problems. - Removed all mention of ExtendedResponse due to lack of implementation.
- 建议服务器在知道属性短名称不明确或可能导致互操作性问题时不要使用它们。-由于缺乏实现，删除了所有对ExtendedResponse的提及。
- Made changes similar to those made to Section 4.1.11.
- 进行了与第4.1.11节类似的更改。
- Fixed examples to adhere to changes made to Section 4.5.3.
- 固定示例以遵守第4.5.3节的更改。
- Replaced AttributeTypeAndValues with Attribute as they are equivalent. - Specified the types of modification changes that might temporarily violate schema. Some readers were under the impression that any temporary schema violation was allowed.
- 将AttributeTypeAndValue替换为属性，因为它们是等效的。-指定了可能暂时违反架构的修改更改类型。一些读者的印象是，任何临时的模式冲突都是允许的。
- Aligned Add operation with X.511 in that the attributes of the RDN are used in conjunction with the listed attributes to create the entry. Previously, Add required that the distinguished values be present in the listed attributes. - Removed requirement that the objectClass attribute MUST be specified as some DSE types do not require this attribute. Instead, generic wording was added, requiring the added entry to adhere to the data model. - Removed recommendation regarding placement of objects. This is covered in the data model document.
- 与X.511对齐的添加操作，其中RDN的属性与列出的属性一起用于创建条目。之前，Add要求在列出的属性中存在可分辨的值。-删除了必须指定objectClass属性的要求，因为某些DSE类型不需要此属性。相反，添加了通用措辞，要求添加的条目符合数据模型。-删除了有关对象放置的建议。这将在数据模型文档中介绍。
- Required servers to not dereference aliases for Modify DN. This was added for consistency with other operations and to help ensure data consistency. - Allow Modify DN to fail when moving between naming contexts. - Specified what happens when the attributes of the newrdn are not present on the entry.
- 要求服务器不取消对Modify DN别名的引用。这是为了与其他操作保持一致，并帮助确保数据一致性而添加的。-在命名上下文之间移动时允许修改DN失败。-指定当条目上不存在newrdn的属性时发生的情况。
- Specified that compareFalse means that the Compare took place and the result is false. There was confusion that led people to believe that an Undefined match resulted in compareFalse. - Required servers to not dereference aliases for Compare. This was added for consistency with other operations and to help ensure data consistency.
- 指定CompareValse表示进行了比较，结果为false。有一种困惑使人们相信，未定义的匹配会导致比较要求服务器不取消对别名的引用以进行比较。这是为了与其他操作保持一致，并帮助确保数据一致性而添加的。
- Explained that since Abandon returns no response, clients should not use it if they need to know the outcome. - Specified that Abandon and Unbind cannot be abandoned.
- 解释说，由于放弃不返回响应，如果客户需要知道结果，则不应使用它。-指定不能放弃放弃和取消绑定。
- Specified how values of Extended operations defined in terms of ASN.1 are to be encoded. - Added instructions on what Extended operation specifications consist of. - Added a recommendation that servers advertise supported Extended operations.
- 指定如何对ASN.1中定义的扩展操作的值进行编码。-增加了关于扩展操作规范包括哪些内容的说明。-添加了服务器播发支持的扩展操作的建议。
- Moved referral-specific instructions into referral-related sections.
- 将转诊特定说明移动到转诊相关部分。
- Reworded notes regarding SASL not protecting certain aspects of the LDAP Bind messages. - Noted that Servers are encouraged to prevent directory modifications by clients that have authenticated anonymously [RFC4513]. - Added a note regarding the possibility of changes to security factors (authentication, authorization, and data confidentiality). - Warned against following referrals that may have been injected in the data stream. - Noted that servers should protect information equally, whether in an error condition or not, and mentioned matchedDN, diagnosticMessage, and resultCodes specifically. - Added a note regarding malformed and long encodings.
- 重写了关于SASL不保护LDAP绑定消息某些方面的注释。-注意，鼓励服务器防止匿名身份验证的客户端修改目录[RFC4513]。-添加了关于安全因素（身份验证、授权和数据机密性）更改可能性的说明警告不要在数据流中注入以下引用。-注意到服务器应该平等地保护信息，无论是否处于错误状态，并特别提到matchedDN、diagnosticMessage和resultCodes。-添加了关于格式错误和长编码的注释。
- Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. - Removed AttributeType. It is not used.
- 在ASN.1定义中增加了“隐含可扩展性”已删除属性类型。它没有被使用。
This section summarizes the substantive changes made to Sections of RFC 2830. Readers should consult [RFC4513] for summaries of changes to other sections.
本节总结了对RFC 2830章节所做的实质性更改。读者应参考[RFC4513]了解其他章节的变更摘要。
- Removed wording indicating that referrals can be returned from StartTLS. - Removed requirement that only a narrow set of result codes can be returned. Some result codes are required in certain scenarios, but any other may be returned if appropriate. - Removed requirement that the ExtendedResponse.responseName MUST be present. There are circumstances where this is impossible, and requiring this is at odds with language in Section 4.12.
- 删除了表示可以从StartTLS返回转介的措辞。-删除了只能返回一小部分结果代码的要求。某些情况下需要某些结果代码，但如果合适，可以返回任何其他结果代码。-删除了必须存在ExtendedResponse.responseName的要求。在某些情况下，这是不可能的，要求这样做与第4.12节中的语言不一致。
- Reworded most of this section to align with definitions of the LDAP protocol layers. - Removed instructions on abrupt closure as this is covered in other areas of the document (specifically, Section 5.3)
- 改写了本节的大部分内容，以与LDAP协议层的定义保持一致。-删除了关于突然关闭的说明，因为本文件其他部分（特别是第5.3节）对此进行了说明
- Rewrote to fit into this document. In general, semantics were preserved. Supporting and background language seen as redundant due to its presence in this document was omitted.
- 重写以适应本文件。总的来说，语义得到了保留。由于本文件中存在冗余的支持语言和背景语言，因此被省略。
- Specified that Intermediate responses to a request may be of different types, and one of the response types may be specified to have no response value.
- 指定对请求的中间响应可以是不同的类型，并且其中一种响应类型可以指定为没有响应值。
Editor's Address
编辑地址
Jim Sermersheim Novell, Inc. 1800 South Novell Place Provo, Utah 84606, USA
Jim Sermersheim Novell，Inc.美国犹他州普罗沃南诺维尔广场1800号，邮编：84606
Phone: +1 801 861-3088
EMail: jimse@novell.com
Phone: +1 801 861-3088
EMail: jimse@novell.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。