[要約] RFC 4533は、LDAPのコンテンツ同期操作に関する仕様です。目的は、複数のLDAPサーバ間でディレクトリデータを同期するための効率的な方法を提供することです。
Network Working Group K. Zeilenga
Request for Comments: 4533 OpenLDAP Foundation
Category: Experimental J.H. Choi
IBM Corporation
June 2006
The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation
軽量ディレクトリアクセスプロトコル（LDAP）コンテンツ同期操作
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この仕様では、Lightweight Directory Access Protocol（LDAP）コンテンツの同期操作について説明します。この操作により、クライアントはディレクトリ情報ツリー（DIT）のフラグメントのコピーを維持できます。変更の投票と変更を聞くことの両方をサポートします。操作は、LDAP検索操作の拡張として定義されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Intended Usage .............................................4
1.3. Overview ...................................................5
1.4. Conventions ................................................8
2. Elements of the Sync Operation ..................................8
2.1. Common ASN.1 Elements ......................................9
2.2. Sync Request Control .......................................9
2.3. Sync State Control ........................................10
2.4. Sync Done Control .........................................10
2.5. Sync Info Message .........................................11
2.6. Sync Result Codes .........................................11
3. Content Synchronization ........................................11
3.1. Synchronization Session ...................................12
3.2. Content Determination .....................................12
3.3. refreshOnly Mode ..........................................13
3.4. refreshAndPersist Mode ....................................16
3.5. Search Request Parameters .................................17
3.6. objectName ................................................18
3.7. Canceling the Sync Operation ..............................19
3.8. Refresh Required ..........................................19
3.9. Chattiness Considerations .................................20
3.10. Operation Multiplexing ...................................21
4. Meta Information Considerations ................................22
4.1. Entry DN ..................................................22
4.2. Operational Attributes ....................................22
4.3. Collective Attributes .....................................23
4.4. Access and Other Administrative Controls ..................23
5. Interaction with Other Controls ................................23
5.1. ManageDsaIT Control .......................................24
5.2. Subentries Control ........................................24
6. Shadowing Considerations .......................................24
7. Security Considerations ........................................25
8. IANA Considerations ............................................26
8.1. Object Identifier .........................................26
8.2. LDAP Protocol Mechanism ...................................26
8.3. LDAP Result Codes .........................................26
9. Acknowledgements ...............................................26
10. Normative References ..........................................27
11. Informative References ........................................28
Appendix A. CSN-based Implementation Considerations ..............29
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.
LightWeight Directory Access Protocol（LDAP）[RFC4510]は、クライアントが複雑なアサーションセットに一致するディレクトリコンテンツを要求し、サーバーがこのコンテンツを返すように要求し、アクセス制御を依頼するメカニズムである検索操作[RFC4511]を提供します。クライアントに対するその他の制限。ただし、LDAPは（この領域に多数の拡張機能が導入されているにもかかわらず）、ディレクトリコンテンツの同期コピーを維持するための効果的かつ効率的なメカニズムを提供しません。このドキュメントでは、洗練されたディレクトリアプリケーションのコンテンツ同期要件を満たすように特別に設計された新しいメカニズムを紹介します。
This document defines the LDAP Content Synchronization Operation, or Sync Operation for short, which allows a client to maintain a synchronized copy of a fragment of a Directory Information Tree (DIT). The Sync Operation is defined as a set of controls and other protocol elements that extend the Search Operation.
このドキュメントでは、LDAPコンテンツの同期操作、または短期間の同期操作を定義します。これにより、クライアントはディレクトリ情報ツリー（DIT）のフラグメントの同期コピーを維持できます。同期操作は、検索操作を拡張する一連のコントロールおよびその他のプロトコル要素として定義されます。
Over the years, a number of content synchronization approaches have been suggested for use in LDAP directory services. These approaches are inadequate for one or more of the following reasons:
長年にわたり、LDAPディレクトリサービスで使用するために、多くのコンテンツ同期アプローチが提案されてきました。これらのアプローチは、次の1つ以上の理由で不十分です。
- 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.
- White Page Serviceアプリケーションは、同期操作を使用してDITフラグメントの現在のコピーを維持する場合があります。たとえば、Sync操作を使用してエンタープライズアドレス帳のローカルコピーを維持するメールユーザーエージェントです。
- 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フラグメントの影のコピーを維持するためにスレーブサーバーによって使用できます。（注：International Telephone Union（ITU）は、X.500ディレクトリ[X.500]情報シャドーイングプロトコル（Disp）[X.525]を定義しました。複製プロトコルも存在します。）
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.
このプロトコルは、Change Deltasの代わりに変更時にコンテンツに属するエントリのすべての可視値を転送するため、このプロトコルは帯域幅に挑戦したアプリケーションまたは展開には適していません。
This section provides an overview of basic ways the Sync Operation can be used to maintain a synchronized client copy of a DIT fragment.
このセクションでは、同期操作を使用して、DITフラグメントの同期クライアントコピーを維持するために使用できる基本的な方法の概要を説明します。
- Polling for changes: refreshOnly mode
- 変更のポーリング：爽快なモード
- Listening for changes: refreshAndPersist mode
- 変更のリスニング：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 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.
最初のクライアントのコピーを取得するには、クライアントは同期要求を発行します。Syncリクエストコントロールを使用した検索要求モードを爽快に設定します。サーバーは、通常の検索操作と同じように、検索基準（BaseObject、Scope、Filter、属性）に一致するコンテンツを返します（アクセスコントロールおよびその他の制限の対象となります）。さらに、各エントリが返されると、サーバーは状態の追加を示す同期状態制御を提供します。このコントロールには、エントリ[RFC4530]の普遍的に一意の識別子（UUID）[UUID]が含まれています。時間の経過とともに変化する可能性のある著名な名前（DN）とは異なり、エントリのUUIDは安定しています。初期コンテンツの後に、同期が完了した制御を備えた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をクライアントが以前に送信したコンテンツのインジケーターとして使用すると、サーバーはSync State Control Addを示すSync State Controlで変更されたエントリのコピーを送信します。変更された各エントリについて、コンテンツに属するすべての（変更または変更されていない）属性が送信されます。
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つの異なる同期フェーズのいずれかまたは両方を実行できます：現在と削除フェーズ。サーバーが更新段階に単一フェーズを使用すると、各フェーズは、同期実行制御を備えたSearchResultDoneによって終了するようにマークされます。現在の位相は、同期実行制御の誤ったrefreshdeletes値によって識別されます。削除フェーズは、真のrefreshdeletes値によって識別されます。現在のフェーズの後に削除フェーズが続く場合があります。2つのフェーズは、false refreshdone値を持つrefresspresent同期情報メッセージによって区切られています。両方のフェーズが使用される場合、現在のフェーズを使用して、クライアントのコピーを後続の削除フェーズを開始できる状態に持ち込みます。
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 Sync情報メッセージを送信する場合があります。Syncidsetのrefreshdeletesがfalseに設定されている場合、変更されていない現在のエントリのuuidはSyncuuidsセットに含まれています。Syncidsetのrefreshdeletesがtrueに設定されている場合、コンテンツに存在するエントリのuuidがSyncuuidsセットに含まれています。Syncuuidsセットに含まれるエントリの存在または存在を同期した後、コンテンツの状態を表すために、オプションのCookieを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を更新することを希望する場合、SyncokieがSync State ControlまたはSync Infoメッセージを返していることを含めることができます。
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]をキャンセルするか、サーバーによって終了するまで持続します。同期実行制御は、新しい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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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]を使用して記述されています。「BERENCODED」という用語は、[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.
同期操作は、Directoryユーザーエージェント（DUAまたはクライアント）が同期リクエストコントロールでSearchRequestメッセージを送信し、ディレクトリシステムエージェント（DSAまたはサーバー）がゼロ以上で応答します。SearchResultentryメッセージ。それぞれが同期状態制御を備えています。ゼロ以上のSearchResultReferenceメッセージ。それぞれが同期状態制御を備えています。ゼロ以上の同期情報中間応答メッセージ。同期実行制御を備えた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）の「サポートコントロール」属性[RFC4512]の値として1.3.6.1.4.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].
同期データ型は、128ビット（16-OCTET）普遍的に一意の識別子（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としてエンコードされているが、その値は同期セッションとその状態に関する情報を含む不透明な値であることを示すための表彰可能な利便性です。一般に、セッション情報には、サーバーを変更する必要がない操作パラメーターのハッシュが含まれ、同期状態情報にはコミット（ログ）シーケンス番号、変更シーケンス番号、またはタイムスタンプが含まれます。説明の便利さのために、「No Cookie」という用語は、Null Cookieまたは事前に開催された同期状態を持つCookieのいずれかを指します。
syncCookie ::= OCTET STRING
The Sync Request Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the controlValue, an OCTET STRING, contains a BER-encoded syncRequestValue. The criticality field is either TRUE or FALSE.
同期要求制御はLDAPコントロール[RFC4511]です。ここで、制御タイプはオブジェクト識別子1.3.6.1.4.1.4203.1.9.1.1.1であり、コントロールバリューであるオクテット文字列には、ベルコードされた同期リコステルが含まれています。クリティカルフィールドは真または偽のいずれかです。
syncRequestValue ::= SEQUENCE {
mode ENUMERATED {
-- 0 unused
refreshOnly (1),
-- 2 reserved
refreshAndPersist (3)
},
cookie syncCookie OPTIONAL,
reloadHint BOOLEAN DEFAULT FALSE
}
The Sync Request Control is only applicable to the SearchRequest Message.
同期要求コントロールは、SearchRequestメッセージにのみ適用されます。
The Sync State Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the controlValue, an OCTET STRING, contains a BER-encoded syncStateValue. The criticality is FALSE.
同期状態制御はLDAP制御[RFC4511]です。ここで、制御タイプはオブジェクト識別子1.3.6.1.4.1.4203.1.9.1.9であり、コントロールバリューであるオクテット文字列には、ベルコードされたSyncStateValueが含まれています。臨界性は間違っています。
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.
Sync状態制御は、SearchResultentryおよびSearchResultReferenceメッセージにのみ適用されます。
The Sync Done Control is an LDAP Control [RFC4511] where the controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the controlValue contains a BER-encoded syncDoneValue. The criticality is FALSE (and hence absent).
同期実行制御はLDAPコントロール[RFC4511]です。ここで、制御タイプはオブジェクト識別子1.3.6.1.4.1.4203.1.9.1.3であり、コントロールバリューにはバーエンコードされた同期型が含まれています。臨界性は偽です（したがって、存在しない）。
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).
同期情報メッセージはLDAP中間応答メッセージ[RFC4511]です。ここで、responseLameはオブジェクト識別子1.3.6.1.4.1.4203.1.9.1.9.4であり、ResponseValueにはBer-Encoded SyncinfoValueが含まれています。臨界性は偽です（したがって、存在しない）。
syncInfoValue ::= CHOICE {
newcookie [0] syncCookie,
refreshDelete [1] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
refreshPresent [2] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDone BOOLEAN DEFAULT TRUE
},
syncIdSet [3] SEQUENCE {
cookie syncCookie OPTIONAL,
refreshDeletes BOOLEAN DEFAULT FALSE,
syncUUIDs SET OF syncUUID
}
}
The following LDAP resultCode [RFC4511] is defined:
次のLDAP結果コード[RFC4511]が定義されています。
e-syncRefreshRequired (4096)
e-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.
CookieまたはCookieに初期化された同期状態がないことは、初期コンテンツのリクエストを示しますが、クライアントのコピーの状態を表すCookieの存在は、コンテンツの更新のリクエストを示します。同期セッションについては、セクション3.1で説明します。コンテンツの決定については、セクション3.2で説明します。
The mode is either refreshOnly or refreshAndPersist. The refreshOnly and refreshAndPersist modes are discussed in Sections 3.3 and 3.4, respectively. The refreshOnly mode consists only of a refresh stage, while the refreshAndPersist mode consists of a refresh stage and a subsequent persist stage.
モードは爽快またはrefreshandpersistのいずれかです。リフレッシュとリフレッシストのモードについては、それぞれセクション3.3と3.4で説明します。更新モードはリフレッシュステージのみで構成されますが、RefReshandPersistモードはリフレッシュステージとその後の永続ステージで構成されます。
A sequence of Sync Operations where the last cookie returned by the server for one operation is provided by the client in the next operation is said to belong to the same Synchronization Session.
次の操作でクライアントが1つの操作のためにサーバーによって返された最後のCookieが次の操作で提供される一連の同期操作は、同じ同期セッションに属すると言われています。
The client MUST specify the same content-controlling parameters (see Section 3.5) in each Search Request of the session. The client SHOULD also issue each Sync request of a session under the same authentication and authorization associations with equivalent integrity and protections. If the server does not recognize the request cookie or the request is made under different associations or non-equivalent protections, the server SHALL return the initial content as if no cookie had been provided or return an empty content with the e-syncRefreshRequired LDAP result code. The decision between the return of the initial content and the return of the empty content with the e-syncRefreshRequired result code MAY be based on reloadHint in the Sync Request Control from the client. If the server recognizes the request cookie as representing empty or initial synchronization state of the client copy, the server SHALL return the initial content.
クライアントは、セッションの各検索要求で同じコンテンツ制御パラメーター（セクション3.5を参照）を指定する必要があります。また、クライアントは、同じ認証および承認協会の下で、同等の整合性と保護とのセッションの各同期要求を発行する必要があります。サーバーがリクエストCookieを認識しない場合、またはリクエストが異なる関連または非等価保護の下で行われた場合、サーバーはCookieが提供されていないかのように初期コンテンツを返すか、e-SyncrefreshRequed LDAP結果コードで空のコンテンツを返します。e-syncrefreshRequiredの結果コードを使用して、初期コンテンツの返品と空のコンテンツの返品との間の決定は、クライアントからの同期リクエストコントロールのreloadhintに基づいている場合があります。サーバーがクライアントのコピーの空の同期状態または初期同期状態を表すものとしてリクエストCookieを認識した場合、サーバーは初期コンテンツを返すものとします。
A Synchronization Session may span multiple LDAP sessions between the client and the server. The client SHOULD issue each Sync request of a session to the same server. (Note: Shadowing considerations are discussed in Section 6.)
同期セッションは、クライアントとサーバーの間で複数のLDAPセッションにまたがる場合があります。クライアントは、セッションの各同期要求を同じサーバーに発行する必要があります。（注：シャドウイングの考慮事項については、セクション6で説明します。）
The content to be provided is determined by parameters of the Search Request, as described in [RFC4511], and possibly other controls. The same content parameters SHOULD be used in each Sync request of a session. If different content is requested and the server is unwilling or unable to process the request, the server SHALL return the initial content as if no cookie had been provided or return an empty content with the e-syncRefreshRequired LDAP result code. The decision between the return of the initial content and the return of the empty content with the e-syncRefreshRequired result code MAY be based on reloadHint in the Sync Request Control from the client.
提供されるコンテンツは、[RFC4511]で説明されているように、検索要求のパラメーター、および場合によっては他のコントロールによって決定されます。セッションの各同期要求で同じコンテンツパラメーターを使用する必要があります。異なるコンテンツが要求され、サーバーがリクエストを処理することを嫌がっている、または不可能な場合、サーバーはCookieが提供されていないか、e-SyncrefreshRequed LDAP結果コードを使用して空のコンテンツを返すかのように初期コンテンツを返すものとします。e-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.
Mode RefreshonlyとCookieのない同期リクエストは、初期コンテンツの世論調査です。同期状態を表すMode ModeとCookieを使用した同期要求は、コンテンツの更新の投票です。
Upon receipt of the request, the server provides the initial content using a set of zero or more SearchResultEntry and SearchResultReference Messages followed by a SearchResultDone Message.
リクエストを受け取ると、サーバーは、ゼロ以上のsearchResultentryとsearchResultReferenceメッセージのセットを使用して、SearchResultdoneメッセージを使用して初期コンテンツを提供します。
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メッセージには、状態ADDの同期状態制御、エントリのUUID、およびCookieが含まれていないEntruuidが含まれます。各SearchResultReferenceメッセージには、参照に関連付けられたUUID（通常は関連付けられた名前の紹介[RFC3296]オブジェクトのUUID）を含むEntruidの同期状態制御、およびCookieが含まれます。SearchResultDoneメッセージには、falseに設定されたrefreshdeletesを使用する同期実行制御を含めるものとします。
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.
成功の結果コード値は、操作が正常に完了したことを示します。それ以外の場合、結果コードは障害の性質を示します。サーバーは、さまざまな理由で操作を実行できない場合に安全である場合、最初のコンテンツポーリングでe-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.
操作が成功した場合、現在のクライアントコピーの同期状態を表すCookieを、後続の同期操作で使用するために返品する必要があります。
Upon receipt of the request, the server provides the content refresh using a set of zero or more SearchResultEntry and SearchResultReference Messages followed by a SearchResultDone Message.
リクエストを受け取ると、サーバーは、ゼロ以上のsearchResultentryとsearchResultReferenceメッセージのセットを使用してコンテンツの更新を提供し、その後にSeartResultDoneメッセージが提供されます。
The server is REQUIRED to:
サーバーには次のことが必要です。
a) provide the sequence of messages necessary for eventual convergence of the client's copy of the content to the server's copy,
a) コンテンツのクライアントのコピーをサーバーのコピーに最終的に収束させるために必要な一連のメッセージを提供します。
b) treat the request as an initial content request (e.g., ignore the cookie or the synchronization state represented in the cookie),
b) リクエストを最初のコンテンツリクエストとして扱います（たとえば、Cookieに表されるCookieまたは同期状態を無視してください）、
c) indicate that the incremental convergence is not possible by returning e-syncRefreshRequired,
c) e-syncrefreshrequiredを返すことで増分収束が不可能であることを示します。
d) return a resultCode other than success or e-syncRefreshRequired.
d) 成功またはe-syncrefreshRequired以外の結果コードを返します。
A Sync Operation may consist of a single present phase, a single delete phase, or a present phase followed by a delete phase.
同期操作は、単一の現在の位相、単一の削除フェーズ、または現在の位相に続いて削除フェーズで構成されます。
In each phase, for each entry or reference that has been added to the content or been changed since the previous Sync Operation indicated by the cookie, the server returns a SearchResultEntry or SearchResultReference Message, respectively, each with a Sync State Control consisting of state add, an entryUUID containing the UUID of the entry or reference, and no cookie. Each SearchResultEntry Message represents the current state of a changed entry. Each SearchResultReference Message represents the current state of a changed reference.
各フェーズでは、Cookieが示す以前の同期操作以降にコンテンツに追加された、または変更された各エントリまたは参照について、サーバーはそれぞれSearchResultentryまたはSearchResultReferenceメッセージを返します。、エントリまたは参照のuuidを含むエントリuuid、およびcookieなし。各SearchResultentryメッセージは、変更されたエントリの現在の状態を表します。各searchResultReferenceメッセージは、変更された参照の現在の状態を表します。
In the present phase, for each entry that has not been changed since the previous Sync Operation, an empty SearchResultEntry is returned whose objectName reflects the entry's current DN, whose attributes field is empty, and whose Sync State Control consists of state present, an entryUUID containing the UUID of the entry, and no cookie. For each reference that has not been changed since the previous Sync Operation, an empty SearchResultReference containing an empty SEQUENCE OF LDAPURL is returned with a Sync State Control consisting of state present, an entryUUID containing the UUID of the entry, and no cookie. No messages are sent for entries or references that are no longer in the content.
現在のフェーズでは、以前の同期操作以降に変更されていない各エントリについて、オブジェクト名がエントリの現在のDNを反映している空のsearchResultententryが返されます。エントリのuuidが含まれており、クッキーは含まれていません。以前の同期操作以降に変更されていない各参照について、ldapurlの空のシーケンスを含む空のsearchresultreferenceが、存在する状態の状態コントロール、エントリのuuidを含む侵入、およびcookieなしで構成される同期状態コントロールで返されます。コンテンツに含まれていないエントリや参照については、メッセージは送信されません。
Multiple empty entries with a Sync State Control of state present SHOULD be coalesced into one or more Sync Info Messages of syncIdSet value with refreshDeletes set to FALSE. syncUUIDs contain a set of UUIDs of the entries and references unchanged since the last Sync 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.
存在する状態の同期状態制御を備えた複数の空のエントリは、falseに設定されたsyncidset値の1つまたは複数の同期情報メッセージに合体する必要があります。Syncuuidには、最後の同期操作以降に変更されていないエントリと参照のuuidのセットが含まれています。Syncuuidは空である可能性があります。同期情報メッセージには、セット内のエントリの同期を実行した後、コンテンツの状態を表すCookieが含まれている場合があります。
In the delete phase, for each entry no longer in the content, the server returns a SearchResultEntry whose objectName reflects a past DN of the entry or is empty, whose attributes field is empty, and whose Sync State Control consists of state delete, an entryUUID containing the UUID of the deleted entry, and no cookie. For each reference no longer in the content, a SearchResultReference containing an empty SEQUENCE OF LDAPURL is returned with a Sync State Control consisting of state delete, an entryUUID containing the UUID of the deleted reference, and no cookie.
削除フェーズでは、コンテンツ内の各エントリのエントリごとに、サーバーは、オブジェクト名がエントリの過去のDNを反映しているか、空であるSearchResultentryを返し、その属性が空で、同期状態制御は状態削除で構成されています。削除されたエントリのUUID、およびCookieなしを含む。コンテンツ内の各参照については、ldapurlの空のシーケンスを含むSearchResultReferenceが、削除された参照のUUIDを含むEntruuid、およびCookieを含むEntruuidで構成される同期状態コントロールで返されます。
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.
状態削除の同期状態制御を備えた複数の空のエントリは、syncidset値の1つまたは複数の同期情報メッセージに合わせて合体して、resuredeletesがtrueに設定されている必要があります。Syncuuidには、最後のSync操作以降にコンテンツから削除されたエントリと参照のuuidのセットが含まれています。Syncuuidは空である可能性があります。同期情報メッセージには、セット内のエントリの同期を実行した後、コンテンツの状態を表すCookieが含まれている場合があります。
When a present phase is followed by a delete phase, the two phases are delimited by a Sync Info Message containing syncInfoValue of refreshPresent, which may contain a cookie representing the state after completing the present phase. The refreshPresent contains refreshDone, which is always FALSE in the refreshOnly mode of Sync Operation because it is followed by a delete phase.
現在の位相の後に削除フェーズが続くと、2つのフェーズには、現在のフェーズを完了した後に状態を表すCookieを含む可能性のあるsyncinfovalueを含む同期情報メッセージが区切られています。refresspresentにはrefreshdoneが含まれています。これは、削除フェーズが続くため、sync操作の爽快なモードで常に偽です。
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.
同期操作が単一フェーズで構成されている場合、各フェーズ、したがって同期操作は、同期操作を完了した後にコンテンツの状態を表すCookieを含む必要があるSearchResultDoneメッセージで終了するようにマークされます。同期完了制御には、現在のフェーズで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.
同期操作が現在の位相とそれに続く削除フェーズで構成されている場合、同期操作は、searchResultdoneメッセージによって削除フェーズの最後に終了するとマークされます。同期操作を完了します。Sync Done Controlには、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.
クライアントは、サーバーが達成することが不可能または非効率的であると判断した場合、TrueのReloadhintを提供することで初期コンテンツを受信することを好むか、e-SyncrefreshRequered ResultCodeを受信することを好むか、e-SyncrefreshRequered ResultCodeを受信することを好むか、e-SyncrefreshRequered ResultCodeを受信することを指定できます（したがって、存在しない）ことができます。現在の増分同期スレッドを継続することにより、最終的な収束。
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.
成功の結果コード値は、操作が正常に完了したことを示します。e-syncrefreshrequiredの結果コード値は、完全または部分的な更新が必要であることを示します。それ以外の場合、結果コードは障害の性質を示します。Cookieは、インクリメンタル同期のためにその後の同期操作で使用するために同期完了制御で提供されます。
A Sync request with mode refreshAndPersist asks for initial content or content update (during the refresh stage) followed by change notifications (during the persist stage).
Mode RefReshandPersistとの同期リクエストは、初期コンテンツまたはコンテンツの更新（更新段階で）を要求し、その後に通知を変更します（永続段階で）。
The content refresh is provided as described in Section 3.3, except that the successful completion of content refresh is indicated by sending a Sync Info Message of refreshDelete or refreshPresent with a refreshDone value set to TRUE instead of a SearchResultDone Message with resultCode success. A cookie SHOULD be returned in the Sync Info Message to represent the state of the content after finishing the refresh stage of the Sync Operation.
コンテンツの更新は、セクション3.3で説明されているように提供されます。ただし、コンテンツリフレッシュの正常な完了は、ResuredDone値がsearchResultdoneメッセージの代わりにTrueに設定されたrefreshdeleteまたはrefreshpresentの同期情報メッセージを送信することによって示されます。同期操作の更新段階を終えた後、コンテンツの状態を表すために、同期情報メッセージでCookieを返してください。
Change notifications are provided during the persist stage.
変更通知は、永続段階で提供されます。
As updates are made to the DIT, the server notifies the client of changes to the content. DIT updates may cause entries and references to be added to the content, deleted from the content, or modified within the content. DIT updates may also cause references to be added, deleted, or modified within the content.
DITの更新が行われると、サーバーはクライアントにコンテンツの変更を通知します。DITの更新により、エントリと参照がコンテンツに追加されたり、コンテンツから削除されたり、コンテンツ内で変更されたりする場合があります。DITの更新により、コンテンツ内に参照が追加、削除、または変更される場合があります。
Where DIT updates cause an entry to be added to the content, the server provides a SearchResultEntry Message that represents the entry as it appears in the content. The message SHALL include a Sync State Control with state of add, an entryUUID containing the entry's UUID, and an optional cookie.
DITの更新により、エントリがコンテンツに追加される場合、サーバーはコンテンツに表示されるエントリを表すSearchResultentryメッセージを提供します。メッセージには、ADDの状態を備えた同期状態制御、エントリのUUIDを含むエントリuUID、およびオプションのCookieが含まれます。
Where DIT updates cause a reference to be added to the content, the server provides a SearchResultReference Message that represents the reference in the content. The message SHALL include a Sync State Control with state of add, an entryUUID containing the UUID associated with the reference, and an optional cookie.
DITの更新により、参照がコンテンツに追加される場合、サーバーはコンテンツ内の参照を表すSearchResultReferenceメッセージを提供します。このメッセージには、ADDの状態を備えた同期状態制御、参照に関連付けられたUUIDを含むEntruUID、およびオプションのCookieが含まれます。
Where DIT updates cause an entry to be modified within the content, the server provides a SearchResultEntry Message that represents the entry as it appears in the content. The message SHALL include a Sync State Control with state of modify, an entryUUID containing the entry's UUID, and an optional cookie.
DITの更新により、エントリがコンテンツ内で変更される場合、サーバーはコンテンツに表示されるエントリを表すSearchResultentryメッセージを提供します。メッセージには、修正状態を備えた同期状態制御、エントリのUUIDを含むエントリuuid、およびオプションのCookieが含まれます。
Where DIT updates cause a reference to be modified within the content, the server provides a SearchResultReference Message that represents the reference in the content. The message SHALL include a Sync State Control with state of modify, an entryUUID containing the UUID associated with the reference, and an optional cookie.
DITの更新により、コンテンツ内で参照が変更される場合、サーバーはコンテンツ内の参照を表すSearchResultReferenceメッセージを提供します。メッセージには、修正状態を備えた同期状態制御、参照に関連付けられたUUIDを含むentruuid、およびオプションのCookieが含まれます。
Where DIT updates cause an entry to be deleted from the content, the server provides a SearchResultEntry Message with no attributes. The message SHALL include a Sync State Control with state of delete, an entryUUID containing the entry's UUID, and an optional cookie.
DITの更新により、エントリがコンテンツから削除される場合、サーバーは属性のないSearchResultentryメッセージを提供します。メッセージには、deleteの状態を備えた同期状態制御、エントリのUUIDを含むエントリuuid、およびオプションのCookieが含まれます。
Where DIT updates cause a reference to be deleted from the content, the server provides a SearchResultReference Message with an empty SEQUENCE OF LDAPURL. The message SHALL include a Sync State Control with state of delete, an entryUUID containing the UUID associated with the reference, and an optional cookie.
DITの更新により、コンテンツから参照が削除される場合、サーバーはLDAPURLの空のシーケンスを使用してSearchResultReferenceメッセージを提供します。メッセージには、参照に関連付けられたUUIDを含むEntruid、およびオプションのCookieを含むdeleteの状態を備えた同期状態制御を含めるものとします。
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.
状態削除の同期状態制御を備えた複数の空のエントリは、syncidset値の1つまたは複数の同期情報メッセージに合わせて合体して、resuredeletesがtrueに設定されている必要があります。Syncuuidには、コンテンツから削除されたエントリと参照のUUIDのセットが含まれています。同期情報メッセージには、セット内のエントリの同期を実行した後、コンテンツの状態を表すCookieが含まれている場合があります。
With each of these messages, the server may provide a new cookie to be used in subsequent Sync Operations. Additionally, the server may also return Sync Info Messages of choice newCookie to provide a new cookie. The client SHOULD use the newest (last) cookie it received from the server in subsequent Sync Operations.
これらの各メッセージを使用すると、サーバーは、その後の同期操作で使用される新しいCookieを提供する場合があります。さらに、サーバーは、新しいCookieを提供するために、選択したNewCookieの同期情報メッセージを返すこともできます。クライアントは、その後の同期操作でサーバーから受け取った最新（最後の）Cookieを使用する必要があります。
As stated in Section 3.1, the client SHOULD specify the same content-controlling parameters in each Search Request of the session. All fields of the SearchRequest Message are considered content-controlling parameters except for sizeLimit and timeLimit.
セクション3.1で述べたように、クライアントはセッションの各検索要求で同じコンテンツ制御パラメーターを指定する必要があります。SearchRequestメッセージのすべてのフィールドは、SizelimitとTimelimitを除くコンテンツ制御パラメーターと見なされます。
As with the normal search operation, the refresh and persist stages are not isolated from DIT changes. It is possible that the entry referred to by the baseObject is deleted, renamed, or moved. It is also possible that the alias object used in finding the entry referred to by the baseObject is changed such that the baseObject refers to a different entry.
通常の検索操作と同様に、更新および永続段階はDITの変更から分離されていません。BaseObjectが参照するエントリが削除、名前が変更、または移動される可能性があります。BaseObjectが参照するエントリを見つける際に使用されるエイリアスオブジェクトが、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.
SYNC操作の処理中に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 DerefaliaseパラメーターにNeverDereFaliaseまたはDereffindingBaseobjを指定するものとします。サーバーは、他の値（例：Derefinsearching、Derefalways）をプロトコルエラーとして扱うものとします。
The sizeLimit applies only to entries (regardless of their state in Sync State Control) returned during the refreshOnly operation or the refresh stage of the refreshAndPersist operation.
Sizelimitは、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.
爽快な同期操作の場合、TimeLimitは操作全体に適用されます。RefReshandPersistの操作の場合、Timelimitは、Trueの更新値を持つ同期情報メッセージの生成を含む更新段階にのみ適用されます。
The client SHOULD avoid filter assertions that apply to the values of the attributes likely to be considered by the server as ones holding meta-information. See Section 4.
クライアントは、サーバーがメタ情報を保持しているものと見なされる可能性が高い属性の値に適用されるフィルターアサーションを避ける必要があります。セクション4を参照してください。
The Sync Operation uses entryUUID values provided in the Sync State Control as the primary keys to entries. The client MUST use these entryUUIDs to correlate synchronization messages.
同期操作は、同期状態制御で提供されたエントリコンテンツをエントリの主要なキーとして使用します。クライアントは、これらのEntruuidを使用して、同期メッセージを相関させる必要があります。
In some circumstances, the DN returned may not reflect the entry's current DN. In particular, when the entry is being deleted from the content, the server may provide an empty DN if the server does not wish to disclose the entry's current DN (or, if deleted from the DIT, the entry's last DN).
状況によっては、返されたDNはエントリの現在のDNを反映していない場合があります。特に、エントリがコンテンツから削除されている場合、サーバーがエントリの現在のDNを開示したくない場合（または、DITから削除された場合、エントリの最後のDN）をサーバーが空のDNを提供する場合があります。
Also note that the entry's DN may be viewed as meta information (see Section 4.1).
また、エントリのDNはメタ情報と見なされる場合があることに注意してください（セクション4.1を参照）。
Servers MUST implement the LDAP Cancel [RFC3909] Operation and support cancellation of outstanding Sync Operations as described here.
サーバーは、ここで説明するように、LDAPキャンセル[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.
サーバーが同期操作の処理を継続することを不本意または継続したくない場合、サーバーは、操作の終了の理由を示す非サクセス結果コードでSeartResultDoneを返します。
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.
クライアントまたはサーバーが終了を開始したかどうかにかかわらず、サーバーは、その後の同期操作で使用するために同期完了制御でCookieを提供することができます。
In order to achieve the eventually-convergent synchronization, the server may terminate the Sync Operation in the refresh or persist stages by returning an e-syncRefreshRequired resultCode to the client. If no cookie is provided, a full refresh is needed. If a cookie representing a synchronization state is provided in this response, an incremental refresh is needed.
最終的に合成する同期を実現するために、サーバーは、クライアントにe-syncrefreshrequired resultコードを返すことにより、リフレッシュまたは持続段階での同期操作を終了する場合があります。Cookieが提供されていない場合は、完全な更新が必要です。この応答で同期状態を表すCookieが提供されている場合、インクリメンタルリフレッシュが必要です。
To obtain a full refresh, the client then issues a new synchronization request with no cookie. To obtain an incremental reload, the client issues a new synchronization with the provided cookie.
完全に更新するために、クライアントはCookieなしで新しい同期リクエストを発行します。インクリメンタルリロードを取得するために、クライアントは提供されたCookieとの新しい同期を発行します。
The server may choose to provide a full copy in the refresh stage (e.g., ignore the cookie or the synchronization state represented in the cookie) instead of providing an incremental refresh in order to achieve the eventual convergence.
サーバーは、最終的な収束を実現するために、インクリメンタルな更新を提供する代わりに、更新段階で完全なコピーを提供することを選択できます（たとえば、Cookieに表されるCookieまたは同期状態を無視します）。
The decision between the return of the initial content and the return of the e-syncRefreshRequired result code may be based on reloadHint in the Sync Request Control from the client.
初期コンテンツの返品とe-SyncrefreshRequiredの結果コードの返却との間の決定は、クライアントからの同期要求コントロールの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.
永続的なステージ同期の場合、サーバーはクライアントにe-syncrefreshRequedの結果コードを返して、コンテンツの同期コピーを取得するためにクライアントが新しい同期操作を発行する必要があることを示します。Cookieが提供されていない場合は、完全な更新が必要です。同期状態を表すCookieが提供される場合、インクリメンタルリフレッシュが必要です。
The server may also return e-syncRefreshRequired if it determines that a refresh would be more efficient than sending all the messages required for convergence.
サーバーは、収束に必要なすべてのメッセージを送信するよりも更新が効率的であると判断した場合、e-syncrefreshRequedを返す場合があります。
Note that the client may receive one or more of SearchResultEntry, SearchResultReference, and/or Sync Info Messages before it receives a SearchResultDone Message with the e-syncRefreshRequired result code.
クライアントは、e-syncrefreshRequired resultコードを使用してSearchResultdoneメッセージを受信する前に、1つまたは複数の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.
サーバーで維持されている履歴情報の量が、クライアントがまれに爽快に同期する操作を実行するのに十分ではない場合、サーバーがそれらのクライアントが再び接続するまでに不完全な履歴情報（たとえば、切り捨てによる）を持っている可能性があります。
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.
サーバーの実装者は、セッションの複数の同期操作にまたがるおしゃべりさの問題を考慮する必要があります。セクション3.8で述べたように、サーバーは、リロードが現在の操作の下で継続するよりも効率的であると判断した場合、e-SyncrefreshRequedを返すことができます。同期リクエストのReloAdhintがTRUEである場合、サーバーはクライアントにリロードを要求するように指示することなくリロードを開始する場合があります。
The server SHOULD transfer a new cookie frequently to avoid having to transfer information already provided to the client. Even where DIT changes do not cause content synchronization changes to be transferred, it may be advantageous to provide a new cookie using a Sync Info Message. However, the server SHOULD avoid overloading the client or network with Sync Info Messages.
サーバーは、クライアントに既に提供されている情報を転送しないように、新しいCookieを頻繁に転送する必要があります。DITの変更がコンテンツの同期の変更を引き起こさない場合でも、同期情報メッセージを使用して新しいCookieを提供することが有利かもしれません。ただし、サーバーは、同期情報メッセージでクライアントまたはネットワークを過負荷にすることを避ける必要があります。
During persist mode, the server SHOULD coalesce multiple outstanding messages updating the same entry. The server MAY delay generation of an entry update in anticipation of subsequent changes to that entry that could be coalesced. The length of the delay should be long enough to allow coalescing of update requests issued back to back but short enough that the transient inconsistency induced by the delay is corrected in a timely manner.
永続モード中、サーバーは同じエントリを更新する複数の未解決のメッセージを合体する必要があります。サーバーは、合体する可能性のあるエントリのその後の変更を見越して、エントリアップデートの生成を遅らせる場合があります。遅延の長さは、遅延によって誘導される過渡的な矛盾がタイムリーに修正されるほど短いですが、遅延リクエストの合体を許可するのに十分な長さでなければなりません。
The server SHOULD use the syncIdSet Sync Info Message when there are multiple delete or present messages to reduce the amount of synchronization traffic.
サーバーは、同期トラフィックの量を減らすために複数の削除または提示メッセージがある場合、Syncidset Sync情報メッセージを使用する必要があります。
Also note that there may be many clients interested in a particular directory change, and that servers attempting to service all of these at once may cause congestion on the network. The congestion issues are magnified when the change requires a large transfer to each interested client. Implementors and deployers of servers should take steps to prevent and manage network congestion.
また、特定のディレクトリの変更に関心のある多くのクライアントが存在する可能性があり、これらすべてを一度にサービスを提供しようとするサーバーがネットワークに渋滞を引き起こす可能性があることに注意してください。変更には、各関心のあるクライアントへの大規模な転送が必要な場合、混雑の問題が拡大されます。サーバーの実装者と展開者は、ネットワークの混雑を防止および管理するための措置を講じる必要があります。
The LDAP protocol model [RFC4511] allows operations to be multiplexed over a single LDAP session. Clients SHOULD NOT maintain multiple LDAP sessions with the same server. Servers SHOULD ensure that responses from concurrently processed operations are interleaved fairly.
LDAPプロトコルモデル[RFC4511]により、単一のLDAPセッションで操作を多重化できます。クライアントは、同じサーバーで複数のLDAPセッションを維持しないでください。サーバーは、同時に処理された操作からの応答が公正にインターリーブされるようにする必要があります。
Clients SHOULD combine Sync Operations whose result set is largely overlapping. This avoids having to return multiple messages, once for each overlapping session, for changes to entries in the overlap.
クライアントは、結果セットが主に重複している同期操作を組み合わせる必要があります。これにより、オーバーラップのエントリの変更のために、オーバーラップセッションごとに複数のメッセージを返す必要がありません。
Clients SHOULD NOT combine Sync Operations whose result sets are largely non-overlapping. This ensures that an event requiring an e-syncRefreshRequired response can be limited to as few result sets as possible.
クライアントは、結果セットがほとんど重複していない同期操作を組み合わせるべきではありません。これにより、e-SyncrefreshRequered応答を必要とするイベントが、可能な限り少ない結果セットに制限されることが保証されます。
As an entry's DN is constructed from its relative DN (RDN) and the entry's parent's DN, it is often viewed as meta information.
エントリのDNは、相対的なDN（RDN）とエントリの親のDNから構築されているため、多くの場合、メタ情報と見なされます。
While renaming or moving to a new superior causes the entry's DN to change, that change SHOULD NOT, by itself, cause synchronization messages to be sent for that entry. However, if the renaming or the moving could cause the entry to be added or deleted from the content, appropriate synchronization messages should be generated to indicate this to the client.
新しい上司に変更または移動すると、エントリのDNが変更されますが、その変更自体が同期メッセージをそのエントリに送信することはできません。ただし、変更または移動により、エントリがコンテンツから追加または削除される可能性がある場合は、これをクライアントに示すために適切な同期メッセージを生成する必要があります。
When a server treats the entry's DN as meta information, the server SHALL either
サーバーがエントリのDNをメタ情報として扱う場合、サーバーはどちらも
- evaluate all MatchingRuleAssertions [RFC4511] to TRUE if matching a value of an attribute of the entry, otherwise Undefined, or
- エントリの属性の値を一致させる場合は、すべてのmatchingRuleasSertions [rfc4511]をtrueに評価します。
- evaluate all MatchingRuleAssertion with dnAttributes of TRUE as Undefined.
- 未定義のように真のdnattributesを使用して、すべての一致するluleassertionを評価します。
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]を実装するサーバーでは、サブスケマ症属性の同期をサポートしてはなりません。その値は、サブスケマサブエントリで保持され管理されている値によって決定されます。
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]を実装するサーバーは、エイリアスエントリの一部としてその値が保持および管理されているため、エイリアスオブジェクト名属性の同期をサポートできます。
Servers SHOULD support synchronization of the following operational attributes: createTimestamp, modifyTimestamp, creatorsName, modifiersName [RFC4512]. Servers MAY support synchronization of other operational attributes.
サーバーは、次の動作属性の同期をサポートする必要があります：createTimestamp、ModiyTimestamp、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).
ポリシー情報の変更に起因するコンテンツの変更を生成することが非実用的または実行不可能な場合、サーバーはe-SyncrefreshRequedを返したり、同期操作を初期コンテンツリクエストとして扱うことを選択できます（たとえば、CookieまたはCookieまたは同期状態を無視してください。クッキー）。
The Sync Operation may be used with:
同期操作は次のとおりです。
- ManageDsaIT Control [RFC3296]
- マネージドセイトコントロール[RFC3296]
- Subentries Control [RFC3672]
- Subentries Control [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 Control [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.
Subentriesコントロールは、「範囲内にあるエントリとサブエントリの可視性を制御するために」[RFC3672]の検索操作とともに使用されます。同期操作とともに使用すると、Subentriesコントロールおよびその他の要因（検索スコープ、フィルターなど）を使用して、エントリまたはサブエントリーがコンテンツに表示されるかどうかを判断します。
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つの論理サーバーとして表示できます。同期操作のサポートに関して等しく能力があり、エントリの等しく完全なコピーを保持するサーバーのみを、1つの論理サーバーとして表示する必要があります。特に、1つの論理サーバーとして機能する各物理サーバーは、完全なリロードを必要とせずに、他の物理サーバーのいずれかが提供するCookieに基づいて、コンテンツの同期を等しく継続できる必要があります。標準的なLDAPシャドウイングメカニズムがないため、同等に有能なサーバー（および「等しく有能」の正確な定義）を独立して実装する方法の仕様は、将来のドキュメントに任されています。
Note that it may be difficult for the server to reliably determine what content was provided to the client by another server, especially in the shadowing environments that allow shadowing events to be coalesced. For these servers, the use of the delete phase discussed in Section 3.3.2 may not be applicable.
特にシャドーイベントイベントを合体化できるシャドーイング環境では、サーバーが他のサーバーによってクライアントに提供されたコンテンツを確実に決定することは難しい場合があることに注意してください。これらのサーバーの場合、セクション3.3.2で説明した削除フェーズの使用は適用できない場合があります。
In order to maintain a synchronized copy of the content, a client is to delete information from its copy of the content as described above. However, the client may maintain knowledge of information disclosed to it by the server separate from its copy of the content used for synchronization. Management of this knowledge is beyond the scope of this document. Servers should be careful not to disclose information for content the client is not authorized to have knowledge of and/or about.
コンテンツの同期コピーを維持するために、クライアントは、上記のようにコンテンツのコピーから情報を削除することです。ただし、クライアントは、同期に使用されるコンテンツのコピーとは別に、サーバーによって開示された情報の知識を維持する場合があります。この知識の管理は、このドキュメントの範囲を超えています。サーバーは、コンテンツの情報を開示しないように注意する必要があります。
While the information provided by a series of refreshOnly Sync Operations is similar to that provided by a series of Search Operations, persist stage may disclose additional information. A client may be able to discern information about the particular sequence of update operations that caused content change.
一連の爽快な同期操作によって提供される情報は、一連の検索操作によって提供される情報と類似していますが、永続的なステージには追加情報が開示される場合があります。クライアントは、コンテンツの変更を引き起こした特定の更新操作のシーケンスに関する情報を識別できる場合があります。
Implementors should take precautions against malicious cookie content, including malformed cookies or valid cookies used with different security associations and/or protections in an attempt to obtain unauthorized access to information. Servers may include a digital signature in the cookie to detect tampering.
実装者は、情報への不正アクセスを取得するために、異なるセキュリティ関連および/または保護で使用される奇形のCookieまたは有効なCookieを含む、悪意のあるCookieコンテンツに対して予防策を講じる必要があります。サーバーには、改ざんを検出するためにCookieにデジタル署名が含まれる場合があります。
The operation may be the target of direct denial-of-service attacks. Implementors should provide safeguards to ensure the operation is not abused. Servers may place access control or other restrictions upon the use of this operation.
この操作は、直接のサービス拒否攻撃のターゲットである可能性があります。実装者は、操作が乱用されないように保護手段を提供する必要があります。サーバーは、この操作の使用時にアクセス制御またはその他の制限を配置する場合があります。
Note that even small updates to the directory may cause a significant amount of traffic to be generated to clients using this operation. A user could abuse its update privileges to mount an indirect denial of service to these clients, other clients, and/or portions of the network. Servers should provide safeguards to ensure that update operations are not abused.
ディレクトリの小さな更新でさえ、この操作を使用してクライアントにかなりの量のトラフィックが生成される可能性があることに注意してください。ユーザーは、最新の特権を悪用して、これらのクライアント、他のクライアント、および/またはネットワークの一部に間接的なサービスの拒否を取り付けることができます。サーバーは、更新操作が乱用されないことを確認するためにセーフガードを提供する必要があります。
Implementors of this (or any) LDAP extension should be familiar with general LDAP security considerations [RFC4510].
この（または任意の）LDAP拡張の実装者は、一般的なLDAPセキュリティに関する考慮事項[RFC4510]に精通している必要があります。
Registration of the following values have been completed by the IANA [RFC4520].
次の値の登録は、IANA [RFC4520]によって完了しました。
The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the OpenLDAP Foundation, under its IANA-assigned private enterprise allocation [PRIVATE], for use in this specification.
OID ARC 1.3.6.1.4.1.4203.1.9.1は、この仕様で使用するために、IANAが割り当てられた民間企業配分[プライベート]の下で、OpenLdap Foundationによって[割り当て]に割り当てられました。
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
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
This document borrows significantly from the LDAP Client Update Protocol [RFC3928], a product of the IETF LDUP working group. This document also benefited from Persistent Search [PSEARCH], Triggered Search [TSEARCH], and Directory Synchronization [DIRSYNC] works. This document also borrows from "Lightweight Directory Access Protocol (v3)" [RFC2251].
このドキュメントは、IETF LDUPワーキンググループの製品であるLDAPクライアントアップデートプロトコル[RFC3928]から大幅に借用しています。このドキュメントは、永続的な検索[PSEarch]、トリガー検索[Tsearch]、およびディレクトリの同期[dirsync]が機能することからも恩恵を受けました。このドキュメントは、「Lightweight Directory Access Protocol（V3）」[RFC2251]からも借用しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories", RFC 3296, July 2002.
[RFC3296] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）ディレクトリの下位参照」、RFC 3296、2002年7月。
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003.
[RFC3671] Zeilenga、K。、「軽量ディレクトリアクセスプロトコル（LDAP）の集合属性」、RFC 3671、2003年12月。
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3672] Zeilenga、K。、「軽量ディレクトリアクセスプロトコル（LDAP）のサブエントリ」、RFC 3672、2003年12月。
[RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Cancel Operation", RFC 3909, October 2004.
[RFC3909] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）キャンセル操作」、RFC 3909、2004年10月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K。、ed。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、ed。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：ディレクトリ情報モデル」、RFC 4512、2006年6月。
[RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute", RFC 4530, June 2006.
[RFC4530] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）EntryUuid Operational属性」、RFC 4530、2006年6月。
[UUID] International Organization for Standardization (ISO), "Information technology - Open Systems Interconnection - Remote Procedure Call", ISO/IEC 11578:1996
[UUID]国際標準化機関（ISO）、「情報技術 - オープンシステムの相互接続 - リモート手順コール」、ISO/IEC 11578：1996
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[X.501]国際電気通信連合 - 通信標準化セクター、「ディレクトリ - モデル」X.501（1993）（ISO/IEC 9594-2：1994）。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.680]国際電気通信連合 - 通信標準化セクター、「抽象的構文表記1（ASN.1） - 基本表記の仕様」、X.680（1997）（ISO/IEC 8824-1：1998）。
[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(1997) (also ISO/IEC 8825-1:1998).
[X.690]国際電気通信連合 - 通信標準化セクター、「ASN.1エンコーディングルールの仕様：基本エンコーディングルール（BER）、標準エンコードルール（CER）、および区別されたエンコードルール（DER）」、X.690（1997）（ISO/IEC 8825-1：1998）。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl、M.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J. Parham, "Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)", RFC 3928, October 2004.
[RFC3928] Megginson、R.、ed。、Smith、M.、Natkovich、O.、およびJ. Parham、「Lightweight Directory Access Protocol（LDAP）クライアントアップデートプロトコル（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。、「Internet Assigned Numbers Authority（IANA）Lightwight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 4520、2006年6月。
[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers.
[プライベート] IANA、「プライベートエンタープライズ番号」、http：//www.iana.org/assignments/enterprise-numbers。
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt.
[割り当て] OpenLdap Foundation、「OpenLdap Oid Delegations」、http://www.openldap.org/foundation/oid-delegate.txt。
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.500]国際電気通信連合 - 通信標準化セクター、「ディレクトリ - 概念、モデル、サービスの概要」X.500（1993）（また、ISO/IEC 9594-1：1994）。
[X.525] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Replication", X.525(1993).
[X.525]国際電気通信連合 - 通信標準化セクター、「ディレクトリ：レプリケーション」、X.525（1993）。
[DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory Synchronization", Work in Progress.
[dirsync] Armijo、M。、「ディレクトリ同期のためのMicrosoft LDAPコントロール」、進行中の作業。
[PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP Change Notification Mechanism", Work in Progress.
[Psearch] Smith、M.、et al。、「永続的な検索：単純なLDAP変更通知メカニズム」、進行中の作業。
[TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in Progress.
[Tsearch] Wahl、M。、「LDAPV3トリガー検索コントロール」、進行中の作業。
This appendix is provided for informational purposes only; it is not a normative part of the LDAP Content Synchronization Operation's technical specification.
この付録は、情報提供のみを目的としています。これは、LDAPコンテンツ同期操作の技術仕様の規範的な部分ではありません。
This appendix discusses LDAP Content Synchronization Operation server implementation considerations associated with Change Sequence Number based approaches.
この付録では、LDAPコンテンツの同期操作サーバーの実装に関する考慮事項変更シーケンス数ベースのアプローチに関連付けられています。
Change Sequence Number based approaches are targeted for use in servers that do not maintain history information (e.g., change logs, state snapshots) about changes made to the Directory and hence, must rely on current directory state and minimal synchronization state information embedded in Sync Cookie. Servers that maintain history information should consider other approaches that exploit the history information.
シーケンス番号ベースのアプローチの変更は、ディレクトリに加えられた変更に関する履歴情報（例：変更、状態スナップショットなど）を維持しないため、現在のディレクトリ状態に依存し、同期Cookieに組み込まれた最小限の同期状態情報に依存する必要があるサーバーで使用することを目的としています。。履歴情報を維持するサーバーは、履歴情報を活用する他のアプローチを考慮する必要があります。
A Change Sequence Number is effectively a time stamp that has sufficient granularity to ensure that the precedence relationship in time of two updates to the same object can be determined. Change Sequence Numbers are not to be confused with Commit Sequence Numbers or Commit Log Record Numbers. A Commit Sequence Number allows one to determine how two commits (to the same object or different objects) relate to each other in time. A Change Sequence Number associated with different entries may be committed out of order. In the remainder of this Appendix, the term CSN refers to a Change Sequence Number.
変更シーケンス番号は、事実上、同じオブジェクトへの2つの更新の時点で優先順位の関係を決定できるように十分な粒度を備えたタイムスタンプです。シーケンス番号の変更は、コミットシーケンス番号と混同したり、ログ記録番号をコミットしたりしないでください。コミットシーケンス番号を使用すると、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に埋め込みます。これをCookie CSNと呼びます。更新が要求された場合、サーバーは、CSNが提供されたCookie CSNよりも大きいコンテンツのすべてのエントリに対して「更新」メッセージを生成し、コンテンツ内の他のすべてのエントリに対して「現在の」メッセージを生成します。ただし、現在のコンテキストCSNがCookie CSNと同じ場合、サーバーは代わりにゼロ「更新」を生成し、ゼロ「削除」メッセージを生成し、ディレクトリが変更されていないため、trueの更新されたデレートを示します。
The implementation should also consider the impact of changes to meta information, such as access controls, that affect content determination. One approach is for the server to maintain a context-wide meta information CSN or meta CSN. This meta CSN would be updated whenever meta information affecting content determination was changed. If the value of the meta CSN is greater than the cookie CSN, the server should ignore the cookie and treat the request as an initial request for content.
実装では、コンテンツの決定に影響を与えるアクセス制御などのメタ情報への変更の影響も考慮する必要があります。1つのアプローチは、サーバーがコンテキスト全体のメタ情報CSNまたはメタCSNを維持することです。このメタCSNは、コンテンツの決定に影響を与えるメタ情報が変更されたときに更新されます。メタCSNの値がCookie CSNよりも大きい場合、サーバーはCookieを無視し、リクエストをコンテンツの初期リクエストとして扱う必要があります。
Additionally, servers may want to consider maintaining some per-session history information to reduce the number of messages needed to be transferred during incremental refreshes. Specifically, a server could record information about entries as they leave the scope of a disconnected sync session and later use this information to generate delete messages instead of present messages.
さらに、サーバーは、セッションごとの履歴情報を維持して、インクリメンタルリフレッシュ中に転送する必要があるメッセージの数を減らすことを検討することをお勧めします。具体的には、サーバーは、切断された同期セッションの範囲を残しているときにエントリに関する情報を記録し、後でこの情報を使用して現在のメッセージの代わりに削除メッセージを生成することができます。
When the history information is truncated, the CSN of the latest truncated history information entry may be recorded as the truncated CSN of the history information. The truncated CSN may be used to determine whether a client copy can be covered by the history information by comparing it to the synchronization state contained in the cookie supplied by the client.
履歴情報が切り捨てられると、最新の切り捨てられた履歴情報エントリのCSNが、歴史情報の切り捨てられたCSNとして記録される場合があります。切り捨てられたCSNは、クライアントが提供するCookieに含まれる同期状態と比較することにより、クライアントのコピーを履歴情報でカバーできるかどうかを判断するために使用できます。
When there is a large number of sessions, it may make sense to maintain such history only for the selected clients. Also, servers taking this approach need to consider resource consumption issues to ensure reasonable server operation and to protect against abuse. It may be appropriate to restrict this mode of operation by policy.
多数のセッションがある場合、選択したクライアントのみでそのような履歴を維持することは理にかなっているかもしれません。また、このアプローチを採用しているサーバーは、合理的なサーバーの操作を確保し、虐待から保護するためにリソース消費の問題を検討する必要があります。この操作モードをポリシーによって制限することが適切かもしれません。
Authors' Addresses
著者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
Kurt D. Zeilenga OpenLdap Foundation
EMail: Kurt@OpenLDAP.org
Jong Hyuk Choi IBM Corporation
ジョン・ヒョク・チョイ・イブ・コーポレーション
EMail: jongchoi@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、その中に記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。