Network Working Group K. Zeilenga
Request for Comments: 4521 OpenLDAP Foundation
BCP: 118 June 2006
Category: Best Current Practice
Network Working Group K. Zeilenga
Request for Comments: 4521 OpenLDAP Foundation
BCP: 118 June 2006
Category: Best Current Practice
Considerations for Lightweight Directory Access Protocol (LDAP) Extensions
轻量级目录访问协议（LDAP）扩展的注意事项
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions.
轻量级目录访问协议（LDAP）是可扩展的。它提供了添加新操作、扩展现有操作以及扩展用户和系统模式的机制。本文档讨论LDAP扩展设计者的注意事项。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. General Considerations ..........................................4
2.1. Scope of Extension .........................................4
2.2. Interaction between extensions .............................4
2.3. Discovery Mechanism ........................................4
2.4. Internationalization Considerations ........................5
2.5. Use of the Basic Encoding Rules ............................5
2.6. Use of Formal Languages ....................................5
2.7. Examples ...................................................5
2.8. Registration of Protocol Values ............................5
3. LDAP Operation Extensions .......................................6
3.1. Controls ...................................................6
3.1.1. Extending Bind Operation with Controls ..............6
3.1.2. Extending the Start TLS Operation with Controls .....7
3.1.3. Extending the Search Operation with Controls ........7
3.1.4. Extending the Update Operations with Controls .......8
3.1.5. Extending the Responseless Operations with Controls..8
3.2. Extended Operations ........................................8
3.3. Intermediate Responses .....................................8
3.4. Unsolicited Notifications ..................................9
4. Extending the LDAP ASN.1 Definition .............................9
4.1. Result Codes ...............................................9
4.2. LDAP Message Types .........................................9
4.3. Authentication Methods ....................................10
4.4. General ASN.1 Extensibility ...............................10
5. Schema Extensions ..............................................10
5.1. LDAP Syntaxes .............................................11
5.2. Matching Rules ............................................11
5.3. Attribute Types ...........................................12
5.4. Object Classes ............................................12
6. Other Extension Mechanisms .....................................12
6.1. Attribute Description Options .............................12
6.2. Authorization Identities ..................................12
6.3. LDAP URL Extensions .......................................12
7. Security Considerations ........................................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................15
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. General Considerations ..........................................4
2.1. Scope of Extension .........................................4
2.2. Interaction between extensions .............................4
2.3. Discovery Mechanism ........................................4
2.4. Internationalization Considerations ........................5
2.5. Use of the Basic Encoding Rules ............................5
2.6. Use of Formal Languages ....................................5
2.7. Examples ...................................................5
2.8. Registration of Protocol Values ............................5
3. LDAP Operation Extensions .......................................6
3.1. Controls ...................................................6
3.1.1. Extending Bind Operation with Controls ..............6
3.1.2. Extending the Start TLS Operation with Controls .....7
3.1.3. Extending the Search Operation with Controls ........7
3.1.4. Extending the Update Operations with Controls .......8
3.1.5. Extending the Responseless Operations with Controls..8
3.2. Extended Operations ........................................8
3.3. Intermediate Responses .....................................8
3.4. Unsolicited Notifications ..................................9
4. Extending the LDAP ASN.1 Definition .............................9
4.1. Result Codes ...............................................9
4.2. LDAP Message Types .........................................9
4.3. Authentication Methods ....................................10
4.4. General ASN.1 Extensibility ...............................10
5. Schema Extensions ..............................................10
5.1. LDAP Syntaxes .............................................11
5.2. Matching Rules ............................................11
5.3. Attribute Types ...........................................12
5.4. Object Classes ............................................12
6. Other Extension Mechanisms .....................................12
6.1. Attribute Description Options .............................12
6.2. Authorization Identities ..................................12
6.3. LDAP URL Extensions .......................................12
7. Security Considerations ........................................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................15
The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an extensible protocol.
轻量级目录访问协议（LDAP）[RFC4510]是一种可扩展协议。
LDAP allows for new operations to be added and for existing operations to be enhanced [RFC4511].
LDAP允许添加新操作和增强现有操作[RFC4511]。
LDAP allows additional schema to be defined [RFC4512][RFC4517]. This can include additional object classes, attribute types, matching rules, additional syntaxes, and other elements of schema. LDAP provides an ability to extend attribute types with options [RFC4512].
LDAP允许定义其他模式[RFC4512][RFC4517]。这可以包括附加的对象类、属性类型、匹配规则、附加语法和模式的其他元素。LDAP提供了使用选项[RFC4512]扩展属性类型的能力。
LDAP supports a Simple Authentication and Security Layer (SASL) authentication method [RFC4511][RFC4513]. SASL [RFC4422] is extensible. LDAP may be extended to support additional authentication methods [RFC4511].
LDAP支持简单身份验证和安全层（SASL）身份验证方法[RFC4511][RFC4513]。SASL[RFC4422]是可扩展的。LDAP可以扩展以支持其他身份验证方法[RFC4511]。
LDAP supports establishment of Transport Layer Security (TLS) [RFC4511][RFC4513]. TLS [RFC4346] is extensible.
LDAP支持建立传输层安全性（TLS）[RFC4511][RFC4513]。TLS[RFC4346]是可扩展的。
LDAP has an extensible Uniform Resource Locator (URL) format [RFC4516].
LDAP具有可扩展的统一资源定位器（URL）格式[RFC4516]。
Lastly, LDAP allows for certain extensions to the protocol's Abstract Syntax Notation - One (ASN.1) [X.680] definition to be made. This facilitates a wide range of protocol enhancements, for example, new result codes needed to support extensions to be added through extension of the protocol's ASN.1 definition.
最后，LDAP允许对协议的抽象语法符号-One（ASN.1）[X.680]定义进行某些扩展。这有助于广泛的协议增强，例如，支持通过扩展协议的ASN.1定义添加扩展所需的新结果代码。
This document describes practices that engineers should consider when designing extensions to LDAP.
该文档描述了工程师在设计LDAP扩展时应考虑的实践。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. In this document, "the specification", as used by BCP 14, RFC 2119, refers to the engineering of LDAP extensions.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。在本文档中，BCP14 RFC2119使用的“规范”指的是LDAP扩展的工程设计。
The term "Request Control" refers to a control attached to a client-generated message sent to a server. The term "Response Control" refers to a control attached to a server-generated message sent to a client.
术语“请求控制”是指附加到发送到服务器的客户端生成的消息的控制。术语“响应控制”是指附加到发送到客户端的服务器生成消息的控制。
DIT stands for Directory Information Tree. DSA stands for Directory System Agent, a server. DSE stands for DSA-Specific Entry. DUA stands for Directory User Agent, a client. DN stands for Distinguished Name.
DIT代表目录信息树。DSA代表目录系统代理，一个服务器。DSE代表DSA特定条目。DUA代表目录用户代理，一个客户端。DN代表可分辨名称。
Mutually agreeing peers may, within the confines of an extension, agree to significant changes in protocol semantics. However, designers MUST consider the impact of an extension upon protocol peers that have not agreed to implement or otherwise recognize and support the extension. Extensions MUST be "truly optional" [RFC2119].
在扩展的范围内，相互同意的对等方可能同意协议语义的重大变化。然而，设计者必须考虑扩展对协议对等体的影响，这些协议对等点不同意实现或以其他方式识别和支持扩展。扩展必须是“真正可选的”[RFC2119]。
Designers SHOULD consider how extensions they engineer interact with other extensions.
设计者应该考虑工程师如何与其他扩展交互。
Designers SHOULD consider the extensibility of extensions they specify. Extensions to LDAP SHOULD themselves be extensible.
设计者应该考虑他们指定的扩展的可扩展性。LDAP的扩展本身应该是可扩展的。
Except where it is stated otherwise, extensibility is implied.
除非另有说明，否则暗示可扩展性。
Extensions SHOULD provide adequate discovery mechanisms.
扩展应该提供足够的发现机制。
As LDAP design is based upon the client-request/server-response paradigm, the general discovery approach is for the client to discover the capabilities of the server before utilizing a particular extension. Commonly, this discovery involves querying the root DSE and/or other DSEs for operational information associated with the extension. LDAP provides no mechanism for a server to discover the capabilities of a client.
由于LDAP设计基于客户机请求/服务器响应范例，因此一般的发现方法是让客户机在使用特定扩展之前发现服务器的功能。通常，此发现涉及查询根DSE和/或其他DSE以获取与扩展相关的操作信息。LDAP没有为服务器提供发现客户机功能的机制。
The 'supportedControl' attribute [RFC4512] is used to advertise supported controls. The 'supportedExtension' attribute [RFC4512] is used to advertise supported extended operations. The 'supportedFeatures' attribute [RFC4512] is used to advertise features. Other root DSE attributes MAY be defined to advertise other capabilities.
“supportedControl”属性[RFC4512]用于公布受支持的控件。“supportedExtension”属性[RFC4512]用于公布支持的扩展操作。“supportedFeatures”属性[RFC4512]用于公布功能。可以定义其他根DSE属性来公布其他功能。
LDAP is designed to support the full Unicode [Unicode] repertory of characters. Extensions SHOULD avoid unnecessarily restricting applications to subsets of Unicode (e.g., Basic Multilingual Plane, ISO 8859-1, ASCII, Printable String).
LDAP旨在支持完整的Unicode[Unicode]字符库。扩展应避免不必要地将应用程序限制在Unicode的子集（例如，基本多语言平面、ISO 8859-1、ASCII、可打印字符串）。
LDAP Language Tag options [RFC3866] provide a mechanism for tagging text (and other) values with language information. Extensions that define attribute types SHOULD allow use of language tags with these attributes.
LDAP语言标记选项[RFC3866]提供了一种使用语言信息标记文本（和其他）值的机制。定义属性类型的扩展应该允许使用具有这些属性的语言标记。
Numerous elements of LDAP are described using ASN.1 [X.680] and are encoded using a particular subset [Protocol, Section 5.2] of the Basic Encoding Rules (BER) [X.690]. To allow reuse of parsers/generators used in implementing the LDAP "core" technical specification [RFC4510], it is RECOMMENDED that extension elements (e.g., extension specific contents of controlValue, requestValue, responseValue fields) described by ASN.1 and encoded using BER be subjected to the restrictions of [Protocol, Section 5.2].
LDAP的许多元素使用ASN.1[X.680]进行描述，并使用基本编码规则（BER）[X.690]的特定子集[协议，第5.2节]进行编码。为了允许重用用于实施LDAP“核心”技术规范[RFC4510]的解析器/生成器，建议ASN.1描述并使用BER编码的扩展元素（如controlValue、requestValue、responseValue字段的扩展特定内容）受[协议，第5.2节]的限制。
Formal languages SHOULD be used in specifications in accordance with IESG guidelines [FORMAL].
规范中应根据IESG指南[正式]使用正式语言。
Example DN strings SHOULD conform to the syntax defined in [RFC4518]. Example LDAP filter strings SHOULD conform to the syntax defined in [RFC4515]. Example LDAP URLs SHOULD conform to the syntax defined in [RFC4516]. Entries SHOULD be represented using LDIF [RFC2849].
示例DN字符串应符合[RFC4518]中定义的语法。示例LDAP筛选器字符串应符合[RFC4515]中定义的语法。示例LDAP URL应符合[RFC4516]中定义的语法。条目应使用LDIF[RFC2849]表示。
Designers SHALL register protocol values of their LDAP extensions in accordance with BCP 64, RFC 4520 [RFC4520]. Specifications that create new extensible protocol elements SHALL extend existing registries or establish new registries for values of these elements in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434 [RFC2434].
设计者应根据BCP 64、RFC 4520[RFC4520]注册其LDAP扩展的协议值。创建新的可扩展协议元素的规范应根据BCP 64、RFC 4520[RFC4520]和BCP 26、RFC 2434[RFC2434]扩展现有注册表或为这些元素的值建立新注册表。
Extensions SHOULD use controls in defining extensions that complement existing operations. Where the extension to be defined does not complement an existing operation, designers SHOULD consider defining an extended operation instead.
扩展应该使用控件来定义补充现有操作的扩展。在定义的扩展不补充现有操作的情况下，设计者应考虑定义扩展操作。
For example, a subtree delete operation could be designed as either an extension of the delete operation or as a new operation. As the feature complements the existing delete operation, use of the control mechanism to extend the delete operation is likely more appropriate.
例如，子树删除操作可以设计为删除操作的扩展或新操作。由于该特性是对现有删除操作的补充，因此使用控制机制来扩展删除操作可能更合适。
As a counter (and contrived) example, a locate services operation (an operation that would return for a DN a set of LDAP URLs to services that may hold the entry named by this DN) could be designed as either a search operation or a new operation. As the feature doesn't complement the search operation (e.g., the operation is not contrived to search for entries held in the Directory Information Tree), it is likely more appropriate to define a new operation using the extended operation mechanism.
作为一个计数器（和人为设计的）示例，定位服务操作（将为DN返回一组LDAP URL到可能包含此DN命名的条目的服务的操作）可以设计为搜索操作或新操作。由于该功能不补充搜索操作（例如，该操作不是为了搜索目录信息树中的条目而设计的），因此使用扩展操作机制定义新操作可能更合适。
Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for extending existing operations. The existing operation can be a base operation defined in [RFC4511] (e.g., search, modify) , an extended operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or an operation defined as an extension to a base or extended operation.
控制[协议，第4.1.11节]是扩展现有操作的推荐机制。现有操作可以是[RFC4511]中定义的基本操作（例如，搜索、修改）、扩展操作（例如，启动TLS[RFC4511]、密码修改[RFC3062]），或者定义为基本操作或扩展操作的扩展的操作。
Extensions SHOULD NOT return Response controls unless the server has specific knowledge that the client can make use of the control. Generally, the client requests the return of a particular response control by providing a related request control.
扩展不应该返回响应控件，除非服务器知道客户端可以使用该控件。通常，客户端通过提供相关的请求控件来请求返回特定的响应控件。
An existing operation MAY be extended to return IntermediateResponse messages [Protocol, Section 4.13].
可以扩展现有操作以返回中间响应消息[协议，第4.13节]。
Specifications of controls SHALL NOT attach additional semantics to the criticality of controls beyond those defined in [Protocol, Section 4.1.11]. A specification MAY mandate the criticality take on a particular value (e.g., TRUE or FALSE), where appropriate.
控制规范不得附加超出[协议，第4.1.11节]定义的控制关键性的附加语义。在适当的情况下，规范可规定临界值采用特定值（如真或假）。
Controls attached to the request and response messages of a Bind Operation [RFC4511] are not protected by any security layers established by that Bind operation.
附加到绑定操作[RFC4511]的请求和响应消息的控件不受该绑定操作建立的任何安全层的保护。
Specifications detailing controls extending the Bind operation SHALL detail that the Bind negotiated security layers do not protect the information contained in these controls and SHALL detail how the information in these controls is protected or why the information does not need protection.
详细说明扩展绑定操作的控件的规范应详细说明绑定协商的安全层不保护这些控件中包含的信息，并应详细说明如何保护这些控件中的信息或为什么这些信息不需要保护。
It is RECOMMENDED that designers consider alternative mechanisms for providing the function. For example, an extended operation issued subsequent to the Bind operation (hence, protected by the security layers negotiated by the Bind operation) might be used to provide the desired function.
建议设计者考虑替代机制来提供该功能。例如，绑定操作之后发布的扩展操作（因此，受绑定操作协商的安全层保护）可用于提供所需的功能。
Additionally, designers of Bind control extensions MUST also consider how the controls' semantics interact with individual steps of a multi-step Bind operation. Note that some steps are optional and thus may require special attention in the design.
此外，绑定控件扩展的设计者还必须考虑控件的语义如何与多步绑定操作的各个步骤交互。请注意，有些步骤是可选的，因此在设计中可能需要特别注意。
Controls attached to the request and response messages of a Start TLS Operation [RFC4511] are not protected by the security layers established by the Start TLS operation.
附加到启动TLS操作[RFC4511]的请求和响应消息的控件不受启动TLS操作建立的安全层保护。
Specifications detailing controls extending the Start TLS operation SHALL detail that the Start TLS negotiated security layers do not protect the information contained in these controls and SHALL detail how the information in these controls is protected or why the information does not need protection.
详细说明扩展Start TLS操作的控制的规范应详细说明Start TLS协商的安全层不保护这些控制中包含的信息，并应详细说明如何保护这些控制中的信息或为什么信息不需要保护。
It is RECOMMENDED that designers consider alternative mechanisms for providing the function. For example, an extended operation issued subsequent to the Start TLS operation (hence, protected by the security layers negotiated by the Start TLS operation) might be used to provided the desired function.
建议设计者考虑替代机制来提供该功能。例如，在启动TLS操作之后发布的扩展操作（因此，受启动TLS操作协商的安全层保护）可用于提供所需的功能。
The Search operation processing has two distinct phases:
搜索操作处理有两个不同的阶段：
- finding the base object; and
- 找到基础对象；和
- searching for objects at or under that base object.
- 在该基础对象处或之下搜索对象。
Specifications of controls extending the Search Operation should clearly state in which phase(s) the control's semantics apply. Semantics of controls that are not specific to the Search Operation SHOULD apply in the finding phase.
扩展搜索操作的控件规范应明确说明控件语义应用于哪个阶段。非特定于搜索操作的控件的语义应在查找阶段应用。
Update operations have properties of atomicity, consistency, isolation, and durability ([ACID]).
更新操作具有原子性、一致性、隔离性和持久性（[ACID]）。
- atomicity: All or none of the DIT changes requested are made.
- 原子性：请求的DIT更改全部或全部未进行。
- consistency: The resulting DIT state must be conform to schema and other constraints.
- 一致性：结果DIT状态必须符合架构和其他约束。
- isolation: Intermediate states are not exposed.
- 隔离：不暴露中间状态。
- durability: The resulting DIT state is preserved until subsequently updated.
- 持久性：生成的DIT状态将保留到后续更新。
When defining a control that requests additional (or other) DIT changes be made to the DIT, these additional changes SHOULD NOT be treated as part of a separate transaction. The specification MUST be clear as to whether the additional DIT changes are part of the same or a separate transaction as the DIT changes expressed in the request of the base operation.
定义请求对DIT进行附加（或其他）DIT更改的控件时，这些附加更改不应视为单独事务的一部分。规范必须明确，附加的DIT更改是与基本操作请求中表示的DIT更改相同的事务的一部分，还是单独的事务的一部分。
When defining a control that requests additional (or other) DIT changes be made to the DIT, the specification MUST be clear as to the order in which these and the base changes are to be applied to the DIT.
定义要求对DIT进行额外（或其他）DIT更改的控件时，规范必须明确这些更改和基本更改应用于DIT的顺序。
The Abandon and Unbind operations do not include a response message. For this reason, specifications for controls designed to be attached to Abandon and Unbind requests SHOULD mandate that the control's criticality be FALSE.
放弃和取消绑定操作不包括响应消息。因此，设计用于放弃和解除绑定请求的控件规范应规定控件的关键性为假。
Extended Operations [Protocol, Section 4.12] are the RECOMMENDED mechanism for defining new operations. An extended operation consists of an ExtendedRequest message, zero or more IntermediateResponse messages, and an ExtendedResponse message.
扩展操作[协议，第4.12节]是定义新操作的推荐机制。扩展操作由一条ExtendedRequest消息、零条或多条IntermediateResponse消息和一条ExtendedResponse消息组成。
Extensions SHALL use IntermediateResponse messages instead of ExtendedResponse messages to return intermediate results.
扩展应使用中间响应消息而不是ExtendedResponse消息来返回中间结果。
Unsolicited notifications [Protocol, Section 4.4] offer a capability for the server to notify the client of events not associated with the operation currently being processed.
未经请求的通知[协议，第4.4节]为服务器提供了一种能力，可以将与当前正在处理的操作无关的事件通知客户端。
Extensions SHOULD be designed such that unsolicited notifications are not returned unless the server has specific knowledge that the client can make use of the notification. Generally, the client requests the return of a particular unsolicited notification by performing a related extended operation.
扩展的设计应确保不会返回未经请求的通知，除非服务器明确知道客户端可以使用通知。通常，客户端通过执行相关的扩展操作来请求返回特定的未经请求的通知。
For example, a time hack extension could be designed to return unsolicited notifications at regular intervals that were enabled by an extended operation (which possibly specified the desired interval).
例如，时间黑客扩展可以被设计成定期返回未经请求的通知，这些通知由扩展操作启用（可能指定了所需的时间间隔）。
LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1 definition [Protocol, Appendix B] to be made.
LDAP允许对LDAP ASN.1定义[协议，附录B]进行有限扩展[协议，第4节]。
Extensions that specify new operations or enhance existing operations often need to define new result codes. The extension SHOULD be designed such that a client has a reasonably clear indication of the nature of the successful or non-successful result.
指定新操作或增强现有操作的扩展通常需要定义新的结果代码。扩展的设计应确保客户能够合理明确地指示成功或不成功结果的性质。
Extensions SHOULD use existing result codes to indicate conditions that are consistent with the intended meaning [RFC4511][X.511] of these codes. Extensions MAY introduce new result codes [RFC4520] where no existing result code provides an adequate indication of the nature of the result.
扩展应使用现有结果代码来指示与这些代码的预期含义[RFC4511][X.511]一致的条件。扩展可能会引入新的结果代码[RFC4520]，其中现有的结果代码不能充分指示结果的性质。
Extensions SHALL NOT disallow or otherwise restrict the return of general service result codes, especially those reporting a protocol, service, or security problem, or indicating that the server is unable or unwilling to complete the operation.
扩展不得禁止或以其他方式限制返回一般服务结果代码，尤其是那些报告协议、服务或安全问题，或表明服务器无法或不愿完成操作的代码。
While extensions can specify new types of LDAP messages by extending the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally unnecessary and inappropriate. Existing operation extension mechanisms (e.g., extended operations, unsolicited notifications, and intermediate responses) SHOULD be used instead. However, there may be cases where an extension does not fit well into these mechanisms.
虽然扩展可以通过扩展LDAPMessage序列的protocolOp选项来指定新的LDAP消息类型，但这通常是不必要和不合适的。应改用现有的操作扩展机制（例如，扩展操作、未经请求的通知和中间响应）。但是，在某些情况下，扩展可能不适合这些机制。
In such cases, a new extension mechanism SHOULD be defined that can be used by multiple extensions that have similar needs.
在这种情况下，应该定义一种新的扩展机制，可以由具有类似需求的多个扩展使用。
The Bind operation currently supports two authentication methods, simple and SASL. SASL [RFC4422] is an extensible authentication framework used by multiple application-level protocols (e.g., BEEP, IMAP, SMTP). It is RECOMMENDED that new authentication processes be defined as SASL mechanisms. New LDAP authentication methods MAY be added to support new authentication frameworks.
绑定操作目前支持两种身份验证方法，simple和SASL。SASL[RFC4422]是一个可扩展的身份验证框架，由多个应用程序级协议（如BEEP、IMAP、SMTP）使用。建议将新的身份验证过程定义为SASL机制。可以添加新的LDAP身份验证方法以支持新的身份验证框架。
The Bind operation's primary function is to establish the LDAP association [RFC4513]. No other operation SHALL be defined (or extended) to establish the LDAP association. However, other operations MAY be defined to establish other security associations (e.g., IPsec).
绑定操作的主要功能是建立LDAP关联[RFC4513]。不得定义（或扩展）任何其他操作来建立LDAP关联。然而，可以定义其他操作以建立其他安全关联（例如，IPsec）。
Section 4 of [RFC4511] states the following:
[RFC4511]第4节规定如下：
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]中所述，这些类型可以显式扩展。由于隐含的可扩展性，客户机和服务器必须（除非另有规定）忽略其标记不可识别的尾部序列组件。
Designers SHOULD avoid introducing extensions that rely on unsuspecting implementations to ignore trailing components of SEQUENCE whose tags they do not recognize.
设计者应该避免引入依赖于毫无防备的实现的扩展，以忽略序列的后续组件，这些组件的标签是他们无法识别的。
Extensions defining LDAP schema elements SHALL provide schema definitions conforming with syntaxes defined in [Models, Section 4.1]. While provided definitions MAY be reformatted (line wrapped) for readability, this SHALL be noted in the specification.
定义LDAP模式元素的扩展应提供符合[模型，第4.1节]中定义的语法的模式定义。虽然提供的定义可以重新格式化（换行）以便于阅读，但应在规范中注明。
For definitions that allow a NAME field, new schema elements SHOULD provide one and only one name. The name SHOULD be short.
对于允许名称字段的定义，新架构元素应提供一个且仅提供一个名称。名字应该很短。
Each schema definition allows a DESC field. The DESC field, if provided, SHOULD contain a short descriptive phrase. The DESC field MUST be regarded as informational. That is, the specification MUST
每个模式定义都允许一个DESC字段。DESC字段（如果提供）应包含一个简短的描述性短语。“描述”字段必须视为信息字段。也就是说，规范必须
be written such that its interpretation is the same with and without the provided DESC fields.
书写时应确保其解释与提供的DESC字段的解释相同。
The extension SHALL NOT mandate that implementations provide the same DESC field in the schema they publish. Implementors MAY replace or remove the DESC field.
扩展不应强制实现在其发布的模式中提供相同的DESC字段。实施者可以替换或删除DESC字段。
Published schema elements SHALL NOT be redefined. Replacement schema elements (new OIDs, new NAMEs) SHOULD be defined as needed.
不得重新定义已发布的架构元素。应根据需要定义替换架构元素（新OID、新名称）。
Schema designers SHOULD reuse existing schema elements, where appropriate. However, any reuse MUST not alter the semantics of the element.
在适当的情况下，模式设计者应该重用现有的模式元素。但是，任何重用都不能改变元素的语义。
Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680]. Each extension detailing an LDAP syntax MUST specify the ASN.1 data definition associated with the syntax. A distinct LDAP syntax SHOULD be created for each distinct ASN.1 data definition (including constraints).
每个LDAP语法[RFC4517]都是根据ASN.1[X.680]定义的。每个详细说明LDAP语法的扩展必须指定与该语法关联的ASN.1数据定义。应该为每个不同的ASN.1数据定义（包括约束）创建不同的LDAP语法。
Each LDAP syntax SHOULD have a string encoding defined for it. It is RECOMMENDED that this string encoding be restricted to UTF-8 [RFC3629] encoded Unicode [Unicode] characters. Use of Generic String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic string encoding rules to provide string encodings for complex ASN.1 data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that the string encoding be described using a formal language (e.g., ABNF [RFC4234]). Formal languages SHOULD be used in specifications in accordance with IESG guidelines [FORMAL].
每个LDAP语法都应该定义一个字符串编码。建议将此字符串编码限制为UTF-8[RFC3629]编码的Unicode[Unicode]字符。建议使用通用字符串编码规则（GSER）[RFC3641][RFC3642]或其他通用字符串编码规则为复杂ASN.1数据定义提供字符串编码。否则，建议使用正式语言（例如ABNF[RFC4234]）描述字符串编码。规范中应根据IESG指南[正式]使用正式语言。
If no string encoding is defined, the extension SHALL specify how the transfer encoding is to be indicated. Generally, the extension SHOULD mandate use of binary or other transfer encoding option.
如果未定义字符串编码，则扩展名应指定如何指示传输编码。通常，扩展应该强制使用二进制或其他传输编码选项。
Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and SUBSTRING) may be associated with an attribute type. In addition, LDAP provides an extensible matching rule mechanism.
三种基本类型的匹配规则（例如，相等、排序和子字符串）可能与属性类型相关联。此外，LDAP还提供了一种可扩展的匹配机制。
The matching rule specification SHOULD detail which kind of matching rule it is and SHOULD describe which kinds of values it can be used with.
匹配规则规范应该详细说明它是哪种类型的匹配规则，并且应该描述它可以与哪种类型的值一起使用。
In addition to requirements stated in the LDAP technical specification, equality matching rules SHOULD be commutative.
除了LDAP技术规范中规定的要求外，相等匹配规则还应该是可交换的。
Designers SHOULD carefully consider how the structure of values is to be restricted. Designers SHOULD consider that servers will only enforce constraints of the attribute's syntax. That is, an attribute intended to hold URIs, but that has directoryString syntax, is not restricted to values that are URIs.
设计师应该仔细考虑如何限制价值结构。设计者应该考虑服务器只会执行属性语法的约束。也就是说，用于保存URI但具有directoryString语法的属性不限于URI值。
Designers SHOULD carefully consider which matching rules, if any, are appropriate for the attribute type. Matching rules specified for an attribute type MUST be compatible with the attribute type's syntax.
设计者应该仔细考虑哪些匹配规则（如果有的话）适合于属性类型。为属性类型指定的匹配规则必须与属性类型的语法兼容。
Extensions specifying operational attributes MUST detail how servers are to maintain and/or utilize values of each operational attribute.
指定操作属性的扩展必须详细说明服务器如何维护和/或利用每个操作属性的值。
Designers SHOULD carefully consider whether each attribute of an object class is required ("MUST") or allowed ("MAY").
设计者应该仔细考虑对象类的每个属性是否需要（“必须”）或允许（“可能”）。
Extensions specifying object classes that allow (or require) operational attributes MUST specify how servers are to maintain and/or utilize entries belonging to these object classes.
指定允许（或需要）操作属性的对象类的扩展必须指定服务器如何维护和/或利用属于这些对象类的条目。
Each option is identified by a string of letters, numbers, and hyphens. This string SHOULD be short.
每个选项都由一串字母、数字和连字符标识。这个字符串应该很短。
Extensions interacting with authorization identities SHALL support the LDAP authzId format [RFC4513]. The authzId format is extensible.
与授权标识交互的扩展应支持LDAP authzId格式[RFC4513]。authzId格式是可扩展的。
LDAP URL extensions are identified by a short string, a descriptor. Like other descriptors, the string SHOULD be short.
LDAP URL扩展由一个短字符串（描述符）标识。与其他描述符一样，字符串应该很短。
LDAP does not place undue restrictions on the kinds of extensions that can be implemented. While this document attempts to outline some specific issues that designers need to consider, it is not (and
LDAP不会对可以实现的扩展类型施加不适当的限制。虽然本文档试图概述设计者需要考虑的一些具体问题，但它不是（和）
cannot be) all encompassing. Designers MUST do their own evaluations of the security considerations applicable to their extensions.
不能是）包罗万象的。设计人员必须对适用于其扩展的安全注意事项进行自己的评估。
Designers MUST NOT assume that the LDAP "core" technical specification [RFC4510] adequately addresses the specific concerns surrounding their extensions or assume that their extensions have no specific concerns.
设计者不得假设LDAP“核心”技术规范[RFC4510]充分解决了围绕其扩展的特定问题，或假设其扩展没有特定问题。
Extension specifications, however, SHOULD note whether security considerations specific to the feature they are extending, as well as general LDAP security considerations, apply to the extension.
但是，扩展规范应该注意它们所扩展的功能的特定安全注意事项以及一般LDAP安全注意事项是否适用于扩展。
The author thanks the IETF LDAP community for their thoughtful comments.
作者感谢IETF LDAP社区提出的深思熟虑的意见。
This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce Greenblatt.
这项工作基于Bruce Greenblatt的“LDAP扩展风格指南”[Guide]。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[RFC2849]Good，G.，“LDAP数据交换格式（LDIF）-技术规范”，RFC 28492000年6月。
[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月。
[RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003.
[RFC3641]Legg，S.“ASN.1类型的通用字符串编码规则（GSER）”，RFC 3641，2003年10月。
[RFC3642] Legg, S., "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, October 2003.
[RFC3642]Legg，S.，“通用字符串编码规则（GSER）编码的公共元素”，RFC 3642，2003年10月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512]Zeilenga，K.，“轻量级目录访问协议（LDAP）：目录信息模型”，RFC4512，2006年6月。
[RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)", RFC 3866, July 2004.
[RFC3866]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）中的语言标记和范围”，RFC 3866，2004年7月。
[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月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，Ed.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年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月。
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
[RFC4515]Smith，M.，Ed.和T.Howes，“轻量级目录访问协议（LDAP）：搜索过滤器的字符串表示”，RFC45152006年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月。
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4518, June 2006.
[RFC4518]Zeilenga，K.，“轻量级目录访问协议（LDAP）：可分辨名称的字符串表示”，RFC4518，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月。
[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月。
[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/).
[FORMAL] IESG, "Guidelines for the use of formal languages in IETF specifications", <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt>, 2001.
[正式]IESG，“IETF规范中正式语言使用指南”<http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt>, 2001.
[X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
[X.511]国际电信联盟-电信标准化部门，“目录：抽象服务定义”，X.511（1993）（也称ISO/IEC 9594-3:1993）。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.680]国际电信联盟-电信标准化部门，“抽象语法符号1（ASN.1）-基本符号规范”，X.680（2002）（也称ISO/IEC 8824-1:2002）。
[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(2002) (also ISO/IEC 8825-1:2002).
[X.690]国际电信联盟-电信标准化部门，“ASN.1编码规则规范：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）”，X.690（2002）（另见ISO/IEC 8825-1:2002）。
[ACID] Section 4 of ISO/IEC 10026-1:1992.
[酸]ISO/IEC 10026-1:1992第4节。
[GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in Progress.
[GUIDE]Greenblatt，B.，“LDAP扩展风格指南”，正在进行中。
[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", RFC 3062, February 2001.
[RFC3062]Zeilenga，K.，“LDAP密码修改扩展操作”，RFC 3062，2001年2月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
Author's Address
作者地址
Kurt D. Zeilenga OpenLDAP Foundation
库尔特D.Zeeliga OpenLDAP基金会
EMail: Kurt@OpenLDAP.org
EMail: Kurt@OpenLDAP.org
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）提供。