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)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content.
このドキュメントでは、LDAP（Lightweight Directory Access Protocol）のクライアントアップデートプロトコル（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.
- 異種データストアを同期しようとするアプリケーション。メタディレクトリアプリケーションは、例えば、定期的に、ディレクトリから変更されたエントリのリストを取得し、変更を構築し、海外のデータストアにそれらを適用します。
- 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
LCUP will work best if the following conditions are met:
以下の条件が満たされた場合LCUPが最適に動作します：
1) The server stores some degree of historical state or change information to reduce the amount of wire traffic required for incremental synchronizations. The optimal balance between server state and wire traffic varies amongst implementations and usage scenarios, and is therefore left in the hands of implementers.
1）サーバは、歴史的状態のある程度を格納または増分同期に必要なワイヤトラフィックの量を削減するための情報を変更します。サーバ状態とワイヤトラフィックの最適なバランスは、実装と使用シナリオ間で変化し、従って、実装者の手に残されます。
2) The client cannot be assumed to understand the physical information model (virtual attributes, operational attributes, subentries, etc.) implemented by the server. Optimizations would be possible if such assumptions could be made.
2）クライアントは、サーバによって実装される物理的な情報モデル（仮想属性、操作属性、サブエントリ、など）を理解すると仮定することはできません。そのような仮定を行うことができれば、最適化が可能です。
3) Meta data changes and renames and deletions of large subtrees are very infrequent. LCUP makes these assumptions in order to reduce client complexity required to deal with these special operations, though when they do occur they may result in a large number of incremental update messages or a full resync.
3）メタデータの変更と名前変更及び大サブツリーの削除は非常にまれです。彼らが発生したとき、彼らは、増分更新メッセージの数が多いか、完全再同期につながるかもしれませんがLCUPは、これらの特殊作戦に対処するために必要なクライアントの複雑さを軽減するために、これらの仮定を行います。
The following sections define the new elements required to use this protocol.
次のセクションでは、このプロトコルを使用するために必要な新しい要素を定義します。
Protocol elements are described using ASN.1 [X.680]. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC2251]. All ASN.1 in this document uses implicit tags.
プロトコル要素は、ASN.1 [X.680]を使用して記載されています。用語「BERエンコードは」要素は[RFC2251]のセクション5.1に詳述制約下基本符号化規則[X.690]を使用して符号化されるべきであることを意味します。この文書に記載されているすべてのASN.1は、暗黙的なタグを使用しています。
Distinguished names can change, so are therefore unreliable as identifiers. A Universally Unique Identifier (or UUID for short) MUST be used to uniquely identify entries used with LCUP. The UUID is part of the Sync Update control value (see below) returned with each search result. The server SHOULD provide the UUID as a single valued operational attribute of the entry (e.g., "entryUUID"). We RECOMMEND that the server provides a way to do efficient (i.e., indexed) searches for values of UUID, e.g., by using a search filter like (entryUUID=<some UUID value>) to quickly search for and retrieve an entry based on its UUID. Servers SHOULD use a UUID format as specified in [UUID]. The UUID used by LCUP is a value of the following ASN.1 type:
識別名は変更するので、そのための識別子として信頼性が低いことができます。汎用一意識別子（または略してUUID）が一意LCUPと共に使用されるエントリを識別するために使用されなければなりません。 UUIDは、同期更新制御値の一部である（下記参照）の各検索結果に返されます。サーバは、エントリ（例えば、「entryUUIDは」）の単一値オペレーショナル属性としてUUIDを提供すべきです。私たちは迅速に検索し、そのに基づいてエントリを取得するために（entryUUIDは= <一部のUUID値>）のような検索フィルタを使用することにより、例えば、サーバが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プロトコルは、サーバーのデータに対するクライアントのデータの状態を保持するためにクッキーを使用しています。各クッキーのフォーマットは独自にそのスキームによって識別されます。 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クッキー値のフォーマットを識別するOIDです。スキームOIDは、すべてのオブジェクト識別子として、与えられたクッキーのスキームのためのユニークでなければなりません。クッキーの値は不透明であってもよいし、LCUPクライアントに公開することができます。自分の価値を公開クッキースキームについては、ドキュメントの好ましい形態は、RFCです。一つ以上の基準値のフォーマットが露出して詳細に説明されているクッキーのスキームを追跡があるであろうことが期待されます。
The LCUP Cookie is a value of the following ASN.1 type:
LCUPクッキーは以下の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クッキー値の更なる用途は、以下に記載されています。
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コンテキストをサポートすることができます。例えば、二つの名前付けコンテキストを持つサーバーは、1つのネーミングコンテキストでLCUPをサポートしていますが、他のではないか、各名前付けコンテキスト内の別のLCUPクッキースキームをサポートすることができます。各LCUPコンテキストは、異なるクッキー方式を使用することができます。 LCUP検索はLCUPコンテキスト境界を越えることはありませんが、その代わり、現在検索、およびベースDNで新しいLCUPコンテキストのベースDNに設定されているものとしてLDAPのURLが同じホストとポートを指定して、のSearchResultReferenceメッセージを返します。クライアントは、そのLCUPコンテキストが異なるCookieを使用している場合、新しいベースDNを使用して別の検索、そしておそらく異なるクッキーを発行する責任があります。クライアントは、それに対応するクッキーにLDAPのURLのマッピングを維持する責任があります。
Implementations of this specification SHALL recognize the following additional resultCode values. The LDAP result code names and numbers defined in the following table have been assigned by IANA per RFC 3383 [RFC3383].
この仕様の実装は、以下の追加のresultCode値を認識しなければなりません。以下の表に定義された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
lcupResourcesExhausted（113）サーバはクライアントがlcupInvalidData（115）無効な方式やクッキーがクライアントによって供給された悪質な行為の疑いがあるリソースlcupSecurityViolation（114）のうち、実行されています
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）クッキー方式は、有効なOIDですがlcupReloadRequired（117）は、クライアントのデータを再初期化する必要があることを示し、このサーバーでサポートされていません。サーバーがクライアントを同期させるために十分な情報が含まれていない場合や、サーバーのデータは最後の同期セッション以降にリロードされた場合は、この理由は返されます
The uses of these codes are described below.
これらのコードの用途は、以下に記載されています。
The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2] where the controlType is the object identifier 1.3.6.1.1.7.1 and the controlValue, an OCTET STRING, contains a BER-encoded syncRequestControlValue.
同期リクエストコントロールcontrolTypeは、オブジェクト識別子1.3.6.1.1.7.1とcontrolValue、オクテット列であるLDAPコントロール[RFC2251、セクション4.1.2]は、BERエンコードsyncRequestControlValueを含んでいます。
syncRequestControlValue ::= SEQUENCE {
updateType ENUMERATED {
syncOnly (0),
syncAndPersist (1),
persistOnly (2) },
sendCookieInterval [0] INTEGER OPTIONAL,
scheme [1] LCUPScheme OPTIONAL,
cookie [2] LCUPCookie OPTIONAL
}
sendCookieInterval - the server SHOULD send the cookie back in the Sync Update control value (defined below) for every sendCookieInterval number of SearchResultEntry and SearchResultReference PDUs returned to the client. For example, if the value is 5, the server SHOULD send the cookie back in the Sync Update control value for every 5 search results returned to the client. If this value is absent, zero or less than zero, the server chooses the interval.
sendCookieIntervalは - のSearchResultEntryとのSearchResultReference PDUのすべてのsendCookieInterval数のために戻って（以下に定義）同期更新制御値でクッキーを送信するサーバは、クライアントに返します。値が5であれば、例えば、サーバがクライアントに戻されたすべての5件の検索結果をバック同期の更新制御値でクッキーを送るべきです。この値がゼロ、存在しないか、またはゼロ未満である場合、サーバは、間隔を選択します。
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.
同期更新コントロールcontrolTypeは、オブジェクト識別子1.3.6.1.1.7.2とcontrolValue、オクテット列であるLDAPコントロール[RFC2251、セクション4.1.2]は、BERエンコード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.
同期更新コントロールの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コントロールcontrolTypeオブジェクト識別子1.3.6.1.1.7.3でありcontrolValueはBERエンコードsyncDoneValueを含有する[RFC2251、セクション4.1.2]です。
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.
エラー条件がある場合、サーバーはすぐにエラーコードが設定resultCodeが持つSearchResultDoneメッセージを返さなければなりません。このテーブルには、それに対応する行動とのresultCodeに条件をマッピングします。
Condition Behavior or resultCode
条件の動作や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
Schemeは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ない、またはクッキーが無効である）であります
Server is running out of lcupResourcesExhausted resources
サーバーはlcupResourcesExhaustedリソースが不足しています
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
UPDATETYPEは - syncOnlyまたはsyncAndPersist sendCookieIntervalに設定しなければならない - スキームを設定されるかもしれ - 設定されるかもしれ - 設定された場合、サーバは、この指定されたスキームを使用するか、lcupUnsupportedSchemeを返さなければならない（上記参照） - 設定されていない場合、サーバはそれがサポートする任意のスキームを使用するかもしれ。クッキー - を設定してはいけません
If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
リクエストが成功した場合は、以下のセクション「LCUP検索レスポンス」で説明したように、クライアントが結果を受け取ります。
For an incremental or update synchronization, the fields of the Sync Request control MUST be specified as follows:
次のように増分または更新同期のために、同期要求制御のフィールドが指定する必要があります。
updateType - MUST be set to syncOnly or syncAndPersist sendCookieInterval - MAY be set scheme - MUST be set cookie - MUST be set
UPDATETYPEは - syncOnlyまたはsyncAndPersist sendCookieIntervalに設定しなければならない - スキームを設定されるかもしれ - クッキーを設定しなければならない - 設定しなければなりません。
The client SHOULD always use the latest cookie it received from the server.
クライアントは、常にそれが、サーバから受信した最新のクッキーを使用すべきです。
If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
リクエストが成功した場合は、以下のセクション「LCUP検索レスポンス」で説明したように、クライアントが結果を受け取ります。
For persistent only search request, the fields of the Sync Request MUST be specified as follows:
次のように永続的なだけで、検索要求の場合、同期要求のフィールドを指定する必要があります。
updateType - MUST be set to persistOnly sendCookieInterval - MAY be set scheme - MAY be set - if set, the server MUST use this specified scheme or return lcupUnsupportedScheme (see above) - if not set, the server MAY use any scheme it supports. cookie - MAY be set, but the server MUST ignore it
UPDATETYPEは - persistOnly sendCookieIntervalに設定しなければならない - スキームを設定されるかもしれ - 設定されるかもしれ - 設定された場合、サーバは、この指定されたスキームを使用するか、lcupUnsupportedSchemeを返さなければならない（上記参照） - 設定されていない場合、サーバはそれがサポートする任意の方式を使用することができます。クッキーは - に設定してもよいが、サーバーはそれを無視しなければなりません
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要求に応答して、サーバはSearchResultDone PDUに続いて、クライアントの仕様に合わせて、ゼロ以上のSearchResultEntryかのSearchResultReference PDUを返します。 [RFC2251セクション4.5]で指定された動作です。それぞれのSearchResultEntryかのSearchResultReference PDUはまた、返されたエントリのLCUP状態を記述する同期更新コントロールが含まれています。 SearchResultDone PDUは、同期の完了コントロールが含まれています。次のセクションでは、[RFC2251セクション4.5]に加えて、動作を指定します。
The server may use the Sync Update control to return information not related to a particular entry. It MAY do this at any time to return a cookie to the client, or to inform the client that the sync phase of a syncAndPersist search is complete and the persist phase has begun. It MAY do this during the persist phase even though no entry has changed that would have normally triggered a response. In order to do this, it is REQUIRED to return the following:
サーバーは、特定のエントリに関連しない情報を返すために、同期の更新コントロールを使用することができます。これは、クライアントにクッキーを返すために、いつでもこれを行うことができ、またはsyncAndPersist検索の同期フェーズが完了し、持続相が開始されたことをクライアントに通知します。これは、エントリが正常な応答を引き起こしたであろうと変わらなかったとしても存続期にこれを行うことができます。これを実行するためには、以下を返すことが必要です。
- A SearchResultEntry PDU with the objectName field set to the DN of the baseObject of the search request and with an empty attribute list.
- 検索要求のbaseObjectのDNに、空の属性リストを設定するObjectNameフィールドでのSearchResultEntry PDU。
- A Sync Update control value with the fields set to the following:
- 次のように設定されたフィールドを持つ同期更新制御値：
stateUpdate - MUST be set to TRUE entryUUID - SHOULD be set to the UUID of the baseObject of the search request entryLeftSet - MUST be set to FALSE persistPhase - MUST be FALSE if the search is in the sync phase of a request, and MUST be TRUE if the search is in the persist phase UUIDAttribute - SHOULD only be set if this is either the first result returned or if the attribute has changed scheme - MUST be set if the cookie is set and the cookie format has changed; otherwise, it MAY be omitted cookie - SHOULD be set
stateUpdateは - TRUE entryUUIDはに設定しなければなりません - 検索要求entryLeftSetのbaseObjectのUUIDに設定されてください - FALSE persistPhaseに設定しなければなりません - 検索要求の同期位相にある場合にFALSEでなければなりません、そして真でなければなりません検索が持続相UUIDAttributeにある場合 - これは最初の結果が返さまたは属性スキームを変更した場合のいずれかである場合にのみ設定する必要があります - クッキーが設定され、クッキーのフォーマットが変更された場合に設定されなければなりません。それ以外の場合は、クッキーを省略されるかもしれません - 設定されるべきである（SHOULD）
If the server merely wants to return a cookie to the client, it should return as above with the cookie field set.
サーバは単にクライアントにクッキーを返したい場合は、クッキーのフィールドセットで、上記のように返す必要があります。
During a syncAndPersist request, the server MUST return (as above) immediately after the last entry of the sync phase has been sent and before the first entry of the persist phase has been sent. In this case, the persistPhase field MUST be set to TRUE. This allows the client to know that the sync phase is complete and the persist phase is starting.
syncAndPersist要求中に、サーバは直ちに送信された同期位相の最後のエントリの後に及び持続相の最初のエントリが送信される前に（上記のように）返さなければなりません。この場合、persistPhaseフィールドがTrueに設定する必要があります。これは、クライアントが同期フェーズが完了し、・フェーズが開始されて存続することを知ることができます。
The cookie field of the Sync Update control value MAY be set in any returned result, during both the sync phase and the persist phase. The server should return the cookie to the client often enough for the client to resync in a reasonable period of time in case the search is disconnected or otherwise terminated. The sendCookieInterval field in the Sync Request control is a suggestion to the server of how often to return the cookie in the Sync Update control. The server SHOULD respect this value.
同期更新制御値のクッキーフィールドは、同期位相と持続段階の両方の間、任意の返された結果に設定されてもよいです。サーバーは、クライアントが検索が切断あるいは終了した場合には、時間の合理的な期間内に再同期するために十分な頻度でクライアントにクッキーを返す必要があります。同期要求コントロールのsendCookieIntervalフィールドは、同期の更新制御にクッキーを返す頻度のサーバーへの提案です。サーバーは、この値を尊重しなければなりません。
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.
クッキーが設定され、クッキーのフォーマットが変更された場合、同期更新制御値のスキームフィールドが設定されなければなりません。それ以外の場合は省略されるかもしれません。
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接続を信頼できない接続を有していてもよいです。これらのクライアントは、彼らが再接続する必要がある場合、彼らは多くの冗長なエントリを処理する必要がないようにクッキーが、同期の更新制御値に、多くの場合、返されることを保証することをお勧めします。これらのクライアントは、しかし、（でもすべてでクッキーを多分1.一部のクライアントは、限られた帯域幅の接続を有していてもよく、低い数値に同期要求制御値にsendCookieIntervalを設定する必要があり、非常に多くの場合、クッキーを受信したくないかもしれない、または常に）正常に完了した同期の完了コントロール値に戻って送信されます。これらのクライアントは、高い数値に同期要求制御値に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コンテキスト内のデータが変更されただけクッキーを返すことです。何も変わっていない場合、サーバーはおそらくクッキーを返さないことにより、いくつかの帯域幅を節約することができます。
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経由による追加されたエントリにすることができ、または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経由による追加されたエントリにすることができ、または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つ以上が変更された場合は、エントリを変更するために考慮しなければなりません。検索要求は「SNのUIDのcn」の属性を列挙され、そして変更されている「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.
これの逆は検索要求の属性リスト内の属性のどれもが、エントリの属性を変更されていない場合は、エントリを変更していると考えてはならないということです。検索要求は「SNのUIDのcn」の属性を列挙され、そしてたとえば、「CN」または「SN」または変更された「foo」という属性で設定したクライアントの検索結果のエントリ、およびなしがあります「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は - FALSE entryUUIDはに設定しなければなりません - エントリentryLeftSetのUUIDに設定しなければならない - FALSE persistPhaseに設定しなければなりません - 同期フェーズ中または真の場合ザ相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リターンがentryUUIDはが必要とされていないことを除いて、同じように見えます。それが指定されている場合、それは参照知識を保持するDSEのUUIDを含まなければなりません。
An entry SHOULD be returned as having left the result set under the following conditions:
エントリは、以下の条件で設定し、結果を残したとして返されるべきです。
- The request is an incremental synchronization during the sync phase and the entry has left the result set
- 要求が同期フェーズ中に増分同期であり、エントリは、結果セットを残しています
- The search is in the persist phase and the entry has left the result set
- 検索が持続相であり、エントリは、結果セットを残しています
- The entry has left the result set as a result of an LDAP Delete or LDAP Modify DN operation against the entry itself (i.e., not as a result of an operation against its parent or ancestor)
- エントリは、LDAPの結果として、結果セットを残した削除または変更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リターンのために、同期更新制御値のフィールドを設定する必要があります。
stateUpdate - MUST be set to FALSE entryUUID - MUST be set to the UUID of the entry that left the result set entryLeftSet - MUST be set to TRUE persistPhase - MUST be set to FALSE if during the sync phase or TRUE if during the persist phase UUIDAttribute - SHOULD only be set if this is either the first result returned or if the attribute has changed scheme - as above cookie - as above
stateUpdateが - FALSE entryUUIDはに設定しなければなりません - entryLeftSet結果セットを左エントリのUUIDに設定しなければならない - TRUE persistPhaseに設定しなければなりませんが - の間場合ザ相UUIDAttribute持続同期フェーズ中または真の場合にFALSEに設定しなければなりませんクッキー上記のように - - 上記のように - これは最初の結果が返されたいずれかの場合または属性がスキーマを変更された場合にのみ設定されるべきである（SHOULD）
The searchResultReference return will look the same, except that the entryUUID is not required. If it is specified, it MUST contain the UUID of the DSE holding the reference knowledge.
SearchResultReferenceリターンがentryUUIDはが必要とされていないことを除いて、同じように見えます。それが指定されている場合、それは参照知識を保持するDSEのUUIDを含まなければなりません。
Some server implementations keep track of deleted entries using a tombstone - a hidden entry that keeps track of the state, but not all of the data, of an entry that has been deleted. In this case, the tombstone may not contain all of the original attributes of the entry, and therefore it may be impossible for the server to determine if an entry should be removed from the result set based on the attributes in the client's search request. Servers SHOULD keep enough information about the attributes in the deleted entries to determine if an entry should be removed from the result set. Since this may not be possible, the server MAY return an entry as having left the result set even if it is not or never was in the client's result set. Clients MUST ignore these notifications.
削除されたエントリの、状態を追跡隠されたエントリではなく、すべてのデータの - 一部のサーバーの実装は、墓石を使用して削除されたエントリを追跡します。この場合は、墓石には、エントリの元の属性のすべてを含んでいないかもしれないので、それは、エントリがクライアントの検索要求に属性に基づいて、結果セットから削除するかどうかを決定するために、サーバーのためにできない場合があります。サーバは、エントリは、結果セットから削除するかどうかを決定するために削除されたエントリの属性に関する十分な情報を維持する必要があります。これが可能ではないかもしれないので、サーバは、クライアントの結果セットにしたではないか、決してされていても、結果セットを去ったとエントリが返されることがあります。クライアントは、これらの通知を無視しなければなりません。
The following sections describe special handling that may be required when returning results.
次のセクションでは、結果を返すときに必要とされる特別な処理を記述します。
During the persistent phase, the server SHOULD return the changed entries to the client as quickly as possible.
永続的なフェーズでは、サーバーは、可能な限り迅速にクライアントに変更したエントリを返すべきです。
During a sync phase, the server MUST NOT return any entries with the persistPhase flag set to TRUE, and during the persist phase, all entries returned MUST have the persistPhase flag set to TRUE. The server MUST NOT mix and match sync phase entries with persist phase entries. If there are any sync phase entries to return, they MUST be returned before any persist phase entries are returned.
同期のフェーズでは、サーバがTRUEに設定されpersistPhaseフラグですべてのエントリを返してはならない、との間に・フェーズを持続し、すべてのエントリがpersistPhaseフラグがTRUEに設定されていなければなら戻りました。サーバーは、位相のエントリを保持して同期位相エントリをミックスし、一致してはいけません。戻るには任意の同期位相エントリがある場合は任意の位相のエントリが返され存続する前に、彼らは返さなければなりません。
There may be updates to the entries in the result set of a sync phase search during the actual search operation. If the DSA is under a heavy update load, and it attempts to send all of those updated entries to the client in addition to the other updates it was already planning to send for the sync phase, the server may never get to the end of the sync phase. Therefore, it is left up to the discretion of the server implementation to decide when the client is "in sync" - that is, when to end a syncOnly request, or when to send the Sync Update Informational Response between the sync phase and the persist phase of a syncAndPersist request. The server MAY send the same entry multiple times during the sync phase if the entry changes during the sync phase.
実際の検索動作時の同期位相検索の結果セット内のエントリへの更新があるかもしれません。 DSAは、更新負荷があり、それはそれはすでに同期フェーズのために送信することを計画していた他の更新プログラムに加えて、クライアントにそれらの更新されたエントリのすべてを送信しようとした場合、サーバーは、年末に取得することはありませんあり同期フェーズ。 syncOnly要求を終了するときには、ある場合、またはシンク相との間で同期の更新情報応答を送信し、永続化する - したがって、クライアントが「同期」であるときを決定するために、サーバの実装の裁量に任されていますsyncAndPersist要求の段階。エントリが同期フェーズ中に変更された場合、サーバは同期のフェーズの間に同じエントリを複数回送るかもしれません。
A reasonable behavior is for the server to generate a cookie based on the server state at the time the client initiated the LCUP request, and only send entries up to that point during the sync phase. Entries updated after that point will be returned only during the persist phase of a syncAndPersist request, or only upon an incremental synchronization.
サーバは、クライアントがLCUP要求を開始した時点でのサーバーの状態に基づいてクッキーを生成し、唯一の同期フェーズの間に、その時点までのエントリを送信するための合理的な動作です。その時点の後に更新されたエントリのみ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]の制約を受けるとして返される場合は操作属性が返されます。サーバーは、操作属性の同期をサポートしていない場合、サーバーはunwillingToPerformのresultCodeがでSearchResultDoneメッセージを返さなければなりません。
LDAP Subentries [RFC3672] SHOULD be returned if they would normally be returned by the search request. If the server does not support syncing of LDAP Subentries, and the server can determine from the search request that the client has requested LDAP Subentries to be returned (e.g., search control or search filter), the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform. Otherwise, the server MAY simply omit returning LDAP Subentries.
彼らは通常、検索要求によって返される場合は、LDAPサブエントリ[RFC3672]は返されるべきです。サーバがLDAPサブエントリの同期をサポートしていないと、サーバは、クライアントが返されるLDAPサブエントリを要求した検索要求から判断することができる場合（例えば、検索制御や検索フィルタ）は、サーバはresultCodeがでSearchResultDoneメッセージを返さなければなりませんunwillingToPerformの。そうしないと、サーバは単に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]の制約を受けるとして返される場合、仮想属性が返されます。サーバーが仮想属性の同期をサポートしていない場合、サーバーはunwillingToPerformのresultCodeがでSearchResultDoneメッセージを返さなければなりません。
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を受信した場合、クライアントは、DN変更操作の結果である新しいDNを検索するためにentryUUIDはとUUIDAttributeを使用するかもしれません。
If at any time during an LCUP search, either during the sync phase or the persist phase, the server determines that it cannot guarantee that it can bring the client's copy of the data to eventual convergence, it SHOULD immediately terminate the LCUP search request and return a SearchResultDone message with a resultCode of lcupReloadRequired. This can also happen at the beginning of an incremental synchronization request, if the client presents a cookie that is out of date or otherwise unable to be processed. The client should then issue an initial synchronization request.
LCUP検索中の任意の時点であれば、いずれかの同期相または持続相の間に、サーバはそれが最終的な収束へのデータのクライアントのコピーをもたらすことができることを保証できないと判断し、それはすぐにLCUP検索要求とリターンを終了すべきですlcupReloadRequiredのresultCodeが持つSearchResultDoneメッセージ。クライアントが古くなったり、処理されるそうできないクッキーを提示した場合にも、増分同期要求の開始時に発生する可能性があります。次に、クライアントは、最初の同期要求を発行する必要があります。
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メッセージが成功またはキャンセルされないのresultCodeが含まれている場合は、同期完了制御を省略してもよいです。 LCUPクッキーが同期完了制御値のオプションですがSearchResultDone resultCodeが成功またはキャンセルされた場合、それを設定しなければなりません。 resultCodeはlcupResourcesExhausted、timeLimitExceeded、sizeLimitExceeded、またはadminLimitExceededであれば、サーバにもクッキーを設定する必要があります。これは、クライアントがより簡単に、後に再同期することができます。いくつかのエラーが発生した場合は、LDAP検索エラー（例えば、insufficientAccessRights）またはLCUPエラー（例えば、lcupUnsupportedScheme）のいずれかは、クッキーは省略されるかもしれません。クッキーが設定されている場合は、クッキーの形式が変更された場合、スキームは、それ以外の場合は省略されるかもしれません、また、設定しなければなりません。
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.
サーバーのリソースがタイトになっている場合、サーバーはlcupResourcesExhaustedのにresultCodeをクライアント（複数可）にSearchResultDoneメッセージを送信することにより、1つ以上の検索操作を終了することができます。サーバは、クッキーがセットされた同期の完了コントロールを添付してください。サーバー側のポリシーが終了するために検索するかを決定するために使用されます。また、これは悪質な行為の疑いがされているクライアントを切断するために、セキュリティ・メカニズムとして使用することができますが、サーバーがクライアントが悪質であると推測できる場合、サーバは代わりに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].
クライアントは、同期プロセスを終了する必要があり、それはそのデータの現在の状態を表すクッキーを取得したい場合は、LDAP操作[RFC3909]をキャンセル発行します。サーバーは、LDAPキャンセル応答[RFC3909]で即座に応答します。サーバーは簡単にその発信キューからそれらの検索結果を中止または削除することができない場合、サーバーは保留中のSearchResultEntryかのSearchResultReference PDUを送るかもしれません。サーバーは、可能な限りこれらの残りのメッセージの数として送るべきです。最後に、サーバは接続同期完了制御とメッセージSearchResultDoneを送信します。検索は、それまで成功した場合は、SearchResultDoneメッセージの結果コードフィールドは、[RFC3909]をキャンセルしなければならない、とクッキーは同期完了制御に設定しなければなりません。エラー条件が存在する場合、上記セクション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]で指定されるように大きさと時間制限をサポートしなければなりません。サーバーは操作が原因これらの条件に終了した場合、クッキーがクライアントに送り返されることを保証しなければなりません。
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定義されたコントロールを無視するかもしれません。サーバが別の重要な制御で重要なLCUPコントロールを受けて、サーバが同時に両方のコントロールをサポートしていない場合、サーバーはunavailableCriticalExtensionを返すべきです。
It is up to the server implementation to determine if the server supports controls such as the Sort or VLV or similar controls that change the order of the entries sent to the client. But note that it may be difficult or impossible for a server to perform an incremental synchronization in the presence of such controls, since the cookie will typically be based off a change number, or Change Sequence Number (CSN), or timestamp, or some criteria other than an alphabetical order.
これは、サーバーは、このようなソートまたはVLVまたはクライアントに送信されたエントリの順序を変更する同様のコントロールなどのコントロールをサポートしているかどうかを判断するために、サーバの実装次第です。しかし、サーバーは、このようなコントロールの存在下での増分同期を実行するためにクッキーは通常、変更番号、または変更シーケンス番号（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クッキーの使用はLCUPによって定義されていません。 LCUPの実装では、別のDSAがLCUPコンテキストのレプリカを保持してLCUPセッションの継続をサポートすることができます。クライアントは、別のDSAに1 DSAによって返されたクッキーを提出することができます。それは、クッキーは、彼らが認識またはないとされていない場合、適切な結果コードを返すために1であるかどうかを判断するために、サーバー次第です。
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.
同期セッションの後にサーバーから受信したクッキーはクッキーを生成した検索と同じ検索指定して使用する必要があります。一部のサーバーは、クッキーがクッキーを生成した検索よりも制限検索指定で使用できるようにすることができます。サーバーはクッキーをサポートしていない場合、それは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.
各アクティブ永続的な操作は、オープンなTCP接続がLDAPクライアントとそうでない場合は開いたままにされない可能性がありますLDAPサーバーとの間で維持されている必要があります。そのため、クライアントの実装は、非必須タスクのために永続的な操作を使用しないようにと、すぐに実用的なアイドルとして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).
検索要求があってもLCUPによって管理されないことがいくつかの異なるLCUPクッキーを必要とするかもしれないいくつかのDITの複数の部分をまたがる場合、クライアントは、継続基準（のSearchResultReference [RFC2251セクション4.5.3]）を受信することができます。クライアントは、継続参照で返されたLDAPのURLのキャッシュおよびそれに関連付けられたクッキーを維持する必要があります。クライアントは参照を追跡するために、別のLCUP検索を実行する責任がある、と（それがクッキーを持っている場合）、その参照のためのLDAPのURLに対応するクッキーを使用すべきです。
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.
クライアントがlcupResourcesExhaustedまたは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をサポートしなければなりません。 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.
設計により、プロトコルが複数のクッキースキームをサポートしています。これは、異なる実装が自分の環境に適用されるすべての情報を格納するの柔軟性を可能にすることです。 LDUP準拠のサーバーのための合理的な実装は、レプリカ更新ベクトル（RUV）を用いることであろう。各マスターのために、RUVがこのマスターから見た最大のCSNが含まれています。また、（LDUP状態ではありません）、いくつかのディレクトリサーバによって実装さRUVは、レプリカの生成が含まれています - レプリカのデータストアを識別し、不透明な文字列を。レプリカのデータがリロードされるたびにレプリカ生成値が変更されます。レプリカ生成は、レプリカのデータが再ロードされたことを複製/同期ピアを知らせるためのものであり、他のすべてのレプリカを再初期化する必要があること。 RUVは、クッキーの3つの最も重要な特性を満たす：（1）それは一意にクライアントのデータの状態を特定し、（2）複数のサーバと同期するために使用することができ、および（3）そのサーバのデータを検出するために使用することができますリロードされました。 RUVがクッキーとして使用されている場合は、最後に特定のマスターによって変更されたエントリは、その最後に変更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クッキースキームをサポートすることができます。スキームはRFCとして自分のOIDと一緒に公開されることが期待されます。サーバーのDITは、それらに関連したさまざまなクッキーを持っていることが異なるセクションに分割することができます。例えば、いくつかのサーバーが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（ただしサーバの実装はDITを分配している）の別の部分のベースのDN（単数または複数）を含まなければなりません返さ。次に、クライアントは、返されたLDAPのURLを使用して別のLCUP検索を発行します。クライアントが別のクッキーに異なるLDAP URL値をマッピングし、キャッシュを維持する必要がありますので、DITの各セクションでは、異なるクッキー値が必要な場合があります。クッキーが変更された場合、スキームは、同様に変更されることがありますが、クッキー方式は、与えられた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.
クッキーは、サーバがクッキーを安全に、それが接続されている検索指定で使用できるかどうかを判断できるようにするために十分な情報が含まれている必要があります。文書で先に述べたように、クッキーだけクッキーが生成されたものに等しい検索指定して使用する必要がありますが、一部のサーバーが使用されるものよりも制限され、検索仕様にクッキーを使用してサポートしてもよい（MAY）クッキーを生成します。
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のデザインは、検索で参照解除された別名に関連した問題を考慮していません。クライアントはneverDerefAliasesまたはderefFindingBaseObjのいずれかとしderefAliasesを指定しなければなりません。サーバーは、クライアントがderefInSearchingまたはderefAlwaysのいずれかを指定する場合はProtocolErrorを返すようにしています。
Clients, like a meta directory join engine, synchronizing multiple writable data stores, will only work correctly if each piece of information comes from a single authoritative data source. In a replicated environment, an LCUP Context should employ the same conflict resolution scheme across all its replicas. This is because different systems have different notions of time and different update resolution procedures. As a result, a change applied on one system can be discarded by the other, thus preventing the data stores from converging.
各情報は、単一の信頼できるデータソースから来ている場合は、複数の書き込み可能なデータストアを同期するメタディレクトリのようなクライアント、エンジンへの参加は、のみ正しく動作します。レプリケートされた環境では、LCUPコンテキストは、そのすべての複製で同じコンフリクト解決スキームを採用する必要があります。異なるシステムは、時間と異なる更新解決手続きの異なる概念を持っているためです。結果として、一つのシステムに適用される変化は、このように収束するからデータ・ストアを防止する、他によって廃棄することができます。
This document lists several values that have been registered by the IANA. The following LDAP result codes have been assigned by IANA as described in section 3.6 of [RFC3383]:
この文書は、IANAによって登録されているいくつかの値を示しています。 [RFC3383]のセクション3.6に記載されているように、次のLDAP結果コードは、IANAによって割り当てられています：
lcupResourcesExhausted 113 lcupSecurityViolation 114 lcupInvalidData 115 lcupUnsupportedScheme 116 lcupReloadRequired 117
lcupResourcesExhausted 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:
[RFC3383]のセクション3.2に記載されているように、この文書で定義された3つのコントロールは、LDAPプロトコルメカニズムとして登録されています。 [RFC3383]のセクション3.1で説明したように一のOID、1.3.6.1.1.7は、IANAによって割り当てられています。 IANAによって割り当てられたものから次のように本書で定義されたコントロールのOIDが導出されます。
LCUP Sync Request Control 1.3.6.1.1.7.1 LCUP Sync Update Control 1.3.6.1.1.7.2 LCUP Sync Done Control 1.3.6.1.1.7.3
LCUP同期要求制御1.3.6.1.1.7.1 LCUP Syncのアップデートコントロール1.3.6.1.1.7.2 LCUP Syncは、コントロールを完了1.3.6.1.1.7.3
In some situations, it may be important to prevent general exposure of information about changes that occur in an LDAP server. Therefore, servers that implement the mechanism described in this document SHOULD provide a means to enforce access control on the entries 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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3383] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 3383、2002年9月。
[RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Cancel Operation", RFC 3909, October 2004.
[RFC3909] Zeilenga、K.、 "LDAP（Lightweight Directory Access Protocol）の操作をキャンセル"、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]ストークス、E.、ワイザー、R.、堀、R.、およびR.ヒューバー、 "ライトウェイトディレクトリアクセスプロトコル（バージョン3）レプリケーションの要件"、RFC 3384、2002年10月。
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003.
[RFC3671] Zeilenga、K.、RFC 3671、2003年12月 "のLDAP（Lightweight Directory Access Protocol）におけるコレクティブ属性"。
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3672] Zeilenga、K.およびS.レッグ、RFC 3672 "のLDAP（Lightweight Directory Access Protocol）でサブエントリ"、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プロトコルはLDAPv3のは、マイケル・Armijoによって定義されたディレクトリ同期のためにマーク・ワールによって定義された検索コントロール、およびLDAPコントロールを契機に、マーク・スミス氏、ゴードン・グッド、ティムハウズ、およびロブWeltmanによって定義された持続検索変更通知メカニズムに基づいています。 IETF LDUPワーキンググループのメンバーはこのドキュメントへの重要な貢献をしました。
Appendix - Features Left Out of LCUP
付録 - LCUPの左アウトを備えています
There are several features present in other protocols or considered useful by clients that are currently not included in the protocol primarily because they are difficult to implement on the server. These features are briefly discussed in this section.
他のプロトコルに存在するか、彼らは、サーバー上で実装することは困難であるため、現在、主にプロトコルに含まれていないクライアントが有用であると考え、いくつかの機能があります。これらの機能は、簡単に、このセクションで説明されています。
Triggered Search Change Type
トリガ検索変更タイプ
This feature is present in the Triggered Search specification. A flag is attached to each entry returned to the client indicating the reason why this entry is returned. The possible reasons from the document are:
この機能は、トリガー検索仕様に存在しています。フラグは、このエントリが返された理由を示すクライアントに返された各エントリに取り付けられています。文書から考えられる理由は以下のとおりです。
- notChange: the entry existed in the directory and matched the search at the time the operation is being performed,
- notChange：エントリがディレクトリに存在し、操作が実行されている時に検索条件に一致します、
- enteredSet: the entry entered the result,
- enteredSet：エントリが結果を入力し、
- leftSet: the entry left the result,
- leftSet：エントリは、結果を残しました
- modified: the entry was part of the result set, was modified or renamed, and still is in the result set.
- 修飾：エントリは、結果セットの一部であった、変更または改名、さらに結果セットになるました。
The leftSet feature is particularly useful because it indicates to the client that an entry is no longer within the client's search specification and the client can remove the associated data from its data store. Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. A compromise could be reached by only providing this feature for the operations that occur while the client is connected to the server. This is easier to accomplish because the decision about the change type can be made based only on the change without need for any historical information. This, however, would add complexity to the protocol.
それはエントリはもはやクライアントの検索仕様内でクライアントに通知し、クライアントがそのデータストアから関連するデータを削除することができますので、leftSet機能は特に便利です。皮肉なことに、この機能は、サーバーがクライアントの状態を追跡し、エントリがクライアントとの同期セッション間の範囲の外に移動占いの簡単な方法を持っていないしていないため、サーバー上で実装する最も困難です。妥協は、クライアントがサーバに接続している間に発生する操作のために、この機能を提供することによって到達することができます。変更タイプについての決定は、任意の履歴情報を必要とせずに唯一の変化に基づいて行うことができるので、これは達成することが容易です。これは、しかし、プロトコルに複雑さを追加します。
Persistent Search Change Type
持続検索変更タイプ
This feature is present in the Persistent Search specification. Persistent search has the notion of changeTypes. The client specifies which type of updates will cause entries to be returned, and optionally whether the server tags each returned entry with the type of change that caused that entry to be returned.
この機能は、持続検索仕様に存在しています。永続的な検索がchangeTypesの概念を持っています。クライアントは、エントリが返され、必要に応じてサーバーのタグかどうか、そのエントリの原因となった変更の種類と、それぞれ返されたエントリが返されることになります更新の種類を指定します。
For LCUP, the intention is full synchronization, not partial. Each entry returned by an LCUP search will have some change associated with it that may concern the client. The client may have to have a 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によってエントリのローカル索引を持っていてもよいです。同期の更新制御の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.
いくつかの以前の同期プロトコルは、クライアント（複数可）エントリ全体ではなく、エントリの唯一の変更された属性を送りました。このアプローチは大幅にクライアントに返されるデータの量を減らすことができますが、それにはいくつかの欠点があります。まず、（上述の変化型のような）別のメカニズムがない限りデータの不完全なバージョンを有するクライアントをもたらすことができる唯一の変更を送信し、検索範囲内に移動するエントリについてクライアントに通知するために使用されます。例を考えてみましょう。エントリの属性が変更されます。変更の結果、エントリがクライアントの検索の範囲に入ります。変更のみが送信される場合、クライアントは、エントリの初期データを見ることはないでしょう。第二に、この機能は、サーバーが単独で、サーバの状態に基づいて変更し、クライアントのクッキーを構築するための十分な情報が含まれていない可能性がありますので、実装するのは困難です。一方、この機能を容易にクライアントがデータの以前のバージョンを持っており、値の比較により値を実行することができると仮定すると、クライアントによって実現することができます。
Data Size Limits
データサイズの制限
Some earlier synchronization protocols allowed clients to control the amount of data sent to them in the search response. This feature was intended to allow clients with limited resources to process synchronization data in batches. However, an LDAP search operation already provides the means for the client to specify the size limit by setting the sizeLimit field in the SearchRequest to the maximum number of entries the client is willing to receive. While the granularity is not the same, the assumption is that regular LDAP clients that can deal with the limitations of the LDAP protocol will implement LCUP.
いくつかの以前の同期プロトコルは、クライアントが検索応答でそれらに送られたデータの量を制御することができました。この機能は、限られたリソースで、クライアントがバッチで同期データを処理できるようにすることを意図していました。しかし、LDAP検索操作はすでにクライアントが受け取るために喜んでエントリの最大数にSearchRequestにSIZELIMITフィールドを設定することで、サイズ制限を指定するには、クライアントのための手段を提供します。粒度が同じではありませんが、仮定は、LDAPプロトコルの制限に対処することができ、通常のLDAPクライアントがLCUPを実施することです。
Data Ordering
データの順序
Some earlier synchronization protocols allowed a client to specify that parent entries should be sent before the children for add operations and children entries sent before their parents during delete operations. This ordering helps clients to maintain a hierarchical view of the data in their data store. While possibly useful, this feature is relatively hard to implement and is expensive to perform.
いくつかの以前の同期プロトコルは、クライアントが操作や子供の削除操作中に、両親の前に送られたエントリを追加するために、親エントリは子供の前に送られるべきであることを指定することができました。この順序は、クライアントが自分のデータストア内のデータの階層ビューを維持するのに役立ちます。おそらく有用であるが、この機能は実装するのが比較的困難であるとを実行するには高価です。
Authors' Addresses
著者のアドレス
Rich Megginson Netscape Communications Corp., an America Online company. 360 W. Caribbean Drive Sunnyvale, CA 94089 USA
リッチMegginson氏ネットスケープ・コミュニケーションズ社、アメリカ・オンライン会社。 360 W.カリブ海ドライブサニーベール、CA 94089 USA
Phone: +1 505 797-7762 EMail: rmegginson0224@aol.com
電話：+1 505 797-7762 Eメール：rmegginson0224@aol.com
Olga Natkovich Yahoo, Inc. 701 First Ave. Sunnyvale, CA 94089 USA
オルガNatkovichヤフー株式会社701ファーストアベニュー。サニーベール、CA 94089 USA
Phone: +1 408 349-6153 EMail: olgan@yahoo-inc.com
電話：+1 408 349-6153 Eメール：olgan@yahoo-inc.com
Mark Smith Pearl Crescent, LLC 447 Marlpool Drive Saline, MI 48176 USA
マーク・スミスパールクレセント、LLC 447 Marlpoolドライブ生理食塩水、MI 48176 USA
Phone: +1 734 944-2856 EMail: mcs@pearlcrescent.com
電話：+1 734 944-2856 Eメール：mcs@pearlcrescent.com
Jeff Parham Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
ジェフ・パラムマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399 USA
Phone: +1 425 882-8080 EMail: jeffparh@microsoft.com
電話：+1 425 882-8080 Eメール：jeffparh@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、www.rfc-editor.orgで、そこに記載される場合を除き、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。