Network Working Group K. Zeilenga
Request for Comments: 4533 OpenLDAP Foundation
Category: Experimental J.H. Choi
IBM Corporation
June 2006
Network Working Group K. Zeilenga
Request for Comments: 4533 OpenLDAP Foundation
Category: Experimental J.H. Choi
IBM Corporation
June 2006
The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation
轻型目录访问协议（LDAP）内容同步操作
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
IESG Note
IESG注释
The IESG notes that this work was originally discussed in the LDUP working group. The group came to consensus on a different approach, documented in RFC 3928; that document is on the standards track and should be reviewed by those considering implementation of this proposal.
IESG指出，这项工作最初是在LDUP工作组中讨论的。小组就RFC 3928中记录的不同方法达成共识；该文件正在标准化轨道上，应由考虑实施该提案的各方进行审查。
Abstract
摘要
This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation.
本规范描述了轻型目录访问协议（LDAP）内容同步操作。该操作允许客户端维护目录信息树（DIT）片段的副本。它支持轮询更改和侦听更改。该操作被定义为LDAP搜索操作的扩展。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Intended Usage .............................................4
1.3. Overview ...................................................5
1.4. Conventions ................................................8
2. Elements of the Sync Operation ..................................8
2.1. Common ASN.1 Elements ......................................9
2.2. Sync Request Control .......................................9
2.3. Sync State Control ........................................10
2.4. Sync Done Control .........................................10
2.5. Sync Info Message .........................................11
2.6. Sync Result Codes .........................................11
3. Content Synchronization ........................................11
3.1. Synchronization Session ...................................12
3.2. Content Determination .....................................12
3.3. refreshOnly Mode ..........................................13
3.4. refreshAndPersist Mode ....................................16
3.5. Search Request Parameters .................................17
3.6. objectName ................................................18
3.7. Canceling the Sync Operation ..............................19
3.8. Refresh Required ..........................................19
3.9. Chattiness Considerations .................................20
3.10. Operation Multiplexing ...................................21
4. Meta Information Considerations ................................22
4.1. Entry DN ..................................................22
4.2. Operational Attributes ....................................22
4.3. Collective Attributes .....................................23
4.4. Access and Other Administrative Controls ..................23
5. Interaction with Other Controls ................................23
5.1. ManageDsaIT Control .......................................24
5.2. Subentries Control ........................................24
6. Shadowing Considerations .......................................24
7. Security Considerations ........................................25
8. IANA Considerations ............................................26
8.1. Object Identifier .........................................26
8.2. LDAP Protocol Mechanism ...................................26
8.3. LDAP Result Codes .........................................26
9. Acknowledgements ...............................................26
10. Normative References ..........................................27
11. Informative References ........................................28
Appendix A. CSN-based Implementation Considerations ..............29
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Intended Usage .............................................4
1.3. Overview ...................................................5
1.4. Conventions ................................................8
2. Elements of the Sync Operation ..................................8
2.1. Common ASN.1 Elements ......................................9
2.2. Sync Request Control .......................................9
2.3. Sync State Control ........................................10
2.4. Sync Done Control .........................................10
2.5. Sync Info Message .........................................11
2.6. Sync Result Codes .........................................11
3. Content Synchronization ........................................11
3.1. Synchronization Session ...................................12
3.2. Content Determination .....................................12
3.3. refreshOnly Mode ..........................................13
3.4. refreshAndPersist Mode ....................................16
3.5. Search Request Parameters .................................17
3.6. objectName ................................................18
3.7. Canceling the Sync Operation ..............................19
3.8. Refresh Required ..........................................19
3.9. Chattiness Considerations .................................20
3.10. Operation Multiplexing ...................................21
4. Meta Information Considerations ................................22
4.1. Entry DN ..................................................22
4.2. Operational Attributes ....................................22
4.3. Collective Attributes .....................................23
4.4. Access and Other Administrative Controls ..................23
5. Interaction with Other Controls ................................23
5.1. ManageDsaIT Control .......................................24
5.2. Subentries Control ........................................24
6. Shadowing Considerations .......................................24
7. Security Considerations ........................................25
8. IANA Considerations ............................................26
8.1. Object Identifier .........................................26
8.2. LDAP Protocol Mechanism ...................................26
8.3. LDAP Result Codes .........................................26
9. Acknowledgements ...............................................26
10. Normative References ..........................................27
11. Informative References ........................................28
Appendix A. CSN-based Implementation Considerations ..............29
The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a mechanism, the search operation [RFC4511], that allows a client to request directory content matching a complex set of assertions and to request that the server return this content, subject to access control and other restrictions, to the client. However, LDAP does not provide (despite the introduction of numerous extensions in this area) an effective and efficient mechanism for maintaining synchronized copies of directory content. This document introduces a new mechanism specifically designed to meet the content synchronization requirements of sophisticated directory applications.
轻量级目录访问协议（LDAP）[RFC4510]提供了一种机制，即搜索操作[RFC4511]，该机制允许客户端请求与复杂断言集匹配的目录内容，并请求服务器根据访问控制和其他限制将此内容返回给客户端。然而，LDAP并没有提供（尽管在这个领域引入了许多扩展）一种有效和高效的机制来维护目录内容的同步副本。本文档介绍了一种新的机制，专门设计用于满足复杂目录应用程序的内容同步要求。
This document defines the LDAP Content Synchronization Operation, or Sync Operation for short, which allows a client to maintain a synchronized copy of a fragment of a Directory Information Tree (DIT). The Sync Operation is defined as a set of controls and other protocol elements that extend the Search Operation.
本文档定义了LDAP内容同步操作，简称同步操作，它允许客户端维护目录信息树（DIT）片段的同步副本。同步操作定义为一组扩展搜索操作的控件和其他协议元素。
Over the years, a number of content synchronization approaches have been suggested for use in LDAP directory services. These approaches are inadequate for one or more of the following reasons:
多年来，人们建议在LDAP目录服务中使用许多内容同步方法。由于以下一个或多个原因，这些方法不充分：
- failure to ensure a reasonable level of convergence;
- 未能确保合理的衔接水平；
- failure to detect that convergence cannot be achieved (without reload);
- 未能检测到无法实现收敛（不重新加载）；
- require pre-arranged synchronization agreements;
- 需要预先安排的同步协议；
- require the server to maintain histories of past changes to DIT content and/or meta information;
- 要求服务器维护DIT内容和/或元信息过去更改的历史记录；
- require the server to maintain synchronization state on a per-client basis; and/or
- 要求服务器在每个客户端的基础上保持同步状态；和/或
- are overly chatty.
- 你太健谈了。
The Sync Operation provides eventual convergence of synchronized content when possible and, when not, notification that a full reload is required.
同步操作在可能的情况下提供同步内容的最终会聚，如果不可能，则通知需要完全重新加载。
The Sync Operation does not require pre-arranged synchronization agreements.
同步操作不需要预先安排的同步协议。
The Sync Operation does not require that servers maintain or use any history of past changes to the DIT or to meta information. However, servers may maintain and use histories (e.g., change logs, tombstones, DIT snapshots) to reduce the number of messages generated and to reduce their size. As it is not always feasible to maintain and use histories, the operation may be implemented using purely (current) state-based approaches. The Sync Operation allows use of either the state-based approach or the history-based approach on an operation-by-operation basis to balance the size of history and the amount of traffic. The Sync Operation also allows the combined use of the state-based and the history-based approaches.
同步操作不要求服务器维护或使用过去对DIT或元信息所做更改的任何历史记录。但是，服务器可以维护和使用历史记录（例如，更改日志、逻辑删除、DIT快照），以减少生成的消息数量并减小其大小。由于维护和使用历史并不总是可行的，因此可以使用纯粹（当前）基于状态的方法来实现操作。同步操作允许在逐个操作的基础上使用基于状态的方法或基于历史的方法，以平衡历史大小和通信量。同步操作还允许结合使用基于状态和基于历史的方法。
The Sync Operation does not require that servers maintain synchronization state on a per-client basis. However, servers may maintain and use per-client state information to reduce the number of messages generated and the size of such messages.
同步操作不要求服务器在每个客户端的基础上保持同步状态。但是，服务器可以维护和使用每个客户端的状态信息，以减少生成的消息数量和此类消息的大小。
A synchronization mechanism can be considered overly chatty when synchronization traffic is not reasonably bounded. The Sync Operation traffic is bounded by the size of updated (or new) entries and the number of unchanged entries in the content. The operation is designed to avoid full content exchanges, even when the history information available to the server is insufficient to determine the client's state. The operation is also designed to avoid transmission of out-of-content history information, as its size is not bounded by the content and it is not always feasible to transmit such history information due to security reasons.
当同步通信量没有合理的界限时，可以认为同步机制过于健谈。同步操作流量受更新（或新）条目的大小和内容中未更改条目的数量的限制。该操作旨在避免完全内容交换，即使服务器可用的历史信息不足以确定客户端的状态。该操作还旨在避免传输内容外的历史信息，因为其大小不受内容限制，并且由于安全原因，传输此类历史信息并不总是可行的。
This document includes a number of non-normative appendices providing additional information to server implementors.
本文档包括许多非规范性附录，为服务器实现者提供了附加信息。
The Sync Operation is intended to be used in applications requiring eventually-convergent content synchronization. Upon completion of each synchronization stage of the operation, all information to construct a synchronized client copy of the content has been provided to the client or the client has been notified that a complete content reload is necessary. Except for transient inconsistencies due to concurrent operation (or other) processing at the server, the client copy is an accurate reflection of the content held by the server. Transient inconsistencies will be resolved by subsequent synchronization operations.
同步操作旨在用于需要最终聚合内容同步的应用程序中。在完成操作的每个同步阶段后，已向客户端提供用于构建内容的同步客户端副本的所有信息，或者已通知客户端需要完全重新加载内容。除了由于服务器上的并发操作（或其他）处理而导致的暂时不一致外，客户端副本是服务器所持有内容的准确反映。瞬态不一致将通过后续同步操作解决。
Possible uses include the following:
可能的用途包括：
- White page service applications may use the Sync Operation to maintain a current copy of a DIT fragment, for example, a mail user agent that uses the sync operation to maintain a local copy of an enterprise address book.
- 白页服务应用程序可以使用同步操作来维护DIT片段的当前副本，例如，使用同步操作来维护企业通讯簿本地副本的邮件用户代理。
- Meta-information engines may use the Sync Operation to maintain a copy of a DIT fragment.
- 元信息引擎可以使用同步操作来维护DIT片段的副本。
- Caching proxy services may use the Sync Operation to maintain a coherent content cache.
- 缓存代理服务可以使用同步操作来维护一致的内容缓存。
- Lightweight master-slave replication between heterogeneous directory servers. For example, the Sync Operation can be used by a slave server to maintain a shadow copy of a DIT fragment. (Note: The International Telephone Union (ITU) has defined the X.500 Directory [X.500] Information Shadowing Protocol (DISP) [X.525], which may be used for master-slave replication between directory servers. Other experimental LDAP replication protocols also exist.)
- 异构目录服务器之间的轻量级主从复制。例如，从服务器可以使用同步操作来维护DIT片段的卷影副本。（注：国际电话联盟（ITU）定义了X.500目录[X.500]信息隐藏协议（DISP）[X.525]，可用于目录服务器之间的主从复制。还存在其他实验性LDAP复制协议。）
This protocol is not intended to be used in applications requiring transactional data consistency.
此协议不适用于要求事务数据一致性的应用程序。
As this protocol transfers all visible values of entries belonging to the content upon change instead of change deltas, this protocol is not appropriate for bandwidth-challenged applications or deployments.
由于此协议在更改时传输属于内容的所有可见条目值，而不是更改增量，因此此协议不适用于带宽受限的应用程序或部署。
This section provides an overview of basic ways the Sync Operation can be used to maintain a synchronized client copy of a DIT fragment.
本节概述了使用同步操作维护DIT片段的同步客户端副本的基本方法。
- Polling for changes: refreshOnly mode
- 轮询更改：仅刷新模式
- Listening for changes: refreshAndPersist mode
- 侦听更改：刷新和持久化模式
To obtain its initial client copy, the client issues a Sync request: a search request with the Sync Request Control with mode set to refreshOnly. The server, much like it would with a normal search operation, returns (subject to access controls and other restrictions) the content matching the search criteria (baseObject, scope, filter, attributes). Additionally, with each entry returned, the server provides a Sync State Control indicating state add. This control contains the Universally Unique Identifier (UUID) [UUID] of
要获取其初始客户端副本，客户端将发出同步请求：同步请求控件的搜索请求，模式设置为refreshOnly。与正常搜索操作一样，服务器返回（受访问控制和其他限制）与搜索条件（baseObject、作用域、筛选器、属性）匹配的内容。此外，对于返回的每个条目，服务器提供一个指示State add的同步状态控件。此控件包含的通用唯一标识符（UUID）[UUID]
the entry [RFC4530]. Unlike the Distinguished Name (DN), which may change over time, an entry's UUID is stable. The initial content is followed by a SearchResultDone with a Sync Done Control. The Sync Done Control provides a syncCookie. The syncCookie represents session state.
条目[RFC4530]。与可分辨名称（DN）不同的是，条目的UUID是稳定的，可分辨名称（DN）可能会随时间而变化。初始内容后面是带有同步完成控件的SearchResultDone。Sync Done控件提供syncCookie。syncCookie表示会话状态。
To poll for updates to the client copy, the client reissues the Sync Operation with the syncCookie previously returned. The server, much as it would with a normal search operation, determines which content would be returned as if the operation were a normal search operation. However, using the syncCookie as an indicator of what content the client was sent previously, the server sends copies of entries that have changed with a Sync State Control indicating state add. For each changed entry, all (modified or unmodified) attributes belonging to the content are sent.
要轮询对客户端副本的更新，客户端将使用先前返回的syncCookie重新发出同步操作。与正常搜索操作一样，服务器确定将返回哪些内容，就像该操作是正常搜索操作一样。但是，使用syncCookie作为客户端以前发送的内容的指示符，服务器会发送已更改的条目的副本，其中Sync State控件指示State add。对于每个更改的条目，将发送属于内容的所有（已修改或未修改）属性。
The server may perform either or both of the two distinct synchronization phases that are distinguished by how to synchronize entries deleted from the content: the present and the delete phases. When the server uses a single phase for the refresh stage, each phase is marked as ended by a SearchResultDone with a Sync Done Control. A present phase is identified by a FALSE refreshDeletes value in the Sync Done Control. A delete phase is identified by a TRUE refreshDeletes value. The present phase may be followed by a delete phase. The two phases are delimited by a refreshPresent Sync Info Message having a FALSE refreshDone value. In the case that both the phases are used, the present phase is used to bring the client copy up to the state at which the subsequent delete phase can begin.
服务器可以执行两个不同的同步阶段中的一个或两个，这两个阶段的区别在于如何同步从内容中删除的条目：当前和删除阶段。当服务器在刷新阶段使用单个阶段时，每个阶段都会被一个带有Sync Done控件的SearchResultDone标记为结束。当前阶段由Sync Done控件中的FALSE refreshDeletes值标识。删除阶段由真值标识。当前阶段之后可能是删除阶段。这两个阶段由具有错误refreshDone值的refreshPresent同步信息消息分隔。在使用这两个阶段的情况下，当前阶段用于使客户端副本达到可以开始后续删除阶段的状态。
In the present phase, the server sends an empty entry (i.e., no attributes) with a Sync State Control indicating state present for each unchanged entry.
在当前阶段中，服务器发送一个空条目（即，无属性），其中一个同步状态控件指示每个未更改条目的状态。
The delete phase may be used when the server can reliably determine which entries in the prior client copy are no longer present in the content and the number of such entries is less than or equal to the number of unchanged entries. In the delete mode, the server sends an empty entry with a Sync State Control indicating state delete for each entry that is no longer in the content, instead of returning an empty entry with state present for each present entry.
当服务器能够可靠地确定先前客户端副本中的哪些条目不再存在于内容中并且这些条目的数量小于或等于未更改条目的数量时，可以使用删除阶段。在删除模式下，服务器发送一个空条目，其中包含一个Sync State控件，该控件指示内容中不再存在的每个条目的状态删除，而不是返回一个状态为present的空条目。
The server may send syncIdSet Sync Info Messages containing the set of UUIDs of either unchanged present entries or deleted entries, instead of sending multiple individual messages. If refreshDeletes of syncIdSet is set to FALSE, the UUIDs of unchanged present entries are contained in the syncUUIDs set; if refreshDeletes of syncIdSet is set to TRUE, the UUIDs of the entries no longer present in the content are contained in the syncUUIDs set. An optional cookie can
服务器可以发送包含未更改的当前条目或已删除条目的UUID集的syncIdSet Sync Info消息，而不是发送多条单独的消息。如果将refreshDeletes of syncIdSet设置为FALSE，则syncUUIDs集中包含未更改的当前条目的UUID；如果将refreshDeletes of syncIdSet设置为TRUE，则内容中不再存在的条目的UUID将包含在SyncUUID集中。一个可选的饼干罐
be included in the syncIdSet to represent the state of the content after synchronizing the presence or the absence of the entries contained in the syncUUIDs set.
将包含在SyncID集中，以表示同步syncUUIDs集中包含的条目的存在或不存在后的内容状态。
The synchronized copy of the DIT fragment is constructed by the client.
DIT片段的同步副本由客户端构造。
If refreshDeletes of syncDoneValue is FALSE, the new copy includes all changed entries returned by the reissued Sync Operation, as well as all unchanged entries identified as being present by the reissued Sync Operation, but whose content is provided by the previous Sync Operation. The unchanged entries not identified as being present are deleted from the client content. They had been either deleted, moved, or otherwise scoped-out from the content.
如果refreshDeletes of syncDoneValue为FALSE，则新副本将包括重新发布的同步操作返回的所有更改的条目，以及重新发布的同步操作标识为存在但其内容由以前的同步操作提供的所有未更改的条目。未标识为存在的未更改条目将从客户端内容中删除。它们要么被删除、移动，要么从内容中缩小范围。
If refreshDeletes of syncDoneValue is TRUE, the new copy includes all changed entries returned by the reissued Sync Operation, as well as all other entries of the previous copy except for those that are identified as having been deleted from the content.
如果refreshDeletes of syncDoneValue为TRUE，则新副本将包括重新发布的同步操作返回的所有更改条目，以及上一副本的所有其他条目，但标识为已从内容中删除的条目除外。
The client can, at some later time, re-poll for changes to this synchronized client copy.
客户端可以在稍后的某个时间重新轮询对此同步客户端副本的更改。
Polling for changes can be expensive in terms of server, client, and network resources. The refreshAndPersist mode allows for active updates of changed entries in the content.
就服务器、客户端和网络资源而言，轮询更改可能代价高昂。refreshAndPersist模式允许对内容中更改的条目进行活动更新。
By selecting the refreshAndPersist mode, the client requests that the server send updates of entries that are changed after the initial refresh content is determined. Instead of sending a SearchResultDone Message as in polling, the server sends a Sync Info Message to the client indicating that the refresh stage is complete and then enters the persist stage. After receipt of this Sync Info Message, the client will construct a synchronized copy as described in Section 1.3.1.
通过选择refreshAndPersist模式，客户端请求服务器发送在确定初始刷新内容后更改的条目的更新。服务器不会像轮询那样发送SearchResultOne消息，而是向客户端发送一条同步信息消息，指示刷新阶段已完成，然后进入持久化阶段。收到此同步信息消息后，客户端将按照第1.3.1节中的说明构建一个同步副本。
The server may then send change notifications as the result of the original Sync search request, which now remains persistent in the server. For entries to be added to the returned content, the server sends a SearchResultEntry (with attributes) with a Sync State Control indicating state add. For entries to be deleted from the content, the server sends a SearchResultEntry containing no attributes and a Sync State Control indicating state delete. For entries to be modified in the return content, the server sends a SearchResultEntry (with attributes) with a Sync State Control indicating state modify.
然后，服务器可以发送更改通知作为原始同步搜索请求的结果，该请求现在在服务器中保持不变。对于要添加到返回内容中的条目，服务器将发送一个SearchResultEntry（带有属性），其中的同步状态控件指示StateAdd。对于要从内容中删除的条目，服务器将发送一个不包含任何属性的SearchResulty和一个指示状态删除的同步状态控件。对于要在返回内容中修改的条目，服务器将发送一个SearchResultEntry（带有属性），其中的同步状态控件指示状态修改。
Upon modification of an entry, all (modified or unmodified) attributes belonging to the content are sent.
修改条目后，将发送属于内容的所有（修改或未修改的）属性。
Note that renaming an entry of the DIT may cause an add state change where the entry is renamed into the content, a delete state change where the entry is renamed out of the content, and a modify state change where the entry remains in the content. Also note that a modification of an entry of the DIT may cause an add, delete, or modify state change to the content.
请注意，重命名DIT条目可能会导致条目重命名为内容时的添加状态更改、条目从内容中重命名时的删除状态更改以及条目保留在内容中时的修改状态更改。还要注意，修改DIT条目可能会导致内容的添加、删除或修改状态更改。
Upon receipt of a change notification, the client updates its copy of the content.
收到更改通知后，客户机更新其内容副本。
If the server desires to update the syncCookie during the persist stage, it may include the syncCookie in any Sync State Control or Sync Info Message returned.
如果服务器希望在持久化阶段更新syncCookie，它可能会在返回的任何同步状态控件或同步信息消息中包含syncCookie。
The operation persists until canceled [RFC3909] by the client or terminated by the server. A Sync Done Control shall be attached to SearchResultDone Message to provide a new syncCookie.
该操作将一直持续，直到客户端取消[RFC3909]或服务器终止。同步完成控件应附加到SearchResultOne消息，以提供新的syncCookie。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
Protocol elements are described using ASN.1 [X.680] with implicit tags. 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 [RFC4511].
协议元素使用带有隐式标记的ASN.1[X.680]进行描述。术语“BER编码”是指根据[RFC4511]第5.1节详述的限制，使用基本编码规则[X.690]对元素进行编码。
The Sync Operation is defined as an extension to the LDAP Search Operation [RFC4511] where the directory user agent (DUA or client) submits a SearchRequest Message with a Sync Request Control and the directory system agent (DSA or server) responds with zero or more SearchResultEntry Messages, each with a Sync State Control; zero or more SearchResultReference Messages, each with a Sync State Control; zero or more Sync Info Intermediate Response Messages; and a SearchResultDone Message with a Sync Done Control.
同步操作被定义为LDAP搜索操作[RFC4511]的扩展，其中目录用户代理（DUA或客户端）提交带有同步请求控件的SearchRequest消息，目录系统代理（DSA或服务器）响应为零条或多条SearchResultEntry消息，每条消息都带有同步状态控件；零条或多条SearchResultReference消息，每条消息都带有同步状态控件；零个或多个同步信息中间响应消息；与searchTone控件同步的结果。
To allow clients to discover support for this operation, servers implementing this operation SHOULD publish 1.3.6.1.4.1.4203.1.9.1.1 as a value of the 'supportedControl' attribute [RFC4512] of the root DSA-specific entry (DSE). A server MAY choose to advertise this extension only when the client is authorized to use it.
要允许客户端发现对此操作的支持，执行此操作的服务器应将1.3.6.1.4.1.4203.1.9.1.1发布为根DSA特定项（DSE）的“supportedControl”属性[RFC4512]的值。只有当客户机被授权使用此扩展时，服务器才可以选择公布此扩展。
The syncUUID data type is an OCTET STRING holding a 128-bit (16-octet) Universally Unique Identifier (UUID) [UUID].
syncUUID数据类型是一个八位字符串，包含128位（16个八位）通用唯一标识符（UUID）[UUID]。
syncUUID ::= OCTET STRING (SIZE(16))
-- constrained to UUID
syncUUID ::= OCTET STRING (SIZE(16))
-- constrained to UUID
The syncCookie is a notational convenience to indicate that, while the syncCookie type is encoded as an OCTET STRING, its value is an opaque value containing information about the synchronization session and its state. Generally, the session information would include a hash of the operation parameters that the server requires not be changed and the synchronization state information would include a commit (log) sequence number, a change sequence number, or a time stamp. For convenience of description, the term "no cookie" refers either to a null cookie or to a cookie with pre-initialized synchronization state.
syncCookie是一种方便的符号，用于指示syncCookie类型编码为八位字节字符串时，其值是一个不透明的值，包含有关同步会话及其状态的信息。通常，会话信息将包括服务器不需要更改的操作参数的散列，并且同步状态信息将包括提交（日志）序列号、更改序列号或时间戳。为了便于描述，术语“无cookie”指的是空cookie或具有预初始化同步状态的cookie。
syncCookie ::= OCTET STRING
syncCookie ::= OCTET STRING
The Sync Request Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the controlValue, an OCTET STRING, contains a BER-encoded syncRequestValue. The criticality field is either TRUE or FALSE.
同步请求控件是LDAP控件[RFC4511]，其中controlType是对象标识符1.3.6.1.4.1.4203.1.9.1.1，controlValue是一个八位字符串，包含一个BER编码的syncRequestValue。临界值字段为真或假。
syncRequestValue ::= SEQUENCE {
mode ENUMERATED {
-- 0 unused
refreshOnly (1),
-- 2 reserved
refreshAndPersist (3)
},
cookie syncCookie OPTIONAL,
reloadHint BOOLEAN DEFAULT FALSE
}
syncRequestValue ::= SEQUENCE {
mode ENUMERATED {
-- 0 unused
refreshOnly (1),
-- 2 reserved
refreshAndPersist (3)
},
cookie syncCookie OPTIONAL,
reloadHint BOOLEAN DEFAULT FALSE
}
The Sync Request Control is only applicable to the SearchRequest Message.
同步请求控件仅适用于SearchRequest消息。
The Sync State Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the controlValue, an OCTET STRING, contains a BER-encoded syncStateValue. The criticality is FALSE.
同步状态控件是LDAP控件[RFC4511]，其中controlType是对象标识符1.3.6.1.4.1.4203.1.9.1.2，controlValue是一个八位字符串，包含一个BER编码的syncStateValue。关键性是错误的。
syncStateValue ::= SEQUENCE {
state ENUMERATED {
present (0),
add (1),
modify (2),
delete (3)
},
entryUUID syncUUID,
cookie syncCookie OPTIONAL
}
syncStateValue ::= SEQUENCE {
state ENUMERATED {
present (0),
add (1),
modify (2),
delete (3)
},
entryUUID syncUUID,
cookie syncCookie OPTIONAL
}
The Sync State Control is only applicable to SearchResultEntry and SearchResultReference Messages.
同步状态控件仅适用于SearchResultEntry和SearchResultReference消息。
The Sync Done Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the controlValue contains a BER-encoded syncDoneValue. The criticality is FALSE (and hence absent).
同步完成控件是LDAP控件[RFC4511]，其中controlType是对象标识符1.3.6.1.4.1.4203.1.9.1.3，controlValue包含BER编码的syncDoneValue。临界性是错误的（因此不存在）。
syncDoneValue ::= SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDeletes BOOLEAN DEFAULT FALSE
}
syncDoneValue ::= SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDeletes BOOLEAN DEFAULT FALSE
}
The Sync Done Control is only applicable to the SearchResultDone Message.
同步完成控件仅适用于SearchResultOne消息。
The Sync Info Message is an LDAP Intermediate Response Message [RFC4511] where responseName is the object identifier 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded syncInfoValue. The criticality is FALSE (and hence absent).
同步信息消息是LDAP中间响应消息[RFC4511]，其中responseName是对象标识符1.3.6.1.4.1.4203.1.9.1.4，responseValue包含BER编码的syncInfoValue。临界性是错误的（因此不存在）。
syncInfoValue ::= CHOICE {
newcookie [0] syncCookie,
refreshDelete [1] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
refreshPresent [2] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
syncIdSet [3] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDeletes BOOLEAN DEFAULT FALSE,
syncUUIDs SET OF syncUUID
}
}
syncInfoValue ::= CHOICE {
newcookie [0] syncCookie,
refreshDelete [1] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
refreshPresent [2] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
syncIdSet [3] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDeletes BOOLEAN DEFAULT FALSE,
syncUUIDs SET OF syncUUID
}
}
The following LDAP resultCode [RFC4511] is defined:
定义了以下LDAP结果代码[RFC4511]：
e-syncRefreshRequired (4096)
需要电子同步刷新（4096）
The Sync Operation is invoked when the client sends a SearchRequest Message with a Sync Request Control.
当客户端发送带有同步请求控件的SearchRequest消息时，将调用同步操作。
The absence of a cookie or an initialized synchronization state in a cookie indicates a request for initial content, while the presence of a cookie representing a state of a client copy indicates a request for a content update. Synchronization Sessions are discussed in Section 3.1. Content Determination is discussed in Section 3.2.
cookie中缺少cookie或初始化的同步状态表示请求初始内容，而存在表示客户端副本状态的cookie表示请求内容更新。第3.1节讨论了同步会话。第3.2节讨论了含量测定。
The mode is either refreshOnly or refreshAndPersist. The refreshOnly and refreshAndPersist modes are discussed in Sections 3.3 and 3.4, respectively. The refreshOnly mode consists only of a refresh stage, while the refreshAndPersist mode consists of a refresh stage and a subsequent persist stage.
模式为refreshOnly或refreshAndPersist。第3.3节和第3.4节分别讨论了refreshOnly和refreshAndPersist模式。refreshOnly模式仅包含刷新阶段，而refreshAndPersist模式包含刷新阶段和后续的持久化阶段。
A sequence of Sync Operations where the last cookie returned by the server for one operation is provided by the client in the next operation is said to belong to the same Synchronization Session.
一系列同步操作，其中服务器为一个操作返回的最后一个cookie由客户端在下一个操作中提供，被称为属于同一同步会话。
The client MUST specify the same content-controlling parameters (see Section 3.5) in each Search Request of the session. The client SHOULD also issue each Sync request of a session under the same authentication and authorization associations with equivalent integrity and protections. If the server does not recognize the request cookie or the request is made under different associations or non-equivalent protections, the server SHALL return the initial content as if no cookie had been provided or return an empty content with the e-syncRefreshRequired LDAP result code. The decision between the return of the initial content and the return of the empty content with the e-syncRefreshRequired result code MAY be based on reloadHint in the Sync Request Control from the client. If the server recognizes the request cookie as representing empty or initial synchronization state of the client copy, the server SHALL return the initial content.
客户端必须在会话的每个搜索请求中指定相同的内容控制参数（参见第3.5节）。客户端还应在具有同等完整性和保护的相同身份验证和授权关联下发出会话的每个同步请求。如果服务器无法识别请求cookie，或者请求是在不同的关联或非等效保护下发出的，则服务器应返回初始内容，就像没有提供cookie一样，或者返回带有所需LDAP结果代码的空内容。返回初始内容和返回带有e-syncRefreshRequired结果代码的空内容之间的决定可能基于来自客户端的同步请求控件中的重载提示。如果服务器识别出请求cookie表示客户端副本的空或初始同步状态，则服务器应返回初始内容。
A Synchronization Session may span multiple LDAP sessions between the client and the server. The client SHOULD issue each Sync request of a session to the same server. (Note: Shadowing considerations are discussed in Section 6.)
同步会话可能跨越客户端和服务器之间的多个LDAP会话。客户端应向同一服务器发出会话的每个同步请求。（注：阴影注意事项在第6节中讨论。）
The content to be provided is determined by parameters of the Search Request, as described in [RFC4511], and possibly other controls. The same content parameters SHOULD be used in each Sync request of a session. If different content is requested and the server is unwilling or unable to process the request, the server SHALL return the initial content as if no cookie had been provided or return an empty content with the e-syncRefreshRequired LDAP result code. The decision between the return of the initial content and the return of the empty content with the e-syncRefreshRequired result code MAY be based on reloadHint in the Sync Request Control from the client.
要提供的内容由[RFC4511]中描述的搜索请求的参数以及可能的其他控件确定。会话的每个同步请求中应使用相同的内容参数。如果请求了不同的内容，并且服务器不愿意或无法处理该请求，则服务器应返回初始内容，就像没有提供cookie一样，或者返回带有所需LDAP结果代码的空内容。返回初始内容和返回带有e-syncRefreshRequired结果代码的空内容之间的决定可能基于来自客户端的同步请求控件中的重载提示。
The content may not necessarily include all entries or references that would be returned by a normal search operation, nor, for those entries included, all attributes returned by a normal search. When the server is unwilling or unable to provide synchronization for any attribute for a set of entries, the server MUST treat all filter components matching against these attributes as Undefined and MUST NOT return these attributes in SearchResultEntry responses.
内容不一定包括正常搜索操作将返回的所有条目或引用，也不一定包括正常搜索返回的所有属性。当服务器不愿意或无法为一组条目的任何属性提供同步时，服务器必须将与这些属性匹配的所有筛选器组件视为未定义，并且不得在SearchResultEntry响应中返回这些属性。
Servers SHOULD support synchronization for all non-collective user-application attributes for all entries.
服务器应支持所有条目的所有非集合用户应用程序属性的同步。
The server may also return continuation references to other servers or to itself. The latter is allowed as the server may partition the entries it holds into separate synchronization contexts.
服务器还可以将继续引用返回到其他服务器或自身。后者是允许的，因为服务器可能会将其持有的条目划分到单独的同步上下文中。
The client may chase all or some of these continuations, each as a separate content synchronization session.
客户机可以追踪所有或部分这些延续，每个延续都作为单独的内容同步会话。
A Sync request with mode refreshOnly and with no cookie is a poll for initial content. A Sync request with mode refreshOnly and with a cookie representing a synchronization state is a poll for content update.
只有刷新模式且没有cookie的同步请求是对初始内容的轮询。仅具有刷新模式且具有表示同步状态的cookie的同步请求是内容更新轮询。
Upon receipt of the request, the server provides the initial content using a set of zero or more SearchResultEntry and SearchResultReference Messages followed by a SearchResultDone Message.
在收到请求后，服务器使用一组零或多个SearchResultEntry和SearchResultReference消息提供初始内容，然后是SearchResultOne消息。
Each SearchResultEntry Message SHALL include a Sync State Control of state add, an entryUUID containing the entry's UUID, and no cookie. Each SearchResultReference Message SHALL include a Sync State Control of state add, an entryUUID containing the UUID associated with the reference (normally the UUID of the associated named referral [RFC3296] object), and no cookie. The SearchResultDone Message SHALL include a Sync Done Control having refreshDeletes set to FALSE.
每个SearchResultEntry消息应包括状态添加的同步状态控件、包含条目的UUID的entryUUID以及无cookie。每个SearchResultReference消息应包括状态添加的同步状态控件、包含与引用关联的UUID的entryUUID（通常是关联的命名引用[RFC3296]对象的UUID）以及无cookie。SearchResultOne消息应包括一个同步完成控件，该控件的refreshDeletes设置为FALSE。
A resultCode value of success indicates that the operation successfully completed. Otherwise, the result code indicates the nature of the failure. The server may return e-syncRefreshRequired result code on the initial content poll if it is safe to do so when it is unable to perform the operation due to various reasons. reloadHint is set to FALSE in the SearchRequest Message requesting the initial content poll.
resultCode值success表示操作已成功完成。否则，结果代码将指示故障的性质。由于各种原因无法执行操作时，如果安全的话，服务器可以在初始内容轮询时返回e-syncRefreshRequired结果代码。在请求初始内容轮询的SearchRequest消息中，reloadHint设置为FALSE。
If the operation is successful, a cookie representing the synchronization state of the current client copy SHOULD be returned for use in subsequent Sync Operations.
如果操作成功，则应返回表示当前客户端副本的同步状态的cookie，以便在后续同步操作中使用。
Upon receipt of the request, the server provides the content refresh using a set of zero or more SearchResultEntry and
在收到请求后，服务器使用一组零或多个SearchResultEntry和
SearchResultReference Messages followed by a SearchResultDone Message.
SearchResultReference消息后跟SearchResultOne消息。
The server is REQUIRED to:
服务器需要：
a) provide the sequence of messages necessary for eventual convergence of the client's copy of the content to the server's copy,
a) 提供最终将客户端的内容副本聚合到服务器副本所需的消息序列，
b) treat the request as an initial content request (e.g., ignore the cookie or the synchronization state represented in the cookie),
b) 将请求视为初始内容请求（例如，忽略cookie或cookie中表示的同步状态），
c) indicate that the incremental convergence is not possible by returning e-syncRefreshRequired,
c) 通过返回e-syncRefreshRequired指示增量收敛是不可能的，
d) return a resultCode other than success or e-syncRefreshRequired.
d) 返回除success或e-syncRefreshRequired之外的resultCode。
A Sync Operation may consist of a single present phase, a single delete phase, or a present phase followed by a delete phase.
同步操作可能包括单个当前阶段、单个删除阶段或当前阶段后接删除阶段。
In each phase, for each entry or reference that has been added to the content or been changed since the previous Sync Operation indicated by the cookie, the server returns a SearchResultEntry or SearchResultReference Message, respectively, each with a Sync State Control consisting of state add, an entryUUID containing the UUID of the entry or reference, and no cookie. Each SearchResultEntry Message represents the current state of a changed entry. Each SearchResultReference Message represents the current state of a changed reference.
在每个阶段中，对于已添加到内容或自cookie指示的上一次同步操作以来已更改的每个条目或引用，服务器分别返回一条SearchResultEntry或SearchResultReference消息，每条消息都带有一个同步状态控件，该控件由State add，一个entryUUID，包含条目或引用的UUID，不包含cookie。每个SearchResultEntry消息表示已更改条目的当前状态。每个SearchResultReference消息表示已更改引用的当前状态。
In the present phase, for each entry that has not been changed since the previous Sync Operation, an empty SearchResultEntry is returned whose objectName reflects the entry's current DN, whose attributes field is empty, and whose Sync State Control consists of state present, an entryUUID containing the UUID of the entry, and no cookie. For each reference that has not been changed since the previous Sync Operation, an empty SearchResultReference containing an empty SEQUENCE OF LDAPURL is returned with a Sync State Control consisting of state present, an entryUUID containing the UUID of the entry, and no cookie. No messages are sent for entries or references that are no longer in the content.
在当前阶段，对于自上一次同步操作以来未更改的每个条目，将返回一个空的SearchResultEntry，其objectName反映条目的当前DN，其属性字段为空，其同步状态控件由State present、包含条目UUID的entryUUID和no cookie组成。对于自上次同步操作以来未更改的每个引用，将返回一个包含LDAPURL空序列的空SearchResultReference，其中包含一个同步状态控件，该控件由State present、一个包含条目的UUID的entryUUID和no cookie组成。对于内容中不再存在的条目或引用，不会发送任何消息。
Multiple empty entries with a Sync State Control of state present SHOULD be coalesced into one or more Sync Info Messages of syncIdSet value with refreshDeletes set to FALSE. syncUUIDs contain a set of UUIDs of the entries and references unchanged since the last Sync
同步状态控件为“状态存在”的多个空条目应合并为一个或多个syncIdSet值的同步信息消息，refreshDeletes设置为FALSE。syncuuid包含一组自上次同步以来未更改的条目和引用的uuid
Operation. syncUUIDs may be empty. The Sync Info Message of syncIdSet may contain a cookie to represent the state of the content after performing the synchronization of the entries in the set.
活动syncuuid可能为空。syncIdSet的Sync Info消息可能包含一个cookie，用于表示在执行集合中项目的同步后内容的状态。
In the delete phase, for each entry no longer in the content, the server returns a SearchResultEntry whose objectName reflects a past DN of the entry or is empty, whose attributes field is empty, and whose Sync State Control consists of state delete, an entryUUID containing the UUID of the deleted entry, and no cookie. For each reference no longer in the content, a SearchResultReference containing an empty SEQUENCE OF LDAPURL is returned with a Sync State Control consisting of state delete, an entryUUID containing the UUID of the deleted reference, and no cookie.
在删除阶段，对于内容中不再存在的每个条目，服务器返回一个SearchResulty，其objectName反映该条目过去的DN或为空，其attributes字段为空，其同步状态控件由State delete、包含已删除条目的UUID的entryUUID和no cookie组成。对于内容中不再存在的每个引用，将返回一个包含空LDAPURL序列的SearchResultReference，其中包含一个同步状态控件，该同步状态控件包含State delete、一个包含已删除引用的UUID的entryUUID，且不包含cookie。
Multiple empty entries with a Sync State Control of state delete SHOULD be coalesced into one or more Sync Info Messages of syncIdSet value with refreshDeletes set to TRUE. syncUUIDs contain a set of UUIDs of the entries and references that have been deleted from the content since the last Sync Operation. syncUUIDs may be empty. The Sync Info Message of syncIdSet may contain a cookie to represent the state of the content after performing the synchronization of the entries in the set.
多个同步状态控件为State delete的空条目应合并为一个或多个syncIdSet值的Sync Info消息，refreshDeletes设置为TRUE。SyncuUID包含自上次同步操作以来已从内容中删除的条目和引用的一组UUID。syncuuid可能为空。syncIdSet的Sync Info消息可能包含一个cookie，用于表示在执行集合中项目的同步后内容的状态。
When a present phase is followed by a delete phase, the two phases are delimited by a Sync Info Message containing syncInfoValue of refreshPresent, which may contain a cookie representing the state after completing the present phase. The refreshPresent contains refreshDone, which is always FALSE in the refreshOnly mode of Sync Operation because it is followed by a delete phase.
当当前阶段后接删除阶段时，两个阶段由包含refreshPresent的syncInfoValue的同步信息消息分隔，该消息可能包含表示完成当前阶段后状态的cookie。refreshPresent包含refreshDone，它在同步操作的refreshOnly模式中始终为FALSE，因为它后面是删除阶段。
If a Sync Operation consists of a single phase, each phase and hence the Sync Operation are marked as ended by a SearchResultDone Message with Sync Done Control, which SHOULD contain a cookie representing the state of the content after completing the Sync Operation. The Sync Done Control contains refreshDeletes, which is set to FALSE for the present phase and set to TRUE for the delete phase.
如果同步操作由单个阶段组成，则每个阶段以及同步操作都会被带有Sync Done控件的SearchResultDone消息标记为结束，该消息应包含表示完成同步操作后内容状态的cookie。Sync Done控件包含refreshDeletes，当前阶段设置为FALSE，删除阶段设置为TRUE。
If a Sync Operation consists of a present phase followed by a delete phase, the Sync Operation is marked as ended at the end of the delete phase by a SearchResultDone Message with Sync Done Control, which SHOULD contain a cookie representing the state of the content after completing the Sync Operation. The Sync Done Control contains refreshDeletes, which is set to TRUE.
如果同步操作由当前阶段和删除阶段组成，则同步操作将在删除阶段结束时被带有同步完成控件的SearchResultOne消息标记为结束，该消息应包含表示完成同步操作后内容状态的cookie。Sync Done控件包含设置为TRUE的refreshDeletes。
The client can specify whether it prefers to receive an initial content by supplying reloadHint of TRUE or to receive a e-syncRefreshRequired resultCode by supplying reloadHint of FALSE (hence absent), in the case that the server determines that it is
如果服务器确定初始内容是真的，客户端可以指定是通过提供reloadHint接收初始内容，还是通过提供reloadHint FALSE（因此不存在）接收e-syncRefreshRequired resultCode
impossible or inefficient to achieve the eventual convergence by continuing the current incremental synchronization thread.
通过继续当前增量同步线程来实现最终收敛是不可能的或效率低下的。
A resultCode value of success indicates that the operation is successfully completed. A resultCode value of e-syncRefreshRequired indicates that a full or partial refresh is needed. Otherwise, the result code indicates the nature of failure. A cookie is provided in the Sync Done Control for use in subsequent Sync Operations for incremental synchronization.
resultCode值success表示操作已成功完成。resultCode值e-syncRefreshRequired表示需要完全或部分刷新。否则，结果代码将指示故障的性质。Sync Done控件中提供了一个cookie，用于增量同步的后续同步操作。
A Sync request with mode refreshAndPersist asks for initial content or content update (during the refresh stage) followed by change notifications (during the persist stage).
具有refreshAndPersist模式的同步请求请求初始内容或内容更新（在刷新阶段），然后更改通知（在持久化阶段）。
The content refresh is provided as described in Section 3.3, except that the successful completion of content refresh is indicated by sending a Sync Info Message of refreshDelete or refreshPresent with a refreshDone value set to TRUE instead of a SearchResultDone Message with resultCode success. A cookie SHOULD be returned in the Sync Info Message to represent the state of the content after finishing the refresh stage of the Sync Operation.
内容刷新如第3.3节所述，但内容刷新的成功完成是通过发送refreshDelete或refreshPresent的同步信息消息（refreshDone值设置为TRUE）而不是resultCode success的SearchResultOne消息来表示的。同步信息消息中应返回cookie，以表示完成同步操作的刷新阶段后内容的状态。
Change notifications are provided during the persist stage.
更改通知在持久化阶段提供。
As updates are made to the DIT, the server notifies the client of changes to the content. DIT updates may cause entries and references to be added to the content, deleted from the content, or modified within the content. DIT updates may also cause references to be added, deleted, or modified within the content.
在对DIT进行更新时，服务器会通知客户端内容的更改。DIT更新可能会导致将条目和引用添加到内容、从内容中删除或在内容中修改。DIT更新还可能导致在内容中添加、删除或修改引用。
Where DIT updates cause an entry to be added to the content, the server provides a SearchResultEntry Message that represents the entry as it appears in the content. The message SHALL include a Sync State Control with state of add, an entryUUID containing the entry's UUID, and an optional cookie.
当DIT更新导致将条目添加到内容中时，服务器将提供一条SearchResultEntry消息，该消息表示该条目在内容中的显示。消息应包括状态为add的同步状态控件、包含条目UUID的entryUUID和可选cookie。
Where DIT updates cause a reference to be added to the content, the server provides a SearchResultReference Message that represents the reference in the content. The message SHALL include a Sync State Control with state of add, an entryUUID containing the UUID associated with the reference, and an optional cookie.
当DIT更新导致向内容添加引用时，服务器将提供一条SearchResultReference消息，该消息表示内容中的引用。消息应包括一个状态为add的同步状态控件、一个包含与引用关联的UUID的entryUUID以及一个可选cookie。
Where DIT updates cause an entry to be modified within the content, the server provides a SearchResultEntry Message that represents the entry as it appears in the content. The message SHALL include a Sync State Control with state of modify, an entryUUID containing the entry's UUID, and an optional cookie.
当DIT更新导致内容中的条目被修改时，服务器将提供一条SearchResultEntry消息，该消息表示内容中出现的条目。消息应包括具有修改状态的同步状态控件、包含条目UUID的entryUUID和可选cookie。
Where DIT updates cause a reference to be modified within the content, the server provides a SearchResultReference Message that represents the reference in the content. The message SHALL include a Sync State Control with state of modify, an entryUUID containing the UUID associated with the reference, and an optional cookie.
当DIT更新导致内容中的引用被修改时，服务器将提供一条SearchResultReference消息，该消息表示内容中的引用。消息应包括具有修改状态的同步状态控件、包含与引用关联的UUID的entryUUID以及可选cookie。
Where DIT updates cause an entry to be deleted from the content, the server provides a SearchResultEntry Message with no attributes. The message SHALL include a Sync State Control with state of delete, an entryUUID containing the entry's UUID, and an optional cookie.
当DIT更新导致从内容中删除条目时，服务器会提供一条不带属性的SearchResultEntry消息。消息应包括具有删除状态的同步状态控件、包含条目UUID的entryUUID和可选cookie。
Where DIT updates cause a reference to be deleted from the content, the server provides a SearchResultReference Message with an empty SEQUENCE OF LDAPURL. The message SHALL include a Sync State Control with state of delete, an entryUUID containing the UUID associated with the reference, and an optional cookie.
当DIT更新导致从内容中删除引用时，服务器将提供一条带有空LDAPURL序列的SearchResultReference消息。该消息应包括具有删除状态的同步状态控件、包含与引用关联的UUID的entryUUID以及可选cookie。
Multiple empty entries with a Sync State Control of state delete SHOULD be coalesced into one or more Sync Info Messages of syncIdSet value with refreshDeletes set to TRUE. syncUUIDs contain a set of UUIDs of the entries and references that have been deleted from the content. The Sync Info Message of syncIdSet may contain a cookie to represent the state of the content after performing the synchronization of the entries in the set.
多个同步状态控件为State delete的空条目应合并为一个或多个syncIdSet值的Sync Info消息，refreshDeletes设置为TRUE。syncuuid包含一组从内容中删除的条目和引用的uuid。syncIdSet的Sync Info消息可能包含一个cookie，用于表示在执行集合中项目的同步后内容的状态。
With each of these messages, the server may provide a new cookie to be used in subsequent Sync Operations. Additionally, the server may also return Sync Info Messages of choice newCookie to provide a new cookie. The client SHOULD use the newest (last) cookie it received from the server in subsequent Sync Operations.
对于这些消息中的每一条，服务器可能会提供一个新的cookie，用于后续的同步操作。此外，服务器还可以返回选择newCookie的同步信息消息以提供新的cookie。客户端应在后续同步操作中使用从服务器接收的最新（最后一个）cookie。
As stated in Section 3.1, the client SHOULD specify the same content-controlling parameters in each Search Request of the session. All fields of the SearchRequest Message are considered content-controlling parameters except for sizeLimit and timeLimit.
如第3.1节所述，客户端应在会话的每个搜索请求中指定相同的内容控制参数。SearchRequest消息的所有字段都被视为内容控制参数，sizeLimit和timeLimit除外。
As with the normal search operation, the refresh and persist stages are not isolated from DIT changes. It is possible that the entry referred to by the baseObject is deleted, renamed, or moved. It is also possible that the alias object used in finding the entry referred to by the baseObject is changed such that the baseObject refers to a different entry.
与正常搜索操作一样，刷新和持久化阶段不会与DIT更改隔离。baseObject引用的条目可能被删除、重命名或移动。还可能更改用于查找baseObject引用的条目的alias对象，使baseObject引用不同的条目。
If the DIT is updated during processing of the Sync Operation in a manner that causes the baseObject no longer to refer to any entry or in a manner that changes the entry the baseObject refers to, the server SHALL return an appropriate non-success result code, such as noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or e-syncRefreshRequired.
如果在处理同步操作期间，以导致baseObject不再引用任何条目的方式或以更改baseObject引用的条目的方式更新DIT，则服务器应返回适当的非成功结果代码，例如noSuchObject、aliasProblem、AliasDereferenceProblem、referral、，或电子同步。
This operation does not support alias dereferencing during searching. The client SHALL specify neverDerefAliases or derefFindingBaseObj for the SearchRequest derefAliases parameter. The server SHALL treat other values (e.g., derefInSearching, derefAlways) as protocol errors.
此操作不支持在搜索期间取消别名引用。客户端应为SearchRequest Derfaliases参数指定neverDerefAliases或DerefiningBaseObj。服务器应将其他值（例如，derefInSearching、derefAlways）视为协议错误。
The sizeLimit applies only to entries (regardless of their state in Sync State Control) returned during the refreshOnly operation or the refresh stage of the refreshAndPersist operation.
sizeLimit仅适用于在refreshOnly操作或refreshAndPersist操作的刷新阶段返回的条目（无论其在同步状态控件中的状态如何）。
For a refreshOnly Sync Operation, the timeLimit applies to the whole operation. For a refreshAndPersist operation, the timeLimit applies only to the refresh stage including the generation of the Sync Info Message with a refreshDone value of TRUE.
对于仅刷新同步操作，时间限制将应用于整个操作。对于refreshAndPersist操作，timeLimit仅适用于刷新阶段，包括生成refreshDone值为TRUE的同步信息消息。
The client SHOULD avoid filter assertions that apply to the values of the attributes likely to be considered by the server as ones holding meta-information. See Section 4.
客户端应该避免应用于属性值的过滤器断言，这些属性值可能被服务器视为包含元信息的属性值。见第4节。
The Sync Operation uses entryUUID values provided in the Sync State Control as the primary keys to entries. The client MUST use these entryUUIDs to correlate synchronization messages.
同步操作使用同步状态控件中提供的entryUUID值作为条目的主键。客户端必须使用这些EntryUUID关联同步消息。
In some circumstances, the DN returned may not reflect the entry's current DN. In particular, when the entry is being deleted from the content, the server may provide an empty DN if the server does not wish to disclose the entry's current DN (or, if deleted from the DIT, the entry's last DN).
在某些情况下，返回的DN可能不会反映条目的当前DN。特别是，当从内容中删除条目时，如果服务器不希望披露条目的当前DN（或者，如果从DIT中删除，则为条目的最后一个DN），则服务器可能会提供一个空DN。
Also note that the entry's DN may be viewed as meta information (see Section 4.1).
还请注意，条目的DN可能被视为元信息（参见第4.1节）。
Servers MUST implement the LDAP Cancel [RFC3909] Operation and support cancellation of outstanding Sync Operations as described here.
服务器必须实现LDAP Cancel[RFC3909]操作，并支持此处所述的取消未完成的同步操作。
To cancel an outstanding Sync Operation, the client issues an LDAP Cancel [RFC3909] Operation.
要取消未完成的同步操作，客户端将发出LDAP取消[RFC3909]操作。
If at any time the server becomes unwilling or unable to continue processing a Sync Operation, the server SHALL return a SearchResultDone with a non-success resultCode indicating the reason for the termination of the operation.
如果服务器在任何时候不愿意或无法继续处理同步操作，则服务器应返回一个SearchResultOne，其中包含一个未成功的resultCode，指明操作终止的原因。
Whether the client or the server initiated the termination, the server may provide a cookie in the Sync Done Control for use in subsequent Sync Operations.
无论是客户端还是服务器发起终止，服务器都可以在Sync Done控件中提供cookie，以便在后续的同步操作中使用。
In order to achieve the eventually-convergent synchronization, the server may terminate the Sync Operation in the refresh or persist stages by returning an e-syncRefreshRequired resultCode to the client. If no cookie is provided, a full refresh is needed. If a cookie representing a synchronization state is provided in this response, an incremental refresh is needed.
为了实现最终收敛的同步，服务器可以通过向客户端返回e-syncRefreshRequired resultCode来终止刷新或持久化阶段的同步操作。如果没有提供cookie，则需要进行完全刷新。如果此响应中提供了表示同步状态的cookie，则需要进行增量刷新。
To obtain a full refresh, the client then issues a new synchronization request with no cookie. To obtain an incremental reload, the client issues a new synchronization with the provided cookie.
为了获得完全刷新，客户端然后发出一个不带cookie的新同步请求。要获得增量重新加载，客户端将与提供的cookie进行新的同步。
The server may choose to provide a full copy in the refresh stage (e.g., ignore the cookie or the synchronization state represented in the cookie) instead of providing an incremental refresh in order to achieve the eventual convergence.
服务器可以选择在刷新阶段提供完整副本（例如，忽略cookie或cookie中表示的同步状态），而不是提供增量刷新以实现最终收敛。
The decision between the return of the initial content and the return of the e-syncRefreshRequired result code may be based on reloadHint in the Sync Request Control from the client.
返回初始内容和返回e-syncRefreshRequired结果代码之间的决定可能基于来自客户端的同步请求控件中的重载提示。
In the case of persist stage Sync, the server returns the resultCode of e-syncRefreshRequired to the client to indicate that the client needs to issue a new Sync Operation in order to obtain a synchronized copy of the content. If no cookie is provided, a full refresh is needed. If a cookie representing a synchronization state is provided, an incremental refresh is needed.
在持久阶段同步的情况下，服务器将e-syncRefreshRequired的resultCode返回给客户端，以指示客户端需要发出新的同步操作以获取内容的同步副本。如果没有提供cookie，则需要进行完全刷新。如果提供了表示同步状态的cookie，则需要进行增量刷新。
The server may also return e-syncRefreshRequired if it determines that a refresh would be more efficient than sending all the messages required for convergence.
如果服务器确定刷新将比发送聚合所需的所有消息更有效，则还可能返回e-syncRefreshRequired。
Note that the client may receive one or more of SearchResultEntry, SearchResultReference, and/or Sync Info Messages before it receives a SearchResultDone Message with the e-syncRefreshRequired result code.
请注意，客户端在收到带有e-SyncRefresh所需结果代码的SearchResultOne消息之前，可能会收到一条或多条SearchResultEntry、SearchResultReference和/或Sync Info消息。
The server MUST ensure that the number of entry messages generated to refresh the client content does not exceed the number of entries presently in the content. While there is no requirement for servers to maintain history information, if the server has sufficient history to allow it to reliably determine which entries in the prior client copy are no longer present in the content and the number of such entries is less than or equal to the number of unchanged entries, the server SHOULD generate delete entry messages instead of present entry messages (see Section 3.3.2).
服务器必须确保为刷新客户端内容而生成的条目消息数不超过内容中当前的条目数。虽然不要求服务器维护历史记录信息，但如果服务器具有足够的历史记录，使其能够可靠地确定内容中不再存在先前客户端副本中的哪些条目，并且这些条目的数量小于或等于未更改条目的数量，服务器应生成删除条目消息，而不是当前条目消息（参见第3.3.2节）。
When the amount of history information maintained in the server is not enough for the clients to perform infrequent refreshOnly Sync Operations, it is likely that the server has incomplete history information (e.g., due to truncation) by the time those clients connect again.
当服务器中维护的历史记录信息量不足以让客户端执行不频繁的仅刷新同步操作时，在这些客户端再次连接时，服务器可能具有不完整的历史记录信息（例如，由于截断）。
The server SHOULD NOT resort to full reload when the history information is not enough to generate delete entry messages. The server SHOULD generate either present entry messages only or present entry messages followed by delete entry messages to bring the client copy to the current state. In the latter case, the present entry messages bring the client copy to a state covered by the history information maintained in the server.
当历史记录信息不足以生成删除条目消息时，服务器不应求助于完全重新加载。服务器应生成“仅显示条目消息”或“显示条目消息”，然后生成“删除条目消息”，以将客户端副本恢复到当前状态。在后一种情况下，当前条目消息使客户端副本处于服务器中维护的历史信息所覆盖的状态。
The server SHOULD maintain enough (current or historical) state information (such as a context-wide last modify time stamp) to determine if no changes were made in the context since the content
服务器应维护足够的（当前或历史）状态信息（例如上下文范围的上次修改时间戳），以确定自内容更新后上下文中是否未进行任何更改
refresh was provided and, when no changes were made, generate zero delete entry messages instead of present messages.
提供了刷新，当未进行任何更改时，生成零删除条目消息，而不是当前消息。
The server SHOULD NOT use the history information when its use does not reduce the synchronization traffic or when its use can expose sensitive information not allowed to be received by the client.
当历史记录信息的使用不会减少同步通信量，或者使用历史记录信息会暴露客户端不允许接收的敏感信息时，服务器不应使用历史记录信息。
The server implementor should also consider chattiness issues that span multiple Sync Operations of a session. As noted in Section 3.8, the server may return e-syncRefreshRequired if it determines that a reload would be more efficient than continuing under the current operation. If reloadHint in the Sync Request is TRUE, the server may initiate a reload without directing the client to request a reload.
服务器实现者还应该考虑跨越会话的多个同步操作的CHARTY问题。如第3.8节所述，如果服务器确定重新加载比在当前操作下继续更有效，则可能会返回e-syncRefreshRequired。如果同步请求中的reloadHint为TRUE，则服务器可以启动重新加载，而无需指示客户端请求重新加载。
The server SHOULD transfer a new cookie frequently to avoid having to transfer information already provided to the client. Even where DIT changes do not cause content synchronization changes to be transferred, it may be advantageous to provide a new cookie using a Sync Info Message. However, the server SHOULD avoid overloading the client or network with Sync Info Messages.
服务器应该经常传输新的cookie，以避免必须传输已经提供给客户端的信息。即使在DIT更改不会导致传输内容同步更改的情况下，使用同步信息消息提供新cookie也可能是有利的。但是，服务器应避免使用同步信息消息使客户端或网络过载。
During persist mode, the server SHOULD coalesce multiple outstanding messages updating the same entry. The server MAY delay generation of an entry update in anticipation of subsequent changes to that entry that could be coalesced. The length of the delay should be long enough to allow coalescing of update requests issued back to back but short enough that the transient inconsistency induced by the delay is corrected in a timely manner.
在持久化模式下，服务器应该合并多个未完成的消息来更新相同的条目。服务器可能会延迟条目更新的生成，以预期可能合并的条目的后续更改。延迟的长度应足够长，以允许合并背靠背发出的更新请求，但足够短，以及时纠正延迟引起的暂时不一致性。
The server SHOULD use the syncIdSet Sync Info Message when there are multiple delete or present messages to reduce the amount of synchronization traffic.
当存在多条删除或显示消息时，服务器应使用syncIdSet Sync Info消息以减少同步通信量。
Also note that there may be many clients interested in a particular directory change, and that servers attempting to service all of these at once may cause congestion on the network. The congestion issues are magnified when the change requires a large transfer to each interested client. Implementors and deployers of servers should take steps to prevent and manage network congestion.
还请注意，可能有许多客户端对特定目录更改感兴趣，而试图同时为所有这些更改提供服务的服务器可能会导致网络拥塞。当变更需要向每个感兴趣的客户机进行大量传输时，拥塞问题会被放大。服务器的实施者和部署者应该采取措施防止和管理网络拥塞。
The LDAP protocol model [RFC4511] allows operations to be multiplexed over a single LDAP session. Clients SHOULD NOT maintain multiple LDAP sessions with the same server. Servers SHOULD ensure that responses from concurrently processed operations are interleaved fairly.
LDAP协议模型[RFC4511]允许在单个LDAP会话上多路传输操作。客户端不应在同一服务器上维护多个LDAP会话。服务器应确保并行处理操作的响应公平地交错。
Clients SHOULD combine Sync Operations whose result set is largely overlapping. This avoids having to return multiple messages, once for each overlapping session, for changes to entries in the overlap.
客户端应该组合同步操作，其结果集在很大程度上是重叠的。这避免了必须为每个重叠会话返回多条消息，以更改重叠会话中的条目。
Clients SHOULD NOT combine Sync Operations whose result sets are largely non-overlapping. This ensures that an event requiring an e-syncRefreshRequired response can be limited to as few result sets as possible.
客户端不应组合结果集基本上不重叠的同步操作。这确保了需要e-syncRefreshRequired响应的事件可以限制为尽可能少的结果集。
As an entry's DN is constructed from its relative DN (RDN) and the entry's parent's DN, it is often viewed as meta information.
由于条目的DN是由其相对DN（RDN）和父条目的DN构成的，因此它通常被视为元信息。
While renaming or moving to a new superior causes the entry's DN to change, that change SHOULD NOT, by itself, cause synchronization messages to be sent for that entry. However, if the renaming or the moving could cause the entry to be added or deleted from the content, appropriate synchronization messages should be generated to indicate this to the client.
重命名或移动到新上级会导致条目的DN发生更改，但更改本身不应导致为该条目发送同步消息。但是，如果重命名或移动可能导致从内容中添加或删除条目，则应生成适当的同步消息，以向客户端表明这一点。
When a server treats the entry's DN as meta information, the server SHALL either
当服务器将条目的DN视为元信息时，服务器应
- evaluate all MatchingRuleAssertions [RFC4511] to TRUE if matching a value of an attribute of the entry, otherwise Undefined, or
- 如果匹配条目属性的值，则将所有MatchingRuleAssertions[RFC4511]求值为TRUE，否则为未定义，或者
- evaluate all MatchingRuleAssertion with dnAttributes of TRUE as Undefined.
- 将dnAttributes为TRUE的所有MatchingRuleAssertion计算为未定义。
The latter choice is offered for ease of server implementation.
后一种选择是为了便于服务器实现。
Where values of an operational attribute are determined by values not held as part of the entry it appears in, the operational attribute SHOULD NOT support synchronization of that operational attribute.
如果操作属性的值是由未作为其出现的条目的一部分保留的值确定的，则操作属性不应支持该操作属性的同步。
For example, in servers that implement the X.501 subschema model [X.501], servers should not support synchronization of the subschemaSubentry attribute as its value is determined by values held and administrated in subschema subentries.
例如，在实现X.501子模式模型[X.501]的服务器中，服务器不应支持子模式AsubEntry属性的同步，因为其值由子模式子项中保存和管理的值确定。
As a counter example, servers that implement aliases [RFC4512][X.501] can support synchronization of the aliasedObjectName attribute as its values are held and administrated as part of the alias entries.
作为反例，实现别名[RFC4512][X.501]的服务器可以支持aliasedObjectName属性的同步，因为其值作为别名项的一部分进行保存和管理。
Servers SHOULD support synchronization of the following operational attributes: createTimestamp, modifyTimestamp, creatorsName, modifiersName [RFC4512]. Servers MAY support synchronization of other operational attributes.
服务器应支持以下操作属性的同步：createTimestamp、modifyTimestamp、creatorsName、modifierName[RFC4512]。服务器可能支持其他操作属性的同步。
A collective attribute is "a user attribute whose values are the same for each member of an entry collection" [X.501]. Use of collective attributes in LDAP is discussed in [RFC3671].
集合属性是“其值对于条目集合的每个成员都相同的用户属性”[X.501]。[RFC3671]中讨论了LDAP中集合属性的使用。
Modification of a collective attribute generally affects the content of multiple entries, which are the members of the collection. It is inefficient to include values of collective attributes visible in entries of the collection, as a single modification of a collective attribute requires transmission of multiple SearchResultEntry (one for each entry of the collection that the modification affected).
修改集合属性通常会影响作为集合成员的多个条目的内容。将集合属性的值包含在集合的条目中是无效的，因为对集合属性的一次修改需要传输多个SearchResultEntry（受修改影响的集合的每个条目一个）。
Servers SHOULD NOT synchronize collective attributes appearing in entries of any collection. Servers MAY support synchronization of collective attributes appearing in collective attribute subentries.
服务器不应同步任何集合项中出现的集合属性。服务器可能支持出现在集合属性子项中的集合属性的同步。
Entries are commonly subject to access and other administrative Controls. While portions of the policy information governing a particular entry may be held in the entry, policy information is often held elsewhere (in superior entries, in subentries, in the root DSE, in configuration files, etc.). Because of this, changes to policy information make it difficult to ensure eventual convergence during incremental synchronization.
条目通常受到访问和其他管理控制。虽然管理特定条目的策略信息的部分可能保存在条目中，但策略信息通常保存在其他地方（在上级条目、子条目、根DSE、配置文件等中）。因此，对策略信息的更改使得在增量同步期间很难确保最终的收敛。
Where it is impractical or infeasible to generate content changes resulting from a change to policy information, servers may opt to return e-syncRefreshRequired or to treat the Sync Operation as an initial content request (e.g., ignore the cookie or the synchronization state represented in the cookie).
如果由于策略信息的更改而生成内容更改是不切实际或不可行的，服务器可以选择返回e-syncRefreshRequired或将同步操作视为初始内容请求（例如，忽略cookie或cookie中表示的同步状态）。
The Sync Operation may be used with:
同步操作可用于以下情况：
- ManageDsaIT Control [RFC3296]
- ManageDsaIT控件[RFC3296]
- Subentries Control [RFC3672]
- 子项控制[RFC3672]
as described below. The Sync Operation may be used with other LDAP extensions as detailed in other documents.
如下所述。同步操作可与其他LDAP扩展一起使用，详见其他文档。
The ManageDsaIT Control [RFC3296] indicates that the operation acts upon the DSA Information Tree and causes referral and other special entries to be treated as object entries with respect to the operation.
ManageDsaIT控件[RFC3296]表示该操作作用于DSA信息树，并导致引用和其他特殊条目被视为与该操作相关的对象条目。
The Subentries Control is used with the search operation "to control the visibility of entries and subentries which are within scope" [RFC3672]. When used with the Sync Operation, the subentries control and other factors (search scope, filter, etc.) are used to determine whether an entry or subentry appears in the content.
子条目控件用于搜索操作“控制范围内的条目和子条目的可见性”[RFC3672]。与同步操作一起使用时，子条目控件和其他因素（搜索范围、筛选器等）用于确定内容中是否显示条目或子条目。
As noted in [RFC4511], some servers may hold shadow copies of entries that can be used to answer search and comparison queries. Such servers may also support content synchronization requests. This section discusses considerations for implementors and deployers for the implementation and deployment of the Sync operation in shadowed directories.
如[RFC4511]中所述，一些服务器可能持有可用于回答搜索和比较查询的条目的卷影副本。此类服务器还可以支持内容同步请求。本节讨论实现者和部署者在阴影目录中实现和部署同步操作的注意事项。
While a client may know of multiple servers that are equally capable of being used to obtain particular directory content from, a client SHOULD NOT assume that each of these servers is equally capable of continuing a content synchronization session. As stated in Section 3.1, the client SHOULD issue each Sync request of a Sync session to the same server.
虽然客户机可能知道多个服务器同样能够用于从中获取特定目录内容，但客户机不应假设这些服务器中的每一个都同样能够继续内容同步会话。如第3.1节所述，客户端应向同一服务器发出同步会话的每个同步请求。
However, through domain naming or IP address redirection or other techniques, multiple physical servers can be made to appear as one logical server to a client. Only servers that are equally capable in regards to their support for the Sync operation and that hold equally complete copies of the entries should be made to appear as one logical server. In particular, each physical server acting as one logical server SHOULD be equally capable of continuing a content synchronization based upon cookies provided by any of the other physical servers without requiring a full reload. Because there is no standard LDAP shadowing mechanism, the specification of how to independently implement equally capable servers (as well as the precise definition of "equally capable") is left to future documents.
但是，通过域命名或IP地址重定向或其他技术，可以使多个物理服务器在客户端上显示为一个逻辑服务器。只有在支持同步操作方面具有同等能力且具有相同完整条目副本的服务器才应显示为一个逻辑服务器。特别是，作为一个逻辑服务器的每个物理服务器都应该同样能够基于任何其他物理服务器提供的cookie继续内容同步，而无需完全重新加载。由于没有标准的LDAP跟踪机制，如何独立实现具有同等能力的服务器（以及“具有同等能力”的精确定义）的规范将留给未来的文档。
Note that it may be difficult for the server to reliably determine what content was provided to the client by another server, especially in the shadowing environments that allow shadowing events to be coalesced. For these servers, the use of the delete phase discussed in Section 3.3.2 may not be applicable.
请注意，服务器可能很难可靠地确定另一台服务器向客户端提供了哪些内容，特别是在允许合并阴影事件的阴影环境中。对于这些服务器，使用第3.3.2节中讨论的删除阶段可能不适用。
In order to maintain a synchronized copy of the content, a client is to delete information from its copy of the content as described above. However, the client may maintain knowledge of information disclosed to it by the server separate from its copy of the content used for synchronization. Management of this knowledge is beyond the scope of this document. Servers should be careful not to disclose information for content the client is not authorized to have knowledge of and/or about.
为了维护内容的同步副本，客户机需要如上所述从其内容副本中删除信息。然而，客户端可以将服务器向其公开的信息的知识与其用于同步的内容的副本分开来维护。此知识的管理超出了本文件的范围。服务器应注意不要披露客户无权了解和/或了解的内容的信息。
While the information provided by a series of refreshOnly Sync Operations is similar to that provided by a series of Search Operations, persist stage may disclose additional information. A client may be able to discern information about the particular sequence of update operations that caused content change.
虽然一系列refreshOnly同步操作提供的信息与一系列搜索操作提供的信息类似，但persist stage可能会披露其他信息。客户机可能能够识别有关导致内容更改的特定更新操作序列的信息。
Implementors should take precautions against malicious cookie content, including malformed cookies or valid cookies used with different security associations and/or protections in an attempt to obtain unauthorized access to information. Servers may include a digital signature in the cookie to detect tampering.
实施者应采取预防措施，防止恶意cookie内容，包括格式错误的cookie或与不同安全关联和/或保护一起使用的有效cookie，以试图获得对信息的未经授权访问。服务器可以在cookie中包含数字签名以检测篡改。
The operation may be the target of direct denial-of-service attacks. Implementors should provide safeguards to ensure the operation is not abused. Servers may place access control or other restrictions upon the use of this operation.
该操作可能是直接拒绝服务攻击的目标。实施者应提供保障措施，以确保操作不被滥用。服务器可能会对此操作的使用设置访问控制或其他限制。
Note that even small updates to the directory may cause a significant amount of traffic to be generated to clients using this operation. A user could abuse its update privileges to mount an indirect denial of service to these clients, other clients, and/or portions of the network. Servers should provide safeguards to ensure that update operations are not abused.
请注意，即使对目录进行很小的更新，也可能会导致使用此操作的客户端产生大量通信量。用户可能滥用其更新权限，向这些客户机、其他客户机和/或部分网络安装间接拒绝服务。服务器应提供保护措施，以确保更新操作不会被滥用。
Implementors of this (or any) LDAP extension should be familiar with general LDAP security considerations [RFC4510].
此（或任何）LDAP扩展的实现者应该熟悉一般LDAP安全注意事项[RFC4510]。
Registration of the following values have been completed by the IANA [RFC4520].
IANA已完成以下值的注册[RFC4520]。
The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the OpenLDAP Foundation, under its IANA-assigned private enterprise allocation [PRIVATE], for use in this specification.
在本规范中使用的IANA ARC1.3.61.4.1.4203.1.91被OpenLDAP基金会指派[分配]，在其IANA分配的私有企业分配[私有]下。
The IANA has registered the LDAP Protocol Mechanism described in this document.
IANA已经注册了本文档中描述的LDAP协议机制。
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
Description: LDAP Content Synchronization Control
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFC 4533
Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
Comments: none
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
Description: LDAP Content Synchronization Control
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFC 4533
Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
Comments: none
The IANA has registered the LDAP Result Code described in this document.
IANA已经注册了本文档中描述的LDAP结果代码。
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: e-syncRefreshRequired (4096)
Specification: RFC 4533
Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
Comments: none
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: e-syncRefreshRequired (4096)
Specification: RFC 4533
Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
Comments: none
This document borrows significantly from the LDAP Client Update Protocol [RFC3928], a product of the IETF LDUP working group. This document also benefited from Persistent Search [PSEARCH], Triggered Search [TSEARCH], and Directory Synchronization [DIRSYNC] works. This document also borrows from "Lightweight Directory Access Protocol (v3)" [RFC2251].
本文档主要借鉴了IETF LDUP工作组的产品LDAP客户端更新协议[RFC3928]。本文档还得益于持久搜索[PSEARCH]、触发搜索[TSEARCH]和目录同步[DIRSYNC]的工作。本文档还借用了“轻量级目录访问协议（v3）”[RFC2251]。
[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月。
[RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories", RFC 3296, July 2002.
[RFC3296]Zeilenga，K.，“轻量级目录访问协议（LDAP）目录中的命名从属引用”，RFC3296，2002年7月。
[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., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3672]Zeilenga，K.，“轻量级目录访问协议（LDAP）中的子项”，RFC 3672，2003年12月。
[RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Cancel Operation", RFC 3909, October 2004.
[RFC3909]Zeilenga，K.，“轻型目录访问协议（LDAP）取消操作”，RFC 3909，2004年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月。
[RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute", RFC 4530, June 2006.
[RFC4530]Zeilenga，K.，“轻量级目录访问协议（LDAP）入口UUID操作属性”，RFC4530，2006年6月。
[UUID] International Organization for Standardization (ISO), "Information technology - Open Systems Interconnection - Remote Procedure Call", ISO/IEC 11578:1996
[UUID]国际标准化组织（ISO），“信息技术-开放系统互连-远程过程调用”，ISO/IEC 11578:1996
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.501]国际电信联盟-电信标准化部门，“目录——模型”，X.501（1993）（也指ISO/IEC 9594-2:1994）。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.680]国际电信联盟-电信标准化部门，“抽象语法符号1（ASN.1）-基本符号规范”，X.680（1997）（也称ISO/IEC 8824-1:1998）。
[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(1997) (also ISO/IEC 8825-1:1998).
[X.690]国际电信联盟-电信标准化部门，“ASN.1编码规则规范：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）”，X.690（1997）（另见ISO/IEC 8825-1:1998）。
[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月。
[RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J. Parham, "Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)", RFC 3928, October 2004.
[RFC3928]Megginson，R.，Ed.，Smith，M.，Natkovich，O.，和J.Parham，“轻量级目录访问协议（LDAP）客户端更新协议（LCUP）”，RFC 39282004年10月。
[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月。
[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers.
[私人]IANA，“私人企业编号”，http://www.iana.org/assignments/enterprise-numbers.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt.
[分配] OpenLDAP基金会，“OpenLDAP类委托”，http://www.openldap.org/foundation/oid-delegate.txt.
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.500]国际电信联盟-电信标准化部门，“目录——概念、模型和服务概述”，X.500（1993）（也指ISO/IEC 9594-1:1994）。
[X.525] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Replication", X.525(1993).
[X.525]国际电信联盟-电信标准化部门，“目录：复制”，X.525（1993年）。
[DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory Synchronization", Work in Progress.
[DIRSYNC]Armijo，M.，“用于目录同步的Microsoft LDAP控件”，正在进行中。
[PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP Change Notification Mechanism", Work in Progress.
[PSEARCH]Smith，M.等人，“持久搜索：一种简单的LDAP更改通知机制”，正在进行中。
[TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in Progress.
[TSEARCH]Wahl，M.，“LDAPv3触发搜索控制”，正在进行中。
This appendix is provided for informational purposes only; it is not a normative part of the LDAP Content Synchronization Operation's technical specification.
本附录仅供参考；它不是LDAP内容同步操作技术规范的规范性部分。
This appendix discusses LDAP Content Synchronization Operation server implementation considerations associated with Change Sequence Number based approaches.
本附录讨论与基于更改序列号的方法相关联的LDAP内容同步操作服务器实现注意事项。
Change Sequence Number based approaches are targeted for use in servers that do not maintain history information (e.g., change logs, state snapshots) about changes made to the Directory and hence, must rely on current directory state and minimal synchronization state information embedded in Sync Cookie. Servers that maintain history information should consider other approaches that exploit the history information.
基于更改序列号的方法适用于不维护有关目录更改的历史信息（如更改日志、状态快照）的服务器，因此必须依赖于当前目录状态和嵌入在同步Cookie中的最小同步状态信息。维护历史信息的服务器应该考虑利用历史信息的其他方法。
A Change Sequence Number is effectively a time stamp that has sufficient granularity to ensure that the precedence relationship in time of two updates to the same object can be determined. Change Sequence Numbers are not to be confused with Commit Sequence Numbers or Commit Log Record Numbers. A Commit Sequence Number allows one to determine how two commits (to the same object or different objects) relate to each other in time. A Change Sequence Number associated with different entries may be committed out of order. In the remainder of this Appendix, the term CSN refers to a Change Sequence Number.
变更序列号实际上是一个时间戳，它具有足够的粒度，以确保可以确定同一对象的两次更新的时间优先级关系。更改序列号不得与提交序列号或提交日志记录号混淆。提交序列号允许确定两个提交（对同一对象或不同对象）在时间上如何相互关联。与不同条目关联的变更序号可能会无序提交。在本附录的其余部分中，术语CSN指变更序号。
In these approaches, the server not only maintains a CSN for each directory entry (the entry CSN) but also maintains a value that we will call the context CSN. The context CSN is the greatest committed entry CSN that is not greater than any outstanding (uncommitted) entry CSNs for all entries in a directory context. The values of context CSN are used in syncCookie values as synchronization state indicators.
在这些方法中，服务器不仅为每个目录条目维护一个CSN（条目CSN），而且还维护一个我们称之为上下文CSN的值。上下文CSN是最大的已提交条目CSN，它不大于目录上下文中所有条目的任何未提交（未提交）条目CSN。上下文CSN的值在syncCookie值中用作同步状态指示器。
As search operations are not isolated from individual directory update operations and individual update operations cannot be assumed to be serialized, one cannot assume that the returned content incorporates each relevant change whose change sequence number is less than or equal to the greatest entry CSN in the content. The content incorporates all the relevant changes whose change sequence numbers are less than or equal to context CSN before search processing. The content may also incorporate any subset of the changes whose change sequence number is greater than context CSN before search processing but less than or equal to the context CSN after search processing. The content does not incorporate any of the
由于搜索操作未与单个目录更新操作隔离，并且无法假定单个更新操作是序列化的，因此不能假定返回的内容包含每个相关更改，这些更改的更改序号小于或等于内容中的最大条目CSN。在搜索处理之前，内容包含其更改序列号小于或等于上下文CSN的所有相关更改。内容还可以包括其变更序列号在搜索处理之前大于上下文CSN但在搜索处理之后小于或等于上下文CSN的变更的任何子集。内容不包含以下任何内容：
changes whose CSN is greater than the context CSN after search processing.
搜索处理后其CSN大于上下文CSN的更改。
A simple server implementation could use the value of the context CSN before search processing to indicate state. Such an implementation would embed this value into each SyncCookie returned. We'll call this the cookie CSN. When a refresh was requested, the server would simply generate "update" messages for all entries in the content whose CSN is greater than the supplied cookie CSN and generate "present" messages for all other entries in the content. However, if the current context CSN is the same as the cookie CSN, the server should instead generate zero "updates" and zero "delete" messages and indicate a refreshDeletes of TRUE, as the directory has not changed.
一个简单的服务器实现可以在搜索处理之前使用上下文CSN的值来指示状态。这样的实现会将此值嵌入到返回的每个SyncCookie中。我们称之为cookie CSN。当请求刷新时，服务器只需为内容中CSN大于提供的cookie CSN的所有条目生成“更新”消息，并为内容中的所有其他条目生成“显示”消息。但是，如果当前上下文CSN与cookie CSN相同，则服务器应生成零“更新”和零“删除”消息，并指示refreshDeletes为TRUE，因为目录未更改。
The implementation should also consider the impact of changes to meta information, such as access controls, that affect content determination. One approach is for the server to maintain a context-wide meta information CSN or meta CSN. This meta CSN would be updated whenever meta information affecting content determination was changed. If the value of the meta CSN is greater than the cookie CSN, the server should ignore the cookie and treat the request as an initial request for content.
实现还应考虑更改对元信息（如访问控制）的影响，从而影响内容确定。一种方法是服务器维护上下文范围的元信息CSN或元CSN。每当影响内容确定的元信息发生变化时，该元CSN就会更新。如果meta CSN的值大于cookie CSN，服务器应忽略cookie，并将请求视为内容的初始请求。
Additionally, servers may want to consider maintaining some per-session history information to reduce the number of messages needed to be transferred during incremental refreshes. Specifically, a server could record information about entries as they leave the scope of a disconnected sync session and later use this information to generate delete messages instead of present messages.
此外，服务器可能需要考虑维护一些会话历史信息，以减少在增量刷新期间需要传输的消息的数量。具体来说，服务器可以在条目离开断开连接的同步会话范围时记录有关条目的信息，然后使用此信息生成删除消息，而不是当前消息。
When the history information is truncated, the CSN of the latest truncated history information entry may be recorded as the truncated CSN of the history information. The truncated CSN may be used to determine whether a client copy can be covered by the history information by comparing it to the synchronization state contained in the cookie supplied by the client.
当历史信息被截断时，最新截断的历史信息条目的CSN可以被记录为历史信息的截断CSN。截断的CSN可用于通过将历史信息与客户端提供的cookie中包含的同步状态进行比较来确定客户端副本是否可被历史信息覆盖。
When there is a large number of sessions, it may make sense to maintain such history only for the selected clients. Also, servers taking this approach need to consider resource consumption issues to ensure reasonable server operation and to protect against abuse. It may be appropriate to restrict this mode of operation by policy.
当存在大量会话时，仅为选定的客户端维护此类历史记录可能是有意义的。此外，采用这种方法的服务器需要考虑资源消耗问题，以确保合理的服务器操作和防止滥用。通过策略限制这种操作模式可能是合适的。
Authors' Addresses
作者地址
Kurt D. Zeilenga OpenLDAP Foundation
库尔特D.Zeeliga OpenLDAP基金会
EMail: Kurt@OpenLDAP.org
EMail: Kurt@OpenLDAP.org
Jong Hyuk Choi IBM Corporation
蔡正赫IBM公司
EMail: jongchoi@us.ibm.com
EMail: jongchoi@us.ibm.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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）提供。