[要約] RFC 3928は、LDAPクライアントの更新プロトコルであるLCUPについての仕様を提供しています。このプロトコルの目的は、LDAPディレクトリサーバーへのクライアントの変更を効率的に同期させることです。
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)
LightWeight Directory Access Protocol（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）The Internet Society（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.
このドキュメントでは、Lightweight Directory Access Protocol（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
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.
- 異種のデータストアを同期することを目的としたアプリケーション。たとえば、Meta Directoryアプリケーションは、ディレクトリから変更されたエントリのリストを定期的に取得し、変更を構築し、外国のデータストアに適用します。
- 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は、LDUP [RFC3384]と呼ばれるLDAPレプリケーションプロトコルを開発しています。これは、この問題領域に対処するために特別に設計されています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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]を使用して説明されています。「BERENCODED」という用語は、[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:
著名な名前は変更される可能性があるため、識別子として信頼できません。LCUPで使用されるエントリを一意に識別するために、普遍的に一意の識別子（または略してUUID）を使用する必要があります。UUIDは、各検索結果で返される同期更新制御値（以下を参照）の一部です。サーバーは、UUIDをエントリの単一の価値のある操作属性として提供する必要があります（例：「EntryUuid」）。サーバーは、UUIDの値を効率的に（つまり、インデックス付き）検索する方法を提供することをお勧めします。uuid。サーバーは、[UUID]で指定されているようにUUID形式を使用する必要があります。LCUPで使用されるUUIDは、次のASN.1タイプの値です。
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を使用して、サーバーのデータに関してクライアントのデータの状態を保持します。各クッキー形式は、そのスキームによって一意に識別されます。LCUPスキームは、次のASN.1タイプの値です。
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です。値形式が公開され、詳細に説明されている1つ以上の標準トラックCookieスキームがあることが予想されます。
The LCUP Cookie is a value of the following ASN.1 type:
LCUP Cookieは、次のASN.1タイプの値です。
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コンテキストと呼ばれます。サーバーは、1つ以上のLCUPコンテキストをサポートする場合があります。たとえば、2つの命名コンテキストを備えたサーバーは、1つの命名コンテキストでLCUPをサポートしますが、もう1つの命名コンテキストではありません。また、各命名コンテキストで異なるLCUP Cookieスキームをサポートします。各LCUPコンテキストは、異なるCookieスキームを使用する場合があります。LCUP検索では、LCUPコンテキストの境界を越えませんが、代わりにSearchResultReferenceメッセージを返します。LDAPURLは、現在検索されているのと同じホストとポートを指定し、新しいLCUPコンテキストのBasedNに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].
この仕様の実装は、以下の追加の結果コード値を認識するものとします。次の表で定義されているLDAP結果コード名と数字は、RFC 3383 [RFC3383]ごとにIANAによって割り当てられています。
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
lcupresourcesexexed（113）サーバーはリソースを使い果たしていますlcupsecurityviolation（114）クライアントは悪意のある行動の疑いがありますlcupinvaliddata（115）無効なスキームまたはクッキーはクライアントによって提供されました
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ですが、このサーバーではサポートされていませんlcupreloadrequired（117）は、クライアントデータを再有itial化する必要があることを示しています。この理由は、サーバーにクライアントを同期するのに十分な情報が含まれていない場合、または最後の同期セッション以降にサーバーのデータがリロードされた場合に返されます
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であり、コントロールバリューであるOctet Stringには、BER-ENCODED SYNCREQUESTCONTROLOLOLVALUEが含まれています。
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-サーバーは、SERDCOOKIEINTERVAL数のSEARCHRESULTENTRYとSEARCHRESULTREFERENCE PDUのすべてのSENDCOOKIEINTERVALのすべてのSENDCOOKIEINTERVALのSyncアップデートコントロール値（以下に定義）で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]です。ここで、制御タイプはオブジェクト識別子1.3.6.1.1.7.2であり、コントロールバリューであるオクテット文字列には、ベルエンコードのSyncupDateControlValueが含まれています。
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には、クライアントがUUIDに基づいてエントリの検索を実行するために使用する属性の名前またはoidが含まれています。クライアントは、「（<UUID属性> = <エントリUUID値>）」など、等しい検索フィルターでそれを使用できる必要があり、検索要求の属性リストで値を返すことができるはずです。サーバーが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.
Sync Updateコントロールは、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]です。ここで、制御タイプはオブジェクト識別子1.3.6.1.1.7.3であり、コントロールバリューにはバーエンコードされた同期型が含まれています。
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.
同期実行制御は、SearchResultDoneメッセージにのみ適用されます。このコントロールの使用については、以下に説明します。
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.
エラー条件がある場合、サーバーは、結果コードがエラーコードに設定されたSearchResultDoneメッセージを直ちに返す必要があります。このテーブルは、条件を対応する動作と結果コードにマッピングします。
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] - 具体的には、コントロールの重要性がfalseの場合、サーバーは通常の検索要求として要求を処理します
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
サーバーは、lcupresourcesexexedのリソースを使い果たしています
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)
サーバーは、lcupreloadRequiredクライアントを最新の状態にすることはできません（サーバーデータがリロードされているか、その他の変更が収束を防ぎます）
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 If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
updateType- synconlyまたはsyncandpersist sendcookieIntervalに設定する必要があります-SendCookieInterval-設定されたスキームが設定される場合があります - 設定される場合、サーバーはこの指定されたスキームを使用するか、lcupunsupportedsschemeを返す必要があります（上記を参照） - セットではない場合、サーバーはサポートするスキームを使用できます。Cookie-リクエストが成功した場合、クライアントは以下のセクション「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に設定する必要があります - スキームが設定される可能性があります - 設定されている必要があります - 設定する必要があります
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は、永続的にsendcookieIntervalに設定する必要があります - 設定されたスキーム - 設定される場合があります - 設定する場合、サーバーはこの指定されたスキームを使用するか、lcupunsupportedsscheme（上記を参照）を返す必要があります（上記を参照） - セットではない場合、サーバーはサポートするスキームを使用する場合があります。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を返し、その後にSearchResultDone PDUが続きます。動作は、[RFC2251セクション4.5]で指定されているとおりです。各SearchResultentryまたはSearchResultReference PDUには、返されたエントリのLCUP状態を説明する同期更新制御も含まれています。SearchResultDone PDUには、同期DONEコントロールが含まれています。次のセクションでは、[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:
サーバーは、Sync Updateコントロールを使用して、特定のエントリに関連しない情報を返すことができます。これをいつでもこれを行うことができます。クッキーをクライアントに戻すか、クライアントにシナンドペルシスト検索の同期フェーズが完了し、永続フェーズが始まっていることをクライアントに通知することができます。通常、応答をトリガーするエントリが変更されていない場合でも、これは永続フェーズでこれを行う可能性があります。これを行うには、以下を返す必要があります。
- 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フィールドを使用したSearchResultentry PDUは、検索要求のbaseObjectのDNに設定され、空の属性リストを使用します。
- 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-真のentreUUIDに設定する必要があります - 検索リクエストのbaseObject enterleftsetのbaseObjectのuuidに設定する必要があります - 虚偽の持続性に設定する必要があります - 検索がリクエストの同期フェーズにある場合はfalseでなければならず、真でなければなりません検索が永続フェーズにある場合 - これが最初の結果が返された場合、または属性が変更された場合にのみ設定する必要があります - Cookieが設定され、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のリクエスト中に、サーバーは、Syncフェーズの最後のエントリが送信され、永続フェーズの最初のエントリが送信される直前に（上記のように）戻る必要があります。この場合、粘り強いフィールドは真に設定する必要があります。これにより、クライアントは同期フェーズが完了し、永続フェーズが開始されていることをクライアントが知ることができます。
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 to the server of how often to return the cookie in the Sync Update control. The server SHOULD respect this value.
Sync Updateコントロール値のCookieフィールドは、同期フェーズと永続フェーズの両方で、返された結果で設定できます。サーバーは、検索が切断されているか、その他の終了が終了した場合に備えて、クライアントが妥当な期間に再調整するのに十分な頻度でクライアントにCookieを返す必要があります。Sync Request ControlのSendCookieIntervalフィールドは、Syncアップデートコントロールで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形式が変更された場合、Sync更新制御値のスキームフィールドを設定する必要があります。それ以外の場合は、省略される場合があります。
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がSync Updateコントロール値で頻繁に返されることを保証する場合があります。そのため、再接続する必要がある場合は、多くの冗長エントリを処理する必要がありません。これらのクライアントは、SendCookieIntervalを同期リクエスト制御値を低い数、おそらく1に設定する必要があります。一部のクライアントは、帯域幅の接続が限られている可能性があり、Cookieをあまり頻繁に受け取りたくない場合もあります（ただし、Cookie正常に完了すると、常に同期実行された制御値で送信されます）。これらのクライアントは、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.
サーバーの合理的な動作は、クライアントが頻繁にSendCookieIntervalを指定した場合でも、LCUPコンテキストのデータが変更された場合にのみCookieを返すことです。何も変更されていない場合、サーバーはおそらく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変更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 enter the result set (e.g., relaxing of some access control that permits the entry to be visible to the client).
- 永続的な検索操作の永続フェーズ中、エントリは検索結果セットに入ります。これは、LDAP Add操作を介してエントリが追加された場合、またはLDAP変更DN操作によって設定された結果に移動するエントリ、または結果セットを入力するエントリへの変更により、エントリが追加されます（例えば、例えば、クライアントの検索フィルターに一致する属性値を追加するか、エントリが結果セットに入力する原因となるメタデータの変更によって（たとえば、エントリがクライアントに表示されるようにするアクセス制御のリラックス）。
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.
検索要求の属性リストの属性の1つ以上が変更された場合、エントリは変更されると見なされます。たとえば、検索要求に属性が「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」、または「または「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 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操作を介して結果をセットするエントリによる、または結果セットのままにするエントリの変更により、結果が設定されたためです（例：変更//クライアントの検索フィルターと一致しなくなるように属性値を削除するか、エントリが結果セットを残しているメタデータの変更によって（たとえば、エントリがクライアントに表示されることを拒否するアクセス制御を追加する）。
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-誤った侵入に設定する必要があります - エントリエントリレフセットのuuidに設定する必要があります - 誤って持続するために設定する必要があります - 同期フェーズ中に、または永続フェーズuuidattribute中にの場合の場合はfalseに設定する必要があります - これが最初の結果が返された場合、または属性がスキームを変更した場合 - 上記のように -
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のリターンは同じように見えますが、Entruuidが必要ないことを除いて。指定されている場合、参照知識を保持する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の削除またはLDAPがエントリ自体に対して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のリターンの場合、Sync更新制御値のフィールドは次のように設定する必要があります。
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-誤った侵入に設定する必要があります - 結果をenterleftsetを去ったエントリのuuidに設定する必要があります - enterleftsetに設定する必要があります - 同期フェーズ中にfalseに設定する必要があります。-これが最初の結果が返された場合、または属性がスキームを変更した場合にのみ設定する必要があります - 上記のように - 上記のように
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のリターンは同じように見えますが、Entruuidが必要ないことを除いて。指定されている場合、参照知識を保持する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.
一部のサーバーの実装は、Tombstoneを使用して削除されたエントリを追跡しています。これは、削除されたエントリのすべてのデータではなく、状態を追跡する隠されたエントリです。この場合、墓石にはエントリの元の属性のすべてが含まれていない場合があるため、サーバーがクライアントの検索要求の属性に基づいて結果セットからエントリを削除する必要があるかどうかを判断することができない場合があります。サーバーは、削除されたエントリの属性に関する十分な情報を保持して、結果セットからエントリを削除するかどうかを判断する必要があります。これは不可能な場合があるため、サーバーは、クライアントの結果セットではない場合でも、結果が出ないようにエントリを返す場合があります。クライアントはこれらの通知を無視する必要があります。
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に設定されたエントリを返してはなりません。また、RETURNIEDのすべてのエントリは、Persisthaseフラグを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リクエストをいつ終了するか、Sync更新情報応答をSync Phaseとstavesで送信するタイミングを決定するために、サーバーの実装の裁量に任されています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]の制約の対象として返される場合は、動作属性を返す必要があります。サーバーが運用属性の同期をサポートしていない場合、サーバーはunwilltoperformの結果コードを使用してSeartResultDoneメッセージを返す必要があります。
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 Subentries [RFC3672]は、通常、検索リクエストによって返される場合は返品する必要があります。サーバーがLDAPサブエントリの同期をサポートせず、サーバーが検索リクエストからクライアントがLDAPサブエントリをリクエストするように要求したこと（たとえば、検索コントロールまたは検索フィルター）を決定できる場合、サーバーはresultCodeを使用してSeartResultDoneメッセージを返す必要がありますlunwilltoperformの。それ以外の場合、サーバーは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]の制約の対象として返される場合は、仮想属性を返す必要があります。サーバーが仮想属性の同期をサポートしていない場合、サーバーはlunwilltoperformの結果コードを使用してSeartResultDoneメッセージを返す必要があります。
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.
この結果の1つは、仮想属性の定義を変更して、クライアントの検索スコープの多くのエントリにその属性の値を変更するように変更する場合、これはサーバーがクライアントに多くのエントリを返す必要があることを意味することです。その1つの変更の結果。これが頻繁に発生することは予想されておらず、サーバーには、必要に応じてクライアントに再配置を強制するオプションがあります。
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検索中に、同期フェーズまたは永続フェーズのいずれかでいつでも、サーバーは、クライアントのデータのコピーを最終的な収束に持ち込むことができることを保証できないと判断します。lcupreloadrequiredの結果コードを備えたSearchResultdoneメッセージ。これは、クライアントが時代遅れまたは処理できない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.
また、サーバーは、クライアントがリロードを実行する方が効率的であると判断した場合、lcupreloadRequiredを返すこともできます。たとえば、あまりにも多くのエントリが変更され、単純なリロードがはるかに高速になる場合。
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.
サーバーがクライアントのリクエストの処理が正常に完了した場合、SearchResultDoneメッセージに同期実行制御を添付し、クライアントに送信します。ただし、SearchResultDoneメッセージに成功またはキャンセルされていない結果コードが含まれている場合、同期実行制御は省略される場合があります。LCUP Cookieは同期実行されたコントロール値でオプションですが、SeartResultDone resultCodeが成功またはキャンセルされている場合は設定する必要があります。また、結果コードがlcupresourcesexexed、timelimitex cuceed、sizelimitex cuceed、またはadminlimitex cuceedの場合、サーバーはCookieを設定する必要があります。これにより、クライアントは後でより簡単に再配置できます。LDAP検索エラー（例：不十分なアクセス権）またはLCUPエラー（例：lcupunsupportedsscheme）のいずれかであるエラーが発生した場合、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 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.
サーバーのリソースがタイトになると、サーバーは、lcupresourcesexexedの結果を得て、searchResultdoneメッセージをクライアントに送信することにより、1つ以上の検索操作を終了できます。サーバーは、Cookieセットで同期実行制御を添付する必要があります。サーバー側のポリシーは、終了する検索を決定するために使用されます。これは、悪意のあるアクションの疑いのあるクライアントを切断するためのセキュリティメカニズムとしても使用できますが、サーバーがクライアントが悪意があると推測できる場合、サーバーは代わりに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を送信する場合があります。サーバーは、これらの残りのメッセージをできるだけ少なく送信する必要があります。最後に、サーバーは、同期DONEコントロールが添付されたメッセージを送信します。検索がその時点までに成功した場合、SearchResultDoneメッセージの結果コードフィールドをキャンセル[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 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は、以下を除き、他のLDAPコントロールと組み合わせてこのドキュメントで定義されているコントロールを使用する能力についての制限も保証も定義していません。サーバーは、非批判的であり、他の重要なコントロールが供給されている場合、LCUP定義のコントロールを無視する場合があります。サーバーが別の重要なコントロールを使用して重要なLCUPコントロールを受信し、サーバーが両方のコントロールを同時にサポートしていない場合、サーバーは無バレーブクライティカルエクステンションを返す必要があります。
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.
サーバーがクライアントに送信されたエントリの順序を変更するソートやVLVなどのコントロールをサポートするかどうかを判断するのは、サーバーの実装次第です。ただし、Cookieは通常、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.
複製された環境で複数のDSAを備えたLCUP Cookieの使用は、LCUPで定義されていません。LCUPの実装は、LCUPコンテキストのレプリカを保持している別のDSAとのLCUPセッションの継続をサポートする場合があります。クライアントは、1つのDSAによって返されたCookieを別のDSAに送信できます。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 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.
LCUPクライアントは、標準のLDAP検索仕様を介して同期したいツリーの領域を指定するため、同期領域のルートが同期セッション間または同期セッション中に変更された場合、クライアントはNosuchobjectエラーを返すことができます。この条件が発生した場合、クライアントは、クライアントのローカルデータストアで保存されたルートのUUIDを使用して、ルートを見つけようとします。次に、新しい検索ベースを使用して同期リクエストを繰り返すことができます。一般に、クライアントはエントリの名前が変更されたことを検出し、DNベースのアドレス指定ではなくUUIDを使用して、受信した変更を適切なエントリに適用できます。
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]）を受け取ることができます。クライアントは、継続参照とそれらに関連付けられたCookieで返されるLDAP URLのキャッシュを維持する必要があります。クライアントは、参照に従うために別の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.
クライアントがlcupresourcesexexedまたはlcupsecurityviolation resultcodeを受信した場合、クライアントは別の操作を試みる前に少なくとも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をサポートする必要があります。Sync Updateコントロールでは、UUIDが必要です。さらに、サーバーの実装者は、エントリの属性として利用可能なエントリのUUID値を作成し、検索フィルターのUUID属性を使用してクライアントがエントリを検索できるようにインデックスまたはその他のメカニズムを提供する必要があります。SynCupDateコントロールは、サーバーがUUIDによるエントリの検索に使用する属性の名前またはOIDをサーバーに知らせるためのフィールドUUIDATTRIBUTEを提供します。
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準拠サーバーの合理的な実装は、Replica Update Vector（RUV）を使用することです。各マスターについて、RUVにはこのマスターから見られた最大のCSNが含まれています。さらに、一部のディレクトリサーバーによって実装されたRUV（まだLDUPではありません）には、レプリカの生成が含まれています。これは、レプリカのデータストアを識別する不透明な文字列です。レプリカの生成値は、レプリカのデータがリロードされるたびに変化します。レプリカの生成は、レプリカのデータがリロードされ、他のすべてのレプリカを再現する必要があることを、レプリケーション/同期ピアに信号を送ることを目的としています。RUVは、Cookieの3つの最も重要なプロパティを満たします。（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
サーバーは、1つ以上のLCUP Cookieスキームをサポートする場合があります。スキームは、RFCSとしてOIDとともに公開されることが予想されます。サーバーの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（s）が含まれている必要があります（ただし、サーバーの実装がDITを分割しています）。クライアントは、返されたLDAP URLを使用して別のLCUP検索を発行します。DITの各セクションには異なるCookie値が必要になる場合があるため、クライアントはキャッシュを維持し、異なるLDAP URL値を異なるCookieにマッピングする必要があります。Cookieが変更された場合、スキームも変更される可能性がありますが、Cookieスキームは特定のLCUPコンテキスト内で同じでなければなりません。
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の設計では、検索中のエイリアスの宣告に関連する問題を考慮しません。クライアントは、DerefaliaseをNeverderefaliaseまたは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.
Meta Directory Join Engineなどのクライアントは、複数の書き込み可能なデータストアを同期するように、各情報が単一の権威あるデータソースから来ている場合にのみ正しく機能します。複製された環境では、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によって登録されたいくつかの値がリストされています。[RFC3383]のセクション3.6で説明されているように、次のLDAP結果コードはIANAによって割り当てられています。
lcupResourcesExhausted 113 lcupSecurityViolation 114 lcupInvalidData 115 lcupUnsupportedScheme 116 lcupReloadRequired 117
lcupresourcesexexed 113 lcupsecurityviolation 114 lcupinvaliddata 115 lcupunsupportedscheme 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:
このドキュメントで定義されている3つのコントロールは、[RFC3383]のセクション3.2で説明されているように、LDAPプロトコルメカニズムとして登録されています。1つのOID、1.3.6.1.1.7は、[RFC3383]のセクション3.1で説明されているように、IANAによって割り当てられています。このドキュメントで定義されているコントロールのOIDは、IANAによって割り当てられたものから次のように導き出されます。
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 Sync Update Control 1.3.6.1.1.7.2 LCUP Sync Done Control 1.3.6.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 returned and MAY also provide specific access control mechanisms to control the use of the controls and extended operations defined in this document.
状況によっては、LDAPサーバーで発生する変更に関する情報の一般的な露出を防ぐことが重要かもしれません。したがって、このドキュメントで説明されているメカニズムを実装するサーバーは、返されたエントリのアクセス制御を実施する手段を提供する必要があり、また、このドキュメントで定義されているコントロールと拡張操作の使用を制御するための特定のアクセス制御メカニズムを提供する場合があります。
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、「Lightweight Directory Access Protocol（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。、「Internet Assigned Numbers Authority（IANA）Lightweight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 3383、2002年9月。
[RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Cancel Operation", RFC 3909, October 2004.
[RFC3909] Zeilenga、K。、「Lightweight Directory Access Protocol（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、「抽象的構文表記1（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、「Lightweight Directory Access Protocol（バージョン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、「Lightweight Directory Access Protocol（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プロトコルは、マークスミス、ゴードングッド、ティムハウズ、およびロブウェルトマンによって定義された永続的な検索変更通知メカニズムに一部基づいています。。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,
- 左セット：エントリは結果を残しました、
- 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.
残りの機能は、クライアントの検索仕様内にエントリがなくなり、クライアントがデータストアから関連データを削除できることをクライアントに示すため、特に便利です。皮肉なことに、この機能は、サーバーがクライアントの状態を追跡せず、クライアントとの同期セッションの間にどのエントリが範囲外に移動したかを伝える簡単な方法がないため、サーバーに実装するのが最も難しいです。クライアントがサーバーに接続されているときに発生する操作にこの機能を提供することによってのみ妥協することができます。変更タイプに関する決定は、履歴情報を必要とせずに変更のみに基づいて行うことができるため、これは簡単に達成できます。ただし、これにより、プロトコルに複雑さが加わります。
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.
この機能は、永続的な検索仕様に存在します。永続的な検索には、変更型の概念があります。クライアントは、どのタイプのアップデートがエントリを返しますか、およびオプションで、サーバーがそのエントリを返される原因となった変更のタイプで各エントリをタグ付けするかどうかを指定します。
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 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.
LCUPの場合、意図は部分的ではなく、完全な同期です。LCUP検索によって返される各エントリには、クライアントに関係する可能性のある変更に関連する変更があります。クライアントは、エントリが追加されたか、変更されたかどうかを判断するために、DNまたはUUIDによるエントリのローカルインデックスを持つ必要がある場合があります。Syncアップデートコントロールの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にサイズリミットフィールドを設定することにより、クライアントがサイズ制限を指定する手段を既に提供しています。粒度は同じではありませんが、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 W.カリビアンドライブサニーベール、カリフォルニア94089 USA
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 First Ave. Sunnyvale、CA 94089 USA
Phone: +1 408 349-6153
EMail: olgan@yahoo-inc.com
Mark Smith Pearl Crescent, LLC 447 Marlpool Drive Saline, MI 48176 USA
Mark Smith Pearl Crescent、LLC 447 Marlpool Drive Saline、MI 48176 USA
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 USA
Phone: +1 425 882-8080
EMail: jeffparh@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。