Network Working Group K. Zeilenga
Request for Comments: 4533 OpenLDAP Foundation
Category: Experimental J.H. Choi
IBM Corporation
June 2006
The Lightweight Directory Access Protocol (LDAP)
Content Synchronization Operation
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
IESG Note
IESG注意
The IESG notes that this work was originally discussed in the LDUP working group. The group came to consensus on a different approach, documented in RFC 3928; that document is on the standards track and should be reviewed by those considering implementation of this proposal.
IESGは、この作品は元々LDUPワーキンググループで議論されたことを指摘しています。グループは、RFC 3928で文書化、異なるアプローチに合意に来ました。その文書には、標準化過程の上で、この提案の実施を考慮することにより、これら見直されるべきです。
Abstract
抽象
This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation.
この仕様は、LDAP（Lightweight Directory Access Protocol）の内容の同期操作を説明します。操作は、クライアントがディレクトリ情報ツリー（DIT）のフラグメントのコピーを維持することができます。これは、変更のためのポーリングし、変更のためのリスニングの両方をサポートしています。操作は、LDAP検索操作の拡張として定義されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Intended Usage .............................................4
1.3. Overview ...................................................5
1.4. Conventions ................................................8
2. Elements of the Sync Operation ..................................8
2.1. Common ASN.1 Elements ......................................9
2.2. Sync Request Control .......................................9
2.3. Sync State Control ........................................10
2.4. Sync Done Control .........................................10
2.5. Sync Info Message .........................................11
2.6. Sync Result Codes .........................................11
3. Content Synchronization ........................................11
3.1. Synchronization Session ...................................12
3.2. Content Determination .....................................12
3.3. refreshOnly Mode ..........................................13
3.4. refreshAndPersist Mode ....................................16
3.5. Search Request Parameters .................................17
3.6. objectName ................................................18
3.7. Canceling the Sync Operation ..............................19
3.8. Refresh Required ..........................................19
3.9. Chattiness Considerations .................................20
3.10. Operation Multiplexing ...................................21
4. Meta Information Considerations ................................22
4.1. Entry DN ..................................................22
4.2. Operational Attributes ....................................22
4.3. Collective Attributes .....................................23
4.4. Access and Other Administrative Controls ..................23
5. Interaction with Other Controls ................................23
5.1. ManageDsaIT Control .......................................24
5.2. Subentries Control ........................................24
6. Shadowing Considerations .......................................24
7. Security Considerations ........................................25
8. IANA Considerations ............................................26
8.1. Object Identifier .........................................26
8.2. LDAP Protocol Mechanism ...................................26
8.3. LDAP Result Codes .........................................26
9. Acknowledgements ...............................................26
10. Normative References ..........................................27
11. Informative References ........................................28
Appendix A. CSN-based Implementation Considerations ..............29
The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a mechanism, the search operation [RFC4511], that allows a client to request directory content matching a complex set of assertions and to request that the server return this content, subject to access control and other restrictions, to the client. However, LDAP does not provide (despite the introduction of numerous extensions in this area) an effective and efficient mechanism for maintaining synchronized copies of directory content. This document introduces a new mechanism specifically designed to meet the content synchronization requirements of sophisticated directory applications.
ライトウェイトディレクトリアクセスプロトコル（LDAP）[RFC4510]コントロールにアクセスする対象、アサーションの複雑なセットに一致する要求ディレクトリのコンテンツにクライアントを可能にし、サーバがこのコンテンツを返すことを要求するためのメカニズム、検索操作[RFC4511]を提供し、そして他の制限、クライアントへ。しかし、LDAPディレクトリのコンテンツの同期コピーを維持するための効果的かつ効率的なメカニズム（この分野で数多くの拡張機能の導入にもかかわらず）提供していません。この文書では、特に洗練されたディレクトリアプリケーションのコンテンツの同期要件を満たすように設計された新しいメカニズムを導入しています。
This document defines the LDAP Content Synchronization Operation, or Sync Operation for short, which allows a client to maintain a synchronized copy of a fragment of a Directory Information Tree (DIT). The Sync Operation is defined as a set of controls and other protocol elements that extend the Search Operation.
この文書では、クライアントがディレクトリ情報ツリー（DIT）のフラグメントの同期コピーを維持することを可能にする、略してLDAP内容同期操作、または同期操作を定義します。同期動作を制御し、検索操作を拡張する他のプロトコル要素の集合として定義されます。
Over the years, a number of content synchronization approaches have been suggested for use in LDAP directory services. These approaches are inadequate for one or more of the following reasons:
長年にわたり、コンテンツの同期のアプローチの数は、LDAPディレクトリサービスで使用するために提案されています。これらのアプローチは、次の理由の一つ以上には不十分です。
- failure to ensure a reasonable level of convergence;
- 障害は、収束の妥当なレベルを確保します。
- failure to detect that convergence cannot be achieved (without reload);
- その収束を検出するための失敗は（リロードなしに）達成することができません。
- require pre-arranged synchronization agreements;
- 事前配置同期アグリーメントを必要とします。
- require the server to maintain histories of past changes to DIT content and/or meta information;
- DITの内容および/またはメタ情報への過去の変更の履歴を維持するために、サーバーを必要とします。
- require the server to maintain synchronization state on a per-client basis; and/or
- クライアントごとに同期状態を維持するために、サーバーを必要とします。および/または
- are overly chatty.
- 過度におしゃべりしています。
The Sync Operation provides eventual convergence of synchronized content when possible and, when not, notification that a full reload is required.
同期操作は、完全なリロードが必要とされる同期コンテンツ可能な場合と、しない、通知の最終的な収束を提供します。
The Sync Operation does not require pre-arranged synchronization agreements.
同期操作は、事前に配置された同期の契約を必要としません。
The Sync Operation does not require that servers maintain or use any history of past changes to the DIT or to meta information. However, servers may maintain and use histories (e.g., change logs, tombstones, DIT snapshots) to reduce the number of messages generated and to reduce their size. As it is not always feasible to maintain and use histories, the operation may be implemented using purely (current) state-based approaches. The Sync Operation allows use of either the state-based approach or the history-based approach on an operation-by-operation basis to balance the size of history and the amount of traffic. The Sync Operation also allows the combined use of the state-based and the history-based approaches.
同期操作は、サーバが維持またはDITまたはメタ情報への過去の変更のいずれかの履歴を使用する必要はありません。ただし、サーバーは、生成されたメッセージの数を減らすために、そのサイズを縮小する履歴（例えば、変更ログ、墓石、DITのスナップショット）を維持して使用することができます。それは常に維持し、履歴を使用することは不可能であるように、動作は純粋に（現在の）状態ベースのアプローチを使用して実施することができます。同期操作は、状態ベースのアプローチまたは履歴のサイズおよびトラフィックの量をバランスさせる操作による操作に基づいて、履歴ベースのアプローチのいずれかを使用することができます。同期操作はまた、状態ベースと履歴ベースのアプローチの併用を可能にします。
The Sync Operation does not require that servers maintain synchronization state on a per-client basis. However, servers may maintain and use per-client state information to reduce the number of messages generated and the size of such messages.
同期操作は、サーバーがクライアントごとに同期状態を維持する必要はありません。ただし、サーバーは、生成されたメッセージの数と、このようなメッセージのサイズを小さくするクライアントごとの状態情報を保持して使用することができます。
A synchronization mechanism can be considered overly chatty when synchronization traffic is not reasonably bounded. The Sync Operation traffic is bounded by the size of updated (or new) entries and the number of unchanged entries in the content. The operation is designed to avoid full content exchanges, even when the history information available to the server is insufficient to determine the client's state. The operation is also designed to avoid transmission of out-of-content history information, as its size is not bounded by the content and it is not always feasible to transmit such history information due to security reasons.
同期トラフィックを合理的に制限されていない場合、同期機構が過度におしゃべり考えることができます。同期操作のトラフィックが更新（または新規）エントリの大きさや内容の変わらないエントリの数によって制限されます。操作は、サーバーが利用可能な履歴情報は、クライアントの状態を判断するには不十分である場合でも、完全なコンテンツの交換を回避するように設計されています。操作は、そのサイズは、コンテンツによって制限されていないとしても、外のコンテンツ履歴情報の送信を回避するように設計されており、セキュリティ上の理由から、このような履歴情報を送信するために、常に可能ではありません。
This document includes a number of non-normative appendices providing additional information to server implementors.
この文書では、サーバーの実装者に追加情報を提供する非規範的な付録が多数含まれています。
The Sync Operation is intended to be used in applications requiring eventually-convergent content synchronization. Upon completion of each synchronization stage of the operation, all information to construct a synchronized client copy of the content has been provided to the client or the client has been notified that a complete content reload is necessary. Except for transient inconsistencies due to concurrent operation (or other) processing at the server, the client copy is an accurate reflection of the content held by the server. Transient inconsistencies will be resolved by subsequent synchronization operations.
同期操作は、最終的に、収束コンテンツの同期を必要とする用途に使用されることが意図されます。操作の各同期段階の完了時に、コンテンツの同期クライアントコピーを構築するためのすべての情報がクライアントに提供されているか、クライアントが完全なコンテンツのリロードが必要であることを通知されています。サーバーでの同時動作（または他の）処理に起因する過渡的矛盾を除いて、クライアントコピーは、サーバが保有するコンテンツを正確に反映しています。過渡矛盾は、後続の同期操作によって解決されます。
Possible uses include the following:
可能な用途は次のとおりです。
- White page service applications may use the Sync Operation to maintain a current copy of a DIT fragment, for example, a mail user agent that uses the sync operation to maintain a local copy of an enterprise address book.
- ホワイトページサービスアプリケーションは、例えば、DITフラグメントの現在のコピーを維持するために、企業のアドレス帳のローカルコピーを維持するために同期操作を使用してメールユーザエージェントを同期操作を使用することができます。
- Meta-information engines may use the Sync Operation to maintain a copy of a DIT fragment.
- メタ情報エンジンはDITの断片のコピーを維持するために同期操作を使用してもよいです。
- Caching proxy services may use the Sync Operation to maintain a coherent content cache.
- キャッシュプロキシサービスは、コヒーレントコンテンツキャッシュを維持するために同期操作を使用することができます。
- Lightweight master-slave replication between heterogeneous directory servers. For example, the Sync Operation can be used by a slave server to maintain a shadow copy of a DIT fragment. (Note: The International Telephone Union (ITU) has defined the X.500 Directory [X.500] Information Shadowing Protocol (DISP) [X.525], which may be used for master-slave replication between directory servers. Other experimental LDAP replication protocols also exist.)
- 異種のディレクトリサーバ間の軽量マスタースレーブのレプリケーション。例えば、同期操作は、DIT断片のシャドウコピーを維持するために、スレーブ・サーバで使用することができます。 （注：国際電話連合（ITU）は、ディレクトリ・サーバー間のマスタースレーブレプリケーションのために使用することができるX.500ディレクトリ[X.500]インフォメーションシャドウプロトコル（DISP）[X.525]を、定義された他の実験LDAP。レプリケーションプロトコルも存在します。）
This protocol is not intended to be used in applications requiring transactional data consistency.
このプロトコルは、トランザクションデータの一貫性を必要とする用途に使用されるものではありません。
As this protocol transfers all visible values of entries belonging to the content upon change instead of change deltas, this protocol is not appropriate for bandwidth-challenged applications or deployments.
このプロトコルではなく、変更デルタの変化時にコンテンツに属するエントリのすべての可視値を転送するように、このプロトコルは、帯域幅チャレンジアプリケーションまたは展開のために適切ではありません。
This section provides an overview of basic ways the Sync Operation can be used to maintain a synchronized client copy of a DIT fragment.
このセクションでは、同期操作はDITの断片の同期化されたクライアントのコピーを維持するために使用することができる基本的な方法の概要を説明します。
- Polling for changes: refreshOnly mode
- 変更のためのポーリング：のrefreshOnlyモード
- Listening for changes: refreshAndPersist mode
- 変更のためのリスニング：refreshAndPersistモード
To obtain its initial client copy, the client issues a Sync request: a search request with the Sync Request Control with mode set to refreshOnly. The server, much like it would with a normal search operation, returns (subject to access controls and other restrictions) the content matching the search criteria (baseObject, scope, filter, attributes). Additionally, with each entry returned, the server provides a Sync State Control indicating state add. This control contains the Universally Unique Identifier (UUID) [UUID] of
refreshOnlyに設定したモードと同期要求制御と検索要求：その最初のクライアントのコピーを入手するには、クライアントが同期要求を発行します。サーバ、はるかにそれが通常の検索操作の場合と同様に、戻る（アクセス制御及びその他の制限を受ける）検索条件（baseObject、スコープ、フィルター、属性）を一致コンテンツ。また、各エントリには、サーバ状態の追加を示す同期状態制御を提供し、返さ。この制御は、汎用一意識別子（UUID）[UUID]のが含まれています
the entry [RFC4530]. Unlike the Distinguished Name (DN), which may change over time, an entry's UUID is stable. The initial content is followed by a SearchResultDone with a Sync Done Control. The Sync Done Control provides a syncCookie. The syncCookie represents session state.
エントリー[RFC4530]。経時的に変化することができる識別名（DN）とは異なり、エントリのUUIDは安定です。初期の内容は、コントロール完了SyncでSearchResultDoneが続いています。同期完了コントロールはsyncCookieを提供します。 syncCookieは、セッション状態を表しています。
To poll for updates to the client copy, the client reissues the Sync Operation with the syncCookie previously returned. The server, much as it would with a normal search operation, determines which content would be returned as if the operation were a normal search operation. However, using the syncCookie as an indicator of what content the client was sent previously, the server sends copies of entries that have changed with a Sync State Control indicating state add. For each changed entry, all (modified or unmodified) attributes belonging to the content are sent.
クライアントコピーの更新のためにポーリングするために、クライアントは以前に返さsyncCookieで同期操作を再発行します。 、それは通常の検索動作と同じように、多くのサーバが動作が正常検索操作であるかのように返されるであろう内容を決定します。しかし、クライアントが以前に送信されたどのようなコンテンツの指標としてsyncCookieを使用して、サーバーが同期ステートコントロールを示す状態の追加と変更されているエントリのコピーを送信します。各エントリを変更するために、コンテンツに属するすべての（修飾または未修飾の）属性が送信されます。
The server may perform either or both of the two distinct synchronization phases that are distinguished by how to synchronize entries deleted from the content: the present and the delete phases. When the server uses a single phase for the refresh stage, each phase is marked as ended by a SearchResultDone with a Sync Done Control. A present phase is identified by a FALSE refreshDeletes value in the Sync Done Control. A delete phase is identified by a TRUE refreshDeletes value. The present phase may be followed by a delete phase. The two phases are delimited by a refreshPresent Sync Info Message having a FALSE refreshDone value. In the case that both the phases are used, the present phase is used to bring the client copy up to the state at which the subsequent delete phase can begin.
現在、削除相：サーバは、コンテンツから削除されたエントリを同期化する方法によって区別される2つの別個の同期相のいずれかまたは両方を実行することができます。サーバはリフレッシュ段の単相を使用する場合コントロール完了SyncでSearchResultDoneで終わるよう、各フェーズがマークされます。本段階は、コントロール完了SyncでFALSE refreshDeletes値によって識別されます。削除フェーズは、TRUE refreshDeletes値によって識別されます。本段階は、削除フェーズが続いてもよいです。二相をrefreshPresent同期情報メッセージがFALSE refreshDoneの値を持つことによって区切られています。相の両方が使用される場合には、本相は、後続の削除フェーズを開始することができた時の状態までのクライアントのコピーを持参するために使用されます。
In the present phase, the server sends an empty entry (i.e., no attributes) with a Sync State Control indicating state present for each unchanged entry.
本段階では、サーバは、各不変のエントリの現在の状態を示す同期状態制御と空きエントリ（すなわち、属性なし）を送信します。
The delete phase may be used when the server can reliably determine which entries in the prior client copy are no longer present in the content and the number of such entries is less than or equal to the number of unchanged entries. In the delete mode, the server sends an empty entry with a Sync State Control indicating state delete for each entry that is no longer in the content, instead of returning an empty entry with state present for each present entry.
確実前クライアントコピーのエントリを決定することができるサーバがもはやコンテンツ中に存在し、そのようなエントリの数が変化しないエントリの数以下である場合、削除相を用いなくてもよいです。削除モードでは、サーバは、状態が代わりにそれぞれ本エントリの現在の状態と、空のエントリを返す、もはやコンテンツ内の各エントリに対して、削除指示の同期状態制御と空きエントリを送信します。
The server may send syncIdSet Sync Info Messages containing the set of UUIDs of either unchanged present entries or deleted entries, instead of sending multiple individual messages. If refreshDeletes of syncIdSet is set to FALSE, the UUIDs of unchanged present entries are contained in the syncUUIDs set; if refreshDeletes of syncIdSet is set to TRUE, the UUIDs of the entries no longer present in the content are contained in the syncUUIDs set. An optional cookie can be included in the syncIdSet to represent the state of the content after synchronizing the presence or the absence of the entries contained in the syncUUIDs set.
サーバーではなく、複数の個々のメッセージを送信する、そのまま現在のエントリまたは削除されたエントリのいずれかののUUIDのセットを含むのsyncIdSet同期情報メッセージを送信することができます。 syncIdSetのrefreshDeletesがFALSEに設定されている場合は、不変本エントリのUUIDが設定syncUUIDsに含まれています。 syncIdSetのrefreshDeletesがTRUEに設定されている場合、コンテンツ中にもはや存在しないエントリのUUIDが設定syncUUIDsに含まれています。任意クッキーが存在またはsyncUUIDsセットに含まれているエントリが存在しないことを同期した後、コンテンツの状態を表すためのsyncIdSetに含めることができます。
The synchronized copy of the DIT fragment is constructed by the client.
DITの断片の同期化されたコピーは、クライアントから構成されています。
If refreshDeletes of syncDoneValue is FALSE, the new copy includes all changed entries returned by the reissued Sync Operation, as well as all unchanged entries identified as being present by the reissued Sync Operation, but whose content is provided by the previous Sync Operation. The unchanged entries not identified as being present are deleted from the client content. They had been either deleted, moved, or otherwise scoped-out from the content.
syncDoneValueのrefreshDeletesがFALSEの場合、新しいコピーが再発行された同期操作によって返されたすべての変更されたエントリだけでなく、再発行同期操作によって存在していると識別されたすべての未変更のエントリが含まれていますが、その内容は前回の同期処理によって提供されます。存在するものとして同定されていない未変更のエントリは、クライアントのコンテンツから削除されます。彼らは、削除、移動、または内容からそうでない場合はスコープアウトされていたのいずれか。
If refreshDeletes of syncDoneValue is TRUE, the new copy includes all changed entries returned by the reissued Sync Operation, as well as all other entries of the previous copy except for those that are identified as having been deleted from the content.
syncDoneValueのrefreshDeletesがTRUEの場合、新しいコピーが再発行された同期操作によって返されたすべての変更されたエントリだけでなく、コンテンツから削除されたものとして識別されているものを除き、前のコピーの他のすべてのエントリが含まれています。
The client can, at some later time, re-poll for changes to this synchronized client copy.
クライアントは、いくつかの後の時点で、再投票をすることができ、この同期クライアントコピーへの変更のために。
Polling for changes can be expensive in terms of server, client, and network resources. The refreshAndPersist mode allows for active updates of changed entries in the content.
変更のポーリングは、サーバー、クライアント、およびネットワークリソースの面で高価になることができます。 refreshAndPersistモードは、コンテンツにおける変更のエントリのアクティブなアップデートが可能になります。
By selecting the refreshAndPersist mode, the client requests that the server send updates of entries that are changed after the initial refresh content is determined. Instead of sending a SearchResultDone Message as in polling, the server sends a Sync Info Message to the client indicating that the refresh stage is complete and then enters the persist stage. After receipt of this Sync Info Message, the client will construct a synchronized copy as described in Section 1.3.1.
refreshAndPersistモードを選択することで、クライアントは、サーバが最初のリフレッシュコンテンツが決定された後に変更されたエントリの更新を送信することを要求します。代わりに、ポーリングのようにSearchResultDoneメッセージを送信すると、サーバーは、リフレッシュ段階が完了したことを示すクライアントに同期情報メッセージを送信し、持続段階に入ります。第1.3.1項で説明したように、この同期情報メッセージを受信した後、クライアントが同期コピーを構築します。
The server may then send change notifications as the result of the original Sync search request, which now remains persistent in the server. For entries to be added to the returned content, the server sends a SearchResultEntry (with attributes) with a Sync State Control indicating state add. For entries to be deleted from the content, the server sends a SearchResultEntry containing no attributes and a Sync State Control indicating state delete. For entries to be modified in the return content, the server sends a SearchResultEntry (with attributes) with a Sync State Control indicating state modify.
その後、サーバーは、今サーバーで永続的なまま、元の同期検索要求の結果として変更通知を送信することができます。エントリが返されたコンテンツに付加されるためには、サーバが同期ステートコントロール示す状態アドオンと（属性付き）のSearchResultEntryを送信します。エントリは、コンテンツから削除されるためには、サーバーには属性と状態が削除を示す同期ステートコントロールを含んでいないのSearchResultEntryを送信します。エントリはリターンコンテンツに変更するために、サーバは、状態変更を示す同期状態制御と（属性を持つ）のSearchResultEntryを送信します。
Upon modification of an entry, all (modified or unmodified) attributes belonging to the content are sent.
エントリの変更時に、コンテンツに属するすべての（修飾または未修飾の）属性が送信されます。
Note that renaming an entry of the DIT may cause an add state change where the entry is renamed into the content, a delete state change where the entry is renamed out of the content, and a modify state change where the entry remains in the content. Also note that a modification of an entry of the DIT may cause an add, delete, or modify state change to the content.
DITのエントリの名前を変更すると、エントリーが内容に名前が変更された追加の状態変化、エントリは、コンテンツのうち、名前が変更され、削除の状態変化、およびエントリがコンテンツのまま変更状態変化を引き起こす可能性があることに注意してください。また、DITのエントリの変更は、追加の原因となり、削除、またはコンテンツへの状態変化を変更する可能性があることに注意。
Upon receipt of a change notification, the client updates its copy of the content.
変更通知を受信すると、クライアントは、コンテンツのコピーを更新します。
If the server desires to update the syncCookie during the persist stage, it may include the syncCookie in any Sync State Control or Sync Info Message returned.
サーバーが持続段階syncCookieを更新することを望む場合には、それがどの同期ステートコントロールにsyncCookieを含んでいてもよいし、同期情報メッセージが返されます。
The operation persists until canceled [RFC3909] by the client or terminated by the server. A Sync Done Control shall be attached to SearchResultDone Message to provide a new syncCookie.
クライアントが[RFC3909]をキャンセルしたり、サーバによって終了されるまでの動作が持続します。コントロール完了Syncは、新しいsyncCookieを提供するために、SearchResultDoneメッセージを添付しなければなりません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14 [RFC2119]に記載されているように解釈されます。
Protocol elements are described using ASN.1 [X.680] with implicit tags. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC4511].
プロトコル要素は、暗黙的なタグでASN.1 [X.680]を使用して記載されています。用語「BERエンコードは」要素は[RFC4511]のセクション5.1に詳述制約下基本符号化規則[X.690]を使用して符号化されるべきであることを意味します。
The Sync Operation is defined as an extension to the LDAP Search Operation [RFC4511] where the directory user agent (DUA or client) submits a SearchRequest Message with a Sync Request Control and the directory system agent (DSA or server) responds with zero or more SearchResultEntry Messages, each with a Sync State Control; zero or more SearchResultReference Messages, each with a Sync State Control; zero or more Sync Info Intermediate Response Messages; and a SearchResultDone Message with a Sync Done Control.
同期操作は、ディレクトリユーザーエージェント（DUAまたはクライアント）は、同期要求制御でSearchRequestメッセージを送信し、ディレクトリシステムエージェント（DSAまたはサーバー）がゼロ以上で応答LDAP検索操作[RFC4511]の拡張として定義され、 SearchResultEntryメッセージ、同期ステートコントロールと各;ゼロ以上のSearchResultReferenceメッセージ、同期状態制御と各。ゼロまたはそれ以上の同期情報中間応答メッセージ。そしてコントロール完了SyncでSearchResultDoneメッセージ。
To allow clients to discover support for this operation, servers implementing this operation SHOULD publish 1.3.6.1.4.1.4203.1.9.1.1 as a value of the 'supportedControl' attribute [RFC4512] of the root DSA-specific entry (DSE). A server MAY choose to advertise this extension only when the client is authorized to use it.
クライアントはこの操作のサポートを発見できるようにするには、この操作を実装したサーバは、ルートDSA固有のエントリ（DSE）の「のsupportedControl」属性[RFC4512]の値として1.3.6.1.4.1.4203.1.9.1.1公開する必要があります。サーバーは、クライアントがそれを使用することが許可されているだけで、この拡張機能を宣伝するために選ぶかもしれません。
The syncUUID data type is an OCTET STRING holding a 128-bit (16-octet) Universally Unique Identifier (UUID) [UUID].
syncUUIDデータ型は、128ビット（16オクテット）を保持OCTET STRINGの汎用一意識別子（UUID）[UUID]です。
syncUUID ::= OCTET STRING (SIZE(16))
-- constrained to UUID
The syncCookie is a notational convenience to indicate that, while the syncCookie type is encoded as an OCTET STRING, its value is an opaque value containing information about the synchronization session and its state. Generally, the session information would include a hash of the operation parameters that the server requires not be changed and the synchronization state information would include a commit (log) sequence number, a change sequence number, or a time stamp. For convenience of description, the term "no cookie" refers either to a null cookie or to a cookie with pre-initialized synchronization state.
syncCookieはsyncCookieタイプはOCTET STRINGとして符号化されている間、その値は、同期セッションとその状態に関する情報を含む不透明な値である、ことを示す表記上の便宜です。一般に、セッション情報は、サーバが変更されない必要があり、同期状態情報がコミット（ログ）シーケンス番号、変更シーケンス番号またはタイムスタンプを含むことになる動作パラメータのハッシュを含むことになります。説明の便宜上、用語「いいえクッキー」は、いずれかのヌルクッキーまたは事前初期化同期状態にクッキーを指します。
syncCookie ::= OCTET STRING
The Sync Request Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the controlValue, an OCTET STRING, contains a BER-encoded syncRequestValue. The criticality field is either TRUE or FALSE.
同期リクエストコントロールcontrolTypeは、オブジェクト識別子1.3.6.1.4.1.4203.1.9.1.1とcontrolValue、オクテット列であるLDAPコントロール[RFC4511]は、BERエンコードsyncRequestValueを含んでいます。臨界フィールドがTRUEまたはFALSEのいずれかです。
syncRequestValue ::= SEQUENCE {
mode ENUMERATED {
-- 0 unused
refreshOnly (1),
-- 2 reserved
refreshAndPersist (3)
},
cookie syncCookie OPTIONAL,
reloadHint BOOLEAN DEFAULT FALSE
}
The Sync Request Control is only applicable to the SearchRequest Message.
同期要求制御はSearchRequestメッセージにのみ適用されます。
The Sync State Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the controlValue, an OCTET STRING, contains a BER-encoded syncStateValue. The criticality is FALSE.
同期状態制御はcontrolTypeは、オブジェクト識別子1.3.6.1.4.1.4203.1.9.1.2とcontrolValue、オクテット列であるLDAPコントロール[RFC4511]は、BERエンコードsyncStateValueを含んでいます。重要度はFALSEです。
syncStateValue ::= SEQUENCE {
state ENUMERATED {
present (0),
add (1),
modify (2),
delete (3)
},
entryUUID syncUUID,
cookie syncCookie OPTIONAL
}
The Sync State Control is only applicable to SearchResultEntry and SearchResultReference Messages.
同期ステートコントロールはのSearchResultEntryとのSearchResultReferenceメッセージにのみ適用されます。
The Sync Done Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the controlValue contains a BER-encoded syncDoneValue. The criticality is FALSE (and hence absent).
同期は、コントロールを完了controlTypeオブジェクト識別子1.3.6.1.4.1.4203.1.9.1.3あり、controlValueはBERエンコードsyncDoneValueを含むLDAPコントロール[RFC4511]です。臨界は、FALSE（したがって存在しない）です。
syncDoneValue ::= SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDeletes BOOLEAN DEFAULT FALSE
}
The Sync Done Control is only applicable to the SearchResultDone Message.
同期完了コントロールはSearchResultDoneメッセージにのみ適用されます。
The Sync Info Message is an LDAP Intermediate Response Message [RFC4511] where responseName is the object identifier 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded syncInfoValue. The criticality is FALSE (and hence absent).
同期情報メッセージresponseNameオブジェクト識別子1.3.6.1.4.1.4203.1.9.1.4あり、responseValueはBERエンコードsyncInfoValueを含むLDAP中間応答メッセージ[RFC4511]です。臨界は、FALSE（したがって存在しない）です。
syncInfoValue ::= CHOICE {
newcookie [0] syncCookie,
refreshDelete [1] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
refreshPresent [2] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
syncIdSet [3] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDeletes BOOLEAN DEFAULT FALSE,
syncUUIDs SET OF syncUUID
}
}
The following LDAP resultCode [RFC4511] is defined:
以下のLDAP resultCodeが[RFC4511]は定義されています。
e-syncRefreshRequired (4096)
電子syncRefreshRequired（4096）
The Sync Operation is invoked when the client sends a SearchRequest Message with a Sync Request Control.
クライアントが同期要求制御でSearchRequestメッセージを送信するときに同期動作が起動されます。
The absence of a cookie or an initialized synchronization state in a cookie indicates a request for initial content, while the presence of a cookie representing a state of a client copy indicates a request for a content update. Synchronization Sessions are discussed in Section 3.1. Content Determination is discussed in Section 3.2.
クライアントコピーの状態を表すクッキーの存在がコンテンツ更新の要求を示しているクッキーまたはクッキーで初期化同期状態が存在しないことは、最初のコンテンツのための要求を示します。同期セッションは、3.1節で議論されています。コンテンツ決意は3.2節で議論されます。
The mode is either refreshOnly or refreshAndPersist. The refreshOnly and refreshAndPersist modes are discussed in Sections 3.3 and 3.4, respectively. The refreshOnly mode consists only of a refresh stage, while the refreshAndPersist mode consists of a refresh stage and a subsequent persist stage.
モードはのrefreshOnlyかrefreshAndPersistのいずれかです。 refreshOnlyとrefreshAndPersistモードは、セクションそれぞれ3.3および3.4に記載されています。 refreshAndPersistモードがリフレッシュステージで構成され、後続のステージを保持しながらのrefreshOnlyモードは、唯一のリフレッシュステージから成ります。
A sequence of Sync Operations where the last cookie returned by the server for one operation is provided by the client in the next operation is said to belong to the same Synchronization Session.
一回の操作のために、サーバによって返された最後のクッキーは、次の操作には、クライアントによって提供される同期の動作のシーケンスは、同じ同期セッションに属していると言われています。
The client MUST specify the same content-controlling parameters (see Section 3.5) in each Search Request of the session. The client SHOULD also issue each Sync request of a session under the same authentication and authorization associations with equivalent integrity and protections. If the server does not recognize the request cookie or the request is made under different associations or non-equivalent protections, the server SHALL return the initial content as if no cookie had been provided or return an empty content with the e-syncRefreshRequired LDAP result code. The decision between the return of the initial content and the return of the empty content with the e-syncRefreshRequired result code MAY be based on reloadHint in the Sync Request Control from the client. If the server recognizes the request cookie as representing empty or initial synchronization state of the client copy, the server SHALL return the initial content.
クライアントは、セッションの各検索要求に（3.5節を参照）と同じコンテンツ制御パラメータを指定する必要があります。また、クライアントは、同等の整合性と保護と同じ認証と認可団体の下でセッションの各同期要求を発行する必要があります。サーバは、要求のクッキーを認識しないか、要求が異なる団体や非同等の保護の下で行われている場合、サーバーはクッキーが用意されていなかったかのように初期の内容を返すか、電子syncRefreshRequired LDAP結果コードと空のコンテンツを返します。初期の内容の復帰と電子syncRefreshRequired結果コードと空のコンテンツの収益との決定は、クライアントからの同期要求制御にreloadHintに基づくことができます。サーバーは、クライアントコピーの空または初期同期状態を表すものとして、要求のクッキーを認識すると、サーバが初期コンテンツを返還しなければなりません。
A Synchronization Session may span multiple LDAP sessions between the client and the server. The client SHOULD issue each Sync request of a session to the same server. (Note: Shadowing considerations are discussed in Section 6.)
同期セッションは、クライアントとサーバの間で複数のLDAPセッションにまたがることがあります。クライアントは、同じサーバーへのセッションの各同期要求を発行する必要があります。 （注：シャドウイング考察は第6章に記載されています）
The content to be provided is determined by parameters of the Search Request, as described in [RFC4511], and possibly other controls. The same content parameters SHOULD be used in each Sync request of a session. If different content is requested and the server is unwilling or unable to process the request, the server SHALL return the initial content as if no cookie had been provided or return an empty content with the e-syncRefreshRequired LDAP result code. The decision between the return of the initial content and the return of the empty content with the e-syncRefreshRequired result code MAY be based on reloadHint in the Sync Request Control from the client.
提供されるコンテンツは、[RFC4511]に記載されているように、検索要求のパラメータ、およびおそらく他のコントロールによって決定されます。同じ内容のパラメータは、セッションの各同期要求で使用されるべきです。さまざまなコンテンツが要求され、サーバが要求を処理したくないか、できない場合は、サーバーにはクッキーが設けられていないか、電子syncRefreshRequired LDAP結果コードと空の内容を返すされていたかのように初期コンテンツを返還しなければなりません。初期の内容の復帰と電子syncRefreshRequired結果コードと空のコンテンツの収益との決定は、クライアントからの同期要求制御にreloadHintに基づくことができます。
The content may not necessarily include all entries or references that would be returned by a normal search operation, nor, for those entries included, all attributes returned by a normal search. When the server is unwilling or unable to provide synchronization for any attribute for a set of entries, the server MUST treat all filter components matching against these attributes as Undefined and MUST NOT return these attributes in SearchResultEntry responses.
これらのエントリは、通常の検索で返されるすべての属性が含まれてためたコンテンツは、必ずしも、通常の検索操作によって返されるすべてのエントリや参照が含まれ、またないかもしれません。サーバはエントリのセットのための任意の属性の同期を提供したくないか、できない場合、サーバは未定義として、これらの属性に対するすべてのフィルタ部品のマッチングを扱わなければならないとのSearchResultEntry応答でこれらの属性を返してはなりません。
Servers SHOULD support synchronization for all non-collective user-application attributes for all entries.
サーバーは、すべてのエントリのすべての非集団のユーザアプリケーションの属性の同期をサポートする必要があります。
The server may also return continuation references to other servers or to itself. The latter is allowed as the server may partition the entries it holds into separate synchronization contexts.
また、サーバは他のサーバーにまたはそれ自体への継続参照を返すことがあります。後者は、それが別の同期コンテキストに保持するエントリを分割することができるサーバとして許可されています。
The client may chase all or some of these continuations, each as a separate content synchronization session.
クライアントは、別のコンテンツの同期セッションとして全部または一部のこれらの継続の、それぞれを追いかけることがあります。
A Sync request with mode refreshOnly and with no cookie is a poll for initial content. A Sync request with mode refreshOnly and with a cookie representing a synchronization state is a poll for content update.
モードのrefreshOnlyとなしクッキーと同期要求は、最初のコンテンツのポーリングです。モードのrefreshOnlyと、同期状態を表すクッキーと同期要求は、コンテンツ更新の投票です。
Upon receipt of the request, the server provides the initial content using a set of zero or more SearchResultEntry and SearchResultReference Messages followed by a SearchResultDone Message.
要求を受信すると、サーバはSearchResultDoneメッセージに続くゼロ以上のSearchResultEntryとのSearchResultReferenceメッセージのセットを使用して初期コンテンツを提供します。
Each SearchResultEntry Message SHALL include a Sync State Control of state add, an entryUUID containing the entry's UUID, and no cookie. Each SearchResultReference Message SHALL include a Sync State Control of state add, an entryUUID containing the UUID associated with the reference (normally the UUID of the associated named referral [RFC3296] object), and no cookie. The SearchResultDone Message SHALL include a Sync Done Control having refreshDeletes set to FALSE.
各のSearchResultEntryメッセージentryUUIDは、エントリのUUID、およびクッキーなしを含む、追加の状態の同期ステートコントロールを含まなければなりません。それぞれのSearchResultReferenceメッセージが追加状態のシンクステート制御、参照（関連命名紹介[RFC3296]オブジェクトの正常UUID）に関連付けられたUUIDを含むentryUUIDは、無クッキーを含まなければなりません。 SearchResultDoneメッセージがFALSEに設定さrefreshDeletesを有する制御完了Syncを含まなければなりません。
A resultCode value of success indicates that the operation successfully completed. Otherwise, the result code indicates the nature of the failure. The server may return e-syncRefreshRequired result code on the initial content poll if it is safe to do so when it is unable to perform the operation due to various reasons. reloadHint is set to FALSE in the SearchRequest Message requesting the initial content poll.
成功の結果コード値は、操作が正常に完了したことを示しています。それ以外の場合は、結果コードは、障害の性質を示します。様々な理由により操作を行うことができないとき、そうすることが安全である場合、サーバは、初期コンテンツの世論調査で電子syncRefreshRequired結果コードを返すことがあります。 reloadHintは、初期コンテンツ投票を要求するSearchRequestメッセージにFALSEに設定されています。
If the operation is successful, a cookie representing the synchronization state of the current client copy SHOULD be returned for use in subsequent Sync Operations.
操作が成功した場合、現在のクライアントコピーの同期状態を表すクッキーは、後続の同期操作で使用するために返されるべきです。
Upon receipt of the request, the server provides the content refresh using a set of zero or more SearchResultEntry and
要求を受信すると、サーバは、ゼロ以上のSearchResultEntryのセットを使用してコンテンツのリフレッシュを提供し
SearchResultReference Messages followed by a SearchResultDone Message.
SearchResultDoneメッセージに続いてのSearchResultReferenceメッセージ。
The server is REQUIRED to:
サーバーをするために必要とされています。
a) provide the sequence of messages necessary for eventual convergence of the client's copy of the content to the server's copy,
a）は、サーバのコピーへのコンテンツのクライアントのコピーの最終的な収束のために必要なメッセージのシーケンスを提供
b) treat the request as an initial content request (e.g., ignore the cookie or the synchronization state represented in the cookie),
B）最初のコンテンツ要求としての要求を処理（例えば、クッキーまたはクッキーに示さ同期状態を無視します）、
c) indicate that the incremental convergence is not possible by returning e-syncRefreshRequired,
c）は、インクリメンタル収束が電子syncRefreshRequiredを返すことでは不可能であることを示しています
d) return a resultCode other than success or e-syncRefreshRequired.
d）の成功または電子syncRefreshRequired以外のresultCodeを返します。
A Sync Operation may consist of a single present phase, a single delete phase, or a present phase followed by a delete phase.
同期操作は、単一の現在の位相、単相削除、または削除フェーズに続く本相からなることができます。
In each phase, for each entry or reference that has been added to the content or been changed since the previous Sync Operation indicated by the cookie, the server returns a SearchResultEntry or SearchResultReference Message, respectively, each with a Sync State Control consisting of state add, an entryUUID containing the UUID of the entry or reference, and no cookie. Each SearchResultEntry Message represents the current state of a changed entry. Each SearchResultReference Message represents the current state of a changed reference.
各段階において、コンテンツに付加されたか、以前の同期操作は、クッキーによって示さ以降に変更され、各エントリまたは参照のために、サーバは、同期状態制御を有する各状態ADDの構成、それぞれのSearchResultEntryまたはのSearchResultReferenceメッセージを返します、エントリまたは参照、および無クッキーのUUIDを含むentryUUIDは。それぞれのSearchResultEntryメッセージは、変更されたエントリの現在の状態を表します。それぞれのSearchResultReferenceメッセージは、変更された基準の現在の状態を表します。
In the present phase, for each entry that has not been changed since the previous Sync Operation, an empty SearchResultEntry is returned whose objectName reflects the entry's current DN, whose attributes field is empty, and whose Sync State Control consists of state present, an entryUUID containing the UUID of the entry, and no cookie. For each reference that has not been changed since the previous Sync Operation, an empty SearchResultReference containing an empty SEQUENCE OF LDAPURL is returned with a Sync State Control consisting of state present, an entryUUID containing the UUID of the entry, and no cookie. No messages are sent for entries or references that are no longer in the content.
本段階では、前回の同期操作以降に変更されていないエントリごとに、空のSearchResultEntryは、そのobjectNameの属性フィールド空であり、そしてその同期状態制御状態の現在構成され、entryUUIDはエントリの現在のDN、反射し返されますエントリーのUUID、およびクッキーなしを含みます。以前の同期操作以降に変更されていない各参考のため、LDAPURL空の配列を含む空のSearchResultReferenceは同期状態制御は、現在の状態からなると戻され、エントリのUUID、および無クッキーを含むentryUUIDは。何のメッセージは、もはやコンテンツであるエントリまたは参照のために送信されません。
Multiple empty entries with a Sync State Control of state present SHOULD be coalesced into one or more Sync Info Messages of syncIdSet value with refreshDeletes set to FALSE. syncUUIDs contain a set of UUIDs of the entries and references unchanged since the last Sync
現在の状態の同期ステートコントロールと複数の空のエントリがFALSEに設定refreshDeletesとのsyncIdSet値の一つ以上の同期情報メッセージに合体されるべきです。 syncUUIDsは、最後の同期以来変わらないエントリのUUIDを参照してのセットが含まれています
Operation. syncUUIDs may be empty. The Sync Info Message of syncIdSet may contain a cookie to represent the state of the content after performing the synchronization of the entries in the set.
操作。 syncUUIDsは、空であってもよいです。 syncIdSetの同期情報メッセージは、セット内のエントリの同期化を実行した後に、コンテンツの状態を表現するためにクッキーを含んでいてもよいです。
In the delete phase, for each entry no longer in the content, the server returns a SearchResultEntry whose objectName reflects a past DN of the entry or is empty, whose attributes field is empty, and whose Sync State Control consists of state delete, an entryUUID containing the UUID of the deleted entry, and no cookie. For each reference no longer in the content, a SearchResultReference containing an empty SEQUENCE OF LDAPURL is returned with a Sync State Control consisting of state delete, an entryUUID containing the UUID of the deleted reference, and no cookie.
削除フェーズでは、もはやコンテンツの各エントリのために、サーバは、その属性フィールド空であり、そしてその同期状態制御状態で構成され、削除、entryUUIDはそのobjectNameのエントリの過去DNを反映するか、空であるのSearchResultEntryを返します削除されたエントリーのUUID、およびクッキーなしを含みます。もはやコンテンツの各参考のため、LDAPURL空の配列を含むのSearchResultReferenceは同期状態制御は、削除状態の削除基準のUUIDを含むentryUUIDは、無クッキーからなると共に返されます。
Multiple empty entries with a Sync State Control of state delete SHOULD be coalesced into one or more Sync Info Messages of syncIdSet value with refreshDeletes set to TRUE. syncUUIDs contain a set of UUIDs of the entries and references that have been deleted from the content since the last Sync Operation. syncUUIDs may be empty. The Sync Info Message of syncIdSet may contain a cookie to represent the state of the content after performing the synchronization of the entries in the set.
状態の同期ステートコントロールを使用した複数の空のエントリの削除がTRUEに設定されrefreshDeletesとのsyncIdSet値の一つ以上の同期情報メッセージに合体されるべきである（SHOULD）。 syncUUIDsは、最後の同期操作以降のコンテンツから削除されたエントリや参照のUUIDがのセットが含まれています。 syncUUIDsは、空であってもよいです。 syncIdSetの同期情報メッセージは、セット内のエントリの同期化を実行した後に、コンテンツの状態を表現するためにクッキーを含んでいてもよいです。
When a present phase is followed by a delete phase, the two phases are delimited by a Sync Info Message containing syncInfoValue of refreshPresent, which may contain a cookie representing the state after completing the present phase. The refreshPresent contains refreshDone, which is always FALSE in the refreshOnly mode of Sync Operation because it is followed by a delete phase.
本相を削除フェーズが続く場合、2つの相が存在する相を完了した後の状態を表すクッキーを含んでいてもよいrefreshPresentの同期情報メッセージを含むsyncInfoValue、によって区切られます。 refreshPresentは、それが削除フェーズが続いているので、同期操作ののrefreshOnlyモードでは常にFALSEですrefreshDoneのが、含まれています。
If a Sync Operation consists of a single phase, each phase and hence the Sync Operation are marked as ended by a SearchResultDone Message with Sync Done Control, which SHOULD contain a cookie representing the state of the content after completing the Sync Operation. The Sync Done Control contains refreshDeletes, which is set to FALSE for the present phase and set to TRUE for the delete phase.
同期操作は、単一相で構成されている場合、同期操作を完了した後、コンテンツの状態を表すクッキーを含むべきでコントロール完了SyncでSearchResultDoneメッセージ、で終わったとして、各フェーズので、同期操作がマークされています。コントロール完了Syncは、現在フェーズのためにFALSEに設定されており、削除フェーズのためにTRUEに設定されているrefreshDeletesが含まれています。
If a Sync Operation consists of a present phase followed by a delete phase, the Sync Operation is marked as ended at the end of the delete phase by a SearchResultDone Message with Sync Done Control, which SHOULD contain a cookie representing the state of the content after completing the Sync Operation. The Sync Done Control contains refreshDeletes, which is set to TRUE.
同期操作は、削除フェーズに続く存在相で構成されている場合は、同期操作をした後、コンテンツの状態を表すクッキーを含むべきでコントロール完了SyncでSearchResultDoneメッセージによって削除フェーズの最後で終了とマークされています同期操作を完了しました。コントロール完了同期がTRUEに設定されているrefreshDeletesが含まれています。
The client can specify whether it prefers to receive an initial content by supplying reloadHint of TRUE or to receive a e-syncRefreshRequired resultCode by supplying reloadHint of FALSE (hence absent), in the case that the server determines that it is impossible or inefficient to achieve the eventual convergence by continuing the current incremental synchronization thread.
クライアントは、サーバは、達成することが不可能又は非効率的であると判断した場合に、それがFALSEのreloadHint（したがって存在しない）を供給することにより、電子syncRefreshRequiredのresultCodeを受信するためにTRUEのreloadHintまたはを供給することによって初期コンテンツを受信することを好むかどうかを指定することができ現在の増分同期のスレッドを継続することにより、最終的な収束。
A resultCode value of success indicates that the operation is successfully completed. A resultCode value of e-syncRefreshRequired indicates that a full or partial refresh is needed. Otherwise, the result code indicates the nature of failure. A cookie is provided in the Sync Done Control for use in subsequent Sync Operations for incremental synchronization.
成功の結果コード値は、操作が正常に完了していることを示しています。電子syncRefreshRequiredのにresultCode値は、完全または部分的なリフレッシュが必要であることを示しています。それ以外の場合は、結果コードは、障害の性質を示します。クッキーは、増分同期のための後続の同期動作で使用するための制御完了同期して設けられています。
A Sync request with mode refreshAndPersist asks for initial content or content update (during the refresh stage) followed by change notifications (during the persist stage).
モードrefreshAndPersistと同期要求（持続段階で）変更通知が続く（リフレッシュ段階）初期コンテンツまたはコンテンツの更新を要求します。
The content refresh is provided as described in Section 3.3, except that the successful completion of content refresh is indicated by sending a Sync Info Message of refreshDelete or refreshPresent with a refreshDone value set to TRUE instead of a SearchResultDone Message with resultCode success. A cookie SHOULD be returned in the Sync Info Message to represent the state of the content after finishing the refresh stage of the Sync Operation.
コンテンツ更新の正常終了を結果コード成功しSearchResultDoneメッセージの代わりに、TRUEに設定さrefreshDoneの値とrefreshDelete又はrefreshPresentの同期情報メッセージを送信することによって示されることを除いて、セクション3.3で説明したようにコンテンツの更新が提供されます。クッキーは、同期操作のリフレッシュステージを終えた後、コンテンツの状態を表現するために同期情報メッセージで返されるべきである（SHOULD）。
Change notifications are provided during the persist stage.
変更通知は、持続段階中に提供されています。
As updates are made to the DIT, the server notifies the client of changes to the content. DIT updates may cause entries and references to be added to the content, deleted from the content, or modified within the content. DIT updates may also cause references to be added, deleted, or modified within the content.
更新がDITに行われると、サーバは、コンテンツへの変更をクライアントに通知します。 DITの更新はエントリと参照が、コンテンツに追加されたコンテンツから削除、またはコンテンツ内で変更される可能性があります。 DITの更新も参照は、追加、削除、またはコンテンツ内で変更される可能性があります。
Where DIT updates cause an entry to be added to the content, the server provides a SearchResultEntry Message that represents the entry as it appears in the content. The message SHALL include a Sync State Control with state of add, an entryUUID containing the entry's UUID, and an optional cookie.
DITの更新がコンテンツに追加するエントリを引き起こす場合は、サーバーは、それがコンテンツに表示されるエントリを表しのSearchResultEntryメッセージを提供します。メッセージは、add、エントリーのUUIDを含むentryUUIDは、オプションのクッキーの状態と同期ステートコントロールを含まなければなりません。
Where DIT updates cause a reference to be added to the content, the server provides a SearchResultReference Message that represents the reference in the content. The message SHALL include a Sync State Control with state of add, an entryUUID containing the UUID associated with the reference, and an optional cookie.
DITの更新を参照のコンテンツに追加される原因となる場合は、サーバは、コンテンツ内の参照を表してのSearchResultReferenceメッセージを提供します。メッセージは、追加の状態と参照に関連付けられたUUID、および任意のクッキーを含むentryUUIDは同期状態制御を含むものとします。
Where DIT updates cause an entry to be modified within the content, the server provides a SearchResultEntry Message that represents the entry as it appears in the content. The message SHALL include a Sync State Control with state of modify, an entryUUID containing the entry's UUID, and an optional cookie.
DITの更新はエントリは、コンテンツ内で変更させることがある場合、サーバは、コンテンツに表示されるエントリを表しのSearchResultEntryメッセージを提供します。メッセージには、変更、エントリのUUIDを含むentryUUIDはの状態と同期ステートコントロール、およびオプションのクッキーを含まなければなりません。
Where DIT updates cause a reference to be modified within the content, the server provides a SearchResultReference Message that represents the reference in the content. The message SHALL include a Sync State Control with state of modify, an entryUUID containing the UUID associated with the reference, and an optional cookie.
DITの更新基準は、コンテンツ内で変更させる場合、サーバは、コンテンツ内の参照を表すのSearchResultReferenceメッセージを提供します。メッセージは、修正、参照に関連付けられたUUIDを含むentryUUIDは状態と同期状態制御、および任意のクッキーを含まなければなりません。
Where DIT updates cause an entry to be deleted from the content, the server provides a SearchResultEntry Message with no attributes. The message SHALL include a Sync State Control with state of delete, an entryUUID containing the entry's UUID, and an optional cookie.
DITの更新がコンテンツから削除するエントリを引き起こす場合は、サーバーには属性とのSearchResultEntryメッセージを提供します。メッセージは、削除の状態、エントリーのUUIDを含むentryUUIDは、オプションのクッキーと同期ステートコントロールを含まなければなりません。
Where DIT updates cause a reference to be deleted from the content, the server provides a SearchResultReference Message with an empty SEQUENCE OF LDAPURL. The message SHALL include a Sync State Control with state of delete, an entryUUID containing the UUID associated with the reference, and an optional cookie.
DITの更新を参照のコンテンツから削除されることになり場合は、サーバーは、LDAPURLの空の配列とのSearchResultReferenceメッセージを提供します。メッセージは、削除の状態と参照に関連付けられたUUID、および任意のクッキーを含むentryUUIDは同期状態制御を含むものとします。
Multiple empty entries with a Sync State Control of state delete SHOULD be coalesced into one or more Sync Info Messages of syncIdSet value with refreshDeletes set to TRUE. syncUUIDs contain a set of UUIDs of the entries and references that have been deleted from the content. The Sync Info Message of syncIdSet may contain a cookie to represent the state of the content after performing the synchronization of the entries in the set.
状態の同期ステートコントロールを使用した複数の空のエントリの削除がTRUEに設定されrefreshDeletesとのsyncIdSet値の一つ以上の同期情報メッセージに合体されるべきである（SHOULD）。 syncUUIDsは、コンテンツから削除されたエントリや参照のUUIDがのセットが含まれています。 syncIdSetの同期情報メッセージは、セット内のエントリの同期化を実行した後に、コンテンツの状態を表現するためにクッキーを含んでいてもよいです。
With each of these messages, the server may provide a new cookie to be used in subsequent Sync Operations. Additionally, the server may also return Sync Info Messages of choice newCookie to provide a new cookie. The client SHOULD use the newest (last) cookie it received from the server in subsequent Sync Operations.
これらのメッセージのそれぞれと、サーバーは、後続の同期操作で使用する新しいクッキーを提供することができます。また、サーバーは、新しいクッキーを提供するために、選択newCookieの同期情報メッセージを返すことがあります。クライアントは、それが、その後の同期操作でサーバーから受信した最新（最後）のクッキーを使用すべきです。
As stated in Section 3.1, the client SHOULD specify the same content-controlling parameters in each Search Request of the session. All fields of the SearchRequest Message are considered content-controlling parameters except for sizeLimit and timeLimit.
3.1節で述べたように、クライアントは、セッションの各検索要求で同じコンテンツ制御パラメータを指定する必要があります。 SearchRequestメッセージのすべてのフィールドがSIZELIMITとTIMELIMIT以外のコンテンツ制御パラメータと考えられています。
As with the normal search operation, the refresh and persist stages are not isolated from DIT changes. It is possible that the entry referred to by the baseObject is deleted, renamed, or moved. It is also possible that the alias object used in finding the entry referred to by the baseObject is changed such that the baseObject refers to a different entry.
通常の検索操作、更新と同様と持続段階は、DITの変化から単離されていません。 baseObjectによって参照されるエントリは、削除、名前変更、または移動することも可能です。 baseObjectによって参照されるエントリを見つけるために使用される別名オブジェクトはbaseObjectが異なるエントリを指すように変更することも可能です。
If the DIT is updated during processing of the Sync Operation in a manner that causes the baseObject no longer to refer to any entry or in a manner that changes the entry the baseObject refers to, the server SHALL return an appropriate non-success result code, such as noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or e-syncRefreshRequired.
DITは、任意のエントリにまたはbaseObjectが指すエントリを変更するようにして参照することはもはやbaseObjectを引き起こすように同期動作の処理中に更新された場合、サーバは、適切な非成功結果コードを返しますこのようnoSuchObject、aliasProblem、aliasDereferencingProblem、紹介、またはE-syncRefreshRequiredなど。
This operation does not support alias dereferencing during searching. The client SHALL specify neverDerefAliases or derefFindingBaseObj for the SearchRequest derefAliases parameter. The server SHALL treat other values (e.g., derefInSearching, derefAlways) as protocol errors.
この操作は、検索時に別名参照解除をサポートしていません。クライアントは、SearchRequest derefAliasesパラメータにneverDerefAliasesまたはderefFindingBaseObjを指定しなければなりません。サーバは、プロトコルエラーとして他の値（例えば、derefInSearching、derefAlways）を治療SHALL。
The sizeLimit applies only to entries (regardless of their state in Sync State Control) returned during the refreshOnly operation or the refresh stage of the refreshAndPersist operation.
SIZELIMITは（関係なく、同期ステート・コントロールにおけるそれらの状態の）エントリのみに適用されるのrefreshOnly操作やrefreshAndPersist操作のリフレッシュステージ中に返さ。
For a refreshOnly Sync Operation, the timeLimit applies to the whole operation. For a refreshAndPersist operation, the timeLimit applies only to the refresh stage including the generation of the Sync Info Message with a refreshDone value of TRUE.
refreshOnly同期操作のために、TIMELIMITは、全体の動作に適用されます。 refreshAndPersist動作の場合、TIMELIMITがTRUEのrefreshDoneの値と同期情報メッセージの生成を含むリフレッシュステージにのみ適用されます。
The client SHOULD avoid filter assertions that apply to the values of the attributes likely to be considered by the server as ones holding meta-information. See Section 4.
クライアントは、メタ情報を保持しているものとして、サーバによって考慮される可能性が高い属性の値に適用されるフィルタアサーションを避ける必要があります。第4節を参照してください。
The Sync Operation uses entryUUID values provided in the Sync State Control as the primary keys to entries. The client MUST use these entryUUIDs to correlate synchronization messages.
同期操作は、エントリの主キーとして同期状態制御に設けentryUUIDは値を使用します。クライアントは、同期メッセージを相関させるためにこれらのentryUUIDを使用しなければなりません。
In some circumstances, the DN returned may not reflect the entry's current DN. In particular, when the entry is being deleted from the content, the server may provide an empty DN if the server does not wish to disclose the entry's current DN (or, if deleted from the DIT, the entry's last DN).
いくつかの状況では、DNは、エントリの現在のDNを反映していない可能性が戻りました。 （DIT、エントリの最後のDNから削除した場合、または）特に、エントリーが内容から削除されている場合、サーバは、サーバは、エントリの現在のDNを開示したくない場合は、空のDNを提供することができます。
Also note that the entry's DN may be viewed as meta information (see Section 4.1).
また、エントリのDNは、メタ情報（セクション4.1を参照）とみなすことができることに注意してください。
Servers MUST implement the LDAP Cancel [RFC3909] Operation and support cancellation of outstanding Sync Operations as described here.
サーバはLDAPは、[RFC3909]の操作をキャンセルして、ここで説明したように、優れた同期操作の取り消しをサポートして実装しなければなりません。
To cancel an outstanding Sync Operation, the client issues an LDAP Cancel [RFC3909] Operation.
優れた同期操作をキャンセルするには、クライアントはLDAPキャンセル[RFC3909]の操作を発行します。
If at any time the server becomes unwilling or unable to continue processing a Sync Operation, the server SHALL return a SearchResultDone with a non-success resultCode indicating the reason for the termination of the operation.
任意の時点で、サーバーが同期操作の処理を続行したくないか、できなくなった場合、サーバーは操作の終了の理由を示す非成功のresultCodeでSearchResultDoneを返します。
Whether the client or the server initiated the termination, the server may provide a cookie in the Sync Done Control for use in subsequent Sync Operations.
クライアントまたはサーバが停止を開始したかどうか、サーバーは、後続の同期操作で使用するために、同期完了コントロールでクッキーを提供することができます。
In order to achieve the eventually-convergent synchronization, the server may terminate the Sync Operation in the refresh or persist stages by returning an e-syncRefreshRequired resultCode to the client. If no cookie is provided, a full refresh is needed. If a cookie representing a synchronization state is provided in this response, an incremental refresh is needed.
最終的には、収束の同期を達成するために、サーバーは、リフレッシュに同期操作を終了させることができるか、クライアントに電子syncRefreshRequiredのresultCodeを返すことでステージを持続します。クッキーが提供されていない場合は、フル・リフレッシュが必要とされています。同期状態を表すクッキーはこの応答で提供されている場合は、増分リフレッシュが必要とされています。
To obtain a full refresh, the client then issues a new synchronization request with no cookie. To obtain an incremental reload, the client issues a new synchronization with the provided cookie.
フル・リフレッシュを取得するには、クライアントは、クッキーなしで新しい同期要求を発行します。インクリメンタルリロードを取得するには、クライアントが提供するクッキーを使用して新しい同期を発行します。
The server may choose to provide a full copy in the refresh stage (e.g., ignore the cookie or the synchronization state represented in the cookie) instead of providing an incremental refresh in order to achieve the eventual convergence.
サーバは、最終的な収束を達成するために、リフレッシュステージ（例えば、クッキーまたはクッキーに示さ同期状態を無視する）代わりに増分リフレッシュを提供する完全なコピーを提供するように選択することができます。
The decision between the return of the initial content and the return of the e-syncRefreshRequired result code may be based on reloadHint in the Sync Request Control from the client.
初期の内容の復帰と電子syncRefreshRequired結果コードの戻り間の決定は、クライアントからの同期要求制御にreloadHintに基づくことができます。
In the case of persist stage Sync, the server returns the resultCode of e-syncRefreshRequired to the client to indicate that the client needs to issue a new Sync Operation in order to obtain a synchronized copy of the content. If no cookie is provided, a full refresh is needed. If a cookie representing a synchronization state is provided, an incremental refresh is needed.
舞台Syncを持続する場合は、サーバーは、クライアントがコンテンツの同期コピーを得るために、新しい同期操作を発行する必要があることを示すために、電子syncRefreshRequiredクライアントへのにresultCodeを返します。クッキーが提供されていない場合は、フル・リフレッシュが必要とされています。同期状態を表すクッキーが提供されている場合は、増分リフレッシュが必要とされています。
The server may also return e-syncRefreshRequired if it determines that a refresh would be more efficient than sending all the messages required for convergence.
それはリフレッシュが収束に必要なすべてのメッセージを送信するよりも、より効率的であると判断した場合、サーバーも電子syncRefreshRequired戻してもよいです。
Note that the client may receive one or more of SearchResultEntry, SearchResultReference, and/or Sync Info Messages before it receives a SearchResultDone Message with the e-syncRefreshRequired result code.
それは電子syncRefreshRequired結果コードを持つSearchResultDoneメッセージを受信する前に、クライアントがのSearchResultEntry、のSearchResultReference、および/または同期情報メッセージの一つ以上を受け取ることができることに注意してください。
The server MUST ensure that the number of entry messages generated to refresh the client content does not exceed the number of entries presently in the content. While there is no requirement for servers to maintain history information, if the server has sufficient history to allow it to reliably determine which entries in the prior client copy are no longer present in the content and the number of such entries is less than or equal to the number of unchanged entries, the server SHOULD generate delete entry messages instead of present entry messages (see Section 3.3.2).
サーバーは、クライアントのコンテンツをリフレッシュするために生成されたエントリーのメッセージの数が現在、コンテンツ内のエントリ数を超えていないことを保証しなければなりません。サーバは、それが確実に前にクライアントコピーのエントリがコンテンツにもはや存在していると、このようなエントリの数がより少ないか等しいであるかを決定しないことを可能にするのに十分な歴史を持っている場合、サーバは、履歴情報を保持するために必要はありませんが変わらないエントリの数は、サーバが削除エントリメッセージの代わりに、現在のエントリーメッセージを（3.3.2項を参照）を生成する必要があります。
When the amount of history information maintained in the server is not enough for the clients to perform infrequent refreshOnly Sync Operations, it is likely that the server has incomplete history information (e.g., due to truncation) by the time those clients connect again.
クライアントは不定期のrefreshOnly同期操作を実行するためのサーバで維持履歴情報の量が十分でない場合は、サーバはこれらのクライアントが再度接続時間で（原因切り捨てに、例えば）不完全な履歴情報を持っている可能性があります。
The server SHOULD NOT resort to full reload when the history information is not enough to generate delete entry messages. The server SHOULD generate either present entry messages only or present entry messages followed by delete entry messages to bring the client copy to the current state. In the latter case, the present entry messages bring the client copy to a state covered by the history information maintained in the server.
履歴情報が削除エントリメッセージを生成するのに十分でない場合、サーバーは、完全な再読み込みに頼るべきではありません。サーバーにのみ存在エントリーメッセージや現在の状態にクライアントのコピーを持参して削除エントリメッセージに続いて現在のエントリーメッセージのいずれかを生成する必要があります。後者の場合には、本エントリーメッセージは、サーバー内に維持履歴情報がカバー状態にクライアントのコピーを持参します。
The server SHOULD maintain enough (current or historical) state information (such as a context-wide last modify time stamp) to determine if no changes were made in the context since the content refresh was provided and, when no changes were made, generate zero delete entry messages instead of present messages.
サーバはゼロを生成し、コンテンツの更新が何も変更が行われなかった場合、提供されたので、変更がコンテキストで行われなかったかどうかを決定する（最後のタイムスタンプを変更するようなワイドコンテキストとして）十分（現在または過去の）状態情報を維持しなければなりませんエントリメッセージの代わりに、現在のメッセージを削除します。
The server SHOULD NOT use the history information when its use does not reduce the synchronization traffic or when its use can expose sensitive information not allowed to be received by the client.
その使用は、同期トラフィックの場合、またはその使用は、クライアントによって受信されることを許可されていない機密情報を公開することができますを削減していない場合、サーバーは、履歴情報を使用しないでください。
The server implementor should also consider chattiness issues that span multiple Sync Operations of a session. As noted in Section 3.8, the server may return e-syncRefreshRequired if it determines that a reload would be more efficient than continuing under the current operation. If reloadHint in the Sync Request is TRUE, the server may initiate a reload without directing the client to request a reload.
サーバーの実装は、セッションの複数の同期操作にまたがるchattiness問題を検討すべきです。 3.8節で述べたように、それがリロードが現在動作中継続するよりも効率的であろうと判断した場合、サーバは、電子syncRefreshRequired戻してもよいです。同期要求でreloadHintがTRUEの場合、サーバーは、リロードを要求するためにクライアントを向けることなく、リロードを開始することができます。
The server SHOULD transfer a new cookie frequently to avoid having to transfer information already provided to the client. Even where DIT changes do not cause content synchronization changes to be transferred, it may be advantageous to provide a new cookie using a Sync Info Message. However, the server SHOULD avoid overloading the client or network with Sync Info Messages.
サーバはすでにクライアントに提供される情報を転送することを避けるために、頻繁に新しいクッキーを転送する必要があります。 DITの変更が転送されるコンテンツの同期の変化を起こさない場合でも、同期情報メッセージを使用して、新しいクッキーを提供することが有利です。ただし、サーバーは、同期情報メッセージをクライアントまたはネットワークの過負荷を避ける必要があります。
During persist mode, the server SHOULD coalesce multiple outstanding messages updating the same entry. The server MAY delay generation of an entry update in anticipation of subsequent changes to that entry that could be coalesced. The length of the delay should be long enough to allow coalescing of update requests issued back to back but short enough that the transient inconsistency induced by the delay is corrected in a timely manner.
モードを持続中は、サーバが同じエントリを更新する複数の未処理のメッセージを合体すべきです。サーバは、合体することができ、そのエントリに続く変化を見越して、エントリの更新の発生を遅延させることができます。遅延の長さは、背中合わせが、遅延により誘導された過渡的矛盾がタイムリーに補正されていることを十分に短くするために発行更新要求の合体を可能にするのに十分長くなければなりません。
The server SHOULD use the syncIdSet Sync Info Message when there are multiple delete or present messages to reduce the amount of synchronization traffic.
複数の削除、又は本メッセージがあると、サーバーは、同期トラフィックの量を減らすためのsyncIdSet同期情報メッセージを使用すべきです。
Also note that there may be many clients interested in a particular directory change, and that servers attempting to service all of these at once may cause congestion on the network. The congestion issues are magnified when the change requires a large transfer to each interested client. Implementors and deployers of servers should take steps to prevent and manage network congestion.
また、特定のディレクトリの変更に興味を持って多くのクライアントが存在する可能性があること、そして一度にこれらのすべてにサービスを提供しようとするサーバーは、ネットワーク上の輻輳を引き起こす可能性があることに注意してください。変更がそれぞれ興味のクライアントへの大規模な転送を必要とするとき、輻輳の問題が拡大しています。サーバの実装者とデプロイヤは、ネットワークの輻輳を防止し、管理するための手順を実行する必要があります。
The LDAP protocol model [RFC4511] allows operations to be multiplexed over a single LDAP session. Clients SHOULD NOT maintain multiple LDAP sessions with the same server. Servers SHOULD ensure that responses from concurrently processed operations are interleaved fairly.
LDAPプロトコルモデル[RFC4511]は操作が単一LDAPセッション上で多重化されることを可能にします。クライアントは、同じサーバーで複数のLDAPセッションを維持すべきではありません。サーバーは、同時に処理事業からの応答がかなりインターリーブされていることを確認してください。
Clients SHOULD combine Sync Operations whose result set is largely overlapping. This avoids having to return multiple messages, once for each overlapping session, for changes to entries in the overlap.
クライアントは、結果セットが大部分が重複している同期の操作を結合する必要があります。これは、オーバーラップのエントリを変更するため、各重複セッションに対して一度、複数のメッセージを返すことがなくなり。
Clients SHOULD NOT combine Sync Operations whose result sets are largely non-overlapping. This ensures that an event requiring an e-syncRefreshRequired response can be limited to as few result sets as possible.
クライアントは、その結果セットの大部分が重複していない同期操作を組み合わせるべきではありません。これは、電子syncRefreshRequired応答を必要とするイベントができるだけ少ない結果セットに制限することができることを確実にします。
As an entry's DN is constructed from its relative DN (RDN) and the entry's parent's DN, it is often viewed as meta information.
エントリのDNは、その相対DN（RDN）と、エントリの親のDNから構築されると、それは多くの場合、メタ情報として表示されます。
While renaming or moving to a new superior causes the entry's DN to change, that change SHOULD NOT, by itself, cause synchronization messages to be sent for that entry. However, if the renaming or the moving could cause the entry to be added or deleted from the content, appropriate synchronization messages should be generated to indicate this to the client.
名前の変更や新しい上司に移動すると、エントリのDNを変化させながら、その変更は、それ自体で、同期メッセージは、そのエントリのために送信されるように発生することはありません。名前の変更または移動するには、エントリの追加やコンテンツから削除される可能性があります場合は、適切な同期メッセージがクライアントにこれを示すために生成されなければなりません。
When a server treats the entry's DN as meta information, the server SHALL either
サーバーは、メタ情報として、エントリのDNを扱う場合は、サーバーのいずれかSHALL
- evaluate all MatchingRuleAssertions [RFC4511] to TRUE if matching a value of an attribute of the entry, otherwise Undefined, or
- エントリの属性の値と一致する場合は不定それ以外の場合は、TRUEに全てMatchingRuleAssertions [RFC4511]を評価し、または
- evaluate all MatchingRuleAssertion with dnAttributes of TRUE as Undefined.
- 未定義としてTRUEのdnAttributesを持つすべてのMatchingRuleAssertionを評価します。
The latter choice is offered for ease of server implementation.
後者の選択は、サーバの実装を容易にするために提供されています。
Where values of an operational attribute are determined by values not held as part of the entry it appears in, the operational attribute SHOULD NOT support synchronization of that operational attribute.
操作属性の値は、それが中に表示されたエントリの一環として開催されていない値によって決定されている場合は、操作属性は、その操作属性の同期をサポートすべきではありません。
For example, in servers that implement the X.501 subschema model [X.501], servers should not support synchronization of the subschemaSubentry attribute as its value is determined by values held and administrated in subschema subentries.
その値が保持され、サブスキーマサブエントリ内に投与した値によって決定されるように、例えば、X.501サブスキーマモデル[X.501]を実装するサーバに、サーバは、subschemaSubentry属性の同期をサポートしてはなりません。
As a counter example, servers that implement aliases [RFC4512][X.501] can support synchronization of the aliasedObjectName attribute as its values are held and administrated as part of the alias entries.
その値は、エイリアスエントリの一部として保持され、投与される反例として、エイリアスを実装するサーバは、[RFC4512] [X.501] aliasedObjectName属性の同期をサポートすることができます。
Servers SHOULD support synchronization of the following operational attributes: createTimestamp, modifyTimestamp, creatorsName, modifiersName [RFC4512]. Servers MAY support synchronization of other operational attributes.
createTimestamp、modifyTimestampの、creatorsName、にmodifiersName [RFC4512]：サーバは、以下の操作属性の同期をサポートする必要があります。サーバーは、他の操作属性の同期をサポートするかもしれません。
A collective attribute is "a user attribute whose values are the same for each member of an entry collection" [X.501]. Use of collective attributes in LDAP is discussed in [RFC3671].
集合属性は、[X.501]「その値エントリコレクションの各メンバについて同じであるユーザ属性」です。 LDAPでの集団的な属性の使用は[RFC3671]で議論されています。
Modification of a collective attribute generally affects the content of multiple entries, which are the members of the collection. It is inefficient to include values of collective attributes visible in entries of the collection, as a single modification of a collective attribute requires transmission of multiple SearchResultEntry (one for each entry of the collection that the modification affected).
集団的属性の変更は、一般的に、コレクションのメンバーである複数のエントリの内容に影響を与えます。集合属性の単一の修飾は複数のSearchResultEntry（修飾が影響を受けるコレクションの各エントリに対して1つ）の送信を必要とすることは、コレクションのエントリに見える集合属性の値を含むように非効率的です。
Servers SHOULD NOT synchronize collective attributes appearing in entries of any collection. Servers MAY support synchronization of collective attributes appearing in collective attribute subentries.
サーバーはすべてのコレクションのエントリーに登場する集団的属性を同期化しないでください。サーバは集団的属性のサブエントリに登場集団の属性の同期をサポートするかもしれません。
Entries are commonly subject to access and other administrative Controls. While portions of the policy information governing a particular entry may be held in the entry, policy information is often held elsewhere (in superior entries, in subentries, in the root DSE, in configuration files, etc.). Because of this, changes to policy information make it difficult to ensure eventual convergence during incremental synchronization.
エントリーはアクセスやその他の管理コントロールに一般的に対象となっています。特定のエントリを管理するポリシー情報の部分はエントリに保持することができるが、ポリシー情報は、多くの場合（コンフィギュレーションファイルなどで、ルートDSEに、サブエントリに、優れたエントリに）他の場所に保持されています。このため、ポリシー情報への変更は、それが困難な増分同期中に最終的な収束を確実にするために作ります。
Where it is impractical or infeasible to generate content changes resulting from a change to policy information, servers may opt to return e-syncRefreshRequired or to treat the Sync Operation as an initial content request (e.g., ignore the cookie or the synchronization state represented in the cookie).
それがポリシー情報への変化に起因するコンテンツの変化を生成することは非現実的または実行不可能である場合は、サーバーは、電子syncRefreshRequiredを返すために選ぶことができたり、最初のコンテンツ要求（例えば、で表されたクッキーや同期状態を無視して同期操作を処理するためにクッキー）。
The Sync Operation may be used with:
同期操作で使用することができます。
- ManageDsaIT Control [RFC3296]
- ManageDSAITコントロール[RFC3296]
- Subentries Control [RFC3672]
- サブエントリコントロール[RFC3672]
as described below. The Sync Operation may be used with other LDAP extensions as detailed in other documents.
以下で説明するように。同期操作は、他の文書で説明するように、他のLDAPエクステンションで使用することができます。
The ManageDsaIT Control [RFC3296] indicates that the operation acts upon the DSA Information Tree and causes referral and other special entries to be treated as object entries with respect to the operation.
ManageDSAITコントロール[RFC3296]は操作がDSA情報ツリーに作用及び動作に関して対象エントリとして扱われることを紹介し、他の特別なエントリを引き起こすことを示しています。
The Subentries Control is used with the search operation "to control the visibility of entries and subentries which are within scope" [RFC3672]. When used with the Sync Operation, the subentries control and other factors (search scope, filter, etc.) are used to determine whether an entry or subentry appears in the content.
サブエントリ制御は[RFC3672]「範囲内にあるエントリとサブエントリの可視性を制御するために、」検索操作で使用されています。同期操作で使用される場合、サブエントリ制御および他の因子（等検索範囲、フィルタは、）エントリまたはサブエントリがコンテンツに表示されるかどうかを決定するために使用されます。
As noted in [RFC4511], some servers may hold shadow copies of entries that can be used to answer search and comparison queries. Such servers may also support content synchronization requests. This section discusses considerations for implementors and deployers for the implementation and deployment of the Sync operation in shadowed directories.
[RFC4511]で述べたように、いくつかのサーバは、検索と比較クエリに応答するために使用できるエントリのシャドウコピーを保持することができます。このようなサーバは、コンテンツ同期要求をサポートすることができます。このセクションでは、シャドウディレクトリ内の同期操作の実装と展開のための実装とデプロイヤのための考慮事項について説明します。
While a client may know of multiple servers that are equally capable of being used to obtain particular directory content from, a client SHOULD NOT assume that each of these servers is equally capable of continuing a content synchronization session. As stated in Section 3.1, the client SHOULD issue each Sync request of a Sync session to the same server.
クライアントから特定のディレクトリの内容を取得するために使用されても同様に実施可能である複数のサーバーを知っているかもしれないが、クライアントは、これらの各サーバーは、コンテンツの同期セッションを継続するも同様に可能であることを仮定するべきではありません。 3.1節で述べたように、クライアントが同じサーバーに同期セッションの各同期要求を発行する必要があります。
However, through domain naming or IP address redirection or other techniques, multiple physical servers can be made to appear as one logical server to a client. Only servers that are equally capable in regards to their support for the Sync operation and that hold equally complete copies of the entries should be made to appear as one logical server. In particular, each physical server acting as one logical server SHOULD be equally capable of continuing a content synchronization based upon cookies provided by any of the other physical servers without requiring a full reload. Because there is no standard LDAP shadowing mechanism, the specification of how to independently implement equally capable servers (as well as the precise definition of "equally capable") is left to future documents.
ただし、ドメイン名前付けやIPアドレスのリダイレクトまたは他の技術によって、複数の物理サーバは、クライアントへの一つの論理サーバとして見えるようにすることができます。同期操作のための彼らのサポートに関しても同様に可能であり、それはエントリーの均等に完全なコピーを保持するサーバーのみ1台の論理サーバとして表示されるようになされるべきです。具体的には、一つの論理サーバとして機能する各物理サーバは、完全な再ロードを必要とすることなく、他の物理サーバのいずれかによって提供されるクッキーに基づいて、コンテンツの同期を継続等しく可能であるべきです。標準的なLDAPのシャドウイングメカニズム、独立して同じようにできるのサーバーを実装する方法の仕様（だけでなく、「均等にできる」の正確な定義）が存在しないため、将来の文書に残されています。
Note that it may be difficult for the server to reliably determine what content was provided to the client by another server, especially in the shadowing environments that allow shadowing events to be coalesced. For these servers, the use of the delete phase discussed in Section 3.3.2 may not be applicable.
サーバが確実に特にシャドウイングイベントを合体させることを可能にするシャドウイング環境で、別のサーバによってクライアントに提供されたどのようなコンテンツを判断することが困難になる場合があります。これらのサーバーの場合は、3.3.2項で述べた削除フェーズの使用が適用できない場合があります。
In order to maintain a synchronized copy of the content, a client is to delete information from its copy of the content as described above. However, the client may maintain knowledge of information disclosed to it by the server separate from its copy of the content used for synchronization. Management of this knowledge is beyond the scope of this document. Servers should be careful not to disclose information for content the client is not authorized to have knowledge of and/or about.
コンテンツの同期コピーを維持するために、クライアントは、上記のように、コンテンツのコピーから情報を削除することです。ただし、クライアントが同期のために使用されるコンテンツのコピーから別のサーバによってそれに開示された情報の知識を維持することができます。この知識の管理は、このドキュメントの範囲を超えています。サーバーは、クライアントがおよび/または程度の知識を持つことが許可されていないコンテンツのための情報を開示しないように注意する必要があります。
While the information provided by a series of refreshOnly Sync Operations is similar to that provided by a series of Search Operations, persist stage may disclose additional information. A client may be able to discern information about the particular sequence of update operations that caused content change.
refreshOnly同期の一連の動作によって提供される情報は、検索の一連の動作によって提供されるものと同様であるが、ステージが追加情報を開示すること持続。クライアントは、コンテンツ変更を生じ更新操作の特定のシーケンスに関する情報を識別することができるかもしれません。
Implementors should take precautions against malicious cookie content, including malformed cookies or valid cookies used with different security associations and/or protections in an attempt to obtain unauthorized access to information. Servers may include a digital signature in the cookie to detect tampering.
実装者は、不正な形式のクッキーや情報への不正アクセスを得るための試みで異なるセキュリティアソシエーションおよび/または保護で使用される有効なクッキーを含む悪意のあるクッキーのコンテンツに対する予防措置を講じなければなりません。サーバは、改ざんを検出するためにクッキーにデジタル署名を含むことができます。
The operation may be the target of direct denial-of-service attacks. Implementors should provide safeguards to ensure the operation is not abused. Servers may place access control or other restrictions upon the use of this operation.
操作は、直接、サービス拒否攻撃の標的となる可能性があります。実装者は、操作が虐待されていないことを確認する保護手段を提供しなければなりません。サーバは、アクセス制御やこの操作の使用時に他の制限を配置することがあります。
Note that even small updates to the directory may cause a significant amount of traffic to be generated to clients using this operation. A user could abuse its update privileges to mount an indirect denial of service to these clients, other clients, and/or portions of the network. Servers should provide safeguards to ensure that update operations are not abused.
ディレクトリに少しでも更新は、この操作を使用してクライアントに生成される大量のトラフィックを引き起こす可能性があることに注意してください。ユーザーはこれらのクライアント、他のクライアント、および/またはネットワークの部分にサービスの間接的な拒否をマウントし、その更新権限を乱用ことができます。サーバーは、更新操作が乱用されていないことを確認するためにセーフガードを提供する必要があります。
Implementors of this (or any) LDAP extension should be familiar with general LDAP security considerations [RFC4510].
この（または任意の）LDAP拡張の実装は、一般的なLDAPのセキュリティ問題[RFC4510]に精通しなければなりません。
Registration of the following values have been completed by the IANA [RFC4520].
次の値の登録は、IANA [RFC4520]で完了しました。
The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the OpenLDAP Foundation, under its IANA-assigned private enterprise allocation [PRIVATE], for use in this specification.
OIDアーク1.3.6.1.4.1.4203.1.9.1は、本明細書で使用するために、そのIANAによって割り当てられたプライベート企業配分[PRIVATE]の下で、OpenLDAPの財団[ASSIGN]を割り当てました。
The IANA has registered the LDAP Protocol Mechanism described in this document.
IANAは、この文書で説明するLDAPプロトコルメカニズムを登録しています。
Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1 Description: LDAP Content Synchronization Control Person & email address to contact for further information: Kurt Zeilenga <kurt@openldap.org> Usage: Control Specification: RFC 4533 Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi Comments: none
件名：LDAPプロトコルメカニズム登録オブジェクト識別子の要求：1.3.6.1.4.1.4203.1.9.1.1説明：LDAP内容同期制御人とEメールアドレス詳細のために連絡する：クルトZeilenga <kurt@openldap.org>使用方法：コントロール仕様：RFC 4533著者/変更コントローラ：クルトD. Zeilenga、ジョンヒョクチェ・コメント：なし
The IANA has registered the LDAP Result Code described in this document.
IANAは、この文書で説明するLDAP結果コードを登録しています。
Subject: LDAP Result Code Registration Person & email address to contact for further information: Kurt Zeilenga <kurt@OpenLDAP.org> Result Code Name: e-syncRefreshRequired (4096) Specification: RFC 4533 Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi Comments: none
件名：LDAP結果コード登録人とEメールアドレスは、詳細のために連絡する：クルトZeilenga <kurt@OpenLDAP.org>結果コード名：電子syncRefreshRequired（4096）仕様：RFC 4533著者/変更コントローラ：クルトD. Zeilenga、ジョンをヒョクチェコメント：なし
This document borrows significantly from the LDAP Client Update Protocol [RFC3928], a product of the IETF LDUP working group. This document also benefited from Persistent Search [PSEARCH], Triggered Search [TSEARCH], and Directory Synchronization [DIRSYNC] works. This document also borrows from "Lightweight Directory Access Protocol (v3)" [RFC2251].
このドキュメントでは、LDAPクライアントアップデートプロトコル[RFC3928]、IETF LDUPワーキンググループの製品から大幅に借用します。また、持続検索の恩恵を受けてこの文書では、[PSEARCH]、検索[TSEARCH]、およびディレクトリ同期[ディレクトリの同期]作品をトリガ。この文書はまた、「ライトウェイトディレクトリアクセスプロトコル（v3の）」[RFC2251]から借ります。
[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月。
[RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories", RFC 3296, July 2002.
[RFC3296] Zeilenga、K.は、RFC 3296、2002年7月 "のLDAP（Lightweight Directory Access Protocol）ディレクトリで下位参照の名前"。
[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., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3672] Zeilenga、K.、RFC 3672 "のLDAP（Lightweight Directory Access Protocol）でサブエントリ"、2003年12月。
[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月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"。、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ディレクトリ情報モデル"、RFC 4512、2006年6月。
[RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute", RFC 4530, June 2006.
[RFC4530] Zeilenga、K.、2006年6月、RFC 4530 "LDAP（Lightweight Directory Access Protocol）は運用属性をentryUUIDは"。
[UUID] International Organization for Standardization (ISO), "Information technology - Open Systems Interconnection - Remote Procedure Call", ISO/IEC 11578:1996
[UUID]国際標準化機構（ISO）、 "情報技術 - 開放型システム間相互接続 - リモートプロシージャコール"、ISO / IEC 11578：1996
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.501]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ - モデル、" X.501（1993）（また、ISO / IEC 9594から2：1994）。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.680]国際電気通信連合 - 電気通信標準化部門、 "抽象構文記法1（ASN.1） - 基本的な記法の仕様"、X.680（1997）（また、ISO / IEC 8824から1：1998）。
[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(1997) (also ISO/IEC 8825-1:1998).
[X.690]国際電気通信連合 - 電気通信標準化部門、 "ASN.1エンコーディング規則の仕様：基本符号化規則（BER）、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）"、X.690（1997 ）（また、ISO / IEC 8825から1：1998）。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J. Parham, "Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)", RFC 3928, October 2004.
[RFC3928] Megginson氏、R.、エド。、スミス、M.、Natkovich、O.、およびJ.パラム、 "LDAP（Lightweight Directory Access Protocol）のクライアントアップデートプロトコル（LCUP）"、RFC 3928、2004年10月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 4520、2006年6月。
[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers.
[PRIVATE] IANA、 "民間企業番号"、http://www.iana.org/assignments/enterprise-numbers。
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt.
[ASSIGN]のOpenLDAP財団、 "OpenLDAPのOIDの代表団"、http://www.openldap.org/foundation/oid-delegate.txt。
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.500]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ - 概念、モデルとサービスの概要、" X.500（1993）（また、ISO / IEC 9594から1：1994）。
[X.525] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Replication", X.525(1993).
[X.525]国際電気通信連合 - 電気通信標準化部門、 "ディレクトリ：レプリケーション"、X.525（1993）。
[DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory Synchronization", Work in Progress.
[ディレクトリの同期] Armijo、M.、 "ディレクトリ同期のためのMicrosoft LDAPコントロール" が進行中で働いています。
[PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP Change Notification Mechanism", Work in Progress.
[PSEARCH]スミス、M.ら、「持続検索：シンプルLDAP変更通知メカニズム」。、進行中の作業。
[TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in Progress.
[TSEARCH]ワール、M.は、進行中の作業 "のLDAPv3は、検索コントロールがトリガー"。
Appendix A. CSN-based Implementation Considerations
付録A. CSNベースの実装に関する考慮事項
This appendix is provided for informational purposes only; it is not a normative part of the LDAP Content Synchronization Operation's technical specification.
この付録は、情報提供のみを目的として提供されます。それは、LDAPコンテンツ同期操作の技術仕様の標準的な部分ではありません。
This appendix discusses LDAP Content Synchronization Operation server implementation considerations associated with Change Sequence Number based approaches.
この付録では、変更シーケンス番号に基づいたアプローチに関連したLDAP内容同期操作サーバー実装の考慮事項について説明します。
Change Sequence Number based approaches are targeted for use in servers that do not maintain history information (e.g., change logs, state snapshots) about changes made to the Directory and hence, must rely on current directory state and minimal synchronization state information embedded in Sync Cookie. Servers that maintain history information should consider other approaches that exploit the history information.
変更順序番号ベースのアプローチは、同期クッキーに埋め込まれ、現在のディレクトリ状態と最小限の同期状態情報に依存しなければならない、それゆえDirectoryとに加えられた変更に関する履歴情報（例えば、変更ログ、状態のスナップショット）を維持していないサーバで使用するために対象とされています。履歴情報を保持するサーバーは、履歴情報を利用する他のアプローチを検討すべきです。
A Change Sequence Number is effectively a time stamp that has sufficient granularity to ensure that the precedence relationship in time of two updates to the same object can be determined. Change Sequence Numbers are not to be confused with Commit Sequence Numbers or Commit Log Record Numbers. A Commit Sequence Number allows one to determine how two commits (to the same object or different objects) relate to each other in time. A Change Sequence Number associated with different entries may be committed out of order. In the remainder of this Appendix, the term CSN refers to a Change Sequence Number.
変更順序番号は、効果的に同じオブジェクトへの2回の更新の時間における優先順位の関係を求めることができることを保証するのに十分な精度を持つタイムスタンプです。変更シーケンス番号は、シーケンス番号をコミットまたはログレコード番号をコミットと混同してはなりません。コミットシーケンス番号は1つが（同じオブジェクトまたは別のオブジェクトへの）は、2つのコミットが時間的に互いにどのように関連するかを決定することを可能にします。異なるエントリに関連付けられた変更順序番号は順不同でコミットすることができます。この付録の残りの部分では、用語CSNは変更シーケンス番号を指します。
In these approaches, the server not only maintains a CSN for each directory entry (the entry CSN) but also maintains a value that we will call the context CSN. The context CSN is the greatest committed entry CSN that is not greater than any outstanding (uncommitted) entry CSNs for all entries in a directory context. The values of context CSN are used in syncCookie values as synchronization state indicators.
これらのアプローチでは、サーバは、各ディレクトリエントリ（エントリCSN）のためにCSNを維持しても、我々はCSNコンテキストを呼び出す値を維持するだけでなく。コンテキストCSNは、ディレクトリコンテキスト内のすべてのエントリの未処理（コミットされていない）エントリのCSNより大きくない最大のコミットエントリCSNです。コンテキストCSNの値が同期状態の指標としてsyncCookie値で使用されています。
As search operations are not isolated from individual directory update operations and individual update operations cannot be assumed to be serialized, one cannot assume that the returned content incorporates each relevant change whose change sequence number is less than or equal to the greatest entry CSN in the content. The content incorporates all the relevant changes whose change sequence numbers are less than or equal to context CSN before search processing. The content may also incorporate any subset of the changes whose change sequence number is greater than context CSN before search processing but less than or equal to the context CSN after search processing. The content does not incorporate any of the changes whose CSN is greater than the context CSN after search processing.
検索操作は、個々のディレクトリ更新操作および個々の更新操作から単離されていないようにシリアル化されると仮定することができず、一方が返されたコンテンツは、その変更シーケンス番号コンテンツの最大のエントリCSN以下、各関連する変更を組み込んでいると仮定することができません。コンテンツは、その変更のシーケンス番号よりも小さいか、検索処理の前にコンテキストCSNに等しい関連するすべての変更が組み込まれています。内容も変更シーケンス番号検索処理後のコンテキストCSNへ検索処理の前にコンテキストCSNよりも大きいが、以下である変更の任意のサブセットを組み込むことができます。コンテンツは、そのCSN検索処理後のコンテキストCSNよりも大きい変化のいずれかを組み込んでいません。
A simple server implementation could use the value of the context CSN before search processing to indicate state. Such an implementation would embed this value into each SyncCookie returned. We'll call this the cookie CSN. When a refresh was requested, the server would simply generate "update" messages for all entries in the content whose CSN is greater than the supplied cookie CSN and generate "present" messages for all other entries in the content. However, if the current context CSN is the same as the cookie CSN, the server should instead generate zero "updates" and zero "delete" messages and indicate a refreshDeletes of TRUE, as the directory has not changed.
単純なサーバーの実装は、状態を示すために、検索処理の前にコンテキストCSNの値を使用することができます。各SyncCookieが返さにこのような実装では、この値を埋め込むでしょう。私たちは、このクッキーのCSN呼ぶことにします。リフレッシュが要求された場合は、サーバは単にCSN供給クッキーCSNより大きく、コンテンツ内の他のすべてのエントリの「現在」のメッセージを生成するコンテンツ内のすべてのエントリのための「更新」のメッセージを生成します。現在のコンテキストCSNは、クッキーCSNと同じである場合は、サーバーではなくゼロ「のアップデート」を生成し、ゼロのメッセージを「削除」し、ディレクトリが変更されていないとして、TRUEのrefreshDeletesを示すべきです。
The implementation should also consider the impact of changes to meta information, such as access controls, that affect content determination. One approach is for the server to maintain a context-wide meta information CSN or meta CSN. This meta CSN would be updated whenever meta information affecting content determination was changed. If the value of the meta CSN is greater than the cookie CSN, the server should ignore the cookie and treat the request as an initial request for content.
実装は、コンテンツの決意に影響を与えるようなアクセスコントロールなどのメタ情報の変更、の影響を考慮すべきです。一つのアプローチは、コンテキスト全体のメタ情報CSNまたはメタCSNを維持するために、サーバー用です。コンテンツ決意に影響を与えるメタ情報が変更された時はいつでもこのメタCSNが更新されます。メタCSNの値がクッキーCSNよりも大きい場合、サーバーはクッキーを無視し、コンテンツの最初の要求としての要求を処理する必要があります。
Additionally, servers may want to consider maintaining some per-session history information to reduce the number of messages needed to be transferred during incremental refreshes. Specifically, a server could record information about entries as they leave the scope of a disconnected sync session and later use this information to generate delete messages instead of present messages.
また、サーバは、増分リフレッシュ中に転送するために必要なメッセージの数を減らすために、いくつかのセッションごとの履歴情報を維持することを検討する必要があります。具体的には、サーバは、彼らが切断同期セッションのスコープを残してエントリに関する情報を記録し、後で削除メッセージの代わりに、現在のメッセージを生成するには、この情報を使用することができます。
When the history information is truncated, the CSN of the latest truncated history information entry may be recorded as the truncated CSN of the history information. The truncated CSN may be used to determine whether a client copy can be covered by the history information by comparing it to the synchronization state contained in the cookie supplied by the client.
履歴情報が切り捨てられた場合、最新の切り捨て履歴情報エントリのCSNは、履歴情報の切り捨てCSNとして記録することができます。切り捨てられたCSNは、クライアント・コピーは、クライアントによって供給されたクッキーに含まれる同期状態と比較することによって、履歴情報によって覆うことができるかどうかを決定するために使用されてもよいです。
When there is a large number of sessions, it may make sense to maintain such history only for the selected clients. Also, servers taking this approach need to consider resource consumption issues to ensure reasonable server operation and to protect against abuse. It may be appropriate to restrict this mode of operation by policy.
多数のセッションがある場合、それだけで、選択したクライアントのためにこのような歴史を維持する意味があります。また、このアプローチを取るのサーバーは、合理的なサーバーの動作を保証するためや虐待から保護するためにリソース消費の問題を考慮する必要があります。ポリシーによってこの動作モードを制限することが適切です。
Authors' Addresses
著者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Jong Hyuk Choi IBM Corporation
ジョンヒョクチェIBMコーポレーション
EMail: jongchoi@us.ibm.com
メールアドレス：jongchoi@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎と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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。