RFC3928 日本語訳
3928 Lightweight Directory Access Protocol (LDAP) Client UpdateProtocol (LCUP). R. Megginson, Ed., M. Smith, O. Natkovich, J.Parham. October 2004. (Format: TXT=36892 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Megginson, Ed.
Request for Comments: 3928 Netscape Communications Corp.
Category: Standards Track M. Smith
Pearl Crescent, LLC
O. Natkovich
Yahoo
J. Parham
Microsoft Corporation
October 2004
ワーキンググループR.Megginson、エドをネットワークでつないでください。コメントのために以下を要求してください。 3928年のネットスケープ・コミュニケーションズカテゴリ: 標準化過程M.スミス真珠三日月、LLC O.Natkovich Yahoo J.Parhamマイクロソフト社2004年10月
Lightweight Directory Access Protocol (LDAP)
Client Update Protocol (LCUP)
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)クライアントアップデートプロトコル(LCUP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content.
このドキュメントはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)クライアントUpdateプロトコル(LCUP)を定義します。 プロトコルが、LDAPクライアントがLDAPサーバによって保存されるディレクトリ情報木(DIT)の内容に連動して、その内容への変化に関して通知されるのを許容することを意図します。
Megginson, et al. Standards Track [Page 1] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[1ページ]。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification of Protocol Elements . . . . . . . . . . . . . . 5
3.1. ASN.1 Considerations . . . . . . . . . . . . . . . . . . 5
3.2. Universally Unique Identifiers . . . . . . . . . . . . . 5
3.3. LCUP Scheme and LCUP Cookie. . . . . . . . . . . . . . . 5
3.4. LCUP Context . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Additional LDAP Result Codes defined by LCUP . . . . . . 6
3.6. Sync Request Control . . . . . . . . . . . . . . . . . . 7
3.7. Sync Update Control. . . . . . . . . . . . . . . . . . . 7
3.8. Sync Done Control. . . . . . . . . . . . . . . . . . . . 8
4. Protocol Usage and Flow. . . . . . . . . . . . . . . . . . . . 8
4.1. LCUP Search Requests . . . . . . . . . . . . . . . . . . 8
4.1.1. Initial Synchronization and Full Resync . . . . . 9
4.1.2. Incremental or Update Synchronization . . . . . . 10
4.1.3. Persistent Only . . . . . . . . . . . . . . . . . 10
4.2. LCUP Search Responses. . . . . . . . . . . . . . . . . . 10
4.2.1. Sync Update Informational Responses . . . . . . . 11
4.2.2. Cookie Return Frequency . . . . . . . . . . . . . 11
4.2.3. Definition of an Entry That Has Entered the
Result Set. . . . . . . . . . . . . . . . . . . . 12
4.2.4. Definition of an Entry That Has Changed . . . . . 13
4.2.5. Definition of an Entry That Has Left the
Result Set. . . . . . . . . . . . . . . . . . . . 13
4.2.6. Results For Entries Present in the Result Set . . 14
4.2.7. Results For Entries That Have Left the Result
Set . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Responses Requiring Special Consideration . . . . . . . . 15
4.3.1. Returning Results During the Persistent Phase . . 15
4.3.2. No Mixing of Sync Phase with Persist Phase. . . . 16
4.3.3. Returning Updated Results During the Sync Phase . 16
4.3.4. Operational Attributes and Administrative
Entries . . . . . . . . . . . . . . . . . . . . . 16
4.3.5. Virtual Attributes. . . . . . . . . . . . . . . . 17
4.3.6. Modify DN and Delete Operations Applied to
Subtrees. . . . . . . . . . . . . . . . . . . . . 17
4.3.7. Convergence Guarantees. . . . . . . . . . . . . . 18
4.4. LCUP Search Termination. . . . . . . . . . . . . . . . . 18
4.4.1. Server Initiated Termination. . . . . . . . . . . 18
4.4.2. Client Initiated Termination. . . . . . . . . . . 19
4.5. Size and Time Limits . . . . . . . . . . . . . . . . . . 19
4.6. Operations on the Same Connection. . . . . . . . . . . . 19
4.7. Interactions with Other Controls . . . . . . . . . . . . 19
4.8. Replication Considerations . . . . . . . . . . . . . . . 20
5. Client Side Considerations . . . . . . . . . . . . . . . . . . 20
5.1. Using Cookies with Different Search Criteria . . . . . . 20
1. 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 適用性。 . . . . . . . . . . . . . . . . . . . . . . . . 4 3. プロトコル要素. . . . . . . . . . . . . . 5 3.1の仕様。 ASN.1問題. . . . . . . . . . . . . . . . . . 5 3.2。 一般にユニークな識別子. . . . . . . . . . . . . 5 3.3。 LCUP体系とLCUPクッキー。 . . . . . . . . . . . . . . 5 3.4. LCUP文脈. . . . . . . . . . . . . . . . . . . . . . 6 3.5。 LCUP. . . . . . 6 3.6によって定義された追加LDAP Result Codes。 要求コントロール. . . . . . . . . . . . . . . . . . 7 3.7を同期させてください。 アップデートコントロールを同期させてください。 . . . . . . . . . . . . . . . . . . 7 3.8. されたコントロールを同期させてください。 . . . . . . . . . . . . . . . . . . . 8 4. 用法と流れについて議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . 8 4.1. LCUPは要求. . . . . . . . . . . . . . . . . . 8 4.1.1を捜します。 同期と完全なResync. . . . . 9 4.1.2に頭文字をつけてください。 増加かアップデート同期. . . . . . 10 4.1.3。 永続的である、.104.2だけ LCUPは応答を捜します。 . . . . . . . . . . . . . . . . . 10 4.2.1. アップデートの情報の応答. . . . . . . 11 4.2.2を同期させてください。 クッキーリターン頻度. . . . . . . . . . . . . 11 4.2.3。 結果に入ったエントリーの定義はセットしました。 . . . . . . . . . . . . . . . . . . . 12 4.2.4. .5に.134.2を変えたエントリーの定義 結果を残したエントリーの定義はセットしました。 . . . . . . . . . . . . . . . . . . . 13 4.2.6. エントリーへの結果は結果でセット. . 14 4.2.7を提示します。 結果を残したエントリーへの結果は.144.3を設定します。 特別の配慮. . . . . . . . 15 4.3.1を必要とする応答。 帰りは永続的なフェーズ. . 15 4.3.2の間、結果として生じます。 同時性フェーズが混入しない、フェーズを固持してください。 . . . 16 4.3.3. 帰りは同時性フェーズ. 16 4.3.4の間、結果をアップデートしました。 操作上の属性と管理エントリー. . . . . . . . . . . . . . . . . . . . . 16 4.3.5。 仮想の属性。 . . . . . . . . . . . . . . . 17 4.3.6. DNを変更してください、そして、下位木に適用された操作を削除してください。 . . . . . . . . . . . . . . . . . . . . 17 4.3.7. 集合保証。 . . . . . . . . . . . . . 18 4.4. LCUPは終了を捜します。 . . . . . . . . . . . . . . . . 18 4.4.1. サーバは終了を開始しました。 . . . . . . . . . . 18 4.4.2. クライアントは終了を開始しました。 . . . . . . . . . . 19 4.5. サイズとタイムリミット. . . . . . . . . . . . . . . . . . 19 4.6。 同じ接続の操作。 . . . . . . . . . . . 19 4.7. 他のコントロール. . . . . . . . . . . . 19 4.8との相互作用。 模写問題. . . . . . . . . . . . . . . 20 5。 クライアントサイド問題. . . . . . . . . . . . . . . . . . 20 5.1。 異なった検索評価基準. . . . . . 20と共にクッキーを使用します。
Megginson, et al. Standards Track [Page 2] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[2ページ]。
5.2. Renaming the Base Object . . . . . . . . . . . . . . . . 20
5.3. Use of Persistent Searches With Respect to Resources . . 21
5.4. Continuation References to Other LCUP Contexts . . . . . 21
5.5. Referral Handling. . . . . . . . . . . . . . . . . . . . 21
5.6. Multiple Copies of Same Entry During Sync Phase. . . . . 21
5.7. Handling Server Out of Resources Condition . . . . . . . 21
6. Server Implementation Considerations . . . . . . . . . . . . . 22
6.1. Server Support for UUIDs . . . . . . . . . . . . . . . . 22
6.2. Example of Using an RUV as the Cookie Value. . . . . . . 22
6.3. Cookie Support Issues. . . . . . . . . . . . . . . . . . 22
6.3.1. Support for Multiple Cookie Schemes . . . . . . . 22
6.3.2. Information Contained in the Cookie . . . . . . . 23
6.4. Persist Phase Response Time. . . . . . . . . . . . . . . 23
6.5. Scaling Considerations . . . . . . . . . . . . . . . . . 23
6.6. Alias Dereferencing. . . . . . . . . . . . . . . . . . . 24
7. Synchronizing Heterogeneous Data Stores. . . . . . . . . . . . 24
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix - Features Left Out of LCUP . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
5.2. 基地のオブジェクト. . . . . . . . . . . . . . . . 20 5.3を改名します。 永続的の使用はリソース. . 21 5.4に関して探されます。 他のLCUP文脈. . . . . 21 5.5の継続参照。 紹介取り扱い。 . . . . . . . . . . . . . . . . . . . 21 5.6. 同時性段階の間の複本の同じエントリー。 . . . . 21 5.7. リソースからサーバを扱って、.216を条件とさせてください。 サーバ実装問題. . . . . . . . . . . . . 22 6.1。 UUIDs. . . . . . . . . . . . . . . . 22 6.2のサーバサポート。 クッキー値としてRUVを使用する例。 . . . . . . 22 6.3. クッキーサポート問題。 . . . . . . . . . . . . . . . . . 22 6.3.1. 複数のクッキーには、体系. . . . . . . 22 6.3が.2であるとサポートしてください。 クッキー. . . . . . . 23 6.4に含まれた情報。 フェーズ応答時間を固持してください。 . . . . . . . . . . . . . . 23 6.5. 問題. . . . . . . . . . . . . . . . . 23 6.6をスケーリングします。 アリアDereferencing。 . . . . . . . . . . . . . . . . . . 24 7. 異種のデータ・ストアを連動させます。 . . . . . . . . . . . 24 8. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 24 9. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 24 10. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1。 引用規格. . . . . . . . . . . . . . . . . . 25 10.2。 有益な参照. . . . . . . . . . . . . . . . . 26 11。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 26付録--特徴は作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 29をLCUP. . . . . . . . . . . . . . . 27から完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 30に出ました。
1. Overview
1. 概要
The LCUP protocol is intended to allow LDAP clients to synchronize with the content stored by LDAP servers.
LCUPプロトコルが、LDAPクライアントがLDAPサーバによって保存される内容に連動するのを許容することを意図します。
The problem areas addressed by the protocol include:
プロトコルによって扱われた問題領域は:
- Mobile clients that maintain a local read-only copy of the
directory data. While off-line, the client uses the local copy of
the data. When the client connects to the network, it
synchronizes with the current directory content and can optionally
receive notification about the changes that occur while it is on-
line. For example, a mail client can maintain a local copy of the
corporate address book that it synchronizes with the master copy
whenever the client is connected to the corporate network.
- ディレクトリデータの地方の書き込み禁止コピーを維持するモバイルクライアント。 クライアントはデータの地方のコピーをオフラインで使用しますが。 クライアントがネットワークに接続するとき、それは、オンである間、内容をカレントディレクトリと同期させて、起こる変化に関して任意に通知を受け取ることができます。系列。 例えば、メールクライアントはクライアントが企業ネットワークに接続されるときはいつも、それがマスターコピーに連動させる法人のアドレス帳の地方のコピーを維持できます。
- Applications intending to synchronize heterogeneous data stores.
A meta directory application, for instance, would periodically
retrieve a list of modified entries from the directory, construct
the changes and apply them to a foreign data store.
- 異種のデータ・ストアを連動させるつもりであるアプリケーション。 例えば、メタディレクトリアプリケーションは、外国データ・ストアにディレクトリから変更されたエントリーのリストを定期的に検索して、変化を組み立てて、それらを当てはまるでしょう。
Megginson, et al. Standards Track [Page 3] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[3ページ]。
- Clients that need to take certain actions when a directory entry
is modified. For instance, an electronic mail repository may want
to perform a "create mailbox" task when a new person entry is
added to an LDAP directory and a "delete mailbox" task when a
person entry is removed.
- ディレクトリエントリが変更されているとき、ある行動を取る必要があるクライアント。 例えば、人のエントリーを取り除くとき、LDAPディレクトリと「メールボックスを削除してください」というタスクに新しい人のエントリーを追加するとき、電子メール倉庫は「メールボックスを作成してください」というタスクを実行したがっているかもしれません。
The problem areas not being considered:
考えられない問題領域:
- Directory server to directory server synchronization. The IETF is
developing a LDAP replication protocol, called LDUP [RFC3384],
which is specifically designed to address this problem area.
- ディレクトリサーバ同期へのディレクトリサーバ。 IETFはこの問題が領域であると扱うように明確に設計されているLDUP[RFC3384]と呼ばれるLDAP模写プロトコルを開発しています。
There are currently several protocols in use for LDAP client server synchronization. While each protocol addresses the needs of a particular group of clients (e.g., on-line clients or off-line clients), none satisfies the requirements of all clients in the target group. For instance, a mobile client that was off-line and wants to become up to date with the server and stay up to date while connected can't be easily supported by any of the existing protocols.
現在、LDAPクライアントサーバ同期に、使用中のいくつかのプロトコルがあります。 各プロトコルはクライアント(例えば、オンラインクライアントかオフラインクライアント)の特定のグループの必要性を扱いますが、なにもターゲット・グループのすべてのクライアントの要件を満たしません。 例えば、既存のプロトコルのいずれも容易にオフラインであり、サーバで最新になって、接続されている間最新のままでありたがっているモバイルクライアントは、サポートすることができません。
LCUP is designed such that the server does not need to maintain state information specific to individual clients. The server may need to maintain additional state information about attribute modifications, deleted entries, and moved/renamed entries. The clients are responsible for storing the information about how up to date they are with respect to the server's content. LCUP design avoids the need for LCUP-specific update agreements to be made between client and server prior to LCUP use. The client decides when and from where to retrieve the changes. LCUP design requires clients to initiate the update session and "pull" the changes from server.
LCUPは、サーバが個々のクライアントにとって特定に州の情報を保守する必要はないように、設計されています。 サーバは、属性変更、削除されたエントリー、および動くか改名されたエントリーの追加州の情報を保守する必要があるかもしれません。 クライアントは彼らがサーバの内容に関しておよそどれくらい最新であるかという情報を保存するのに責任があります。 LCUPデザインはLCUP使用の前にクライアントとサーバの間で作られるべきLCUP特有のアップデート協定の必要性を避けます。 クライアントは時とどこで変化を検索するかから決めます。 LCUPデザインは、クライアントがアップデートセッションを開始して、サーバから変化を「引くこと」を必要とします。
LCUP operations are subject to administrative and access control policies enforced by the server.
LCUP操作はサーバによって励行される管理とアクセス制御方針を受けることがあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
2. Applicability
2. 適用性
LCUP will work best if the following conditions are met:
以下の条件が満たされると、LCUPはうまくいくでしょう:
1) The server stores some degree of historical state or change
information to reduce the amount of wire traffic required for
incremental synchronizations. The optimal balance between server
state and wire traffic varies amongst implementations and usage
scenarios, and is therefore left in the hands of implementers.
1) サーバは、増加の連動に必要であるワイヤトラフィックの量を減少させるためにいくらかの歴史的な状態か変化情報を保存します。 サーバ状態とワイヤトラフィックの間の最適バランスは、実装と用法シナリオの中で異なって、したがって、implementersに任せます。
Megginson, et al. Standards Track [Page 4] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[4ページ]。
2) The client cannot be assumed to understand the physical
information model (virtual attributes, operational attributes,
subentries, etc.) implemented by the server. Optimizations would
be possible if such assumptions could be made.
2) クライアントがサーバによって実装された物理的な情報モデル(仮想の属性、操作上の属性、副次的記載など)を理解していると思うことができません。そのような仮定をすることができるなら、最適化は可能でしょうに。
3) Meta data changes and renames and deletions of large subtrees are
very infrequent. LCUP makes these assumptions in order to reduce
client complexity required to deal with these special operations,
though when they do occur they may result in a large number of
incremental update messages or a full resync.
3) データが変えて、改名するメタと大きい下位木の削除は非常に珍しいです。 LCUPはこれらの特殊作戦に対処するのに必要であるクライアントの複雑さを減少させるためにこれらの仮定をします、起こると、多くのアップデート増加メッセージか完全な「再-同時性」をもたらすかもしれませんが。
3. Specification of Protocol Elements
3. プロトコル要素の仕様
The following sections define the new elements required to use this protocol.
以下のセクションはこのプロトコルを使用しなければならなかった新しい要素を定義します。
3.1. ASN.1 Considerations
3.1. ASN.1問題
Protocol elements are described using ASN.1 [X.680]. The term "BER- encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC2251]. All ASN.1 in this document uses implicit tags.
プロトコル要素は、ASN.1[X.680]を使用することで説明されます。 「コード化されたBER」という用語は、要素が[RFC2251]のセクション5.1で詳細な制限でBasic Encoding Rules[X.690]を使用することでコード化されることであることを意味します。 すべてのASN.1が本書では内在しているタグを使用します。
3.2. Universally Unique Identifiers
3.2. 一般にユニークな識別子
Distinguished names can change, so are therefore unreliable as identifiers. A Universally Unique Identifier (or UUID for short) MUST be used to uniquely identify entries used with LCUP. The UUID is part of the Sync Update control value (see below) returned with each search result. The server SHOULD provide the UUID as a single valued operational attribute of the entry (e.g., "entryUUID"). We RECOMMEND that the server provides a way to do efficient (i.e., indexed) searches for values of UUID, e.g., by using a search filter like (entryUUID=<some UUID value>) to quickly search for and retrieve an entry based on its UUID. Servers SHOULD use a UUID format as specified in [UUID]. The UUID used by LCUP is a value of the following ASN.1 type:
したがって、分類名は、変化できて、識別子として頼り無いです。 唯一LCUPと共に使用されるエントリーを特定するのに、Universally Unique Identifier(または、略してUUID)を使用しなければなりません。 UUIDはそれぞれの検索結果と共に返されたSync Updateコントロール価値(以下を見る)の一部です。 サーバSHOULDはエントリー(例えば、"entryUUID")のただ一つの評価された操作上の属性としてUUIDを提供します。 entryUUIDは<と等しいです。私たち、サーバがUUIDの値、例えば、検索フィルタを使用することによって効率的な(すなわち、索引をつけられる)検索をする方法を供給するRECOMMENDが好きである、(いくらかのUUID値の>) すぐにエントリーを捜し求めて、検索するのはUUIDを基礎づけました。 サーバSHOULDは[UUID]の指定されるとしてのUUID形式を使用します。 LCUPによって使用されたUUIDは以下のASN.1タイプの値です:
LCUPUUID ::= OCTET STRING
LCUPUUID:、:= 八重奏ストリング
3.3. LCUP Scheme and LCUP Cookie
3.3. LCUP体系とLCUPクッキー
The LCUP protocol uses a cookie to hold the state of the client's data with respect to the server's data. Each cookie format is uniquely identified by its scheme. The LCUP Scheme is a value of the following ASN.1 type:
LCUPプロトコルは、サーバのデータに関してクライアントのデータの状態を保持するのにクッキーを使用します。 それぞれのクッキー形式は体系によって唯一特定されます。 LCUP Schemeは以下のASN.1タイプの値です:
LCUPScheme ::= LDAPOID
LCUPScheme:、:= LDAPOID
Megginson, et al. Standards Track [Page 5] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[5ページ]。
This is the OID which identifies the format of the LCUP Cookie value. The scheme OID, as all object identifiers, MUST be unique for a given cookie scheme. The cookie value may be opaque or it may be exposed to LCUP clients. For cookie schemes that expose their value, the preferred form of documentation is an RFC. It is expected that there will be one or more standards track cookie schemes where the value format is exposed and described in detail.
これはLCUP Cookie価値の形式を特定するOIDです。 すべてのオブジェクト識別子として、与えられたクッキー体系に、体系OIDはユニークであるに違いありません。 クッキー値が不透明であるかもしれませんか、またはそれはLCUPクライアントに暴露されるかもしれません。 それらの値を暴露するクッキー体系のために、ドキュメンテーションの好まれた形はRFCです。 1つ以上の標準化過程クッキー体系が値の形式が詳細に暴露されて、説明されるところにあると予想されます。
The LCUP Cookie is a value of the following ASN.1 type:
LCUP Cookieは以下のASN.1タイプの値です:
LCUPCookie ::= OCTET STRING
LCUPCookie:、:= 八重奏ストリング
This is the actual data describing the state of the client's data. This value may be opaque, or its value may have some well-known format, depending on the scheme.
これはクライアントのデータの状態について説明する実際のデータです。 この値が不透明であるかもしれませんか、または体系によって、値には何らかのよく知られる形式があるかもしれません。
Further uses of the LCUP Cookie value are described below.
LCUP Cookie価値のさらなる用途は以下で説明されます。
3.4. LCUP Context
3.4. LCUP文脈
A part of the DIT which is enabled for LCUP is referred to as an LCUP Context. A server may support one or more LCUP Contexts. For example, a server with two naming contexts may support LCUP in one naming context but not the other, or support different LCUP cookie schemes in each naming context. Each LCUP Context MAY use a different cookie scheme. An LCUP search will not cross an LCUP Context boundary, but will instead return a SearchResultReference message, with the LDAP URL specifying the same host and port as currently being searched, and with the baseDN set to the baseDN of the new LCUP Context. The client is then responsible for issuing another search using the new baseDN, and possibly a different cookie if that LCUP Context uses a different cookie. The client is responsible for maintaining a mapping of the LDAP URL to its corresponding cookie.
LCUPのために有効にされるDITの一部がLCUP Contextと呼ばれます。 サーバは1LCUP Contextsをサポートするかもしれません。 例えば、2が文脈を命名しているサーバは、もう片方ではなく、1つの命名文脈でLCUPをサポートするか、またはそれぞれの命名文脈で異なったLCUPクッキー体系をサポートするかもしれません。 各LCUP Contextは異なったクッキー体系を使用するかもしれません。 代わりに現在捜されるように同じホストとポートを指定するLDAP URL、および新しいLCUP ContextのbaseDNに用意ができているbaseDNと共にSearchResultReferenceメッセージを返す以外に、LCUP検索はLCUP Context境界に交差しないでしょう。 クライアントはその時、そのLCUP Contextが異なったクッキーを使用するなら新しいbaseDN、およびことによると異なったクッキーを使用することで別の検索を発行するのに責任があります。 クライアントは対応するクッキーにLDAP URLに関するマッピングを維持するのに責任があります。
3.5. Additional LDAP Result Codes defined by LCUP
3.5. LCUPによって定義された追加LDAP Result Codes
Implementations of this specification SHALL recognize the following additional resultCode values. The LDAP result code names and numbers defined in the following table have been assigned by IANA per RFC 3383 [RFC3383].
SHALLが、以下の追加resultCodeが評価すると認めるこの仕様の実装。 以下のテーブルで定義されたLDAP結果コードネームと数はRFC3383[RFC3383]あたりのIANAによって割り当てられました。
lcupResourcesExhausted (113) the server is running out of resources
lcupSecurityViolation (114) the client is suspected of malicious
actions
lcupInvalidData (115) invalid scheme or cookie was supplied
by the client
サーバがクライアントのリソースlcupSecurityViolation(114)から実行しているlcupResourcesExhausted(113)が(115)の悪意がある動作lcupInvalidData病人体系について疑われたか、またはクッキーはクライアントによって供給されました。
Megginson, et al. Standards Track [Page 6] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[6ページ]。
lcupUnsupportedScheme (116) The cookie scheme is a valid OID but
is not supported by this server
lcupReloadRequired (117) indicates that client data needs to be
reinitialized. This reason is
returned if the server does not
contain sufficient information to
synchronize the client or if the
server's data was reloaded since the
last synchronization session
クッキーが計画するlcupUnsupportedScheme(116)は有効なOIDですが、lcupReloadRequired(117)が示すクライアントデータが再初期化される必要があるこのサーバによってサポートされません。 サーバがクライアントを連動させることができるくらいの情報を含んでいないか、または前回の同期セッション以来サーバのデータを再び積んだなら、この理由を返します。
The uses of these codes are described below.
これらのコードの用途は以下で説明されます。
3.6. Sync Request Control
3.6. 同時性要求コントロール
The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2] where the controlType is the object identifier 1.3.6.1.1.7.1 and the controlValue, an OCTET STRING, contains a BER-encoded syncRequestControlValue.
Sync Request ControlはcontrolTypeがオブジェクト識別子1.3であるところのLDAP Control[RFC2251、セクション4.1.2]です。.6 .1 .1 .7 .1とcontrolValue(OCTET STRING)はBERによってコード化されたsyncRequestControlValueを含んでいます。
syncRequestControlValue ::= SEQUENCE {
updateType ENUMERATED {
syncOnly (0),
syncAndPersist (1),
persistOnly (2) },
sendCookieInterval [0] INTEGER OPTIONAL,
scheme [1] LCUPScheme OPTIONAL,
cookie [2] LCUPCookie OPTIONAL
}
syncRequestControlValue:、:= 系列updateType ENUMERATED、syncOnly(0)、syncAndPersist(1)、persistOnly(2)、sendCookieInterval[0]INTEGER OPTIONAL、[1] LCUPScheme OPTIONALを計画してください、クッキー[2]LCUPCookie OPTIONAL
sendCookieInterval - the server SHOULD send the cookie back in the Sync Update control value (defined below) for every sendCookieInterval number of SearchResultEntry and SearchResultReference PDUs returned to the client. For example, if the value is 5, the server SHOULD send the cookie back in the Sync Update control value for every 5 search results returned to the client. If this value is absent, zero or less than zero, the server chooses the interval.
sendCookieInterval--サーバSHOULDはクライアントに返されたSearchResultEntryとSearchResultReference PDUsのあらゆるsendCookieInterval番号のためにSync Updateコントロール価値(以下では、定義される)でクッキーを返送します。 例えば、値が5であるなら、サーバSHOULDはクライアントに返された5つの検索結果毎のためにSync Updateコントロール価値でクッキーを返送します。 この値が欠けるなら、ゼロかゼロ未満、サーバが間隔を選びます。
The Sync Request Control is only applicable to the searchRequest message. Use of this control is described below.
Sync Request Controlは単にsearchRequestメッセージに適切です。 このコントロールの使用は以下で説明されます。
3.7. Sync Update Control
3.7. 同時性アップデートコントロール
The Sync Update Control is an LDAP Control [RFC2251, Section 4.1.2] where the controlType is the object identifier 1.3.6.1.1.7.2 and the controlValue, an OCTET STRING, contains a BER-encoded syncUpdateControlValue.
Sync Update ControlはcontrolTypeがオブジェクト識別子1.3であるところのLDAP Control[RFC2251、セクション4.1.2]です。.6 .1 .1 .7 .2とcontrolValue(OCTET STRING)はBERによってコード化されたsyncUpdateControlValueを含んでいます。
Megginson, et al. Standards Track [Page 7] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[7ページ]。
syncUpdateControlValue ::= SEQUENCE {
stateUpdate BOOLEAN,
entryUUID [0] LCUPUUID OPTIONAL, -- REQUIRED for entries --
UUIDAttribute [1] AttributeType OPTIONAL,
entryLeftSet [2] BOOLEAN,
persistPhase [3] BOOLEAN,
scheme [4] LCUPScheme OPTIONAL,
cookie [5] LCUPCookie OPTIONAL
}
syncUpdateControlValue:、:= 系列LCUPUUID OPTIONAL--エントリーへのREQUIRED--ブールstateUpdate entryUUID[0]UUIDAttribute[1]AttributeType OPTIONAL、entryLeftSet[2]のブールの、そして、persistPhase[3]ブールの体系[4]LCUPScheme OPTIONAL、クッキー[5]LCUPCookie OPTIONAL
The field UUIDAttribute contains the name or OID of the attribute that the client should use to perform searches for entries based on the UUID. The client should be able to use it in an equality search filter, e.g., "(<uuid attribute>=<entry UUID value>)" and should be able to use it in the attribute list of the search request to return its value. The UUIDAttribute field may be omitted if the server does not support searching on the UUID values.
分野UUIDAttributeが名前を含んでいるか、またはクライアントが働くのに使用するべきである属性のOIDはUUIDに基づくエントリーを捜し求めます。 クライアントは、平等検索フィルタ、例えば、「(<エントリーUUID<uuid属性>=価値の>)」でそれを使用できるべきであって、値を返すという検索要求の属性リストでそれを使用できるべきです。 サーバがUUID値の探すことをサポートしないなら、UUIDAttribute分野は省略されるかもしれません。
The Sync Update Control is only applicable to SearchResultEntry and SearchResultReference messages. Although entryUUID is OPTIONAL, it MUST be used with SearchResultEntry messages. Use of this control is described below.
Sync Update ControlはSearchResultEntryと単にSearchResultReferenceメッセージに適切です。 entryUUIDはOPTIONALですが、SearchResultEntryメッセージと共にそれを使用しなければなりません。 このコントロールの使用は以下で説明されます。
3.8. Sync Done Control
3.8. コントロールが行われた同時性
The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2] where the controlType is the object identifier 1.3.6.1.1.7.3 and the controlValue contains a BER-encoded syncDoneValue.
Sync Done ControlはcontrolTypeがオブジェクト識別子1.3であるところのLDAP Control[RFC2251、セクション4.1.2]です。.6 .1 .1 .7 .3とcontrolValueはBERによってコード化されたsyncDoneValueを含んでいます。
syncDoneValue ::= SEQUENCE {
scheme [0] LCUPScheme OPTIONAL,
cookie [1] LCUPCookie OPTIONAL
}
syncDoneValue:、:= 系列体系[0]LCUPScheme OPTIONAL、クッキー[1]LCUPCookie OPTIONAL
The Sync Done Control is only applicable to SearchResultDone message. Use of this control is described below.
Sync Done Controlは単にSearchResultDoneメッセージに適切です。 このコントロールの使用は以下で説明されます。
4. Protocol Usage and Flow
4. プロトコル用法と流れ
4.1. LCUP Search Requests
4.1. LCUP検索要求
A client initiates a synchronization or persistent search session with a server by attaching a Sync Request control to an LDAP searchRequest message. The search specification determines the part of the directory information tree (DIT) the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. The Sync Request control contains the client's request specification.
クライアントは、Sync RequestコントロールをLDAP searchRequestメッセージに取り付けることによって、サーバとの同期か永続的な検索セッションを開始します。 検索仕様はクライアントが連動したがっているディレクトリ情報木(DIT)の部分、それが興味を持っている属性のセット、およびクライアントが受け取っても構わないと思っているデータ量を測定します。 Sync Requestコントロールはクライアントの要求仕様を含んでいます。
Megginson, et al. Standards Track [Page 8] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[8ページ]。
If there is an error condition, the server MUST immediately return a SearchResultDone message with the resultCode set to an error code. This table maps a condition to its corresponding behavior and resultCode.
エラー条件があれば、サーバはすぐに、resultCodeセットがあるSearchResultDoneメッセージをエラーコードに返さなければなりません。 このテーブルはその対応する振舞いとresultCodeに状態を写像します。
Condition Behavior or resultCode
状態の振舞いかresultCode
Sync Request Control is not Server behaves as [RFC2251, Section
supported 4.1.2] - specifically, if the
criticality of the control is FALSE,
the server will process the request
as a normal search request
同時性Request ControlがServerが振る舞うということでない、[RFC2251、セクションは4.1に.2を]サポートしました--明確に、コントロールの臨界がFALSEであるなら、サーバは通常の検索要求として要求を処理するでしょう。
Scheme is not supported lcupUnsupportedScheme
体系はlcupUnsupportedSchemeであるとサポートされません。
A control value field is lcupInvalidData invalid (e.g., illegal updateType, or the scheme is not a valid OID, or the cookie is invalid)
コントロール値の分野はlcupInvalidData病人です。(例えば、不法なupdateType、体系が有効なOIDでないクッキーが無効である、)
Server is running out of lcupResourcesExhausted resources
サーバはlcupResourcesExhaustedリソースを使い果たしています。
Server suspects client of lcupSecurityViolation malicious behavior (frequent connects/disconnects, etc.)
サーバはlcupSecurityViolation悪意のある態度のクライアントを疑います。(頻繁である、接続、/分離など)
The server cannot bring the lcupReloadRequired client up to date (server data has been reloaded, or other changes prevent convergence)
サーバはlcupReloadRequiredクライアントを最新の状態にすることができません。(サーバデータを再び積んであるか、または他の変化は集合を防ぎます)
4.1.1. Initial Synchronization and Full Resync
4.1.1. 初並列と完全なResync
For an initial synchronization or full resync, the fields of the Sync Request control MUST be specified as follows:
初並列か完全な「再-同時性」として、以下の通りSync Requestコントロールの分野を指定しなければなりません:
updateType - MUST be set to syncOnly or syncAndPersist
sendCookieInterval - MAY be set
scheme - MAY be set - if set, the server MUST use this
specified scheme or return lcupUnsupportedScheme
(see above) - if not set, the server MAY use any
scheme it supports.
cookie - MUST NOT be set
設定されるならupdateType(syncOnlyかsyncAndPersist sendCookieIntervalに設定しなければならない)がセット体系であるかもしれない(設定されるかもしれない)、サーバがこの指定された体系を使用しなければなりませんか、または設定されないなら、サーバがそれが. クッキーを支えるどんな体系も使用するかもしれないというリターンlcupUnsupportedScheme(上を見る)は用意ができてはいけません。
Megginson, et al. Standards Track [Page 9] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[9ページ]。
If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
要求がうまくいったなら、クライアントは以下の「LCUP検索応答」というセクションで説明されるように結果を受けるでしょう。
4.1.2. Incremental or Update Synchronization
4.1.2. 増加かアップデート同期
For an incremental or update synchronization, the fields of the Sync Request control MUST be specified as follows:
増加かアップデート同期として、以下の通りSync Requestコントロールの分野を指定しなければなりません:
updateType - MUST be set to syncOnly or syncAndPersist sendCookieInterval - MAY be set scheme - MUST be set cookie - MUST be set
updateType(セット体系--設定しなければならないのが、クッキーであったかもしれないならsyncOnlyかsyncAndPersist sendCookieIntervalに設定しなければならない)は用意ができなければなりません。
The client SHOULD always use the latest cookie it received from the server.
クライアントSHOULDはいつもそれがサーバから受けた最新のクッキーを使用します。
If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
要求がうまくいったなら、クライアントは以下の「LCUP検索応答」というセクションで説明されるように結果を受けるでしょう。
4.1.3. Persistent Only
4.1.3. 永続的である、唯一
For persistent only search request, the fields of the Sync Request MUST be specified as follows:
永続的である、以下の通り検索要求だけ、Sync Requestの分野を指定しなければなりません:
updateType - MUST be set to persistOnly
sendCookieInterval - MAY be set
scheme - MAY be set - if set, the server MUST use this
specified scheme or return
lcupUnsupportedScheme (see above) - if not set,
the server MAY use any scheme it supports.
cookie - MAY be set, but the server MUST ignore it
設定されるならupdateType(persistOnly sendCookieIntervalに設定しなければならない)がセット体系であるかもしれない(設定されるかもしれない)、サーバがこの指定された体系を使用しなければなりませんか、設定されないなら、サーバがそれが. クッキーを支えるどんな体系も使用するかもしれないというリターンlcupUnsupportedScheme(上を見る)は用意ができるかもしれませんが、またはサーバはそれを無視しなければなりません。
If the request was successful, the client will receive results as described in the section "LCUP Search Responses" below.
要求がうまくいったなら、クライアントは以下の「LCUP検索応答」というセクションで説明されるように結果を受けるでしょう。
4.2. LCUP Search Responses
4.2. LCUP検索応答
In response to the client's LCUP request, the server returns zero or more SearchResultEntry or SearchResultReference PDUs that fit the client's specification, followed by a SearchResultDone PDU. The behavior is as specified in [RFC2251 Section 4.5]. Each SearchResultEntry or SearchResultReference PDU also contains a Sync Update control that describes the LCUP state of the returned entry. The SearchResultDone PDU contains a Sync Done control. The following sections specify behaviors in addition to [RFC2251 Section 4.5].
クライアントのLCUP要求、サーバリターンゼロ、より多くのSearchResultEntryまたはSearchResultReference PDUsに対応して、それはSearchResultDone PDUによって従われたクライアントの仕様に合いました。 振舞いが[RFC2251セクション4.5]で指定されるようにあります。 また、各SearchResultEntryかSearchResultReference PDUが返されたエントリーのLCUP状態について説明するSync Updateコントロールを含んでいます。 SearchResultDone PDUはSync Doneコントロールを含んでいます。 以下のセクションは[RFC2251セクション4.5]に加えて振舞いを指定します。
Megginson, et al. Standards Track [Page 10] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[10ページ]。
4.2.1 Sync Update Informational Responses
4.2.1 同時性のアップデートの情報の応答
The server may use the Sync Update control to return information not related to a particular entry. It MAY do this at any time to return a cookie to the client, or to inform the client that the sync phase of a syncAndPersist search is complete and the persist phase has begun. It MAY do this during the persist phase even though no entry has changed that would have normally triggered a response. In order to do this, it is REQUIRED to return the following:
サーバは、特定のエントリーに関連しない情報を返すのにSync Updateコントロールを使用するかもしれません。 フェーズを固持してください。そして、クッキーをクライアントに返すか、またはsyncAndPersist検索の同時性フェーズが完全であることをクライアントに知らせるのがいつでもこれをするかもしれない、始まりました。 これをするかもしれない、いいえがエントリーで変える通常、そうしたa応答の引き金となりましたが、フェーズを固持してください。 これをして、それは以下を返すREQUIREDです:
- A SearchResultEntry PDU with the objectName field set to the DN of
the baseObject of the search request and with an empty attribute
list.
- objectName分野があるSearchResultEntry PDUは検索要求と空の属性リストでbaseObjectのDNにセットしました。
- A Sync Update control value with the fields set to the following:
- 分野があるSync Updateコントロール価値は以下にセットしました:
stateUpdate - MUST be set to TRUE
entryUUID - SHOULD be set to the UUID of the baseObject of the
search request
entryLeftSet - MUST be set to FALSE
persistPhase - MUST be FALSE if the search is in the sync phase of a
request, and MUST be TRUE if the search is in the
persist phase
UUIDAttribute - SHOULD only be set if this is either the first result
returned or if the attribute has changed
scheme - MUST be set if the cookie is set and the cookie
format has changed; otherwise, it MAY be omitted
cookie - SHOULD be set
stateUpdateに、TRUE entryUUIDに設定しなければなりません--SHOULDが検索が要求の同時性フェーズにあるならentryLeftSet(FALSE persistPhaseに設定しなければならない)がFALSEであるに違いないという検索要求のbaseObjectのUUIDに設定されて、中に検索があるならTRUEであるに違いない、フェーズUUIDAttributeを固持してください--、SHOULD、これが最初の結果が返したどちらかか属性が(体系を);クッキーが設定されて、クッキー形式が変化したなら設定しなければならない--変えたなら、単に設定されてください。 さもなければ、それは省略されたクッキーであるかもしれません--、SHOULD、設定されてください。
If the server merely wants to return a cookie to the client, it should return as above with the cookie field set.
サーバが単にクッキーをクライアントに返したいなら、それはクッキー分野セットと共に同じくらい上に戻るべきです。
During a syncAndPersist request, the server MUST return (as above) immediately after the last entry of the sync phase has been sent and before the first entry of the persist phase has been sent. In this case, the persistPhase field MUST be set to TRUE. This allows the client to know that the sync phase is complete and the persist phase is starting.
フェーズを固持してください。syncAndPersist要求の間、サーバが同時性フェーズの最後のエントリーを送った直後初記入の前に(as above)を返さなければならない、送りました。 この場合、persistPhase分野をTRUEに設定しなければなりません。 フェーズを固持してください。そして、クライアントが、これで同時性フェーズが完全であることを知ることができる、始まっています。
4.2.2 Cookie Return Frequency
4.2.2 クッキーリターン頻度
The cookie field of the Sync Update control value MAY be set in any returned result, during both the sync phase and the persist phase. The server should return the cookie to the client often enough for the client to resync in a reasonable period of time in case the search is disconnected or otherwise terminated. The sendCookieInterval field in the Sync Request control is a suggestion
そして、Sync Updateコントロール価値のクッキー分野はどんな返された結果でも設定されるかもしれません、両方の間の同時性フェーズ、フェーズを固持してください。 検索が切断されるといけないか、または別の方法で終えられるといけないので、サーバは適正な期間に「再-同時性」へのクライアントのために十分しばしばクッキーをクライアントに返すべきです。 Sync RequestコントロールにおけるsendCookieInterval分野は提案です。
Megginson, et al. Standards Track [Page 11] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[11ページ]。
to the server of how often to return the cookie in the Sync Update control. The server SHOULD respect this value.
Sync Updateでどうしばしばクッキーを返すかに関するサーバに、制御してください。 サーバSHOULDはこの値を尊敬します。
The scheme field of the Sync Update control value MUST be set if the cookie is set and the cookie format has changed; otherwise, it MAY be omitted.
クッキーが設定されるなら、Sync Updateコントロール価値の体系分野を設定しなければなりません、そして、クッキー形式は変化しました。 さもなければ、それは省略されるかもしれません。
Some clients may have unreliable connections, for example, a wireless device or a WAN connection. These clients may want to insure that the cookie is returned often in the Sync Update control value, so that if they have to reconnect, they do not have to process many redundant entries. These clients should set the sendCookieInterval in the Sync Request control value to a low number, perhaps even 1. Some clients may have a limited bandwidth connection, and may not want to receive the cookie very often, or even at all (however, the cookie is always sent back in the Sync Done control value upon successful completion). These clients should set the sendCookieInterval in the Sync Request control value to a high number.
例えば頼り無い接続、ワイヤレス機器またはWAN接続がいるクライアントもいるかもしれません。 これらのクライアントは、クッキーがSync Updateコントロール価値でしばしば返されるのを保障したがっているかもしれません、再接続しなければならないなら、彼らが多くの余分なエントリーを処理する必要はないように。 これらのクライアントは低い数字、恐らく同等の1へのSync Requestコントロール価値にsendCookieIntervalをはめ込むべきです。 全くも限られた帯域幅接続があって、クッキーを頻繁に受け取りたがっていない(しかしながら、クッキーは無事終了のSync Doneコントロール価値でいつも返送されます)クライアントも、いるかもしれません。 これらのクライアントは大きい数へのSync Requestコントロール価値にsendCookieIntervalをはめ込むべきです。
A reasonable behavior of the server is to return the cookie only when data in the LCUP context has changed, even if the client has specified a frequent sendCookieInterval. If nothing has changed, the server can probably save some bandwidth by not returning the cookie.
サーバの合理的な働きはLCUP文脈のデータが変化したときだけ、クッキーを返すことです、クライアントが頻繁なsendCookieIntervalを指定したとしても。 何も変化していないなら、サーバは、たぶん戻らないのによるいくらかの帯域幅がクッキーであると保存することができます。
4.2.3. Definition of an Entry That Has Entered the Result Set
4.2.3. 結果に入ったエントリーの定義はセットしました。
An entry SHALL BE considered to have entered the client's search result set if one of the following conditions is met:
以下の条件の1つが会われるなら、SHALL BEがクライアントの検索結果に入ったと考えたエントリーはセットしました:
- During the sync phase for an incremental sync operation, the entry
is present in the search result set but was not present before;
this can be due to the entry being added via an LDAP Add
operation, or by the entry being moved into the result set by an
LDAP Modify DN operation, or by some modification to the entry
that causes it to enter the result set (e.g., adding an attribute
value that matches the clients search filter), or by some meta-
data change that causes the entry to enter the result set (e.g.,
relaxing of some access control that permits the entry to be
visible to the client).
- 増加の同時性操作のための同時性段階の間、エントリーは設定しますが、結果が存在していなかった検索で存在しています。 これはLDAP Add操作LDAP Modify DN操作で結果セットに動かされるエントリー、エントリーへのそれが結果セット(例えば、合っている属性値を加えますクライアント検索がフィルターにかける)に入る何らかの変更、またはエントリーが結果セット(例えば、クライアントにとって、エントリーが目に見えることを許可する何らかのアクセス制御のリラックス)に入るいくらかのメタデータ変化によって加えられるエントリーのためであることができます。
- During the persist phase for a persistent search operation, the
entry enters the search result set; this can be due to the entry
being added via an LDAP Add operation, or by the entry being moved
into the result set by an LDAP Modify DN operation, or by some
modification to the entry that causes it to enter the result set
(e.g., adding an attribute value that matches the clients search
filter), or by some meta-data change that causes the entry to
- 永続的な索敵行動のためにフェーズを固持してください、そして、エントリーは検索結果セットに入ります。 これはLDAP Add操作で加えられるエントリー、またはLDAP Modify DN操作、エントリーへのそれが結果セット(例えば、合っている属性値を加えますクライアント検索がフィルターにかける)に入る何らかの変更、またはそれがエントリーを引き起こすいくらかのメタデータ変化で結果セットに感動しているエントリーであることができます。
Megginson, et al. Standards Track [Page 12] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[12ページ]。
enter the result set (e.g., relaxing of some access control that
permits the entry to be visible to the client).
結果セット(例えば、クライアントにとって、エントリーが目に見えることを許可する何らかのアクセス制御のリラックス)に入ってください。
4.2.4. Definition of an Entry That Has Changed
4.2.4. 変化したエントリーの定義
An entry SHALL BE considered to be changed if one or more of the attributes in the attribute list in the search request have been modified. For example, if the search request listed the attributes "cn sn uid", and there is an entry in the client's search result set with the "cn" attribute that has been modified, the entry is considered to be modified. The modification may be due to an LDAP Modify operation or by some change to the meta-data for the entry (e.g., virtual attributes) that causes some change to the value of the specified attributes.
属性リストの属性が検索要求で1つかまだ変更されているならSHALL BEが変えられると考えたエントリー。 例えば、検索要求が属性"cn sn uid"を記載して、エントリーが変更された"cn"属性で設定されたクライアントの検索結果にあれば、エントリーが変更されると考えられます。 指定された属性の値へのいくらかの変化を引き起こすエントリー(例えば、仮想の属性)には変更がLDAP Modify操作かメタデータへのいくらかの変化であるかもしれません。
The converse of this is that an entry SHALL NOT BE considered to be changed if none of the attributes in the attribute list of the search request are modified attributes of the entry. For example, if the search request listed the attributes "cn sn uid", and there is an entry in the client's search result set with the "foo" attribute that has been modified, and none of the "cn" or "sn" or "uid" attributes have been modified, the entry is NOT considered to be changed.
この逆は検索要求の属性リストの属性のいずれがエントリーの変更された属性でないならSHALL NOT BEが考えたエントリーを変えるということです。 例えば、検索要求が属性"cn sn uid"を記載して、エントリーが変更された"foo"属性で設定されたクライアントの検索結果にあって、"cn"、"sn"または"uid"属性のいずれも変更されていないなら、エントリーが変えられると考えられません。
4.2.5. Definition of an Entry That Has Left the Result Set
4.2.5. 結果が設定される状態で残したエントリーの定義
An entry SHALL BE considered to have left the client's search result set if one of the following conditions is met:
以下の条件の1つが会われるなら、SHALL BEがクライアントの検索を結果に残したと考えたエントリーはセットしました:
- During the sync phase for an incremental sync operation, the entry
is not present in the search result set but was present before;
this can be due to the entry being deleted via an LDAP Delete
operation, or by the entry leaving the result set via an LDAP
Modify DN operation, or by some modification to the entry that
causes it to leave the result set (e.g., changing/removing an
attribute value so that it no longer matches the client's search
filter), or by some meta-data change that causes the entry to
leave the result set (e.g., adding of some access control that
denies the entry to be visible to the client).
- 増加の同時性操作のための同時性段階の間、エントリーは設定しますが、結果が存在していた検索で存在していません。 これはLDAP Delete操作結果がLDAP Modify DN操作で設定される状態で残すエントリー、エントリーへのそれが結果を設定された(例えば、もうクライアントのものを合わせないように属性値を変えるか、または取り除いて、フィルタを捜してください)ままにする何らかの変更、またはエントリーが結果を設定されたままにする(例えば、それが、クライアントにとって、エントリーが目に見えることを否定すると何らかのアクセス制御を言い足します)いくらかのメタデータ変化によって削除されるエントリーのためであることができます。
- During the persist phase for a persistent search operation, the
entry leaves the search result set; this can be due to the entry
being deleted via an LDAP Delete operation, or by the entry
leaving the result set via an LDAP Modify DN operation, or by some
modification to the entry that causes it to leave the result set
(e.g., changing/removing an attribute value so that it no longer
matches the client's search filter), or by some meta-data change
- 永続的な索敵行動のためにフェーズを固持してください、そして、エントリーは検索結果を設定されたままにします。 これはLDAP Delete操作結果がLDAP Modify DN操作で設定される状態で残すエントリー、それが結果を設定された(例えば、もうクライアントのものを合わせないように属性値を変えるか、または取り除いて、フィルタを捜してください)ままにするエントリーへの何らかの変更、またはいくらかのメタデータ変化によって削除されるエントリーのためであることができます。
Megginson, et al. Standards Track [Page 13] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[13ページ]。
that causes the entry to leave the result set (e.g., adding of
some access control that denies the entry to be visible to the
client).
それで、エントリーは結果を設定されたままにします(例えば、それが、クライアントにとって、エントリーが目に見えることを否定すると何らかのアクセス制御を言い足します)。
4.2.6. Results For Entries Present in the Result Set
4.2.6. 結果における現在のエントリーへの結果はセットしました。
An entry SHOULD be returned as present under the following conditions:
エントリーSHOULD、プレゼントとして、以下の条件のもとで返してください:
- The request is an initial synchronization or full resync request
and the entry is present in the client's search result set
- 要求は、初並列か完全な「再-同時性」要求です、そして、エントリーはクライアントの検索結果セットで存在しています。
- The request is an incremental synchronization and the entry has
changed or entered the result set since the last sync
- 要求が増加の同期であり、最後の同時性以来、エントリーは、結果セットに変えるか、または入っています。
- The search is in the persist phase and the entry enters the result
set or changes
- 検索がある、フェーズを固持してください。そうすれば、エントリーは結果セットか変化に入ります。
For a SearchResultEntry return, the fields of the Sync Update control value MUST be set as follows:
SearchResultEntryリターンにおいて、以下の通りSync Updateコントロール価値の分野を設定しなければなりません:
stateUpdate - MUST be set to FALSE
entryUUID - MUST be set to the UUID of the entry
entryLeftSet - MUST be set to FALSE
persistPhase - MUST be set to FALSE if during the sync phase or TRUE
if during the persist phase
UUIDAttribute - SHOULD only be set if this is either the first result
returned or if the attribute has changed
scheme - as above
cookie - as above
stateUpdate(エントリーのUUIDへのセットがentryLeftSetであったに違いないならFALSE entryUUIDに設定しなければならない)がFALSE persistPhase--同時性段階の間FALSEに設定しなければならないか、TRUEに用意ができなければならない、フェーズUUIDAttributeを固持してください--、SHOULD、これが最初の結果が返したどちらかなら単にセットになりなさいか、または属性が変化したなら、クッキーのように同じくらい上に計画してください。
The searchResultReference return will look the same, except that the entryUUID is not required. If it is specified, it MUST contain the UUID of the DSE holding the reference knowledge.
entryUUIDは必要でないのを除いて、searchResultReferenceリターンが同じに見えるでしょう。 指定されるなら、それは参照知識を保持するDSEのUUIDを含まなければなりません。
4.2.7. Results For Entries That Have Left the Result Set
4.2.7. 結果が設定される状態で残したエントリーへの結果
An entry SHOULD be returned as having left the result set under the following conditions:
エントリーSHOULD、結果を以下の条件のもとで設定されたままにしたとして、返してください:
- The request is an incremental synchronization during the sync
phase and the entry has left the result set
- 要求は同時性段階の間、増加の同期です、そして、エントリーは結果を設定されたままにしました。
- The search is in the persist phase and the entry has left the
result set
- 検索がある、フェーズを固持してください。そうすれば、エントリーは結果を設定されたままにしました。
Megginson, et al. Standards Track [Page 14] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[14ページ]。
- The entry has left the result set as a result of an LDAP Delete or
LDAP Modify DN operation against the entry itself (i.e., not as a
result of an operation against its parent or ancestor)
- エントリーは結果をLDAP DeleteかLDAP Modify DN操作の結果、エントリー自体に対して設定されたままにしました。(すなわち、その親か先祖に対する操作の結果、)
For a SearchResultEntry return where the entry has left the result set, the fields of the Sync Update control value MUST be set as follows:
SearchResultEntryリターンにおいて、エントリーが結果を設定されたままにしたところに以下の通りSync Updateコントロール価値の分野を設定しなければなりません:
stateUpdate - MUST be set to FALSE
entryUUID - MUST be set to the UUID of the entry that left the
result set
entryLeftSet - MUST be set to TRUE
persistPhase - MUST be set to FALSE if during the sync phase or TRUE
if during the persist phase
UUIDAttribute - SHOULD only be set if this is either the first result
returned or if the attribute has changed
scheme - as above
cookie - as above
stateUpdate(FALSE entryUUIDに設定しなければならない)が同時性段階の間セットentryLeftSet(TRUE persistPhaseに設定しなければならない)がFALSEに用意ができなければならないという結果を残したエントリーかTRUEのUUIDに用意ができなければならない、フェーズUUIDAttributeを固持してください--、SHOULD、これが最初の結果が返したどちらかなら単にセットになりなさいか、または属性が変化したなら、クッキーのように同じくらい上に計画してください。
The searchResultReference return will look the same, except that the entryUUID is not required. If it is specified, it MUST contain the UUID of the DSE holding the reference knowledge.
entryUUIDは必要でないのを除いて、searchResultReferenceリターンが同じに見えるでしょう。 指定されるなら、それは参照知識を保持するDSEのUUIDを含まなければなりません。
Some server implementations keep track of deleted entries using a tombstone - a hidden entry that keeps track of the state, but not all of the data, of an entry that has been deleted. In this case, the tombstone may not contain all of the original attributes of the entry, and therefore it may be impossible for the server to determine if an entry should be removed from the result set based on the attributes in the client's search request. Servers SHOULD keep enough information about the attributes in the deleted entries to determine if an entry should be removed from the result set. Since this may not be possible, the server MAY return an entry as having left the result set even if it is not or never was in the client's result set. Clients MUST ignore these notifications.
いくつかのサーバ実装が墓石を使用することで削除されたエントリーの動向をおさえます--隠された状態の動向をおさえますが、すべて動向をおさえるというわけではないデータ、削除されたエントリーのエントリー。 この場合、墓石はエントリーの元の属性のすべてを含まないかもしれません、そして、したがって、サーバが、エントリーがクライアントの検索要求で属性に基づく結果セットから取り除かれるべきであるかどうか決定するのは、不可能であるかもしれません。 サーバSHOULDは削除されたエントリーにおける属性のエントリーが結果セットから取り除かれるべきであるかどうか決定できるくらいの情報を保ちます。 これが可能でないかもしれないので、結果を残したのはそれがセットしなかったとしてもセットしたか、またはクライアントの結果セットに決してなかったとき、サーバがエントリーを返すかもしれません。 クライアントはこれらの通知を無視しなければなりません。
4.3. Responses Requiring Special Consideration
4.3. 特別の配慮を必要とする応答
The following sections describe special handling that may be required when returning results.
以下のセクションは結果を返すとき必要であるかもしれない特別な取り扱いについて説明します。
4.3.1. Returning Results During the Persistent Phase
4.3.1. 永続的な段階の間、結果を返します。
During the persistent phase, the server SHOULD return the changed entries to the client as quickly as possible.
永続的な段階の間、サーバSHOULDはできるだけはやく変えられたエントリーをクライアントに返します。
Megginson, et al. Standards Track [Page 15] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[15ページ]。
4.3.2. No Mixing of Sync Phase with Persist Phase
4.3.2. 同時性フェーズが混入しない、フェーズを固持してください。
During a sync phase, the server MUST NOT return any entries with the persistPhase flag set to TRUE, and during the persist phase, all entries returned MUST have the persistPhase flag set to TRUE. The server MUST NOT mix and match sync phase entries with persist phase entries. If there are any sync phase entries to return, they MUST be returned before any persist phase entries are returned.
そして、同時性段階の間、サーバがTRUEに設定されたpersistPhase旗で少しのエントリーも返してはいけない、フェーズを固持してください、そして、エントリーが返したすべてがpersistPhase旗をTRUEに設定させなければなりません。 サーバは混入してはいけません、そして、同時性がエントリーの位相を合わせるマッチはフェーズエントリーを固持しています。 何か返す同時性フェーズエントリーがあれば、それらはいずれも固執する前に返して、フェーズエントリーを返すということであるに違いありません。
4.3.3. Returning Updated Results During the Sync Phase
4.3.3. 帰りは同時性段階の間、結果をアップデートしました。
There may be updates to the entries in the result set of a sync phase search during the actual search operation. If the DSA is under a heavy update load, and it attempts to send all of those updated entries to the client in addition to the other updates it was already planning to send for the sync phase, the server may never get to the end of the sync phase. Therefore, it is left up to the discretion of the server implementation to decide when the client is "in sync" - that is, when to end a syncOnly request, or when to send the Sync Update Informational Response between the sync phase and the persist phase of a syncAndPersist request. The server MAY send the same entry multiple times during the sync phase if the entry changes during the sync phase.
実際の索敵行動の間、同時性フェーズ検索の結果セットにエントリーへのアップデートがあるかもしれません。 DSAが重いアップデート負荷の下にあって、それが同時性フェーズのために送るのを既に計画していた他のアップデートに加えてそれらのアップデートされたエントリーのすべてをクライアントに送るのを試みるなら、サーバは同時性フェーズの終わりを決して始めないかもしれません。 そして、したがって、それがすなわちいつa syncOnlyが要求する終わりまで「同時性」にはクライアントがいるか、そして、またはいつ同時性フェーズの間にSync Update Informational Responseを送るかを決めるのがサーバ実装の思慮深さに任せられる、syncAndPersist要求のフェーズを固持してください。 エントリーが同時性段階の間、変化するなら、サーバは同時性段階の間の複数の回を同じエントリーに送るかもしれません。
A reasonable behavior is for the server to generate a cookie based on the server state at the time the client initiated the LCUP request, and only send entries up to that point during the sync phase. Entries updated after that point will be returned only during the persist phase of a syncAndPersist request, or only upon an incremental synchronization.
合理的な振舞いは、サーバがクライアントがLCUP要求を開始したときサーバ状態に基づくクッキーを生成して、同時性段階の間、エントリーをそのポイントまで送るだけであることです。 そのポイントを返した後にアップデートするエントリーだけ、syncAndPersist要求のフェーズを固持しているか、または増加の同期だけに関して。
4.3.4. Operational Attributes and Administrative Entries
4.3.4. 操作上の属性と管理エントリー
An operational attribute SHOULD be returned if it is specified in the attributes list and would normally be returned as subject to the constraints of [RFC2251 Section 4.5]. If the server does not support syncing of operational attributes, the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform.
操作上の属性SHOULDを属性リストでそれを指定するなら返して、通常、[RFC2251セクション4.5]の規制を条件として返すでしょう。 サーバが操作上の属性の同期をサポートしないなら、サーバはunwillingToPerformのresultCodeがあるSearchResultDoneメッセージを返さなければなりません。
LDAP Subentries [RFC3672] SHOULD be returned if they would normally be returned by the search request. If the server does not support syncing of LDAP Subentries, and the server can determine from the search request that the client has requested LDAP Subentries to be returned (e.g., search control or search filter), the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform. Otherwise, the server MAY simply omit returning LDAP Subentries.
LDAP Subentries[RFC3672]SHOULD、検索要求で通常彼らを返すなら、返してください。 サーバがLDAP Subentriesの同期をサポートしないで、サーバが、クライアントがLDAP Subentriesを要求したという検索要求から(例えば、検索コントロールか検索フィルタ)が返されることを決定できるなら、サーバはunwillingToPerformのresultCodeがあるSearchResultDoneメッセージを返さなければなりません。 さもなければ、サーバは、LDAP Subentriesを返すのを単に忘れるかもしれません。
Megginson, et al. Standards Track [Page 16] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[16ページ]。
4.3.5. Virtual Attributes
4.3.5. 仮想の属性
An entry may have attributes whose presence in the entry, or presence of values of the attribute, is generated on the fly, possibly by some mechanism outside of the entry, elsewhere in the DIT. An example of this is collective attributes [RFC3671]. These attributes shall be referred to in this document as virtual attributes.
エントリーには、エントリーにおける存在、または属性の値の存在がDITのほかの場所でことによるとエントリーにおける外の何らかのメカニズムによって急いで生成される属性があるかもしれません。 この例は集合的な属性[RFC3671]です。 これらの属性は本書では仮想の属性と呼ばれるものとします。
LCUP treats these attributes the same way as normal, non-virtual attributes. A virtual attribute SHOULD be returned if it is specified in the attributes list and would normally be returned as subject to the constraints of [RFC2251 Section 4.5]. If the server does not support syncing of virtual attributes, the server MUST return a SearchResultDone message with a resultCode of unwillingToPerform.
LCUPは同じように正常で、非仮想の属性としてこれらの属性を扱います。 仮想の属性SHOULDを属性リストでそれを指定するなら返して、通常、[RFC2251セクション4.5]の規制を条件として返すでしょう。 サーバが仮想の属性の同期をサポートしないなら、サーバはunwillingToPerformのresultCodeがあるSearchResultDoneメッセージを返さなければなりません。
One consequence of this is that if you change the definition of a virtual attribute such that it makes the value of that attribute change in many entries in the client's search scope, this means that a server may have to return many entries to the client as a result of that one change. It is not anticipated that this will be a frequent occurrence, and the server has the option to simply force the client to resync if necessary.
あなたが仮想の属性の定義を変えるならこの1つの結果がそれであるので、その属性の値はクライアントの検索範囲(サーバがその1回の変化の結果、多くのエントリーをクライアントに返すために持っているかもしれないこの手段)で多くのエントリーでそれで変化します。 これが多発であり、サーバには必要なら、単に「再-同時性」にクライアントを強制するオプションがあると予期されません。
It is also possible that a future LDAP control will allow the client to request only virtual or only non-virtual attributes.
また、クライアントが今後のLDAPコントロールから仮想か唯一の非仮想の属性しか要求できないのも、可能です。
4.3.6. Modify DN and Delete Operations Applied to Subtrees
4.3.6. DNを変更してください、そして、下位木に適用された操作を削除してください。
There is a special case where a Modify DN or a Delete operation is applied to the base entry of a subtree, and either that base entry or entries in the subtree are within the scope of an LCUP search request. In this case, all of the entries in the subtree are implicitly renamed or removed.
特別なケースがModify DNかDelete操作が下位木のベースエントリーに適用されるところにあります、そして、LCUP検索要求の範囲の中に下位木におけるそのベースエントリーかエントリーのどちらかがあります。 この場合、下位木におけるエントリーのすべてをそれとなく改名するか、または取り除きます。
In either of these cases, the server MUST do one of the following:
これらのケースのどちらかでは、サーバは以下の1つをしなければなりません:
- treat all of these entries as having been renamed or removed and
return each entry to the client as such
- 改名するか、または取り除いたとしてこれらのエントリーをすべて扱ってください、そして、各エントリーをそういうもののクライアントに返してください。
- decide that this would be prohibitively expensive, and force the
client to resync
- これが法外に高価であると決めてください、そして、「再-同時性」にクライアントを強制してください。
If the search base object has been renamed, and the client has received a noSuchObject as the result of a search request, the client MAY use the entryUUID and UUIDAttribute to locate the new DN that is the result of the modify DN operation.
検索ベースオブジェクトが改名されて、クライアントが検索要求に、クライアントがentryUUIDとUUIDAttributeを使用するかもしれないという結果である新しいDNの場所を見つける結果としてa noSuchObjectを受け取った、DN操作を変更してください。
Megginson, et al. Standards Track [Page 17] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[17ページ]。
4.3.7. Convergence Guarantees
4.3.7. 集合保証
If at any time during an LCUP search, either during the sync phase or the persist phase, the server determines that it cannot guarantee that it can bring the client's copy of the data to eventual convergence, it SHOULD immediately terminate the LCUP search request and return a SearchResultDone message with a resultCode of lcupReloadRequired. This can also happen at the beginning of an incremental synchronization request, if the client presents a cookie that is out of date or otherwise unable to be processed. The client should then issue an initial synchronization request.
フェーズを固持してください、とサーバは決定します。または、いつでもLCUP検索と、どちらか同時性段階の間、クライアントのデータのコピーを最後の集合に持って来ることができるのを保証できないで、SHOULDであることはすぐに、LCUP検索要求を終えて、lcupReloadRequiredのresultCodeがあるSearchResultDoneメッセージを返します。 また、これは増加の同期要求の始めに起こることができます、クライアントが時代遅れであるか、またはそうでなければ処理できないクッキーを贈るなら。 そして、クライアントは初並列要求を出すべきです。
This can happen, for example, if the data on the server is reloaded, or if there has been some change to the meta-data that makes it impossible for the server to determine if a particular entry should or should not be part of the search result set, or if the meta-data change makes it too resource intensive for the server to calculate the proper result set.
例えば、サーバに関するデータが再び積まれるか、またはサーバが、特定のエントリーが検索結果セットの一部であるべきであるかどうかかそれともメタデータ変化でサーバが、適切な結果がセットしたと見込むのがリソース徹底的になり過ぎるかどうか決定するのを不可能にするメタデータへのいくらかの変化があったなら、これは起こることができます。
The server can also return lcupReloadRequired if it determines that it would be more efficient for the client to perform a reload, for example, if too many entries have changed and a simple reload would be much faster.
また、クライアントが再ロードを実行するのが、例えばより効率的であることを決定するなら、サーバはlcupReloadRequiredを返すことができます、あまりに多くのエントリーが変化して、簡単な再ロードがはるかに速いなら。
4.4. LCUP Search Termination
4.4. LCUP検索終了
4.4.1. Server Initiated Termination
4.4.1. サーバの開始している終了
When the server has successfully finished processing the client's request, it attaches a Sync Done control to the SearchResultDone message and sends it to the client. However, if the SearchResultDone message contains a resultCode that is not success or canceled, the Sync Done control MAY be omitted. Although the LCUP cookie is OPTIONAL in the Sync Done control value, it MUST be set if the SearchResultDone resultCode is success or canceled. The server SHOULD also set the cookie if the resultCode is lcupResourcesExhausted, timeLimitExceeded, sizeLimitExceeded, or adminLimitExceeded. This allows the client to more easily resync later. If some error occurred, either an LDAP search error (e.g., insufficientAccessRights) or an LCUP error (e.g., lcupUnsupportedScheme), the cookie MAY be omitted. If the cookie is set, the scheme MUST be set also if the cookie format has changed, otherwise, it MAY be omitted.
サーバが、首尾よくクライアントの要求を処理し終えたとき、それは、Sync DoneコントロールをSearchResultDoneメッセージに取り付けて、それをクライアントに送ります。 しかしながら、SearchResultDoneメッセージが成功でないresultCodeを含んだか、または取り消されたなら、Sync Doneコントロールは省略されるかもしれません。 LCUPクッキーはSync Doneコントロール価値においてOPTIONALですが、SearchResultDone resultCodeが成功であるか取り消されて、それを設定しなければなりません。 また、サーバSHOULDはresultCodeがlcupResourcesExhausted、timeLimitExceeded、sizeLimitExceeded、またはadminLimitExceededであるならクッキーを設定します。 これは後でより容易に「再-同時性」にクライアントを許容します。 何らかの誤りが発生したか、そして、LDAP検索誤り(例えば、insufficientAccessRights)かLCUP誤り(例えば、lcupUnsupportedScheme)、クッキーは省略されるかもしれません。 また、クッキーが設定されるなら、クッキー形式が変化したなら、体系を設定しなければなりません。さもなければ、それは省略されるかもしれません。
If server resources become tight, the server can terminate one or more search operations by sending a SearchResultDone message to the client(s) with a resultCode of lcupResourcesExhausted. The server SHOULD attach a Sync Done control with the cookie set. A server side
サーバリソースがきつくなるなら、サーバは、lcupResourcesExhaustedのresultCodeと共にSearchResultDoneメッセージをクライアントに送ることによって、1つ以上の索敵行動を終えることができます。 サーバSHOULDはクッキーセットによるSync Doneコントロールを取り付けます。 サーバ側
Megginson, et al. Standards Track [Page 18] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[18ページ]。
policy is used to decide which searches to terminate. This can also be used as a security mechanism to disconnect clients that are suspected of malicious actions, but if the server can infer that the client is malicious, the server SHOULD return lcupSecurityViolation instead.
方針は、どれが終わるために探されるかを決めるのに使用されます。 また、悪意がある行為について疑われるクライアントから切断するのにセキュリティー対策としてこれを使用できますが、サーバが、クライアントは悪意があると推論できるなら、サーバSHOULDが代わりにlcupSecurityViolationを返します。
4.4.2. Client Initiated Termination
4.4.2. クライアントの開始している終了
If the client needs to terminate the synchronization process and it wishes to obtain the cookie that represents the current state of its data, it issues an LDAP Cancel operation [RFC3909]. The server responds immediately with a LDAP Cancel response [RFC3909]. The server MAY send any pending SearchResultEntry or SearchResultReference PDUs if the server cannot easily abort or remove those search results from its outgoing queue. The server SHOULD send as few of these remaining messages as possible. Finally, the server sends the message SearchResultDone with the Sync Done control attached. If the search was successful up to that point, the resultCode field of the SearchResultDone message MUST be canceled [RFC3909], and the cookie MUST be set in the Sync Done control. If there is an error condition, the server MAY return as described in section 4.4.1 above, or MAY return as described in [RFC3909].
クライアントが、同期プロセスを終える必要があって、データの現状を表すクッキーを入手したいなら、それはLDAPキャンセル操作[RFC3909]を発行します。 サーバはすぐLDAPキャンセル応答[RFC3909]で反応します。 サーバが外向的な待ち行列からそれらの検索結果を容易に中止になることができませんし、取り除くことができないなら、サーバはどんな未定のSearchResultEntryやSearchResultReference PDUsも送るかもしれません。 サーバSHOULDは可能であるとしてのこれらの残っているメッセージの同じくらいわずかしか送りません。 最終的に、サーバは添付のSync DoneコントロールでメッセージSearchResultDoneを送ります。 検索がそのポイントまでうまくいったなら、SearchResultDoneメッセージのresultCode分野を取り消さなければなりません、そして、[RFC3909]Sync Doneコントロールでクッキーを設定しなければなりません。 エラー条件があれば、サーバは、上のセクション4.4.1で説明されるように戻るか、または[RFC3909]で説明されるように戻るかもしれません。
If the client is not interested in the state information, it can simply abandon the search operation or disconnect from the server.
クライアントは州の情報に関心がないなら、それが、単に索敵行動を捨てるか、またはサーバから切断することができます。
4.5. Size and Time Limits
4.5. サイズとタイムリミット
The server SHALL support size and time limits as specified in [RFC2251, Section 5]. The server SHOULD ensure that if the operation is terminated due to these conditions, the cookie is sent back to the client.
サーバSHALLは、サイズと時間が指定されるとして[RFC2251、セクション5]で限界であるとサポートします。 サーバSHOULDは、操作がこれらの状態のため終えられるなら、クッキーがクライアントに送り返されるのを確実にします。
4.6. Operations on the Same Connection
4.6. 同じ接続の操作
It is permissible for the client to issue other LDAP operations on the connection used by the protocol. Since each LDAP request/response carries a message id there will be no ambiguity about which PDU belongs to which operation. By sharing the connection among multiple operations, the server will be able to conserve its resources.
クライアントがプロトコルによって使用される接続のときに他のLDAP操作を発行するのは、許されています。 それぞれのLDAP要求/応答がメッセージイドを運ぶので、PDUがどの操作に属すあいまいさが全くないでしょう。 同時併行処理の中で接続を共有することによって、サーバは資源を節約できるでしょう。
4.7. Interactions with Other Controls
4.7. 他のコントロールとの相互作用
LCUP defines neither restrictions nor guarantees about the ability to use the controls defined in this document in conjunction with other LDAP controls, except for the following: A server MAY ignore non- critical controls supplied with the LCUP control. A server MAY
LCUPは本書では他のLDAPコントロールに関連して定義されたコントロールを使用する能力に関して制限も保証も定義しません、以下を除いて: サーバはLCUPコントロールが供給された非重要なコントロールを無視するかもしれません。 サーバはそうするかもしれません。
Megginson, et al. Standards Track [Page 19] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[19ページ]。
ignore an LCUP defined control if it is non-critical and it is supplied with other critical controls. If a server receives a critical LCUP control with another critical control, and the server does not support both controls at the same time, the server SHOULD return unavailableCriticalExtension.
LCUPを無視してください。それが非臨界であり、他の重要なコントロールをそれに供給するなら、コントロールを定義しました。 サーバが別の重要なコントロールで重要なLCUPコントロールを受けて、サーバが同時に両方のコントロールをサポートしないなら、サーバSHOULDはunavailableCriticalExtensionを返します。
It is up to the server implementation to determine if the server supports controls such as the Sort or VLV or similar controls that change the order of the entries sent to the client. But note that it may be difficult or impossible for a server to perform an incremental synchronization in the presence of such controls, since the cookie will typically be based off a change number, or Change Sequence Number (CSN), or timestamp, or some criteria other than an alphabetical order.
サーバが、Sort、VLVまたは同様のコントロールなどのコントロールがエントリーの注文がクライアントに送ったその変化であるとサポートするかどうか決定するのがサーバ実装まで達しています。 しかし、サーバがそのようなコントロールがあるとき増加の同期を実行するのが、難しいか、または不可能であるかもしれないことに注意してください、クッキーが変化番号、Change Sequence Number(CSN)、タイムスタンプ、またはアルファベット順以外のいくつかの評価基準から通常基づくので。
4.8. Replication Considerations
4.8. 模写問題
Use of an LCUP cookie with multiple DSAs in a replicated environment is not defined by LCUP. An implementation of LCUP may support continuation of an LCUP session with another DSA holding a replica of the LCUP context. Clients MAY submit cookies returned by one DSA to a different DSA; it is up to the server to determine if a cookie is one they recognize or not and to return an appropriate result code if not.
模写された環境における複数のDSAsとのLCUPクッキーの使用はLCUPによって定義されません。 LCUPの実装は、成立する別のDSAとのLCUPセッションの継続がLCUP文脈のレプリカであるとサポートするかもしれません。 クライアントは1DSAによって異なったDSAに返されたクッキーを提出するかもしれません。 クッキーが彼らが認識する1つであるかどうか決定して、そうでなければ、適切な結果コードを返すのはサーバまで達しています。
5. Client Side Considerations
5. クライアントサイド問題
5.1. Using Cookies with Different Search Criteria
5.1. 異なった検索評価基準と共にクッキーを使用します。
The cookie received from the server after a synchronization session SHOULD only be used with the same search specification as the search that generated the cookie. Some servers MAY allow the cookie to be used with a more restrictive search specification than the search that generated the cookie. If the server does not support the cookie, it MUST return lcupInvalidCookie. This is because the client can end up with an incomplete data store otherwise. A more restrictive search specification is one that would generate a subset of the data produced by the original search specification.
サーバからクッキーを受信しました。同期セッションSHOULDの後に、クッキーを生成した検索と同じ検索仕様で単に使用されてください。 いくつかのサーバが、クッキーがクッキーを生成した検索より制限している検索仕様で使用されるのを許容するかもしれません。 サーバがクッキーを支えないなら、それはlcupInvalidCookieを返さなければなりません。 これはそうでなければ、クライアントが不完全なデータ・ストアで終わることができるからです。 より制限している検索仕様は当初の検索仕様で作り出されたデータの部分集合を生成するものです。
5.2. Renaming the Base Object
5.2. 基地のオブジェクトを改名します。
Because an LCUP client specifies the area of the tree with which it wishes to synchronize through the standard LDAP search specification, the client can be returned noSuchObject error if the root of the synchronization area was renamed between the synchronization sessions or during a synchronization session. If this condition occurs, the client can attempt to locate the root by using the root's UUID saved in client's local data store. It then can repeat the synchronization
LCUPクライアントがそれが標準のLDAP検索仕様で連動したがっている木の領域を指定するので、同期領域の根が同期セッションの間、または、同期セッション間、改名されたなら、noSuchObject誤りをクライアントに返すことができます。 この状態が現れるなら、クライアントは、クライアントの地方のデータ・ストアに取っておかれた根のUUIDを使用することによって根の場所を見つけるのを試みることができます。 そして、それは同期を繰り返すことができます。
Megginson, et al. Standards Track [Page 20] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[20ページ]。
request using the new search base. In general, a client can detect that an entry was renamed and apply the changes received to the right entry by using the UUID rather than DN based addressing.
新しい検索ベースを使用することで、要求します。 一般に、エントリーがDNのベースのアドレシングよりむしろUUIDを使用することで改名されて、正しいエントリーに受け取られた変化を適用するクライアントは、検出できます。
5.3. Use of Persistent Searches With Respect to Resources
5.3. リソースに関する永続的な検索の使用
Each active persistent operation requires that an open TCP connection be maintained between an LDAP client and an LDAP server that might not otherwise be kept open. Therefore, client implementors are encouraged to avoid using persistent operations for non-essential tasks and to close idle LDAP connections as soon as practical. The server may close connections if server resources become tight.
それぞれの活発な永続的な操作は、オープンなTCP接続がそうでなければ開くように保たれないかもしれないLDAPクライアントとLDAPサーバの間で維持されるのを必要とします。 したがって、クライアント作成者が、実用的であるとして不要不急なタスク、同じくらいすぐ無駄なLDAP接続を終えるのに永続的な操作を使用するのを避けるよう奨励されます。 サーバリソースがきつくなるなら、サーバは接続を終えるかもしれません。
5.4. Continuation References to Other LCUP Contexts
5.4. 他のLCUP文脈の継続参照
The client MAY receive a continuation reference (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search request spans multiple parts of the DIT, some of which may require a different LCUP cookie, some of which may not even be managed by LCUP. The client SHOULD maintain a cache of the LDAP URLs returned in the continuation references and the cookies associated with them. The client is responsible for performing another LCUP search to follow the references, and SHOULD use the cookie corresponding to the LDAP URL for that reference (if it has a cookie).
クライアントが継続参照を受け取るかもしれない、(SearchResultReference、[RFC2251 SECTION、4.5、.3、)、検索要求がそれの或るものがそれの或るものがLCUPによって管理さえされないかもしれない異なったLCUPクッキーを必要とするかもしれないDITの複数の部分にかかっているなら。 クライアントSHOULDは、LDAPのキャッシュが継続参照で返されたURLとそれらに関連しているクッキーであることを支持します。 クライアントは参照に続くように別のLCUP検索を実行するのに責任があります、そして、SHOULDはその参照において、LDAP URLに対応するクッキーを使用します(クッキーを食べるなら)。
5.5. Referral Handling
5.5. 紹介取り扱い
The client may receive a referral (Referral [RFC2251 SECTION 4.1.11]) when the search base is a subordinate reference, and this will end the operation.
クライアントが紹介を受けるかもしれない、(紹介、[RFC2251 SECTION、4.1、.11、)、検索ベースが下位参照であり、これが操作を終わらせると。
5.6. Multiple Copies of Same Entry During Sync Phase
5.6. 同時性段階の間の複本の同じエントリー
The server MAY send the same entry multiple times during a sync phase if the entry changes during the sync phase. The client SHOULD use the last sent copy of the entry as the current one.
エントリーが同時性段階の間、変化するなら、サーバは同時性段階の間の複数の回を同じエントリーに送るかもしれません。 クライアントSHOULDは現在のものとしてエントリーの最後に送られたコピーを使用します。
5.7. Handling Server Out of Resources Condition
5.7. リソース状態からの取り扱いサーバ
If the client receives an lcupResourcesExhausted or lcupSecurityViolation resultCode, the client SHOULD wait at least 5 seconds before attempting another operation. It is RECOMMENDED that the client use an exponential backoff strategy, but different clients may want to use different backoff strategies.
クライアントがlcupResourcesExhaustedかlcupSecurityViolation resultCodeを受け取るなら、別の操作を試みる前に、クライアントSHOULDは少なくとも5秒待ちます。 クライアントが指数のbackoff戦略を使用するのが、RECOMMENDEDですが、異なったクライアントは異なったbackoff戦略を使用したがっているかもしれません。
Megginson, et al. Standards Track [Page 21] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[21ページ]。
6. Server Implementation Considerations
6. サーバ実装問題
6.1. Server Support for UUIDs
6.1. UUIDsのサーバサポート
Servers MUST support UUIDs. UUIDs are required in the Sync Update control. Additionally, server implementers SHOULD make the UUID values for the entries available as an attribute of the entry, and provide indexing or other mechanisms to allow clients to search for an entry using the UUID attribute in the search filter. The syncUpdate control provides a field UUIDAttribute to allow the server to let the client know the name or OID of the attribute to use to search for an entry by UUID.
サーバはUUIDsをサポートしなければなりません。 UUIDsがSync Updateコントロールで必要です。 さらに、サーバimplementers SHOULDは、エントリーの属性として利用可能なエントリーにUUID値を作って、クライアントがエントリーを捜し求めるのを検索フィルタでUUID属性を使用することで許容するためにインデックスか他のメカニズムを提供します。 syncUpdateコントロールは、サーバが名前をクライアントに知らせるのを許容するか、または使用する属性のOIDがUUIDによるエントリーを捜し求めるのを許容するために分野UUIDAttributeを提供します。
6.2. Example of Using an RUV as the Cookie Value
6.2. クッキー値としてRUVを使用する例
By design, the protocol supports multiple cookie schemes. This is to allow different implementations the flexibility of storing any information applicable to their environment. A reasonable implementation for an LDUP compliant server would be to use the Replica Update Vector (RUV). For each master, RUV contains the largest CSN seen from this master. In addition, RUV implemented by some directory servers (not yet in LDUP) contains replica generation - an opaque string that identifies the replica's data store. The replica generation value changes whenever the replica's data is reloaded. Replica generation is intended to signal the replication/synchronization peers that the replica's data was reloaded and that all other replicas need to be reinitialized. RUV satisfies the three most important properties of the cookie: (1) it uniquely identifies the state of client's data, (2) it can be used to synchronize with multiple servers, and (3) it can be used to detect that the server's data was reloaded. If RUV is used as the cookie, entries last modified by a particular master must be sent to the client in the order of their last modified CSN. This ordering guarantees that the RUV can be updated after each entry is sent.
故意に、プロトコルは複数のクッキー体系をサポートします。 これは、彼らの環境に適切などんな情報も保存する柔軟性を異なった実装に許容するためのものです。 LDUP対応することのサーバのための妥当な実装はReplica Update Vector(RUV)を使用するだろうことです。 各マスターに関しては、RUVはこのマスターから見られる中で最も大きいCSNを含んでいます。 さらに、いくつかのディレクトリサーバ(まだLDUPでないところの)によって実装されたRUVはレプリカ世代を含んでいます--レプリカのデータ・ストアを特定する不透明なストリング。 レプリカのデータが再び積まれるときはいつも、レプリカ世代価値は変化します。 レプリカ世代が、レプリカのデータが再び積まれて、他のすべてのレプリカが、再初期化される必要であると模写/同期同輩に合図することを意図します。 RUVはクッキーの3つの最も重要な特性を満たします: (1) (3) それは唯一クライアントのデータの状態を特定します、そして、(2) 複数のサーバに連動するのにそれを使用できます、そして、それを検出するのに使用されて、サーバのデータが再び積まれたということであるかもしれません。 クッキーとしてRUVを使用するなら、それらの最後に変更されたCSNの注文におけるクライアントに最後に特定のマスターによって変更されたエントリーを送らなければなりません。 この注文は、各エントリーを送った後にRUVをアップデートできるのを保証します。
6.3. Cookie Support Issues
6.3. クッキーサポート問題
6.3.1. Support for Multiple Cookie Schemes
6.3.1. 複数のクッキー体系のサポート
A server may support one or more LCUP cookie schemes. It is expected that schemes will be published along with their OIDs as RFCs. The server's DIT may be partitioned into different sections which may have different cookies associated with them. For example, some servers may use some sort of replication mechanism to support LCUP. If so, the DIT may be partitioned into multiple replicas. A client may send an LCUP search request that spans multiple replicas. Some parts of the DIT spanned by the search request scope may support LCUP and some may not. The server MUST send a SearchResultReference
サーバは1つ以上のLCUPクッキー体系をサポートするかもしれません。 体系がそれらのOIDsと共にRFCsとして発行されると予想されます。 サーバのDITはそれらに関連している異なったクッキーを持っているかもしれない別区に仕切られるかもしれません。 例えば、いくつかのサーバが、LCUPをサポートするのにある種の模写メカニズムを使用するかもしれません。 そうだとすれば、DITは複数のレプリカに仕切られるかもしれません。 クライアントは複数のレプリカにかかるLCUP検索要求を送るかもしれません。 検索要求範囲によってかかられたDITのいくつかの部分がLCUPを支えるかもしれません、そして、何かは支えないかもしれません。 サーバはSearchResultReferenceを送らなければなりません。
Megginson, et al. Standards Track [Page 22] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[22ページ]。
[RFC2251, SECTION 4.5.3] when the LCUP Context for a returned entry changes. The server SHOULD send all references to other LCUP Contexts in the search scope first, in order to allow the clients to process these searches in parallel. The LDAP URL(s) returned MUST contain the DN(s) of the base of another section of the DIT (however the server implementation has partitioned the DIT). The client will then issue another LCUP search using the LDAP URL returned. Each section of the DIT MAY require a different cookie value, so the client SHOULD maintain a cache, mapping the different LDAP URL values to different cookies. If the cookie changes, the scheme may change as well, but the cookie scheme MUST be the same within a given LCUP Context.
返されたエントリーへのLCUP Contextであることの[RFC2251、セクション4.5.3]は変化します。 サーバSHOULDは最初に検索範囲の他のLCUP Contextsのすべての参照を送ります、クライアントが平行なこれらの検索を処理するのを許容するために。 (s)が返したLDAP URLはDITのもう1つのセクションのベースのDN(s)を含まなければなりません(しかしながら、サーバ実装はDITを仕切りました)。 そして、クライアントはLDAP URLが返した別のLCUP検索使用を発行するでしょう。 DIT MAYの各セクションが異なったクッキー値を必要とするので、クライアントSHOULDはキャッシュを維持します、異なったLDAP URL値を異なったクッキーに写像して。 クッキーが変化するなら、体系はまた、変化するかもしれませんが、クッキー体系は与えられたLCUP Contextの中で同じであるに違いありません。
6.3.2. Information Contained in the Cookie
6.3.2. クッキーに含まれた情報
The cookie must contain enough information to allow the server to determine whether the cookie can be safely used with the search specification it is attached to. As discussed earlier in the document, the cookie SHOULD only be used with the search specification that is equal to the one for which the cookie was generated, but some servers MAY support using a cookie with a search specification that is more restrictive than the one used to generate the cookie.
クッキーはサーバが、それが付けられている検索仕様で安全にクッキーを使用できるかどうか決定するのを許容できるくらいの情報を含まなければなりません。 より早くドキュメントで議論するように、クッキーが生成されたものと等しい検索仕様で使用されますが、サポートがものが以前はよくクッキーを生成していたより制限している検索仕様でクッキーを使用して、クッキーSHOULDはいつかのサーバ5月に使用されるだけです。
6.4. Persist Phase Response Time
6.4. フェーズ応答時間を固持してください。
The specification makes no guarantees about how soon a server should send notification of a changed entry to the client during the persist phase. This is intentional as any specific maximum delay would be impossible to meet in a distributed directory service implementation. Server implementers are encouraged to minimize the delay before sending notifications to ensure that clients' needs for timeliness of change notification are met.
仕様がサーバがどれくらい早く変えられたエントリーの通知をクライアントに送るべきであるかに関する保証を全くしない、フェーズを固持してください。 どんな特定の最大の遅れも分配されたディレクトリサービス実装で会うのが不可能でしょう、したがって、これが意図的です。 サーバimplementersがクライアントの変更届出書のタイムリーの需要が満たされるのを保証するために通告を送る前に遅れを最小にするよう奨励されます。
6.5. Scaling Considerations
6.5. スケーリング問題
Implementers of servers that support the mechanism described in this document should ensure that their implementation scales well as the number of active persistent operations and the number of changes made in the directory increases. Server implementers are also encouraged to support a large number of client connections if they need to support large numbers of persistent operations.
本書では説明されたメカニズムをサポートするサーバのImplementersは、活発な永続的な操作の数とディレクトリで行われた変更の数が増加するのに従ってそれらの実装がよく比例するのを確実にするはずです。 また、彼らが、多くの永続的な操作をサポートする必要があるなら、サーバimplementersが多くのクライアント接続をサポートするよう奨励されます。
Megginson, et al. Standards Track [Page 23] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[23ページ]。
6.6. Alias Dereferencing
6.6. アリアDereferencing
LCUP design does not consider issues associated with alias dereferencing in search. Clients MUST specify derefAliases as either neverDerefAliases or derefFindingBaseObj. Servers are to return protocolError if the client specifies either derefInSearching or derefAlways.
LCUPデザインは、問題が通称検索における「反-参照をつけ」るのに関連していると考えません。 クライアントはneverDerefAliasesかderefFindingBaseObjのどちらかとしてderefAliasesを指定しなければなりません。 サーバはクライアントがderefInSearchingかderefAlwaysのどちらかを指定するならprotocolErrorを返すことです。
7. Synchronizing Heterogeneous Data Stores
7. 異種のデータ・ストアを連動させます。
Clients, like a meta directory join engine, synchronizing multiple writable data stores, will only work correctly if each piece of information comes from a single authoritative data source. In a replicated environment, an LCUP Context should employ the same conflict resolution scheme across all its replicas. This is because different systems have different notions of time and different update resolution procedures. As a result, a change applied on one system can be discarded by the other, thus preventing the data stores from converging.
それぞれの情報が単独の信頼すべきデータソースから来る場合にだけ、複数の書き込み可能なデータ・ストアを連動させて、メタディレクトリがエンジンを接合するようにクライアントは正しく働くでしょう。 模写された環境で、LCUP Contextはすべてのレプリカの向こう側に同じ紛争解決体系を使うはずです。 これは異系統には時間と異なったアップデート解決手順の異なった考えがあるからです。 その結果、もう片方で1台のシステムに適用された変化は捨てることができます、その結果、データ・ストアが一点に集まるのを防ぎます。
8. IANA Considerations
8. IANA問題
This document lists several values that have been registered by the IANA. The following LDAP result codes have been assigned by IANA as described in section 3.6 of [RFC3383]:
このドキュメントはIANAによって示されたいくつかの値を記載します。 以下のLDAP結果コードは[RFC3383]のセクション3.6で説明されるようにIANAによって割り当てられました:
lcupResourcesExhausted 113
lcupSecurityViolation 114
lcupInvalidData 115
lcupUnsupportedScheme 116
lcupReloadRequired 117
lcupResourcesExhausted113lcupSecurityViolation114lcupInvalidData115lcupUnsupportedScheme116lcupReloadRequired117
The three controls defined in this document have been registered as LDAP Protocol Mechanisms as described in section 3.2 of [RFC3383]. One OID, 1.3.6.1.1.7, has been assigned by IANA as described in section 3.1 of [RFC3383]. The OIDs for the controls defined in this document are derived as follows from the one assigned by IANA:
[RFC3383]のセクション3.2で説明されるLDAPプロトコルMechanismsとして本書では定義された3つのコントロールを登録してあります。 1OID、1.3 .6 .1 .1 .7 [RFC3383]のセクション3.1で説明されるようにIANAによって割り当てられました。 以下の通りIANAによって割り当てられたものから本書では定義されたコントロールのためのOIDsを得ます:
LCUP Sync Request Control 1.3.6.1.1.7.1
LCUP Sync Update Control 1.3.6.1.1.7.2
LCUP Sync Done Control 1.3.6.1.1.7.3
LCUP同時性要求コントロール1.3.6.1.1.7.1LCUP同時性アップデートコントロール1.3.6.1.1.7.2LCUP同時性されたコントロール1.3.6.1.1.7.3
9. Security Considerations
9. セキュリティ問題
In some situations, it may be important to prevent general exposure of information about changes that occur in an LDAP server. Therefore, servers that implement the mechanism described in this document SHOULD provide a means to enforce access control on the entries
LDAPサーバでは、起こってください。いくつかの状況で、したがって、このドキュメントSHOULDで説明されたメカニズムを実装するサーバがアクセスコントロールにエントリーに押しつける手段を提供するという変化の情報の一般的な暴露を防ぐのは重要であるかもしれません。
Megginson, et al. Standards Track [Page 24] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[24ページ]。
returned and MAY also provide specific access control mechanisms to control the use of the controls and extended operations defined in this document.
戻って、また、本書では定義されたコントロールと拡大手術の使用を制御するために特定のアクセス管理機構を提供するかもしれません。
As with normal LDAP search requests, a malicious client can initiate a large number of persistent search requests in an attempt to consume all available server resources and deny service to legitimate clients. The protocol provides the means to stop malicious clients by disconnecting them from the server. The servers that implement the mechanism SHOULD provide the means to detect the malicious clients. In addition, the servers SHOULD provide the means to limit the number of resources that can be consumed by a single client.
通常のLDAP検索要求なら、悪意があるクライアントはすべての利用可能なサーバリソースを消費して、正統のクライアントに対するサービスを否定する試みにおける多くの永続的な検索要求を開始できます。 プロトコルはサーバから彼らから切断することによって悪意があるクライアントを止める手段を提供します。メカニズムがSHOULDであると実装するサーバは悪意があるクライアントを検出する手段を提供します。 追加、SHOULDがリソースの数を制限する手段を提供するサーバでは、独身のクライアントはそれを消費できます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol (v3)", RFC 2251, December
1997.
[RFC2251]ウォール、M.、ハウズ、T.、およびS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3383]Zeilenga、K.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC3383、2002年9月。
[RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Cancel Operation", RFC 3909, October 2004.
[RFC3909] Zeilenga、K.、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)キャンセル操作」、RFC3909、2004年10月。
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
[X.680]ITU-T、「構文記法1(ASN.1)を抜き取ってください--基本的な記法の仕様」、X.680、1994
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690,
1994.
[X.690]ITU-T、「ASN.1コード化の仕様は統治します」。 「基本的で、正準で、顕著な符号化規則」、X.690、1994。
[UUID] International Organization for Standardization (ISO),
"Information technology - Open Systems Interconnection -
Remote Procedure Call", ISO/IEC 11578:1996.
[UUID]国際標準化機構(ISO)、「情報技術--オープン・システム・インターコネクション--リモートProcedure Call」ISO/IEC、11578:1996
Megginson, et al. Standards Track [Page 25] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[25ページ]。
10.2. Informative References
10.2. 有益な参照
[RFC3384] Stokes, E., Weiser, R., Moats, R., and R. Huber,
"Lightweight Directory Access Protocol (version 3)
Replication Requirements", RFC 3384, October 2002.
[RFC3384] ストークス、E.、ワイザー、R.、モウツ、R.、およびR.ヒューバー、「ライトウェイト・ディレクトリ・アクセス・プロトコル(バージョン3)模写要件」、RFC3384(2002年10月)。
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
Directory Access Protocol (LDAP)", RFC 3671, December
2003.
[RFC3671] Zeilenga、K.、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)の集合的な属性」、RFC3671、2003年12月。
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
Directory Access Protocol (LDAP)", RFC 3672, December
2003.
[RFC3672] ZeilengaとK.とS.Legg、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)の副次的記載」、RFC3672、2003年12月。
11. Acknowledgments
11. 承認
The LCUP protocol is based in part on the Persistent Search Change Notification Mechanism defined by Mark Smith, Gordon Good, Tim Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined by Mark Wahl, and the LDAP Control for Directory Synchronization defined by Michael Armijo. The members of the IETF LDUP working group made significant contributions to this document.
LCUPプロトコルはマーク・スミス、ゴードンGood、ティム・ハウズによって定義されたPersistent検索Change Notification Mechanism、およびロブWeltman(検索ControlがマイケルArmijoによって定義されたディレクトリSynchronizationのためにマーク・ウォール、およびLDAP Controlで定義したLDAPv3 Triggered)に一部基づいています。 IETF LDUPワーキンググループのメンバーはこのドキュメントへの重要な貢献をしました。
Megginson, et al. Standards Track [Page 26] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[26ページ]。
Appendix - Features Left Out of LCUP
付録--特徴はLCUPから残っています。
There are several features present in other protocols or considered useful by clients that are currently not included in the protocol primarily because they are difficult to implement on the server. These features are briefly discussed in this section.
他のプロトコルにおける現在のいくつかの特徴があるか、または主として彼らはサーバで実装するのが難しいので役に立つと現在プロトコルに含まれていないクライアントによって考えられて、このセクションで簡潔に. これらの特徴について議論します。
Triggered Search Change Type
引き起こされた検索変化タイプ
This feature is present in the Triggered Search specification. A flag is attached to each entry returned to the client indicating the reason why this entry is returned. The possible reasons from the document are:
この特徴はTriggered検索仕様に存在しています。 旗はこのエントリーが返される理由を示すクライアントに返された各エントリーに取り付けられます。 ドキュメントからの可能な理由は以下の通りです。
- notChange: the entry existed in the directory and matched the
search at the time the operation is being performed,
- notChange: 操作が実行されているとき、エントリーは、ディレクトリに存在して、検索に合っていました。
- enteredSet: the entry entered the result,
- enteredSet: エントリーは結果に入りました。
- leftSet: the entry left the result,
- leftSet: エントリーは結果を残しました。
- modified: the entry was part of the result set, was modified or
renamed, and still is in the result set.
- 変更される: エントリーは、結果セットの一部であり、変更されたか、または改名されて、結果セットにまだあります。
The leftSet feature is particularly useful because it indicates to the client that an entry is no longer within the client's search specification and the client can remove the associated data from its data store. Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. A compromise could be reached by only providing this feature for the operations that occur while the client is connected to the server. This is easier to accomplish because the decision about the change type can be made based only on the change without need for any historical information. This, however, would add complexity to the protocol.
もうクライアントのどんな検索仕様の中にもエントリーがないのをクライアントに示すので、leftSetの特徴は特に役に立ちます、そして、クライアントはデータ・ストアから関連データを取り除くことができます。 皮肉にも、サーバがクライアントとの同期セッションの間にクライアントの状態の動向をおさえないで、またどのエントリーが範囲から引っ越したかを言うどんな簡単な方法も持っていないので、この特徴はサーバで最も実装しにくいです。 クライアントがサーバに接続されている間に起こる操作のためのこの特徴を提供するだけで感染に達することができるでしょう。これは、変化タイプに関する決定をどんな歴史に関する知識の必要性なしでも変化だけに基づくようにすることができるので、より達成しやすいです。 しかしながら、これは複雑さをプロトコルに追加するでしょう。
Persistent Search Change Type
永続的な検索変化タイプ
This feature is present in the Persistent Search specification. Persistent search has the notion of changeTypes. The client specifies which type of updates will cause entries to be returned, and optionally whether the server tags each returned entry with the type of change that caused that entry to be returned.
この特徴はPersistent検索仕様に存在しています。 永続的な検索には、changeTypesの考えがあります。 クライアントは、どのタイプのアップデートでエントリーを返すかを指定します、そして、任意に、サーバがそれぞれにタグ付けをするかどうかがそのエントリーを返した変化のタイプでエントリーを返しました。
For LCUP, the intention is full synchronization, not partial. Each entry returned by an LCUP search will have some change associated with it that may concern the client. The client may have to have a
LCUPに関しては、意志は、完全な同期であって、部分ではありません。 LCUP検索で返された各エントリーはクライアントに関するかもしれないそれに関連しているいくらかの変化を持つでしょう。 クライアントには、aがなければならないかもしれません。
Megginson, et al. Standards Track [Page 27] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[27ページ]。
local index of entries by DN or UUID to determine if the entry has been added or just modified. It is easy for clients to determine if the entry has been deleted because the entryLeftSet value of the Sync Update control will be TRUE.
決定するDNかUUIDによるエントリーのローカルのインデックスは、エントリーであるなら加えられるか、またはちょうど変更されたところです。 クライアントが、Sync UpdateコントロールのentryLeftSet価値がTRUEになるのでエントリーが削除されたかどうかと決心しているのは、簡単です。
Sending Changes
送付変化
Some earlier synchronization protocols sent the client(s) only the modified attributes of the entry rather than the entire entry. While this approach can significantly reduce the amount of data returned to the client, it has several disadvantages. First, unless a separate mechanism (like the change type described above) is used to notify the client about entries moving into the search scope, sending only the changes can result in the client having an incomplete version of the data. Let's consider an example. An attribute of an entry is modified. As a result of the change, the entry enters the scope of the client's search. If only the changes are sent, the client would never see the initial data of the entry. Second, this feature is hard to implement since the server might not contain sufficient information to construct the changes based solely on the server's state and the client's cookie. On the other hand, this feature can be easily implemented by the client assuming that the client has the previous version of the data and can perform value by value comparisons.
いくつかの以前の同期プロトコルが全体のエントリーよりむしろエントリーの変更された属性だけをクライアントに送りました。 このアプローチはクライアントに返されたデータ量をかなり減少させることができますが、それには、数回の損失があります。 まず最初に、別々のメカニズム(上で説明された変化タイプのような)が検索範囲に移行するエントリーに関してクライアントに通知するのに使用されない場合、変化だけを送ると、データの不完全なバージョンを持っているクライアントはもたらされることができます。 例を考えましょう。 エントリーの属性は変更されています。 変化の結果、エントリーはクライアントの検索の範囲に入ります。 変化だけを送るなら、クライアントはエントリーの初期のデータを決して見ません。 2番目に、サーバが唯一サーバの状態に基づく変化とクライアントのクッキーを組み立てることができるくらいの情報を含まないかもしれないので、この特徴は実装しにくいです。 他方では、クライアントがデータの旧バージョンを持って、値の比較で値を実行できると仮定するクライアントは容易にこの特徴を実装することができます。
Data Size Limits
データサイズ限界
Some earlier synchronization protocols allowed clients to control the amount of data sent to them in the search response. This feature was intended to allow clients with limited resources to process synchronization data in batches. However, an LDAP search operation already provides the means for the client to specify the size limit by setting the sizeLimit field in the SearchRequest to the maximum number of entries the client is willing to receive. While the granularity is not the same, the assumption is that regular LDAP clients that can deal with the limitations of the LDAP protocol will implement LCUP.
いくつかの以前の同期プロトコルで、クライアントは検索応答で彼らに送られたデータ量を制御できました。 この特徴が、限りある資源をもっているクライアントがバッチにおける同期データを処理するのを許容することを意図しました。 しかしながら、LDAP索敵行動は既にクライアントがsizeLimit分野をSearchRequestにはめ込むことによってクライアントが受けても構わないと思っているエントリーの最大数にサイズ限界を指定する手段を提供します。 粒状は同じではありませんが、仮定はLDAPプロトコルの制限に対処できるレギュラーのLDAPクライアントがLCUPを実装するということです。
Data Ordering
データ注文
Some earlier synchronization protocols allowed a client to specify that parent entries should be sent before the children for add operations and children entries sent before their parents during delete operations. This ordering helps clients to maintain a hierarchical view of the data in their data store. While possibly useful, this feature is relatively hard to implement and is expensive to perform.
いくつかの以前の同期プロトコルで、クライアントは、操作を加えてください。そうすれば、エントリーが彼らの両親の前で発信した子供が操作を削除するので親エントリーが子供の前に送られるべきであると指定できました。 この注文は、クライアントがそれらのデータ・ストアでデータの階層的な視点を維持するのを助けます。 ことによると役に立ちますが、この特徴は、比較的実装しにくくて、働くために高価です。
Megginson, et al. Standards Track [Page 28] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[28ページ]。
Authors' Addresses
作者のアドレス
Rich Megginson Netscape Communications Corp., an America Online company. 360 W. Caribbean Drive Sunnyvale, CA 94089 USA
豊かなMegginsonネットスケープ・コミュニケーションズ、アメリカオンライン会社。 カリブ海のDriveカリフォルニア94089 360w.サニーベル(米国)
Phone: +1 505 797-7762 EMail: rmegginson0224@aol.com
以下に電話をしてください。 +1 505 797-7762 メールしてください: rmegginson0224@aol.com
Olga Natkovich Yahoo, Inc. 701 First Ave. Sunnyvale, CA 94089 USA
最初に、オルガNatkovich Yahoo Inc.701Ave。 サニーベル、カリフォルニア94089米国
Phone: +1 408 349-6153 EMail: olgan@yahoo-inc.com
以下に電話をしてください。 +1 408 349-6153 メールしてください: olgan@yahoo-inc.com
Mark Smith Pearl Crescent, LLC 447 Marlpool Drive Saline, MI 48176 USA
マークスミス真珠三日月、LLC447Marlpoolドライブ塩水、MI48176米国
Phone: +1 734 944-2856 EMail: mcs@pearlcrescent.com
以下に電話をしてください。 +1 734 944-2856 メールしてください: mcs@pearlcrescent.com
Jeff Parham Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
ジェフParhamマイクロソフト社1マイクロソフト道ワシントン98052-6399レッドモンド(米国)
Phone: +1 425 882-8080 EMail: jeffparh@microsoft.com
以下に電話をしてください。 +1 425 882-8080 メールしてください: jeffparh@microsoft.com
Megginson, et al. Standards Track [Page 29] RFC 3928 LDAP Client Update Protocol October 2004
Megginson、他 規格はLDAPクライアントアップデートプロトコル2004年10月にRFC3928を追跡します[29ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と、www.rfc-editor.orgに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Megginson, et al. Standards Track [Page 30]
Megginson、他 標準化過程[30ページ]
一覧
スポンサーリンク
