Network Working Group R. Megginson, Ed.
Request for Comments: 3928 Netscape Communications Corp.
Category: Standards Track M. Smith
Pearl Crescent, LLC
O. Natkovich
Yahoo
J. Parham
Microsoft Corporation
October 2004
Network Working Group R. Megginson, Ed.
Request for Comments: 3928 Netscape Communications Corp.
Category: Standards Track M. Smith
Pearl Crescent, LLC
O. Natkovich
Yahoo
J. Parham
Microsoft Corporation
October 2004
Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)
轻型目录访问协议（LDAP）客户端更新协议（LCUP）
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content.
本文档定义了轻量级目录访问协议（LDAP）客户端更新协议（LCUP）。该协议旨在允许LDAP客户端与LDAP服务器存储的目录信息树（DIT）的内容同步，并通知该内容的更改。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification of Protocol Elements . . . . . . . . . . . . . . 5
3.1. ASN.1 Considerations . . . . . . . . . . . . . . . . . . 5
3.2. Universally Unique Identifiers . . . . . . . . . . . . . 5
3.3. LCUP Scheme and LCUP Cookie. . . . . . . . . . . . . . . 5
3.4. LCUP Context . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Additional LDAP Result Codes defined by LCUP . . . . . . 6
3.6. Sync Request Control . . . . . . . . . . . . . . . . . . 7
3.7. Sync Update Control. . . . . . . . . . . . . . . . . . . 7
3.8. Sync Done Control. . . . . . . . . . . . . . . . . . . . 8
4. Protocol Usage and Flow. . . . . . . . . . . . . . . . . . . . 8
4.1. LCUP Search Requests . . . . . . . . . . . . . . . . . . 8
4.1.1. Initial Synchronization and Full Resync . . . . . 9
4.1.2. Incremental or Update Synchronization . . . . . . 10
4.1.3. Persistent Only . . . . . . . . . . . . . . . . . 10
4.2. LCUP Search Responses. . . . . . . . . . . . . . . . . . 10
4.2.1. Sync Update Informational Responses . . . . . . . 11
4.2.2. Cookie Return Frequency . . . . . . . . . . . . . 11
4.2.3. Definition of an Entry That Has Entered the
Result Set. . . . . . . . . . . . . . . . . . . . 12
4.2.4. Definition of an Entry That Has Changed . . . . . 13
4.2.5. Definition of an Entry That Has Left the
Result Set. . . . . . . . . . . . . . . . . . . . 13
4.2.6. Results For Entries Present in the Result Set . . 14
4.2.7. Results For Entries That Have Left the Result
Set . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Responses Requiring Special Consideration . . . . . . . . 15
4.3.1. Returning Results During the Persistent Phase . . 15
4.3.2. No Mixing of Sync Phase with Persist Phase. . . . 16
4.3.3. Returning Updated Results During the Sync Phase . 16
4.3.4. Operational Attributes and Administrative
Entries . . . . . . . . . . . . . . . . . . . . . 16
4.3.5. Virtual Attributes. . . . . . . . . . . . . . . . 17
4.3.6. Modify DN and Delete Operations Applied to
Subtrees. . . . . . . . . . . . . . . . . . . . . 17
4.3.7. Convergence Guarantees. . . . . . . . . . . . . . 18
4.4. LCUP Search Termination. . . . . . . . . . . . . . . . . 18
4.4.1. Server Initiated Termination. . . . . . . . . . . 18
4.4.2. Client Initiated Termination. . . . . . . . . . . 19
4.5. Size and Time Limits . . . . . . . . . . . . . . . . . . 19
4.6. Operations on the Same Connection. . . . . . . . . . . . 19
4.7. Interactions with Other Controls . . . . . . . . . . . . 19
4.8. Replication Considerations . . . . . . . . . . . . . . . 20
5. Client Side Considerations . . . . . . . . . . . . . . . . . . 20
5.1. Using Cookies with Different Search Criteria . . . . . . 20
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification of Protocol Elements . . . . . . . . . . . . . . 5
3.1. ASN.1 Considerations . . . . . . . . . . . . . . . . . . 5
3.2. Universally Unique Identifiers . . . . . . . . . . . . . 5
3.3. LCUP Scheme and LCUP Cookie. . . . . . . . . . . . . . . 5
3.4. LCUP Context . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Additional LDAP Result Codes defined by LCUP . . . . . . 6
3.6. Sync Request Control . . . . . . . . . . . . . . . . . . 7
3.7. Sync Update Control. . . . . . . . . . . . . . . . . . . 7
3.8. Sync Done Control. . . . . . . . . . . . . . . . . . . . 8
4. Protocol Usage and Flow. . . . . . . . . . . . . . . . . . . . 8
4.1. LCUP Search Requests . . . . . . . . . . . . . . . . . . 8
4.1.1. Initial Synchronization and Full Resync . . . . . 9
4.1.2. Incremental or Update Synchronization . . . . . . 10
4.1.3. Persistent Only . . . . . . . . . . . . . . . . . 10
4.2. LCUP Search Responses. . . . . . . . . . . . . . . . . . 10
4.2.1. Sync Update Informational Responses . . . . . . . 11
4.2.2. Cookie Return Frequency . . . . . . . . . . . . . 11
4.2.3. Definition of an Entry That Has Entered the
Result Set. . . . . . . . . . . . . . . . . . . . 12
4.2.4. Definition of an Entry That Has Changed . . . . . 13
4.2.5. Definition of an Entry That Has Left the
Result Set. . . . . . . . . . . . . . . . . . . . 13
4.2.6. Results For Entries Present in the Result Set . . 14
4.2.7. Results For Entries That Have Left the Result
Set . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Responses Requiring Special Consideration . . . . . . . . 15
4.3.1. Returning Results During the Persistent Phase . . 15
4.3.2. No Mixing of Sync Phase with Persist Phase. . . . 16
4.3.3. Returning Updated Results During the Sync Phase . 16
4.3.4. Operational Attributes and Administrative
Entries . . . . . . . . . . . . . . . . . . . . . 16
4.3.5. Virtual Attributes. . . . . . . . . . . . . . . . 17
4.3.6. Modify DN and Delete Operations Applied to
Subtrees. . . . . . . . . . . . . . . . . . . . . 17
4.3.7. Convergence Guarantees. . . . . . . . . . . . . . 18
4.4. LCUP Search Termination. . . . . . . . . . . . . . . . . 18
4.4.1. Server Initiated Termination. . . . . . . . . . . 18
4.4.2. Client Initiated Termination. . . . . . . . . . . 19
4.5. Size and Time Limits . . . . . . . . . . . . . . . . . . 19
4.6. Operations on the Same Connection. . . . . . . . . . . . 19
4.7. Interactions with Other Controls . . . . . . . . . . . . 19
4.8. Replication Considerations . . . . . . . . . . . . . . . 20
5. Client Side Considerations . . . . . . . . . . . . . . . . . . 20
5.1. Using Cookies with Different Search Criteria . . . . . . 20
5.2. Renaming the Base Object . . . . . . . . . . . . . . . . 20
5.3. Use of Persistent Searches With Respect to Resources . . 21
5.4. Continuation References to Other LCUP Contexts . . . . . 21
5.5. Referral Handling. . . . . . . . . . . . . . . . . . . . 21
5.6. Multiple Copies of Same Entry During Sync Phase. . . . . 21
5.7. Handling Server Out of Resources Condition . . . . . . . 21
6. Server Implementation Considerations . . . . . . . . . . . . . 22
6.1. Server Support for UUIDs . . . . . . . . . . . . . . . . 22
6.2. Example of Using an RUV as the Cookie Value. . . . . . . 22
6.3. Cookie Support Issues. . . . . . . . . . . . . . . . . . 22
6.3.1. Support for Multiple Cookie Schemes . . . . . . . 22
6.3.2. Information Contained in the Cookie . . . . . . . 23
6.4. Persist Phase Response Time. . . . . . . . . . . . . . . 23
6.5. Scaling Considerations . . . . . . . . . . . . . . . . . 23
6.6. Alias Dereferencing. . . . . . . . . . . . . . . . . . . 24
7. Synchronizing Heterogeneous Data Stores. . . . . . . . . . . . 24
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix - Features Left Out of LCUP . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
5.2. Renaming the Base Object . . . . . . . . . . . . . . . . 20
5.3. Use of Persistent Searches With Respect to Resources . . 21
5.4. Continuation References to Other LCUP Contexts . . . . . 21
5.5. Referral Handling. . . . . . . . . . . . . . . . . . . . 21
5.6. Multiple Copies of Same Entry During Sync Phase. . . . . 21
5.7. Handling Server Out of Resources Condition . . . . . . . 21
6. Server Implementation Considerations . . . . . . . . . . . . . 22
6.1. Server Support for UUIDs . . . . . . . . . . . . . . . . 22
6.2. Example of Using an RUV as the Cookie Value. . . . . . . 22
6.3. Cookie Support Issues. . . . . . . . . . . . . . . . . . 22
6.3.1. Support for Multiple Cookie Schemes . . . . . . . 22
6.3.2. Information Contained in the Cookie . . . . . . . 23
6.4. Persist Phase Response Time. . . . . . . . . . . . . . . 23
6.5. Scaling Considerations . . . . . . . . . . . . . . . . . 23
6.6. Alias Dereferencing. . . . . . . . . . . . . . . . . . . 24
7. Synchronizing Heterogeneous Data Stores. . . . . . . . . . . . 24
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix - Features Left Out of LCUP . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
The LCUP protocol is intended to allow LDAP clients to synchronize with the content stored by LDAP servers.
LCUP协议旨在允许LDAP客户端与LDAP服务器存储的内容同步。
The problem areas addressed by the protocol include:
该议定书涉及的问题领域包括：
- Mobile clients that maintain a local read-only copy of the directory data. While off-line, the client uses the local copy of the data. When the client connects to the network, it synchronizes with the current directory content and can optionally receive notification about the changes that occur while it is on-line. For example, a mail client can maintain a local copy of the corporate address book that it synchronizes with the master copy whenever the client is connected to the corporate network.
- 维护目录数据的本地只读副本的移动客户端。脱机时，客户端使用数据的本地副本。当客户端连接到网络时，它将与当前目录内容同步，并且可以选择接收有关联机时发生的更改的通知。例如，邮件客户机可以维护公司通讯簿的本地副本，只要客户机连接到公司网络，该副本就会与主副本同步。
- Applications intending to synchronize heterogeneous data stores. A meta directory application, for instance, would periodically retrieve a list of modified entries from the directory, construct the changes and apply them to a foreign data store.
- 打算同步异构数据存储的应用程序。例如，元目录应用程序将定期从目录中检索修改的条目列表，构造更改并将其应用于外部数据存储。
- Clients that need to take certain actions when a directory entry is modified. For instance, an electronic mail repository may want to perform a "create mailbox" task when a new person entry is added to an LDAP directory and a "delete mailbox" task when a person entry is removed.
- 当目录项被修改时需要采取某些操作的客户端。例如，电子邮件存储库可能希望在向LDAP目录添加新的个人条目时执行“创建邮箱”任务，在删除个人条目时执行“删除邮箱”任务。
The problem areas not being considered:
未考虑的问题领域：
- Directory server to directory server synchronization. The IETF is developing a LDAP replication protocol, called LDUP [RFC3384], which is specifically designed to address this problem area.
- 目录服务器到目录服务器的同步。IETF正在开发一种LDAP复制协议，称为LDUP[RFC3384]，专门设计用于解决这一问题。
There are currently several protocols in use for LDAP client server synchronization. While each protocol addresses the needs of a particular group of clients (e.g., on-line clients or off-line clients), none satisfies the requirements of all clients in the target group. For instance, a mobile client that was off-line and wants to become up to date with the server and stay up to date while connected can't be easily supported by any of the existing protocols.
目前有几种用于LDAP客户机-服务器同步的协议。虽然每个协议都满足特定客户群（例如，在线客户或离线客户）的需求，但没有一个协议满足目标群体中所有客户的需求。例如，一个离线的移动客户端想要与服务器保持最新，并且在连接时保持最新，这是任何现有协议都不容易支持的。
LCUP is designed such that the server does not need to maintain state information specific to individual clients. The server may need to maintain additional state information about attribute modifications, deleted entries, and moved/renamed entries. The clients are responsible for storing the information about how up to date they are with respect to the server's content. LCUP design avoids the need for LCUP-specific update agreements to be made between client and server prior to LCUP use. The client decides when and from where to retrieve the changes. LCUP design requires clients to initiate the update session and "pull" the changes from server.
LCUP的设计使得服务器不需要维护特定于单个客户端的状态信息。服务器可能需要维护有关属性修改、已删除项和已移动/重命名项的其他状态信息。客户机负责存储有关其对服务器内容的更新程度的信息。LCUP设计避免了在使用LCUP之前在客户端和服务器之间签订LCUP特定更新协议的需要。客户机决定何时何地检索更改。LCUP设计要求客户端启动更新会话并从服务器“拉”出更改。
LCUP operations are subject to administrative and access control policies enforced by the server.
LCUP操作受服务器强制实施的管理和访问控制策略的约束。
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, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
LCUP will work best if the following conditions are met:
如果满足以下条件，LCUP将发挥最佳作用：
1) The server stores some degree of historical state or change information to reduce the amount of wire traffic required for incremental synchronizations. The optimal balance between server state and wire traffic varies amongst implementations and usage scenarios, and is therefore left in the hands of implementers.
1) 服务器存储一定程度的历史状态或更改信息，以减少增量同步所需的有线通信量。服务器状态和有线通信量之间的最佳平衡因实现和使用场景而异，因此由实现者掌握。
2) The client cannot be assumed to understand the physical information model (virtual attributes, operational attributes, subentries, etc.) implemented by the server. Optimizations would be possible if such assumptions could be made.
2) 不能假设客户机理解服务器实现的物理信息模型（虚拟属性、操作属性、子项等）。如果能够做出这样的假设，优化是可能的。
3) Meta data changes and renames and deletions of large subtrees are very infrequent. LCUP makes these assumptions in order to reduce client complexity required to deal with these special operations, though when they do occur they may result in a large number of incremental update messages or a full resync.
3) 元数据更改、大型子树的重命名和删除非常罕见。LCUP做出这些假设是为了降低处理这些特殊操作所需的客户端复杂性，尽管当这些操作发生时，可能会导致大量增量更新消息或完全重新同步。
The following sections define the new elements required to use this protocol.
以下各节定义了使用本协议所需的新元素。
Protocol elements are described using ASN.1 [X.680]. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC2251]. All ASN.1 in this document uses implicit tags.
协议元素使用ASN.1[X.680]进行描述。术语“BER编码”是指根据[RFC2251]第5.1节详述的限制，使用基本编码规则[X.690]对元素进行编码。本文档中的所有ASN.1都使用隐式标记。
Distinguished names can change, so are therefore unreliable as identifiers. A Universally Unique Identifier (or UUID for short) MUST be used to uniquely identify entries used with LCUP. The UUID is part of the Sync Update control value (see below) returned with each search result. The server SHOULD provide the UUID as a single valued operational attribute of the entry (e.g., "entryUUID"). We RECOMMEND that the server provides a way to do efficient (i.e., indexed) searches for values of UUID, e.g., by using a search filter like (entryUUID=<some UUID value>) to quickly search for and retrieve an entry based on its UUID. Servers SHOULD use a UUID format as specified in [UUID]. The UUID used by LCUP is a value of the following ASN.1 type:
可分辨名称可以更改，因此它们作为标识符是不可靠的。必须使用通用唯一标识符（简称UUID）来唯一标识与LCUP一起使用的条目。UUID是每个搜索结果返回的同步更新控制值（见下文）的一部分。服务器应提供UUID作为条目的单值操作属性（例如，“entryUUID”）。我们建议服务器提供一种对UUID值进行高效（即索引）搜索的方法，例如，通过使用类似（entryUUID=<some UUID value>）的搜索过滤器快速搜索和检索基于其UUID的条目。服务器应使用[UUID]中指定的UUID格式。LCUP使用的UUID是以下ASN.1类型的值：
LCUPUUID ::= OCTET STRING
LCUPUUID ::= OCTET STRING
The LCUP protocol uses a cookie to hold the state of the client's data with respect to the server's data. Each cookie format is uniquely identified by its scheme. The LCUP Scheme is a value of the following ASN.1 type:
LCUP协议使用cookie保存客户端数据相对于服务器数据的状态。每个cookie格式都由其方案唯一标识。LCUP方案是以下ASN.1类型的值：
LCUPScheme ::= LDAPOID
LCUPScheme ::= LDAPOID
This is the OID which identifies the format of the LCUP Cookie value. The scheme OID, as all object identifiers, MUST be unique for a given cookie scheme. The cookie value may be opaque or it may be exposed to LCUP clients. For cookie schemes that expose their value, the preferred form of documentation is an RFC. It is expected that there will be one or more standards track cookie schemes where the value format is exposed and described in detail.
这是标识LCUP Cookie值格式的OID。与所有对象标识符一样，方案OID对于给定的cookie方案必须是唯一的。cookie值可能是不透明的，也可能暴露给LCUP客户端。对于公开其价值的cookie方案，首选的文档形式是RFC。预计将有一个或多个标准跟踪cookie方案，其中值格式将公开并详细描述。
The LCUP Cookie is a value of the following ASN.1 type:
LCUP Cookie是以下ASN.1类型的值：
LCUPCookie ::= OCTET STRING
LCUPCookie ::= OCTET STRING
This is the actual data describing the state of the client's data. This value may be opaque, or its value may have some well-known format, depending on the scheme.
这是描述客户机数据状态的实际数据。此值可能是不透明的，或者其值可能具有某种众所周知的格式，具体取决于方案。
Further uses of the LCUP Cookie value are described below.
LCUP Cookie值的进一步使用如下所述。
A part of the DIT which is enabled for LCUP is referred to as an LCUP Context. A server may support one or more LCUP Contexts. For example, a server with two naming contexts may support LCUP in one naming context but not the other, or support different LCUP cookie schemes in each naming context. Each LCUP Context MAY use a different cookie scheme. An LCUP search will not cross an LCUP Context boundary, but will instead return a SearchResultReference message, with the LDAP URL specifying the same host and port as currently being searched, and with the baseDN set to the baseDN of the new LCUP Context. The client is then responsible for issuing another search using the new baseDN, and possibly a different cookie if that LCUP Context uses a different cookie. The client is responsible for maintaining a mapping of the LDAP URL to its corresponding cookie.
为LCUP启用的DIT的一部分称为LCUP上下文。服务器可以支持一个或多个LCUP上下文。例如，具有两个命名上下文的服务器可能在一个命名上下文中支持LCUP，但在另一个命名上下文中不支持，或者在每个命名上下文中支持不同的LCUP cookie方案。每个LCUP上下文可以使用不同的cookie方案。LCUP搜索不会跨越LCUP上下文边界，而是返回一条SearchResultReference消息，其中LDAP URL指定与当前搜索相同的主机和端口，并且baseDN设置为新LCUP上下文的baseDN。然后，客户机负责使用新的baseDN发出另一个搜索，如果LCUP上下文使用不同的cookie，则可能发出不同的cookie。客户机负责维护LDAP URL到其相应cookie的映射。
Implementations of this specification SHALL recognize the following additional resultCode values. The LDAP result code names and numbers defined in the following table have been assigned by IANA per RFC 3383 [RFC3383].
本规范的实施应识别以下额外的resultCode值。IANA根据RFC 3383[RFC3383]分配了下表中定义的LDAP结果代码名称和编号。
lcupResourcesExhausted (113) the server is running out of resources lcupSecurityViolation (114) the client is suspected of malicious actions lcupInvalidData (115) invalid scheme or cookie was supplied by the client
LCUPResourcesExhousted（113）服务器资源不足lcupSecurityViolation（114）客户端怀疑有恶意操作lcupInvalidData（115）客户端提供的方案或cookie无效
lcupUnsupportedScheme (116) The cookie scheme is a valid OID but is not supported by this server lcupReloadRequired (117) indicates that client data needs to be reinitialized. This reason is returned if the server does not contain sufficient information to synchronize the client or if the server's data was reloaded since the last synchronization session
lcupUnsupportedScheme（116）cookie方案是有效的OID，但此服务器不支持该方案。LCUPreloadRequested（117）表示需要重新初始化客户端数据。如果服务器没有包含足够的信息来同步客户端，或者自上次同步会话以来重新加载了服务器的数据，则会返回此原因
The uses of these codes are described below.
这些代码的用途如下所述。
The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2] where the controlType is the object identifier 1.3.6.1.1.7.1 and the controlValue, an OCTET STRING, contains a BER-encoded syncRequestControlValue.
同步请求控件是一个LDAP控件[RFC2251，第4.1.2节]，其中controlType是对象标识符1.3.6.1.1.7.1，controlValue是一个八位字符串，包含一个BER编码的syncRequestControlValue。
syncRequestControlValue ::= SEQUENCE {
updateType ENUMERATED {
syncOnly (0),
syncAndPersist (1),
persistOnly (2) },
sendCookieInterval [0] INTEGER OPTIONAL,
scheme [1] LCUPScheme OPTIONAL,
cookie [2] LCUPCookie OPTIONAL
}
syncRequestControlValue ::= SEQUENCE {
updateType ENUMERATED {
syncOnly (0),
syncAndPersist (1),
persistOnly (2) },
sendCookieInterval [0] INTEGER OPTIONAL,
scheme [1] LCUPScheme OPTIONAL,
cookie [2] LCUPCookie OPTIONAL
}
sendCookieInterval - the server SHOULD send the cookie back in the Sync Update control value (defined below) for every sendCookieInterval number of SearchResultEntry and SearchResultReference PDUs returned to the client. For example, if the value is 5, the server SHOULD send the cookie back in the Sync Update control value for every 5 search results returned to the client. If this value is absent, zero or less than zero, the server chooses the interval.
sendCookieInterval-对于返回到客户端的SearchResultEntry和SearchResultReference PDU的每个sendCookieInterval数，服务器应以同步更新控制值（定义如下）的形式将cookie发送回客户端。例如，如果该值为5，则服务器应将每返回到客户端的5个搜索结果的cookie发送回同步更新控制值。如果该值不存在、为零或小于零，服务器将选择间隔。
The Sync Request Control is only applicable to the searchRequest message. Use of this control is described below.
同步请求控件仅适用于searchRequest消息。下面介绍此控件的使用。
The Sync Update Control is an LDAP Control [RFC2251, Section 4.1.2] where the controlType is the object identifier 1.3.6.1.1.7.2 and the controlValue, an OCTET STRING, contains a BER-encoded syncUpdateControlValue.
同步更新控件是一个LDAP控件[RFC2251，第4.1.2节]，其中controlType是对象标识符1.3.6.1.1.7.2，controlValue是一个八位字符串，包含一个BER编码的SyncUpdateControl值。
syncUpdateControlValue ::= SEQUENCE {
stateUpdate BOOLEAN,
entryUUID [0] LCUPUUID OPTIONAL, -- REQUIRED for entries --
UUIDAttribute [1] AttributeType OPTIONAL,
entryLeftSet [2] BOOLEAN,
persistPhase [3] BOOLEAN,
scheme [4] LCUPScheme OPTIONAL,
cookie [5] LCUPCookie OPTIONAL
}
syncUpdateControlValue ::= SEQUENCE {
stateUpdate BOOLEAN,
entryUUID [0] LCUPUUID OPTIONAL, -- REQUIRED for entries --
UUIDAttribute [1] AttributeType OPTIONAL,
entryLeftSet [2] BOOLEAN,
persistPhase [3] BOOLEAN,
scheme [4] LCUPScheme OPTIONAL,
cookie [5] LCUPCookie OPTIONAL
}
The field UUIDAttribute contains the name or OID of the attribute that the client should use to perform searches for entries based on the UUID. The client should be able to use it in an equality search filter, e.g., "(<uuid attribute>=<entry UUID value>)" and should be able to use it in the attribute list of the search request to return its value. The UUIDAttribute field may be omitted if the server does not support searching on the UUID values.
字段UUIDAttribute包含属性的名称或OID，客户端应使用该属性根据UUID搜索条目。客户端应该能够在相等搜索筛选器中使用它，例如“（<uuid attribute>=<entry uuid value>）”，并且应该能够在搜索请求的属性列表中使用它来返回其值。如果服务器不支持对UUID值进行搜索，则可以省略UUIDAttribute字段。
The Sync Update Control is only applicable to SearchResultEntry and SearchResultReference messages. Although entryUUID is OPTIONAL, it MUST be used with SearchResultEntry messages. Use of this control is described below.
同步更新控件仅适用于SearchResultEntry和SearchResultReference消息。尽管entryUUID是可选的，但它必须与SearchResultEntry消息一起使用。下面介绍此控件的使用。
The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2] where the controlType is the object identifier 1.3.6.1.1.7.3 and the controlValue contains a BER-encoded syncDoneValue.
同步完成控件是LDAP控件[RFC2251，第4.1.2节]，其中controlType是对象标识符1.3.6.1.1.7.3，controlValue包含BER编码的syncDoneValue。
syncDoneValue ::= SEQUENCE {
scheme [0] LCUPScheme OPTIONAL,
cookie [1] LCUPCookie OPTIONAL
}
syncDoneValue ::= SEQUENCE {
scheme [0] LCUPScheme OPTIONAL,
cookie [1] LCUPCookie OPTIONAL
}
The Sync Done Control is only applicable to SearchResultDone message. Use of this control is described below.
同步完成控件仅适用于SearchResultOne消息。下面介绍此控件的使用。
A client initiates a synchronization or persistent search session with a server by attaching a Sync Request control to an LDAP searchRequest message. The search specification determines the part of the directory information tree (DIT) the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. The Sync Request control contains the client's request specification.
客户端通过将同步请求控件附加到LDAP searchRequest消息，启动与服务器的同步或持久搜索会话。搜索规范确定客户端希望与之同步的目录信息树（DIT）部分、感兴趣的属性集以及客户端希望接收的数据量。同步请求控件包含客户端的请求规范。
If there is an error condition, the server MUST immediately return a SearchResultDone message with the resultCode set to an error code. This table maps a condition to its corresponding behavior and resultCode.
如果出现错误情况，服务器必须立即返回一条SearchResultOne消息，并将resultCode设置为错误代码。此表将条件映射到其相应的行为和结果代码。
Condition Behavior or resultCode
条件行为或结果代码
Sync Request Control is not Server behaves as [RFC2251, Section supported 4.1.2] - specifically, if the criticality of the control is FALSE, the server will process the request as a normal search request
同步请求控制不是服务器的行为[RFC2251，第4.1.2节支持]——具体来说，如果控制的关键性为假，服务器将作为正常搜索请求处理该请求
Scheme is not supported lcupUnsupportedScheme
方案不受支持lcupUnsupportedScheme
A control value field is lcupInvalidData invalid (e.g., illegal updateType, or the scheme is not a valid OID, or the cookie is invalid)
控制值字段lcupInvalidData无效（例如，非法的updateType，或者方案不是有效的OID，或者cookie无效）
Server is running out of lcupResourcesExhausted resources
服务器正在耗尽LCUPResourcesExhousted资源
Server suspects client of lcupSecurityViolation malicious behavior (frequent connects/disconnects, etc.)
服务器怀疑客户端存在lcupSecurityViolation恶意行为（频繁连接/断开连接等）
The server cannot bring the lcupReloadRequired client up to date (server data has been reloaded, or other changes prevent convergence)
服务器无法使LCUPPERLOADREQUIRED客户端处于最新状态（服务器数据已重新加载，或其他更改阻止聚合）
For an initial synchronization or full resync, the fields of the Sync Request control MUST be specified as follows:
对于初始同步或完全重新同步，必须按如下方式指定同步请求控件的字段：
updateType - MUST be set to syncOnly or syncAndPersist sendCookieInterval - MAY be set scheme - MAY be set - if set, the server MUST use this specified scheme or return lcupUnsupportedScheme (see above) - if not set, the server MAY use any scheme it supports. cookie - MUST NOT be set
updateType-必须设置为syncOnly或syncAndPersist sendCookieInterval-可以设置方案-可以设置-如果设置，服务器必须使用此指定方案或返回lcupUnsupportedScheme（请参见上文）-如果未设置，服务器可以使用其支持的任何方案。cookie-不得设置
If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
如果请求成功，客户端将收到下面“LCUP搜索响应”部分所述的结果。
For an incremental or update synchronization, the fields of the Sync Request control MUST be specified as follows:
对于增量或更新同步，同步请求控件的字段必须指定如下：
updateType - MUST be set to syncOnly or syncAndPersist sendCookieInterval - MAY be set scheme - MUST be set cookie - MUST be set
updateType-必须设置为syncOnly或syncAndPersist sendCookieInterval-可以设置为scheme-必须设置为cookie-必须设置为
The client SHOULD always use the latest cookie it received from the server.
客户端应始终使用从服务器收到的最新cookie。
If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
如果请求成功，客户端将收到下面“LCUP搜索响应”部分所述的结果。
For persistent only search request, the fields of the Sync Request MUST be specified as follows:
对于仅永久性搜索请求，必须按如下方式指定同步请求的字段：
updateType - MUST be set to persistOnly sendCookieInterval - MAY be set scheme - MAY be set - if set, the server MUST use this specified scheme or return lcupUnsupportedScheme (see above) - if not set, the server MAY use any scheme it supports. cookie - MAY be set, but the server MUST ignore it
updateType-必须设置为persistOnly sendCookieInterval-可以设置方案-可以设置方案-如果设置，服务器必须使用此指定方案或返回lcupUnsupportedScheme（请参见上文）-如果未设置，服务器可以使用其支持的任何方案。cookie-可以设置，但服务器必须忽略它
If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
如果请求成功，客户端将收到下面“LCUP搜索响应”部分所述的结果。
In response to the client's LCUP request, the server returns zero or more SearchResultEntry or SearchResultReference PDUs that fit the client's specification, followed by a SearchResultDone PDU. The behavior is as specified in [RFC2251 Section 4.5]. Each SearchResultEntry or SearchResultReference PDU also contains a Sync Update control that describes the LCUP state of the returned entry. The SearchResultDone PDU contains a Sync Done control. The following sections specify behaviors in addition to [RFC2251 Section 4.5].
响应客户端的LCUP请求，服务器返回零个或多个符合客户端规范的SearchResultEntry或SearchResultReference PDU，然后返回一个SearchResultOne PDU。行为符合[RFC2251第4.5节]的规定。每个SearchResultEntry或SearchResultReference PDU还包含一个同步更新控件，该控件描述返回项的LCUP状态。SearchResultOne PDU包含一个同步完成控件。除[RFC2251第4.5节]外，以下各节还规定了行为。
The server may use the Sync Update control to return information not related to a particular entry. It MAY do this at any time to return a cookie to the client, or to inform the client that the sync phase of a syncAndPersist search is complete and the persist phase has begun. It MAY do this during the persist phase even though no entry has changed that would have normally triggered a response. In order to do this, it is REQUIRED to return the following:
服务器可以使用同步更新控件返回与特定条目无关的信息。它可以在任何时候执行此操作，以将cookie返回给客户端，或通知客户端syncAndPersist搜索的同步阶段已完成，并且持久化阶段已开始。它可以在持久化阶段执行此操作，即使没有更改通常会触发响应的条目。为此，需要返回以下信息：
- A SearchResultEntry PDU with the objectName field set to the DN of the baseObject of the search request and with an empty attribute list.
- objectName字段设置为搜索请求的baseObject的DN且属性列表为空的SearchResultEntry PDU。
- A Sync Update control value with the fields set to the following:
- 字段设置为以下值的同步更新控制值：
stateUpdate - MUST be set to TRUE entryUUID - SHOULD be set to the UUID of the baseObject of the search request entryLeftSet - MUST be set to FALSE persistPhase - MUST be FALSE if the search is in the sync phase of a request, and MUST be TRUE if the search is in the persist phase UUIDAttribute - SHOULD only be set if this is either the first result returned or if the attribute has changed scheme - MUST be set if the cookie is set and the cookie format has changed; otherwise, it MAY be omitted cookie - SHOULD be set
stateUpdate-必须设置为TRUE entryUUID-应设置为搜索请求的baseObject的UUID entryLeftSet-必须设置为FALSE persistPhase-如果搜索处于请求的同步阶段，则必须为FALSE，如果搜索处于持久化阶段，则必须为TRUE；如果设置了cookie且cookie格式已更改，则必须设置UUIDAttribute（仅当这是返回的第一个结果或属性已更改方案时才应设置）；否则，它可能会被忽略-应设置cookie
If the server merely wants to return a cookie to the client, it should return as above with the cookie field set.
如果服务器只想将cookie返回给客户端，则应如上所述返回cookie字段。
During a syncAndPersist request, the server MUST return (as above) immediately after the last entry of the sync phase has been sent and before the first entry of the persist phase has been sent. In this case, the persistPhase field MUST be set to TRUE. This allows the client to know that the sync phase is complete and the persist phase is starting.
在syncAndPersist请求期间，服务器必须在发送了同步阶段的最后一个条目之后和发送了持久阶段的第一个条目之前立即返回（如上所述）。在这种情况下，persistPhase字段必须设置为TRUE。这允许客户端知道同步阶段已完成，而持久化阶段正在启动。
The cookie field of the Sync Update control value MAY be set in any returned result, during both the sync phase and the persist phase. The server should return the cookie to the client often enough for the client to resync in a reasonable period of time in case the search is disconnected or otherwise terminated. The sendCookieInterval field in the Sync Request control is a suggestion
同步更新控制值的cookie字段可以在同步阶段和持久化阶段的任何返回结果中设置。服务器应经常将cookie返回给客户端，以便客户端在合理的时间段内重新同步，以防搜索被断开或以其他方式终止。同步请求控件中的sendCookieInterval字段是一个建议
to the server of how often to return the cookie in the Sync Update control. The server SHOULD respect this value.
向服务器发送在同步更新控件中返回cookie的频率。服务器应尊重此值。
The scheme field of the Sync Update control value MUST be set if the cookie is set and the cookie format has changed; otherwise, it MAY be omitted.
如果设置了cookie且cookie格式已更改，则必须设置同步更新控制值的scheme字段；否则，可以省略它。
Some clients may have unreliable connections, for example, a wireless device or a WAN connection. These clients may want to insure that the cookie is returned often in the Sync Update control value, so that if they have to reconnect, they do not have to process many redundant entries. These clients should set the sendCookieInterval in the Sync Request control value to a low number, perhaps even 1. Some clients may have a limited bandwidth connection, and may not want to receive the cookie very often, or even at all (however, the cookie is always sent back in the Sync Done control value upon successful completion). These clients should set the sendCookieInterval in the Sync Request control value to a high number.
一些客户端可能具有不可靠的连接，例如，无线设备或WAN连接。这些客户机可能希望确保cookie经常以同步更新控制值返回，以便在必须重新连接时，不必处理许多冗余条目。这些客户端应将同步请求控制值中的sendCookieInterval设置为一个较低的数字，甚至可能是1。某些客户端可能具有有限的带宽连接，并且可能不希望经常接收cookie，甚至根本不希望接收cookie（但是，cookie总是在成功完成后以Sync Done控制值发送回）。这些客户端应将同步请求控制值中的sendCookieInterval设置为一个较高的数字。
A reasonable behavior of the server is to return the cookie only when data in the LCUP context has changed, even if the client has specified a frequent sendCookieInterval. If nothing has changed, the server can probably save some bandwidth by not returning the cookie.
服务器的一种合理行为是，仅当LCUP上下文中的数据发生更改时才返回cookie，即使客户端指定了频繁的sendCookieInterval。如果没有任何变化，服务器可能会通过不返回cookie来节省一些带宽。
An entry SHALL BE considered to have entered the client's search result set if one of the following conditions is met:
如果满足以下条件之一，则应将条目视为已输入客户的搜索结果集：
- During the sync phase for an incremental sync operation, the entry is present in the search result set but was not present before; this can be due to the entry being added via an LDAP Add operation, or by the entry being moved into the result set by an LDAP Modify DN operation, or by some modification to the entry that causes it to enter the result set (e.g., adding an attribute value that matches the clients search filter), or by some meta-data change that causes the entry to enter the result set (e.g., relaxing of some access control that permits the entry to be visible to the client).
- 在增量同步操作的同步阶段，条目出现在搜索结果集中，但以前不存在；这可能是由于通过LDAP Add操作添加了条目，或者是由于LDAP Modify DN操作将条目移动到结果集中，或者是由于对条目的某些修改导致其进入结果集（例如，添加与客户端搜索筛选器匹配的属性值），或者通过一些元数据更改，导致条目进入结果集（例如，放松一些允许条目对客户端可见的访问控制）。
- During the persist phase for a persistent search operation, the entry enters the search result set; this can be due to the entry being added via an LDAP Add operation, or by the entry being moved into the result set by an LDAP Modify DN operation, or by some modification to the entry that causes it to enter the result set (e.g., adding an attribute value that matches the clients search filter), or by some meta-data change that causes the entry to
- 在持久搜索操作的持久化阶段，条目进入搜索结果集；这可能是由于通过LDAP Add操作添加了条目，或者是由于LDAP Modify DN操作将条目移动到结果集中，或者是由于对条目的某些修改导致其进入结果集（例如，添加与客户端搜索筛选器匹配的属性值），或者通过一些元数据更改导致条目
enter the result set (e.g., relaxing of some access control that permits the entry to be visible to the client).
输入结果集（例如，放松一些访问控制，允许客户端可以看到输入）。
An entry SHALL BE considered to be changed if one or more of the attributes in the attribute list in the search request have been modified. For example, if the search request listed the attributes "cn sn uid", and there is an entry in the client's search result set with the "cn" attribute that has been modified, the entry is considered to be modified. The modification may be due to an LDAP Modify operation or by some change to the meta-data for the entry (e.g., virtual attributes) that causes some change to the value of the specified attributes.
如果已修改搜索请求中属性列表中的一个或多个属性，则应将条目视为已更改。例如，如果搜索请求列出了属性“cn sn uid”，并且客户端的搜索结果集中有一个条目具有已修改的“cn”属性，则该条目被视为已修改。修改可能是由于LDAP修改操作或条目元数据（例如，虚拟属性）的某些更改导致指定属性值的某些更改。
The converse of this is that an entry SHALL NOT BE considered to be changed if none of the attributes in the attribute list of the search request are modified attributes of the entry. For example, if the search request listed the attributes "cn sn uid", and there is an entry in the client's search result set with the "foo" attribute that has been modified, and none of the "cn" or "sn" or "uid" attributes have been modified, the entry is NOT considered to be changed.
相反，如果搜索请求的属性列表中没有任何属性是条目的修改属性，则条目不应被视为已更改。例如，如果搜索请求列出了属性“cn sn uid”，并且客户端的搜索结果集中有一个条目具有已修改的“foo”属性，并且“cn”或“sn”或“uid”属性均未修改，则该条目不被视为已修改。
An entry SHALL BE considered to have left the client's search result set if one of the following conditions is met:
如果满足以下条件之一，则应将条目视为已离开客户的搜索结果集：
- During the sync phase for an incremental sync operation, the entry is not present in the search result set but was present before; this can be due to the entry being deleted via an LDAP Delete operation, or by the entry leaving the result set via an LDAP Modify DN operation, or by some modification to the entry that causes it to leave the result set (e.g., changing/removing an attribute value so that it no longer matches the client's search filter), or by some meta-data change that causes the entry to leave the result set (e.g., adding of some access control that denies the entry to be visible to the client).
- 在增量同步操作的同步阶段，该条目在搜索结果集中不存在，但以前存在；这可能是由于通过LDAP删除操作删除了条目，或者是由于条目通过LDAP修改DN操作离开了结果集，或者是由于对条目的某些修改导致其离开了结果集（例如，更改/删除属性值，使其不再匹配客户端的搜索筛选器），或者通过一些元数据更改导致条目离开结果集（例如，添加一些访问控制，拒绝客户机看到条目）。
- During the persist phase for a persistent search operation, the entry leaves the search result set; this can be due to the entry being deleted via an LDAP Delete operation, or by the entry leaving the result set via an LDAP Modify DN operation, or by some modification to the entry that causes it to leave the result set (e.g., changing/removing an attribute value so that it no longer matches the client's search filter), or by some meta-data change
- 在持久搜索操作的持久化阶段，条目离开搜索结果集；这可能是由于通过LDAP删除操作删除了条目，或者是由于条目通过LDAP修改DN操作离开了结果集，或者是由于对条目的某些修改导致其离开了结果集（例如，更改/删除属性值，使其不再匹配客户端的搜索筛选器），或者通过一些元数据更改
that causes the entry to leave the result set (e.g., adding of some access control that denies the entry to be visible to the client).
这会导致条目离开结果集（例如，添加一些拒绝该条目对客户端可见的访问控制）。
An entry SHOULD be returned as present under the following conditions:
在下列情况下，条目应按当前状态返回：
- The request is an initial synchronization or full resync request and the entry is present in the client's search result set
- 该请求是初始同步或完全重新同步请求，并且该条目存在于客户端的搜索结果集中
- The request is an incremental synchronization and the entry has changed or entered the result set since the last sync
- 请求是增量同步，自上次同步以来，条目已更改或输入结果集
- The search is in the persist phase and the entry enters the result set or changes
- 搜索处于持久化阶段，条目进入结果集或更改
For a SearchResultEntry return, the fields of the Sync Update control value MUST be set as follows:
对于SearchResultEntry返回，同步更新控制值的字段必须设置如下：
stateUpdate - MUST be set to FALSE entryUUID - MUST be set to the UUID of the entry entryLeftSet - MUST be set to FALSE persistPhase - MUST be set to FALSE if during the sync phase or TRUE if during the persist phase UUIDAttribute - SHOULD only be set if this is either the first result returned or if the attribute has changed scheme - as above cookie - as above
stateUpdate-必须设置为FALSE entryUUID-必须设置为entryLeftSet项的UUID-必须设置为FALSE persistPhase-如果在同步阶段，则必须设置为FALSE；如果在持久阶段，则必须设置为TRUE UUIDAttribute-仅当这是返回的第一个结果或如果属性已更改scheme-如上所述cookie-如上所述
The searchResultReference return will look the same, except that the entryUUID is not required. If it is specified, it MUST contain the UUID of the DSE holding the reference knowledge.
searchResultReference返回值看起来相同，只是entryUUID不是必需的。如果已指定，则必须包含保存参考知识的DSE的UUID。
An entry SHOULD be returned as having left the result set under the following conditions:
在以下条件下，应返回一个已离开结果集的条目：
- The request is an incremental synchronization during the sync phase and the entry has left the result set
- 该请求在同步阶段是增量同步，并且条目已离开结果集
- The search is in the persist phase and the entry has left the result set
- 搜索处于持久化阶段，条目已离开结果集
- The entry has left the result set as a result of an LDAP Delete or LDAP Modify DN operation against the entry itself (i.e., not as a result of an operation against its parent or ancestor)
- 由于对条目本身执行LDAP Delete或LDAP Modify DN操作（即，不是针对其父项或祖先的操作），条目已离开结果集
For a SearchResultEntry return where the entry has left the result set, the fields of the Sync Update control value MUST be set as follows:
对于条目已离开结果集的SearchResultEntry返回，同步更新控制值的字段必须设置如下：
stateUpdate - MUST be set to FALSE entryUUID - MUST be set to the UUID of the entry that left the result set entryLeftSet - MUST be set to TRUE persistPhase - MUST be set to FALSE if during the sync phase or TRUE if during the persist phase UUIDAttribute - SHOULD only be set if this is either the first result returned or if the attribute has changed scheme - as above cookie - as above
stateUpdate-必须设置为FALSE entryUUID-必须设置为离开结果集entryLeftSet的条目的UUID-必须设置为TRUE persistPhase-如果在同步阶段，则必须设置为FALSE；如果在持久阶段，则必须设置为TRUE UUIDAttribute-仅当这是返回的第一个结果或属性已更改时才应设置更改的方案-如上cookie-如上
The searchResultReference return will look the same, except that the entryUUID is not required. If it is specified, it MUST contain the UUID of the DSE holding the reference knowledge.
searchResultReference返回值看起来相同，只是entryUUID不是必需的。如果已指定，则必须包含保存参考知识的DSE的UUID。
Some server implementations keep track of deleted entries using a tombstone - a hidden entry that keeps track of the state, but not all of the data, of an entry that has been deleted. In this case, the tombstone may not contain all of the original attributes of the entry, and therefore it may be impossible for the server to determine if an entry should be removed from the result set based on the attributes in the client's search request. Servers SHOULD keep enough information about the attributes in the deleted entries to determine if an entry should be removed from the result set. Since this may not be possible, the server MAY return an entry as having left the result set even if it is not or never was in the client's result set. Clients MUST ignore these notifications.
一些服务器实现使用墓碑跟踪已删除的条目，墓碑是一种隐藏条目，用于跟踪已删除条目的状态，但不是所有数据。在这种情况下，墓碑可能不包含条目的所有原始属性，因此服务器可能无法根据客户端搜索请求中的属性确定是否应从结果集中删除条目。服务器应保留有关已删除条目中属性的足够信息，以确定是否应从结果集中删除条目。由于这可能不可能，服务器可能会返回一个已离开结果集的条目，即使它不在或从未在客户端的结果集中。客户端必须忽略这些通知。
The following sections describe special handling that may be required when returning results.
以下章节描述了返回结果时可能需要的特殊处理。
During the persistent phase, the server SHOULD return the changed entries to the client as quickly as possible.
在持久化阶段，服务器应尽快将更改的条目返回给客户端。
During a sync phase, the server MUST NOT return any entries with the persistPhase flag set to TRUE, and during the persist phase, all entries returned MUST have the persistPhase flag set to TRUE. The server MUST NOT mix and match sync phase entries with persist phase entries. If there are any sync phase entries to return, they MUST be returned before any persist phase entries are returned.
在同步阶段，服务器不得返回任何persistPhase标志设置为TRUE的条目，在persist阶段，所有返回的条目都必须将persistPhase标志设置为TRUE。服务器不得将同步阶段项与持久阶段项混合匹配。如果有任何要返回的同步阶段项，则必须在返回任何持久阶段项之前返回它们。
There may be updates to the entries in the result set of a sync phase search during the actual search operation. If the DSA is under a heavy update load, and it attempts to send all of those updated entries to the client in addition to the other updates it was already planning to send for the sync phase, the server may never get to the end of the sync phase. Therefore, it is left up to the discretion of the server implementation to decide when the client is "in sync" - that is, when to end a syncOnly request, or when to send the Sync Update Informational Response between the sync phase and the persist phase of a syncAndPersist request. The server MAY send the same entry multiple times during the sync phase if the entry changes during the sync phase.
在实际搜索操作期间，同步阶段搜索结果集中的条目可能会有更新。如果DSA处于繁重的更新负载下，并且除了计划为同步阶段发送的其他更新外，它还尝试将所有更新的条目发送到客户端，则服务器可能永远无法到达同步阶段的末尾。因此，由服务器实现自行决定客户端何时“同步”——即何时结束syncOnly请求，或何时在syncAndPersist请求的同步阶段和持久阶段之间发送同步更新信息响应。如果条目在同步阶段发生更改，服务器可能会在同步阶段多次发送相同的条目。
A reasonable behavior is for the server to generate a cookie based on the server state at the time the client initiated the LCUP request, and only send entries up to that point during the sync phase. Entries updated after that point will be returned only during the persist phase of a syncAndPersist request, or only upon an incremental synchronization.
一种合理的行为是，服务器根据客户端启动LCUP请求时的服务器状态生成cookie，并且在同步阶段仅将条目发送到该点。在该点之后更新的条目将仅在syncAndPersist请求的持久化阶段返回，或者仅在增量同步时返回。
An operational attribute SHOULD be returned if it is specified in the attributes list and would normally be returned as subject to the constraints of [RFC2251 Section 4.5]. If the server does not support syncing of operational attributes, the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform.
如果在属性列表中指定了操作属性，则应返回该属性，并且通常根据[RFC2251第4.5节]的约束条件返回。如果服务器不支持操作属性的同步，则服务器必须返回一条SearchResultOne消息，其中resultCode为UnwillingOperForm。
LDAP Subentries [RFC3672] SHOULD be returned if they would normally be returned by the search request. If the server does not support syncing of LDAP Subentries, and the server can determine from the search request that the client has requested LDAP Subentries to be returned (e.g., search control or search filter), the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform. Otherwise, the server MAY simply omit returning LDAP Subentries.
如果搜索请求通常会返回LDAP子项[RFC3672]，则应返回这些子项。如果服务器不支持同步LDAP子项，并且服务器可以从搜索请求中确定客户端已请求返回LDAP子项（例如，搜索控制或搜索筛选器），则服务器必须返回一条SearchResultOne消息，其中resultCode为UnwillingOperform。否则，服务器可能会忽略返回的LDAP子项。
An entry may have attributes whose presence in the entry, or presence of values of the attribute, is generated on the fly, possibly by some mechanism outside of the entry, elsewhere in the DIT. An example of this is collective attributes [RFC3671]. These attributes shall be referred to in this document as virtual attributes.
条目可能具有属性，其在条目中的存在或属性值的存在是动态生成的，可能是由条目外部的某种机制在DIT的其他位置生成的。集体属性[RFC3671]就是一个例子。这些属性在本文件中称为虚拟属性。
LCUP treats these attributes the same way as normal, non-virtual attributes. A virtual attribute SHOULD be returned if it is specified in the attributes list and would normally be returned as subject to the constraints of [RFC2251 Section 4.5]. If the server does not support syncing of virtual attributes, the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform.
LCUP对待这些属性的方式与对待普通、非虚拟属性的方式相同。如果在属性列表中指定了虚拟属性，则应返回该虚拟属性，并且该虚拟属性通常会根据[RFC2251第4.5节]的约束条件返回。如果服务器不支持虚拟属性的同步，则服务器必须返回一条SearchResultOne消息，其中resultCode为UnwillingOperform。
One consequence of this is that if you change the definition of a virtual attribute such that it makes the value of that attribute change in many entries in the client's search scope, this means that a server may have to return many entries to the client as a result of that one change. It is not anticipated that this will be a frequent occurrence, and the server has the option to simply force the client to resync if necessary.
这样做的一个后果是，如果您更改虚拟属性的定义，使该属性的值在客户端搜索范围的多个条目中发生更改，这意味着服务器可能必须将多个条目返回给客户端。预计这种情况不会经常发生，服务器可以选择在必要时强制客户端重新同步。
It is also possible that a future LDAP control will allow the client to request only virtual or only non-virtual attributes.
将来的LDAP控件也可能允许客户端仅请求虚拟或非虚拟属性。
There is a special case where a Modify DN or a Delete operation is applied to the base entry of a subtree, and either that base entry or entries in the subtree are within the scope of an LCUP search request. In this case, all of the entries in the subtree are implicitly renamed or removed.
有一种特殊情况，修改DN或删除操作应用于子树的基本条目，并且该基本条目或子树中的条目在LCUP搜索请求的范围内。在这种情况下，子树中的所有条目都被隐式重命名或删除。
In either of these cases, the server MUST do one of the following:
在这两种情况下，服务器必须执行以下操作之一：
- treat all of these entries as having been renamed or removed and return each entry to the client as such
- 将所有这些条目视为已重命名或删除，并将每个条目返回给客户端
- decide that this would be prohibitively expensive, and force the client to resync
- 确定这样做的代价会高得让人望而却步，并强制客户端重新同步
If the search base object has been renamed, and the client has received a noSuchObject as the result of a search request, the client MAY use the entryUUID and UUIDAttribute to locate the new DN that is the result of the modify DN operation.
如果已重命名搜索基对象，并且客户端已收到noSuchObject作为搜索请求的结果，则客户端可以使用entryUUID和UUIDAttribute来定位作为修改DN操作结果的新DN。
If at any time during an LCUP search, either during the sync phase or the persist phase, the server determines that it cannot guarantee that it can bring the client's copy of the data to eventual convergence, it SHOULD immediately terminate the LCUP search request and return a SearchResultDone message with a resultCode of lcupReloadRequired. This can also happen at the beginning of an incremental synchronization request, if the client presents a cookie that is out of date or otherwise unable to be processed. The client should then issue an initial synchronization request.
如果在LCUP搜索过程中的任何时候，无论是在同步阶段还是在持久化阶段，服务器确定它无法保证能够将客户端的数据副本最终聚合，则它应该立即终止LCUP搜索请求，并返回一条SearchResultOne消息，其中resultCode为lcupReloadRequired。如果客户端提供的cookie已过期或无法处理，则在增量同步请求开始时也会发生这种情况。然后，客户端应发出初始同步请求。
This can happen, for example, if the data on the server is reloaded, or if there has been some change to the meta-data that makes it impossible for the server to determine if a particular entry should or should not be part of the search result set, or if the meta-data change makes it too resource intensive for the server to calculate the proper result set.
例如，如果服务器上的数据被重新加载，或者元数据发生了某些更改，使得服务器无法确定某个特定条目是否应该是搜索结果集的一部分，或者，如果元数据更改使服务器计算正确的结果集的资源过于密集。
The server can also return lcupReloadRequired if it determines that it would be more efficient for the client to perform a reload, for example, if too many entries have changed and a simple reload would be much faster.
如果服务器确定客户端执行重新加载会更有效，例如，如果更改了太多条目，并且简单的重新加载会快得多，则服务器还可以返回LCUPreloadRequested。
When the server has successfully finished processing the client's request, it attaches a Sync Done control to the SearchResultDone message and sends it to the client. However, if the SearchResultDone message contains a resultCode that is not success or canceled, the Sync Done control MAY be omitted. Although the LCUP cookie is OPTIONAL in the Sync Done control value, it MUST be set if the SearchResultDone resultCode is success or canceled. The server SHOULD also set the cookie if the resultCode is lcupResourcesExhausted, timeLimitExceeded, sizeLimitExceeded, or adminLimitExceeded. This allows the client to more easily resync later. If some error occurred, either an LDAP search error (e.g., insufficientAccessRights) or an LCUP error (e.g., lcupUnsupportedScheme), the cookie MAY be omitted. If the cookie is set, the scheme MUST be set also if the cookie format has changed, otherwise, it MAY be omitted.
当服务器成功地处理完客户机的请求后，它会将一个Sync Done控件附加到SearchResultDone消息，并将其发送给客户机。但是，如果SearchResultOne消息包含未成功或未取消的resultCode，则可能会忽略同步完成控件。尽管LCUP cookie在同步完成控制值中是可选的，但如果SearchResultOne resultCode成功或取消，则必须设置它。如果结果代码为lcupresourcesexhousted、timelimitexceed、sizelimitexceed或adminimitexeced，则服务器还应设置cookie。这允许客户端以后更容易地重新同步。如果发生了某些错误，LDAP搜索错误（例如，未充分访问权限）或LCUP错误（例如，lcupUnsupportedScheme），则可能会忽略cookie。如果设置了cookie，则如果cookie格式已更改，则还必须设置该方案，否则，可能会忽略该方案。
If server resources become tight, the server can terminate one or more search operations by sending a SearchResultDone message to the client(s) with a resultCode of lcupResourcesExhausted. The server SHOULD attach a Sync Done control with the cookie set. A server side
如果服务器资源紧张，服务器可以通过向客户端发送结果代码为lcupresourcesexhousted的SearchResultOne消息来终止一个或多个搜索操作。服务器应将Sync Done控件附加到cookie集。服务器端
policy is used to decide which searches to terminate. This can also be used as a security mechanism to disconnect clients that are suspected of malicious actions, but if the server can infer that the client is malicious, the server SHOULD return lcupSecurityViolation instead.
策略用于决定终止哪些搜索。这也可以用作安全机制来断开怀疑存在恶意操作的客户端的连接，但是如果服务器可以推断该客户端是恶意的，则服务器应该返回lcupSecurityViolation。
If the client needs to terminate the synchronization process and it wishes to obtain the cookie that represents the current state of its data, it issues an LDAP Cancel operation [RFC3909]. The server responds immediately with a LDAP Cancel response [RFC3909]. The server MAY send any pending SearchResultEntry or SearchResultReference PDUs if the server cannot easily abort or remove those search results from its outgoing queue. The server SHOULD send as few of these remaining messages as possible. Finally, the server sends the message SearchResultDone with the Sync Done control attached. If the search was successful up to that point, the resultCode field of the SearchResultDone message MUST be canceled [RFC3909], and the cookie MUST be set in the Sync Done control. If there is an error condition, the server MAY return as described in section 4.4.1 above, or MAY return as described in [RFC3909].
如果客户端需要终止同步过程，并且希望获取表示其数据当前状态的cookie，则会发出LDAP取消操作[RFC3909]。服务器立即响应LDAP取消响应[RFC3909]。如果服务器无法轻松中止或从传出队列中删除这些搜索结果，则服务器可能会发送任何挂起的SearchResultEntry或SearchResultReference PDU。服务器应尽可能少地发送这些剩余消息。最后，服务器发送消息SearchResultDone，并附加Sync Done控件。如果搜索成功，则必须取消SearchResultOne消息的resultCode字段[RFC3909]，并且必须在同步完成控件中设置cookie。如果出现错误情况，服务器可以按照上述第4.4.1节中的说明返回，或者按照[RFC3909]中的说明返回。
If the client is not interested in the state information, it can simply abandon the search operation or disconnect from the server.
如果客户端对状态信息不感兴趣，它可以简单地放弃搜索操作或断开与服务器的连接。
The server SHALL support size and time limits as specified in [RFC2251, Section 5]. The server SHOULD ensure that if the operation is terminated due to these conditions, the cookie is sent back to the client.
服务器应支持[RFC2251，第5节]中规定的大小和时间限制。服务器应确保，如果操作因这些条件而终止，cookie将被发送回客户端。
It is permissible for the client to issue other LDAP operations on the connection used by the protocol. Since each LDAP request/response carries a message id there will be no ambiguity about which PDU belongs to which operation. By sharing the connection among multiple operations, the server will be able to conserve its resources.
允许客户端对协议使用的连接执行其他LDAP操作。由于每个LDAP请求/响应都带有一个消息id，因此对于哪个PDU属于哪个操作不会有歧义。通过在多个操作之间共享连接，服务器将能够节省其资源。
LCUP defines neither restrictions nor guarantees about the ability to use the controls defined in this document in conjunction with other LDAP controls, except for the following: A server MAY ignore non-critical controls supplied with the LCUP control. A server MAY
LCUP既不限制也不保证将本文档中定义的控件与其他LDAP控件结合使用的能力，但以下情况除外：服务器可能会忽略随LCUP控件提供的非关键控件。服务器可以
ignore an LCUP defined control if it is non-critical and it is supplied with other critical controls. If a server receives a critical LCUP control with another critical control, and the server does not support both controls at the same time, the server SHOULD return unavailableCriticalExtension.
如果LCUP定义的控件是非关键控件，并且与其他关键控件一起提供，则忽略该控件。如果服务器接收到带有另一个关键控件的关键LCUP控件，并且服务器不同时支持这两个控件，则服务器应返回unavailableCriticalExtension。
It is up to the server implementation to determine if the server supports controls such as the Sort or VLV or similar controls that change the order of the entries sent to the client. But note that it may be difficult or impossible for a server to perform an incremental synchronization in the presence of such controls, since the cookie will typically be based off a change number, or Change Sequence Number (CSN), or timestamp, or some criteria other than an alphabetical order.
由服务器实现来确定服务器是否支持诸如Sort或VLV之类的控件或更改发送到客户端的条目顺序的类似控件。但请注意，服务器在存在此类控件的情况下执行增量同步可能很困难或不可能，因为cookie通常基于更改编号、更改序列号（CSN）、时间戳或除字母顺序以外的一些标准。
Use of an LCUP cookie with multiple DSAs in a replicated environment is not defined by LCUP. An implementation of LCUP may support continuation of an LCUP session with another DSA holding a replica of the LCUP context. Clients MAY submit cookies returned by one DSA to a different DSA; it is up to the server to determine if a cookie is one they recognize or not and to return an appropriate result code if not.
LCUP未定义在复制环境中对多个DSA使用LCUP cookie。LCUP的实现可以支持LCUP会话的继续，而另一个DSA持有LCUP上下文的副本。客户端可以将一个DSA返回的Cookie提交给另一个DSA；由服务器确定cookie是否是他们识别的cookie，如果不是，则返回相应的结果代码。
The cookie received from the server after a synchronization session SHOULD only be used with the same search specification as the search that generated the cookie. Some servers MAY allow the cookie to be used with a more restrictive search specification than the search that generated the cookie. If the server does not support the cookie, it MUST return lcupInvalidCookie. This is because the client can end up with an incomplete data store otherwise. A more restrictive search specification is one that would generate a subset of the data produced by the original search specification.
同步会话后从服务器接收的cookie只能与生成cookie的搜索使用相同的搜索规范。某些服务器可能允许cookie与比生成cookie的搜索更严格的搜索规范一起使用。如果服务器不支持cookie，则必须返回lcupInvalidCookie。这是因为客户机最终可能会出现不完整的数据存储。更严格的搜索规范将生成原始搜索规范生成的数据子集。
Because an LCUP client specifies the area of the tree with which it wishes to synchronize through the standard LDAP search specification, the client can be returned noSuchObject error if the root of the synchronization area was renamed between the synchronization sessions or during a synchronization session. If this condition occurs, the client can attempt to locate the root by using the root's UUID saved in client's local data store. It then can repeat the synchronization
由于LCUP客户端指定了它希望通过标准LDAP搜索规范与之同步的树的区域，因此，如果在同步会话之间或同步会话期间重命名了同步区域的根，则可以不返回任何对象错误。如果出现这种情况，客户端可以尝试使用保存在客户端本地数据存储中的根的UUID来定位根。然后它可以重复同步
request using the new search base. In general, a client can detect that an entry was renamed and apply the changes received to the right entry by using the UUID rather than DN based addressing.
使用新的搜索库请求。通常，客户端可以检测到条目被重命名，并通过使用UUID而不是基于DN的寻址将收到的更改应用到正确的条目。
Each active persistent operation requires that an open TCP connection be maintained between an LDAP client and an LDAP server that might not otherwise be kept open. Therefore, client implementors are encouraged to avoid using persistent operations for non-essential tasks and to close idle LDAP connections as soon as practical. The server may close connections if server resources become tight.
每个活动的持久性操作都需要在LDAP客户端和LDAP服务器之间保持一个开放的TCP连接，否则该连接可能不会保持打开状态。因此，鼓励客户机实现人员避免对非必要任务使用持久性操作，并尽快关闭空闲的LDAP连接。如果服务器资源紧张，服务器可能会关闭连接。
The client MAY receive a continuation reference (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search request spans multiple parts of the DIT, some of which may require a different LCUP cookie, some of which may not even be managed by LCUP. The client SHOULD maintain a cache of the LDAP URLs returned in the continuation references and the cookies associated with them. The client is responsible for performing another LCUP search to follow the references, and SHOULD use the cookie corresponding to the LDAP URL for that reference (if it has a cookie).
如果搜索请求跨越DIT的多个部分，客户端可能会收到一个延续引用（SearchResultReference[RFC2251第4.5.3节]），其中一些可能需要不同的LCUP cookie，其中一些甚至可能不由LCUP管理。客户机应该维护延续引用中返回的LDAP URL以及与之相关联的cookie的缓存。客户机负责执行另一个LCUP搜索以跟踪引用，并且应该为该引用使用与LDAP URL对应的cookie（如果它有cookie）。
The client may receive a referral (Referral [RFC2251 SECTION 4.1.11]) when the search base is a subordinate reference, and this will end the operation.
当搜索库为下级参考时，客户可能会收到参考（参考[RFC2251第4.1.11节]），这将结束操作。
The server MAY send the same entry multiple times during a sync phase if the entry changes during the sync phase. The client SHOULD use the last sent copy of the entry as the current one.
如果条目在同步阶段发生更改，服务器可能会在同步阶段多次发送相同的条目。客户端应使用最后发送的条目副本作为当前副本。
If the client receives an lcupResourcesExhausted or lcupSecurityViolation resultCode, the client SHOULD wait at least 5 seconds before attempting another operation. It is RECOMMENDED that the client use an exponential backoff strategy, but different clients may want to use different backoff strategies.
如果客户端收到LCUPResourcesExhousted或lcupSecurityViolation结果代码，则客户端应至少等待5秒钟，然后再尝试另一个操作。建议客户使用指数退避策略，但不同的客户可能希望使用不同的退避策略。
Servers MUST support UUIDs. UUIDs are required in the Sync Update control. Additionally, server implementers SHOULD make the UUID values for the entries available as an attribute of the entry, and provide indexing or other mechanisms to allow clients to search for an entry using the UUID attribute in the search filter. The syncUpdate control provides a field UUIDAttribute to allow the server to let the client know the name or OID of the attribute to use to search for an entry by UUID.
服务器必须支持UUID。同步更新控件中需要UUID。此外，服务器实现者应将条目的UUID值作为条目的属性提供，并提供索引或其他机制，以允许客户端使用搜索过滤器中的UUID属性搜索条目。syncUpdate控件提供一个字段UUIDAttribute，以允许服务器让客户端知道要用于按UUID搜索条目的属性的名称或OID。
By design, the protocol supports multiple cookie schemes. This is to allow different implementations the flexibility of storing any information applicable to their environment. A reasonable implementation for an LDUP compliant server would be to use the Replica Update Vector (RUV). For each master, RUV contains the largest CSN seen from this master. In addition, RUV implemented by some directory servers (not yet in LDUP) contains replica generation - an opaque string that identifies the replica's data store. The replica generation value changes whenever the replica's data is reloaded. Replica generation is intended to signal the replication/synchronization peers that the replica's data was reloaded and that all other replicas need to be reinitialized. RUV satisfies the three most important properties of the cookie: (1) it uniquely identifies the state of client's data, (2) it can be used to synchronize with multiple servers, and (3) it can be used to detect that the server's data was reloaded. If RUV is used as the cookie, entries last modified by a particular master must be sent to the client in the order of their last modified CSN. This ordering guarantees that the RUV can be updated after each entry is sent.
根据设计，该协议支持多种cookie方案。这是为了允许不同的实现灵活地存储适用于其环境的任何信息。LDUP兼容服务器的合理实现是使用副本更新向量（RUV）。对于每个主机，RUV包含从该主机看到的最大CSN。此外，一些目录服务器（尚未在LDUP中）实现的RUV包含副本生成—一个标识副本数据存储的不透明字符串。只要重新加载复制副本的数据，复制副本生成值就会更改。复制副本生成旨在向复制/同步对等方发出信号，表明复制副本的数据已重新加载，所有其他复制副本都需要重新初始化。RUV满足cookie的三个最重要的属性：（1）它唯一地标识客户端数据的状态；（2）它可用于与多个服务器同步；（3）它可用于检测服务器的数据是否被重新加载。如果使用RUV作为cookie，则必须按照上次修改的CSN的顺序将特定主机上次修改的条目发送给客户端。此排序保证在发送每个条目后可以更新RUV。
A server may support one or more LCUP cookie schemes. It is expected that schemes will be published along with their OIDs as RFCs. The server's DIT may be partitioned into different sections which may have different cookies associated with them. For example, some servers may use some sort of replication mechanism to support LCUP. If so, the DIT may be partitioned into multiple replicas. A client may send an LCUP search request that spans multiple replicas. Some parts of the DIT spanned by the search request scope may support LCUP and some may not. The server MUST send a SearchResultReference
服务器可能支持一个或多个LCUP cookie方案。预计方案将与其OID一起发布为RFC。服务器的DIT可能被划分为不同的部分，这些部分可能有不同的cookie与之关联。例如，某些服务器可能使用某种复制机制来支持LCUP。如果是这样，可以将DIT划分为多个副本。客户端可以发送跨越多个副本的LCUP搜索请求。搜索请求范围跨越的DIT的某些部分可能支持LCUP，而有些部分可能不支持。服务器必须发送SearchResultReference
[RFC2251, SECTION 4.5.3] when the LCUP Context for a returned entry changes. The server SHOULD send all references to other LCUP Contexts in the search scope first, in order to allow the clients to process these searches in parallel. The LDAP URL(s) returned MUST contain the DN(s) of the base of another section of the DIT (however the server implementation has partitioned the DIT). The client will then issue another LCUP search using the LDAP URL returned. Each section of the DIT MAY require a different cookie value, so the client SHOULD maintain a cache, mapping the different LDAP URL values to different cookies. If the cookie changes, the scheme may change as well, but the cookie scheme MUST be the same within a given LCUP Context.
[RFC2251，第4.5.3节]当返回条目的LCUP上下文更改时。服务器应首先发送对搜索范围内其他LCUP上下文的所有引用，以便允许客户端并行处理这些搜索。返回的LDAP URL必须包含DIT另一部分的基础DN（但是服务器实现已对DIT进行分区）。然后，客户端将使用返回的LDAP URL发出另一个LCUP搜索。DIT的每个部分可能需要不同的cookie值，因此客户端应该维护一个缓存，将不同的LDAP URL值映射到不同的cookie。如果cookie更改，则方案也可能更改，但在给定的LCUP上下文中，cookie方案必须相同。
The cookie must contain enough information to allow the server to determine whether the cookie can be safely used with the search specification it is attached to. As discussed earlier in the document, the cookie SHOULD only be used with the search specification that is equal to the one for which the cookie was generated, but some servers MAY support using a cookie with a search specification that is more restrictive than the one used to generate the cookie.
cookie必须包含足够的信息，以允许服务器确定cookie是否可以与它所附加的搜索规范一起安全使用。如本文档前面所讨论的，cookie应仅用于与生成cookie的搜索规范相同的搜索规范，但某些服务器可能支持使用具有比用于生成cookie的搜索规范更严格的搜索规范的cookie。
The specification makes no guarantees about how soon a server should send notification of a changed entry to the client during the persist phase. This is intentional as any specific maximum delay would be impossible to meet in a distributed directory service implementation. Server implementers are encouraged to minimize the delay before sending notifications to ensure that clients' needs for timeliness of change notification are met.
该规范不保证服务器在持久化阶段向客户机发送更改条目通知的速度。这是有意为之的，因为在分布式目录服务实现中不可能满足任何特定的最大延迟。我们鼓励服务器实现者在发送通知之前尽量减少延迟，以确保满足客户对更改通知及时性的需求。
Implementers of servers that support the mechanism described in this document should ensure that their implementation scales well as the number of active persistent operations and the number of changes made in the directory increases. Server implementers are also encouraged to support a large number of client connections if they need to support large numbers of persistent operations.
支持本文档中所述机制的服务器的实现者应确保其实现可以扩展，并且活动持久性操作的数量和目录中所做更改的数量也会增加。如果服务器实现者需要支持大量的持久性操作，还鼓励他们支持大量的客户端连接。
LCUP design does not consider issues associated with alias dereferencing in search. Clients MUST specify derefAliases as either neverDerefAliases or derefFindingBaseObj. Servers are to return protocolError if the client specifies either derefInSearching or derefAlways.
LCUP设计不考虑与搜索中别名撤销相关的问题。客户端必须将DerefAlias指定为NeverDerefAlias或derefFindingBaseObj。如果客户端指定derefInSearching或derefAlways，服务器将返回protocolError。
Clients, like a meta directory join engine, synchronizing multiple writable data stores, will only work correctly if each piece of information comes from a single authoritative data source. In a replicated environment, an LCUP Context should employ the same conflict resolution scheme across all its replicas. This is because different systems have different notions of time and different update resolution procedures. As a result, a change applied on one system can be discarded by the other, thus preventing the data stores from converging.
与元目录连接引擎一样，同步多个可写数据存储的客户端只有在每条信息来自单个权威数据源时才能正常工作。在复制环境中，LCUP上下文应在其所有副本中采用相同的冲突解决方案。这是因为不同的系统具有不同的时间概念和不同的更新解析过程。因此，应用于一个系统的更改可能会被另一个系统丢弃，从而防止数据存储聚合。
This document lists several values that have been registered by the IANA. The following LDAP result codes have been assigned by IANA as described in section 3.6 of [RFC3383]:
本文档列出了IANA已注册的几个值。IANA按照[RFC3383]第3.6节所述分配了以下LDAP结果代码：
lcupResourcesExhausted 113 lcupSecurityViolation 114 lcupInvalidData 115 lcupUnsupportedScheme 116 lcupReloadRequired 117
LCUPRESOURCES列出113个lcupSecurityViolation 114个lcupInvalidData 115个LCUPUnsupported方案116个lcupReloadRequired 117
The three controls defined in this document have been registered as LDAP Protocol Mechanisms as described in section 3.2 of [RFC3383]. One OID, 1.3.6.1.1.7, has been assigned by IANA as described in section 3.1 of [RFC3383]. The OIDs for the controls defined in this document are derived as follows from the one assigned by IANA:
本文件中定义的三个控件已注册为LDAP协议机制，如[RFC3383]第3.2节所述。一个OID，1.3.6.1.1.7，已由IANA分配，如[RFC3383]第3.1节所述。本文件中定义的控制的OID由IANA分配的OID派生如下：
LCUP Sync Request Control 1.3.6.1.1.7.1 LCUP Sync Update Control 1.3.6.1.1.7.2 LCUP Sync Done Control 1.3.6.1.1.7.3
LCUP同步请求控制1.3.6.1.1.7.1 LCUP同步更新控制1.3.6.1.1.7.2 LCUP同步完成控制1.3.6.1.1.7.3
In some situations, it may be important to prevent general exposure of information about changes that occur in an LDAP server. Therefore, servers that implement the mechanism described in this document SHOULD provide a means to enforce access control on the entries
在某些情况下，防止LDAP服务器中发生的更改信息的一般公开可能很重要。因此，实现本文档中描述的机制的服务器应该提供一种对条目实施访问控制的方法
returned and MAY also provide specific access control mechanisms to control the use of the controls and extended operations defined in this document.
返回并可能提供特定的访问控制机制，以控制本文档中定义的控件和扩展操作的使用。
As with normal LDAP search requests, a malicious client can initiate a large number of persistent search requests in an attempt to consume all available server resources and deny service to legitimate clients. The protocol provides the means to stop malicious clients by disconnecting them from the server. The servers that implement the mechanism SHOULD provide the means to detect the malicious clients. In addition, the servers SHOULD provide the means to limit the number of resources that can be consumed by a single client.
与普通LDAP搜索请求一样，恶意客户端可以启动大量持久性搜索请求，试图消耗所有可用的服务器资源并拒绝向合法客户端提供服务。该协议提供了通过断开恶意客户端与服务器的连接来阻止它们的方法。实现该机制的服务器应提供检测恶意客户端的方法。此外，服务器应提供限制单个客户端可以使用的资源数量的方法。
[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月。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]Wahl，M.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3383]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 3383，2002年9月。
[RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Cancel Operation", RFC 3909, October 2004.
[RFC3909]Zeilenga，K.，“轻型目录访问协议（LDAP）取消操作”，RFC 3909，2004年10月。
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680, 1994.
[X.680]ITU-T，“抽象语法符号一（ASN.1）-基本符号规范”，X.680，1994年。
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", X.690, 1994.
[X.690]ITU-T，“ASN.1编码规则规范：基本、规范和区分编码规则”，X.690，1994年。
[UUID] International Organization for Standardization (ISO), "Information technology - Open Systems Interconnection - Remote Procedure Call", ISO/IEC 11578:1996.
[UUID]国际标准化组织（ISO），“信息技术-开放系统互连-远程过程调用”，ISO/IEC 11578:1996。
[RFC3384] Stokes, E., Weiser, R., Moats, R., and R. Huber, "Lightweight Directory Access Protocol (version 3) Replication Requirements", RFC 3384, October 2002.
[RFC3384]Stokes，E.，Weiser，R.，Moats，R.，和R.Huber，“轻型目录访问协议（版本3）复制要求”，RFC 3384，2002年10月。
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003.
[RFC3671]Zeilenga，K.，“轻量级目录访问协议（LDAP）中的集合属性”，RFC 3671，2003年12月。
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3672]Zeilenga，K.和S.Legg，“轻量级目录访问协议（LDAP）中的子项”，RFC 3672，2003年12月。
The LCUP protocol is based in part on the Persistent Search Change Notification Mechanism defined by Mark Smith, Gordon Good, Tim Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined by Mark Wahl, and the LDAP Control for Directory Synchronization defined by Michael Armijo. The members of the IETF LDUP working group made significant contributions to this document.
LCUP协议部分基于Mark Smith、Gordon Good、Tim Howes和Rob Weltman定义的持久搜索更改通知机制、Mark Wahl定义的LDAPv3触发搜索控件以及Michael Armijo定义的目录同步LDAP控件。IETF LDUP工作组的成员对本文件做出了重大贡献。
Appendix - Features Left Out of LCUP
附录-LCUP中遗漏的功能
There are several features present in other protocols or considered useful by clients that are currently not included in the protocol primarily because they are difficult to implement on the server. These features are briefly discussed in this section.
其他协议中存在一些功能，或者客户端认为这些功能很有用，但这些功能目前未包含在协议中，主要是因为它们难以在服务器上实现。本节将简要讨论这些功能。
Triggered Search Change Type
触发搜索更改类型
This feature is present in the Triggered Search specification. A flag is attached to each entry returned to the client indicating the reason why this entry is returned. The possible reasons from the document are:
触发搜索规范中存在此功能。每个返回到客户端的条目都会附加一个标志，指示返回该条目的原因。文件中可能的原因如下：
- notChange: the entry existed in the directory and matched the search at the time the operation is being performed,
- notChange：目录中存在的条目，并且在执行操作时与搜索匹配，
- enteredSet: the entry entered the result,
- enteredSet：输入结果的条目，
- leftSet: the entry left the result,
- leftSet：该条目留下了结果，
- modified: the entry was part of the result set, was modified or renamed, and still is in the result set.
- 已修改：该条目是结果集的一部分，已修改或重命名，并且仍在结果集中。
The leftSet feature is particularly useful because it indicates to the client that an entry is no longer within the client's search specification and the client can remove the associated data from its data store. Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. A compromise could be reached by only providing this feature for the operations that occur while the client is connected to the server. This is easier to accomplish because the decision about the change type can be made based only on the change without need for any historical information. This, however, would add complexity to the protocol.
leftSet特性特别有用，因为它向客户端指示某个条目不再在客户端的搜索规范中，并且客户端可以从其数据存储中删除关联的数据。具有讽刺意味的是，此功能最难在服务器上实现，因为服务器无法跟踪客户端的状态，并且无法轻松地判断哪些条目在与客户端的同步会话之间移出了范围。只有为客户端连接到服务器时发生的操作提供此功能，才能达到折衷的效果。这更容易实现，因为关于更改类型的决策可以仅基于更改而不需要任何历史信息。然而，这将增加协议的复杂性。
Persistent Search Change Type
持久搜索更改类型
This feature is present in the Persistent Search specification. Persistent search has the notion of changeTypes. The client specifies which type of updates will cause entries to be returned, and optionally whether the server tags each returned entry with the type of change that caused that entry to be returned.
持久性搜索规范中提供了此功能。持久搜索具有changeTypes的概念。客户机指定将导致返回条目的更新类型，以及服务器是否使用导致返回该条目的更改类型标记每个返回的条目（可选）。
For LCUP, the intention is full synchronization, not partial. Each entry returned by an LCUP search will have some change associated with it that may concern the client. The client may have to have a
对于LCUP，目的是完全同步，而不是部分同步。LCUP搜索返回的每个条目都会有一些与之相关的更改，这些更改可能与客户端有关。客户可能需要有一个
local index of entries by DN or UUID to determine if the entry has been added or just modified. It is easy for clients to determine if the entry has been deleted because the entryLeftSet value of the Sync Update control will be TRUE.
按DN或UUID对条目进行本地索引，以确定条目是否已添加或刚刚修改。客户端很容易确定条目是否已被删除，因为Sync Update控件的entryLeftSet值将为TRUE。
Sending Changes
发送更改
Some earlier synchronization protocols sent the client(s) only the modified attributes of the entry rather than the entire entry. While this approach can significantly reduce the amount of data returned to the client, it has several disadvantages. First, unless a separate mechanism (like the change type described above) is used to notify the client about entries moving into the search scope, sending only the changes can result in the client having an incomplete version of the data. Let's consider an example. An attribute of an entry is modified. As a result of the change, the entry enters the scope of the client's search. If only the changes are sent, the client would never see the initial data of the entry. Second, this feature is hard to implement since the server might not contain sufficient information to construct the changes based solely on the server's state and the client's cookie. On the other hand, this feature can be easily implemented by the client assuming that the client has the previous version of the data and can perform value by value comparisons.
一些早期的同步协议只向客户端发送条目的修改属性，而不是整个条目。虽然这种方法可以显著减少返回给客户机的数据量，但它有几个缺点。首先，除非使用单独的机制（如上文所述的更改类型）通知客户机条目进入搜索范围，否则仅发送更改可能会导致客户机的数据版本不完整。让我们考虑一个例子。条目的属性被修改。作为更改的结果，条目将进入客户机的搜索范围。如果只发送更改，客户端将永远看不到条目的初始数据。其次，此功能很难实现，因为服务器可能不包含足够的信息来构建仅基于服务器状态和客户端cookie的更改。另一方面，如果客户机具有以前版本的数据，并且可以执行逐值比较，则客户机可以轻松实现此功能。
Data Size Limits
数据大小限制
Some earlier synchronization protocols allowed clients to control the amount of data sent to them in the search response. This feature was intended to allow clients with limited resources to process synchronization data in batches. However, an LDAP search operation already provides the means for the client to specify the size limit by setting the sizeLimit field in the SearchRequest to the maximum number of entries the client is willing to receive. While the granularity is not the same, the assumption is that regular LDAP clients that can deal with the limitations of the LDAP protocol will implement LCUP.
一些早期的同步协议允许客户端控制在搜索响应中发送给它们的数据量。此功能旨在允许资源有限的客户端批量处理同步数据。但是，LDAP搜索操作已经为客户端提供了指定大小限制的方法，方法是将SearchRequest中的sizeLimit字段设置为客户端愿意接收的最大条目数。虽然粒度不同，但假设能够处理LDAP协议限制的常规LDAP客户端将实现LCUP。
Data Ordering
数据排序
Some earlier synchronization protocols allowed a client to specify that parent entries should be sent before the children for add operations and children entries sent before their parents during delete operations. This ordering helps clients to maintain a hierarchical view of the data in their data store. While possibly useful, this feature is relatively hard to implement and is expensive to perform.
一些早期的同步协议允许客户端指定在添加操作中应在子项之前发送父项，在删除操作中应在其父项之前发送子项。这种排序有助于客户机维护其数据存储中数据的分层视图。虽然可能有用，但此功能相对难以实现，而且执行成本较高。
Authors' Addresses
作者地址
Rich Megginson Netscape Communications Corp., an America Online company. 360 W. Caribbean Drive Sunnyvale, CA 94089 USA
Rich Megginson Netscape Communications Corp.，一家美国在线公司。美国加利福尼亚州桑尼维尔加勒比海大道西360号，邮编94089
Phone: +1 505 797-7762
EMail: rmegginson0224@aol.com
Phone: +1 505 797-7762
EMail: rmegginson0224@aol.com
Olga Natkovich Yahoo, Inc. 701 First Ave. Sunnyvale, CA 94089 USA
Olga Natkovich Yahoo，Inc.美国加利福尼亚州桑尼维尔第一大道701号，邮编94089
Phone: +1 408 349-6153
EMail: olgan@yahoo-inc.com
Phone: +1 408 349-6153
EMail: olgan@yahoo-inc.com
Mark Smith Pearl Crescent, LLC 447 Marlpool Drive Saline, MI 48176 USA
马克·史密斯珍珠新月有限责任公司，美国密歇根州马尔普尔大道447号，邮编：48176
Phone: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Phone: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Jeff Parham Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
Jeff Parham Microsoft Corporation One Microsoft Way Redmond，WA 98052-6399美国
Phone: +1 425 882-8080
EMail: jeffparh@microsoft.com
Phone: +1 425 882-8080
EMail: jeffparh@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。