Network Working Group R. Harrison
Request for Comments: 4373 J. Sermersheim
Category: Informational Novell, Inc.
Y. Dong
January 2006
Lightweight Directory Access Protocol (LDAP)
Bulk Update/Replication Protocol (LBURP)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.
LDAP（Lightweight Directory Access Protocol）を一括更新/レプリケーションプロトコル（LBURP）は、LDAPクライアントがLDAPサーバに一括更新を実行することができます。プロトコルは、フレームセット内の更新操作は、すべての操作の順序は、それらが送信される場合でも、処理中に保存することができるように関連しているサーバに通知するためにLDAP拡張操作のペア内の更新操作の配列決定組フレーム非同期クライアントによる。更新操作は、クライアント - サーバ通信の効率を最大にするために、単一のプロトコルメッセージ内でグループ化することができます。
The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server.
プロトコルは、効率的にLDAPサーバのエントリへの更新の実質的なセットを作るのに適しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Overview of Protocol ............................................3
3.1. Update Initiation ..........................................4
3.2. Update Stream ..............................................4
3.2.1. LBURPUpdateRequest ..................................4
3.2.2. LBURPUpdateResponse .................................4
3.3. Update Termination .........................................4
3.4. Applicability of Protocol ..................................5
4. Description of Protocol Flow ....................................5
5. Elements of Protocol ............................................6
5.1. StartLBURPRequest ..........................................7
5.1.1. updateStyleOID ......................................7
5.2. StartLBURPResponse .........................................7
5.2.1. maxOperations .......................................8
5.3. LBURPUpdateRequest .........................................8
5.3.1. sequenceNumber ......................................8
5.3.2. UpdateOperationList .................................9
5.4. LBURPUpdateResponse ........................................9
5.4.1. OperationResults ...................................10
5.4.1.1. operationNumber ...........................10
5.4.1.2. ldapResult ................................10
5.5. EndLBURPRequest ...........................................10
5.5.1. sequenceNumber .....................................10
5.6. EndLBURPResponse ..........................................11
6. Semantics of the Incremental Update Style ......................11
7. General LBURP Semantics ........................................11
8. Security Considerations ........................................12
9. IANA Considerations ............................................13
9.1. LDAP Object Identifier Registrations ......................13
10. Normative References ..........................................14
11. Informative References ........................................14
The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) arose from the need to allow an LDAP client to efficiently present large quantities of updates to an LDAP server and have the LDAP server efficiently process them. LBURP introduces a minimum of new operational functionality to the LDAP protocol because the update requests sent by the client encapsulate standard LDAP [RFC2251] update operations. However, this protocol greatly facilitates bulk updates by allowing the client to send the update operations asynchronously and still allow the server to maintain proper ordering of the operations. It also allows the server to recognize the client's intent to perform a potentially large set of update operations and then to change its processing strategy to more efficiently process the operations.
LDAP（Lightweight Directory Access Protocol）を一括更新/レプリケーションプロトコル（LBURP）は、LDAPサーバーへの更新を効率的に現在大量にLDAPクライアントを許可し、LDAPサーバがそれらを効率的に処理する必要がありする必要性から生まれました。クライアントから送信された更新要求は、標準のLDAP [RFC2251]更新操作をカプセル化するためLBURPは、LDAPプロトコルに新しい動作機能の最小値を紹介します。しかし、このプロトコルは大幅に非同期で更新操作を送信し、まだサーバが業務の適切な順序付けを維持できるようにするためのクライアントを可能にすることにより、一括更新を容易にします。また、サーバーは、更新操作の潜在的に大きなセットを実行し、その後、より効率的に業務を処理するための処理戦略を変更するには、クライアントの意図を認識することができます。
Imperative keywords defined in RFC 2119 [RFC2119] are used in this document, and carry the meanings described there.
[RFC2119] RFC 2119で定義された必須キーワードは、この文書で使用され、そこに記載の意味を担持しています。
All Basic Encoding Rules (BER) [X.690] encodings follow the conventions found in section 5.1 of [RFC2251].
すべての基本符号化規則（BER）[X.690]のエンコーディングは、[RFC2251]のセクション5.1で見つかった規則に従ってください。
The term "supplier" applies to an LDAP client or an LDAP server (acting as a client) that supplies a set of update operations to a consumer.
用語「供給者は、」LDAPクライアントや消費者への更新操作のセットを提供（クライアントとして動作）LDAPサーバーに適用されます。
The term "consumer" applies to an LDAP server that consumes (i.e., processes) the sequenced set of update operations sent to it by a supplier.
用語「消費者」とは、消費LDAPサーバ（すなわち、プロセス）サプライヤーによってそれに送信された更新操作の配列決定のセットに適用されます。
LBURP frames a set of update operations within a pair of LDAP extended operations that mark the beginning and end of the update set. These updates are sent via LDAP extended operations, each containing a sequence number and a list of one or more update operations to be performed by the consumer. Except for the fact that they are grouped together as part of a larger LDAP message, the update operations in each subset are encoded as LDAP update operations and use the LDAP Abstract Syntax Notation One (ASN.1) [X.680] message types specified in [RFC2251].
LBURPはアップデートセットの開始および終了をマークLDAP拡張操作のペア内の更新操作のセットをフレーム。これらの更新は、各シーケンス番号及び消費者によって実行される1つ以上の更新操作のリストを含む、LDAP拡張操作を介して送信されます。それらはより大きなLDAPメッセージの一部として一緒にグループ化されているという事実を除いて、各サブセット内の更新操作がLDAP更新操作としてエンコードされ、LDAP抽象構文記法1（ASN.1）を使用している[X.680]のメッセージタイプは、指定されました[RFC2251]インチ
The protocol is initiated when a supplier sends a StartLBURPRequest extended operation to a consumer as a notification that a stream of associated LBURPUpdateRequests will follow. The supplier associates semantics with this stream of requests by including the Object Identifier (OID) of the bulk update/replication style in the StartLBURPRequest. The consumer responds to the StartLBURPRequest with a StartLBURPResponse message.
サプライヤはStartLBURPRequestは、関連LBURPUpdateRequestsの流れが続く通知として消費者の操作を拡張送信するときのプロトコルが開始されます。 StartLBURPRequestで一括更新/複製スタイルのオブジェクト識別子（OID）を含むことによって、要求のこの流れとサプライヤーの仲間の意味。消費者はStartLBURPResponseメッセージでStartLBURPRequestに応答します。
After the consumer responds with a StartLBURPResponse, the supplier sends a stream of LBURPUpdateRequest messages to the consumer. Messages within this stream may be sent asynchronously to maximize the efficiency of the transfer. The consumer responds to each LBURPUpdateRequest with an LBURPUpdateResponse message.
消費者がStartLBURPResponseで応答した後、供給者は、消費者にLBURPUpdateRequestメッセージのストリームを送信します。このストリーム内のメッセージは転送の効率を最大化するために、非同期的に送信することができます。消費者はLBURPUpdateResponseメッセージで各LBURPUpdateRequestに応答します。
Each LBURPUpdateRequest contains a sequence number identifying its relative position within the update stream and an UpdateOperationList containing an ordered list of LDAP update operations to be applied to the Directory Information Tree (DIT). The sequence number enables the consumer to process LBURPUpdateRequest messages in the order they were sent by the supplier even when they are sent asynchronously. The consumer processes each LBURPUpdateRequest according to the sequence number by applying the LDAP update operations in its UpdateOperationList to the DIT in the order they are listed.
各LBURPUpdateRequest更新ストリームとディレクトリ情報ツリー（DIT）に適用されるLDAP更新操作の順序付きリストを含むUpdateOperationList内での相対位置を特定するシーケンス番号を含みます。シーケンス番号は、彼らはそれらが非同期的に送られても業者によって送信された順序でLBURPUpdateRequestメッセージを処理するために消費者を可能にします。消費者は、それらが記載されているために、DITにそのUpdateOperationListでLDAP更新操作を適用することにより、シーケンス番号に応じて各LBURPUpdateRequestを処理します。
When the consumer has processed the update operations from an UpdateOperationList, it sends an LBURPUpdateResponse to the supplier indicating the success or failure of the update operations contained within the corresponding LBURPUpdateRequest.
消費者がUpdateOperationListから更新操作を処理した場合には、対応するLBURPUpdateRequest内に含まれる更新操作の成功または失敗を示すサプライヤにLBURPUpdateResponseを送信します。
After the supplier has sent all of its LBURPUpdateRequest messages, it sends an EndLBURPRequest message to the consumer to terminate the update stream. Upon servicing all LBURPOperation requests and receiving the EndLBURPRequest, the consumer responds with an EndLBURPResponse, and the update is complete.
サプライヤーは、そのLBURPUpdateRequestすべてのメッセージを送信した後は、それが更新ストリームを終了するために、消費者にEndLBURPRequestメッセージを送信します。すべてLBURPOperation要求にサービスを提供してEndLBURPRequestを受信すると、消費者はEndLBURPResponseで応答し、そしてアップデートは完了です。
LBURP is designed to facilitate the bulk update of LDAP servers. It can also be used to synchronize directory information between a single master and multiple slaves.
LBURPは、LDAPサーバの一括更新を容易にするように設計されています。また、単一のマスタと複数のスレーブ間でディレクトリ情報を同期するために使用することができます。
No attempt is made to deal with the issues associated with multiple-master replication environments (such as keeping modification times of attribute values) so that updates to the same entry on different replicas can be correctly ordered. For this reason, when LBURP alone is used for replication, proper convergence of the data between all replicas can only be assured in a single-master replication environment.
試みは異なるレプリカで同じエントリへの更新が正常に注文することができるように、（そのような属性値の修正時刻を保つなど）マルチマスターレプリケーション環境に関連した問題に対処するために行われません。一人でLBURPを複製するために使用したときに、このような理由から、すべてのレプリカの間でデータの適切な収束は、単一のマスター・レプリケーション環境で保証することができます。
This section describes the LBURP protocol flow and the information contained in each protocol message. Throughout this section, the client or server acting as a supplier is indicated by the letter "S", and the server acting as a consumer is indicated by the letter "C". The construct "S -> C" indicates that the supplier is sending an LDAP message to the consumer, and "C -> S" indicates that the consumer is sending an LDAP message to the supplier. Note that the protocol flow below assumes that a properly authenticated LDAP session has already been established between the supplier and consumer.
このセクションでは、LBURPプロトコルフローと各プロトコルメッセージに含まれる情報を記述する。このセクションを通じて、サプライヤーとして動作するクライアントまたはサーバは、文字「S」で示され、消費者は、文字「C」で示されるように、サーバーが動作しています。構築物「S - > C」は、供給業者が消費者にLDAPメッセージを送信し、されていることを示し、「C - > S」消費者が供給者にLDAPメッセージを送信していることを示しています。以下のプロトコルフローが正しく認証されたLDAPセッションがすでにサプライヤーと消費者の間で確立されていることを前提としています。
S -> C: StartLBURPRequest message. The parameter is:
S - > C：StartLBURPRequestメッセージ。パラメータは次のとおりです。
1) OID for the LBURP update style (see section 5.1.1).
LBURP更新スタイルのための1）OID（セクション5.1.1を参照してください）。
C -> S: StartLBURPResponse message. The parameter is:
C - > S：StartLBURPResponseメッセージ。パラメータは次のとおりです。
1) An optional maxOperations instruction
(see section 5.2.1).
S -> C: An update stream consisting of zero or more LBURPUpdateRequest messages. The requests MAY be sent asynchronously. The parameters are:
S - > C：ゼロ以上LBURPUpdateRequestメッセージから成る更新ストリーム。要求が非同期的に送信されるかもしれません。パラメータは次のとおりです。
1) A sequence number specifying the order of
this LBURPUpdateRequest with respect to the
other LBURPUpdateRequest messages in the update
stream (see section 5.3.1).
2) LBURPUpdateRequest.updateOperationList, a list of one or more LDAP update operations (see section 5.3.2).
2）LBURPUpdateRequest.updateOperationList、1つ以上のLDAP更新操作（セクション5.3.2を参照）のリスト。
The consumer processes the LBURPUpdateRequest messages in the order of their sequence numbers and applies the LDAP update operations contained within each LBURPUpdateRequest to the DIT in the order they are listed.
消費者は彼らのシーケンス番号の順にLBURPUpdateRequestメッセージを処理し、それらが列挙されているために、DITに各LBURPUpdateRequest内に含まれるLDAP更新操作を適用します。
C -> S: LBURPUpdateResponse message. This is sent when the consumer completes processing the update operations from each LBURPUpdateRequest.updateOperationList.
C - > S：LBURPUpdateResponseメッセージ。これは、消費者が各LBURPUpdateRequest.updateOperationListから更新操作を処理完了したときに送信されます。
S -> C: EndLBURPRequest message. This is sent after the supplier sends all of its LBURPUpdateRequest messages to the consumer. The parameter is:
S - > C：EndLBURPRequestメッセージ。サプライヤーは、消費者にそのLBURPUpdateRequestすべてのメッセージを送信した後、これが送信されます。パラメータは次のとおりです。
1) A sequence number that is one greater than the
sequence number of the last LBURPUpdateRequest
message in the update stream. This allows the
EndLBURPRequest to also be sent asynchronously.
C -> S: EndLBURPResponse message. This is sent in response to the EndLBURPRequest after the consumer has serviced all LBURPOperation requests.
C - > S：EndLBURPResponseメッセージ。消費者は、すべてのLBURPOperation要求にサービスを提供した後、これをEndLBURPRequestに応答して送信されます。
LBURP uses two LDAP ExtendedRequest messages--StartLBURPRequest and EndLBURPRequest--to initiate and terminate the protocol. A third LDAP ExtendedRequest message--LBURPUpdateRequest--is used to send update operations from the supplier to the consumer. These three requests along with their corresponding responses comprise the entire protocol.
プロトコルを開始し、終了するために - StartLBURPRequestとEndLBURPRequest - LBURPは、2つのLDAPのExtendedRequestメッセージを使用しています。第LDAPのExtendedRequestメッセージが - LBURPUpdateRequest - 消費者へのサプライヤから更新操作を送信するために使用されます。それらに対応する回答と一緒にこれらの3つの要求は、プロトコル全体を構成します。
LBURP request messages are defined in terms of the LDAP ExtendedRequest [RFC2251] as follows:
次のようにLBURP要求メッセージは、LDAPのExtendedRequest [RFC2251]で定義されています。
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL
}
LBURP response messages are defined in terms of the LDAP ExtendedResponse [RFC2251] as follows:
次のようにLBURP応答メッセージは、LDAP ExtendedResponse [RFC2251]で定義されています。
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS of LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response [11] OCTET STRING OPTIONAL
}
The requestName value of the StartLBURPRequest is OID 1.3.6.1.1.17.1.
StartLBURPRequestのrequestName値はOID 1.3.6.1.1.17.1です。
The requestValue of the StartLBURPRequest contains the BER-encoding of the following ASN.1:
StartLBURPRequestのrequestValueは以下のASN.1のBERエンコードが含まれています。
StartLBURPRequestValue ::= SEQUENCE {
updateStyleOID LDAPOID
}
LDAPOID is defined in [RFC2251], section 4.1.2.
LDAPOIDは、[RFC2251]、セクション4.1.2で定義されています。
The updateStyleOID is an OID that uniquely identifies the LBURP update style being used. This document defines one LBURP update semantic style that can be transmitted between the StartLBURPRequest and EndLBURPRequest. The updateStyleOID is included in the protocol for future expansion of additional update styles. For example, a future specification might define an update style with semantics to replace all existing entries with a new set of entries and thus only allows the Add operation.
updateStyleOID一意使用されているLBURP更新スタイルを識別するOIDです。この文書では、StartLBURPRequestとEndLBURPRequestの間で伝送することができる1つのLBURP更新セマンティックスタイルを定義します。 updateStyleOIDは、追加のアップデートスタイルの将来の拡張のためのプロトコルに含まれています。例えば、将来の仕様では、エントリの新しいセットを持つすべての既存のエントリを置き換えるためにセマンティクスで更新スタイルを定義することができますので、唯一の追加操作ができます。
The updateStyleOID for the LBURP Incremental Update style is 1.3.6.1.1.17.7. The semantics of this update style are described in section 6.
LBURP増分更新スタイルのためのupdateStyleOIDは1.3.6.1.1.17.7です。この更新スタイルのセマンティクスはセクション6で説明されています。
The responseName of the StartLBURPResponse is the OID 1.3.6.1.1.17.2.
StartLBURPResponseのresponseNameはOID 1.3.6.1.1.17.2です。
The optional response element contains the BER-encoding of the following ASN.1:
任意応答エレメントは、以下のASN.1のBER符号化を含んでいます。
StartLBURPResponseValue ::= maxOperations
maxOperations ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
When present, the value of maxOperations instructs the supplier to send no more than that number of update operations per LBURPUpdateRequest.updateOperationList (see section 5.3.2). If the consumer does not send a maxOperations value, it MUST be prepared to accept any number of update operations per LBURPUpdateRequest.updateOperationList. The supplier MAY send fewer but MUST NOT send more than maxOperations update operations in a single LBURPUpdateRequest.updateOperationList.
存在する場合、maxOperationsの値はLBURPUpdateRequest.updateOperationList当たり更新操作（セクション5.3.2を参照）の数よりも多くを送信しないようにサプライヤーに指示します。消費者がmaxOperations値を送信しない場合、LBURPUpdateRequest.updateOperationListあたりの更新操作の任意の数を受け入れるように準備しなければなりません。サプライヤーは少ない送るかもしれませんが、単一LBURPUpdateRequest.updateOperationListにmaxOperations更新操作以上のものを送ってはいけません。
The LBURPUpdateRequest message is used to send a set of zero or more LDAP update operations from the supplier to the consumer along with sequencing information that enables the consumer to maintain the proper sequencing of multiple asynchronous LBURPUpdateRequest messages.
LBURPUpdateRequestメッセージは、複数の非同期LBURPUpdateRequestメッセージの適切な順序を維持するために消費者を可能シーケンシング情報と共に消費者に供給元からゼロ個以上のLDAP更新操作のセットを送信するために使用されます。
The requestName of the LBURPUpdateRequest is the OID 1.3.6.1.1.17.5.
LBURPUpdateRequestのrequestNameはOID 1.3.6.1.1.17.5です。
The requestValue of an LBURPOperation contains the BER-encoding of the following ASN.1:
LBURPOperationのrequestValueは以下のASN.1のBERエンコードが含まれています。
LBURPUpdateRequestValue ::= SEQUENCE {
sequenceNumber INTEGER (1 .. maxInt),
updateOperationList UpdateOperationList
}
The sequenceNumber orders associated LBURPOperation requests. This enables the consumer to process LBURPOperation requests in the order specified by the supplier. The supplier MUST set the value of sequenceNumber of the first LBURPUpdateRequest to 1, and MUST increment the value of sequenceNumber by 1 for each succeeding LBURPUpdateRequest. In the unlikely event that the number of LBURPUpdateRequest messages exceeds maxInt, a sequenceNumber value of 1 is deemed to be the succeeding sequence number following a sequence number of maxInt.
LBURPOperation要求を関連するsequenceNumberが受注。これは、供給者によって指定された順序でLBURPOperation要求を処理するために消費者を可能にします。サプライヤは1第1 LBURPUpdateRequestのれるsequenceNumberの値を設定する必要があり、各後続LBURPUpdateRequestための1れるsequenceNumberの値をインクリメントしなければなりません。 LBURPUpdateRequestメッセージの数がMAXINTを超えて低い場合には、1のsequenceNumberが値MAXINTのシーケンス番号の次に続くシーケンス番号であるとみなされます。
The UpdateOperationList is a list of one or more standard LDAP update requests and is defined as follows:
UpdateOperationListは、1つまたは複数の標準LDAP更新要求のリストで、次のように定義されています。
UpdateOperationList ::= SEQUENCE OF SEQUENCE{
updateOperation CHOICE {
addRequest AddRequest,
modifyRequest ModifyRequest,
delRequest DelRequest,
modDNRequest ModifyDNRequest
},
controls [0] Controls OPTIONAL
}
AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are defined in [RFC2251], sections 4.6, 4.7, 4.8, and 4.9.
AddRequest、ModifyRequest、DelRequest、及びModifyDNRequestは、セクション4.6、4.7、4.8、4.9 [RFC2251]で定義されています。
The LDAP update requests in the UpdateOperationList MUST be applied to the DIT in the order in which they are listed.
UpdateOperationListでLDAP更新要求は、それらがリストされているために、DITに適用されなければなりません。
An LBURPUpdateResponse message is sent from the consumer to the supplier to signal that all of the update operations from the UpdateOperationList of an LBURPUpdateRequest have been completed and to give the results for the update operations from that list.
LBURPUpdateResponseメッセージはLBURPUpdateRequestのUpdateOperationListから更新操作の全てが完了したことを知らせるために、そのリストから更新操作の結果を得るためにサプライヤに消費者から送信されます。
The responseName of the LBURPUpdateResponse is the OID 1.3.6.1.1.17.6.
LBURPUpdateResponseのresponseNameはOID 1.3.6.1.1.17.6です。
If the consumer server cannot successfully decode an LBURPUpdateRequest in its entirety, the resultCode for the corresponding LBURPUpdateResponse is set to protocolError and the response element is omitted. Updates from the LBURPUpdateRequest SHALL NOT be committed to the DIT in this circumstance.
コンシューマサーバが正常にその全体LBURPUpdateRequestをデコードできない場合、対応するLBURPUpdateResponseためのresultCodeにはProtocolErrorに設定され、応答要素は省略されています。 LBURPUpdateRequestからの更新は、この状況でDITにコミットされないものとします。
If the status of all of the update operations being reported by an LBURPUpdateResponse message is success, the resultCode of the LBURPUpdateResponse message is set to success and the response element is omitted.
LBURPUpdateResponseメッセージによって報告される更新操作の全てのステータスが成功である場合、LBURPUpdateResponseメッセージのresultCodeが成功に設定され、応答要素は省略されています。
If the status of any of the update operations being reported by an LBURPUpdateResponse message is something other than success, the resultCode for the entire LBURPUpdateResponse is set to other to signal that the response element is present.
LBURPUpdateResponseメッセージによって報告される更新操作のいずれかのステータスが成功以外の何かである場合、全体LBURPUpdateResponseためのresultCodeは、応答エレメントが存在することを知らせるために、他に設定されています。
When a response element is included in an LBURPUpdateResponse message, it contains the BER-encoding of the following ASN.1:
応答エレメントはLBURPUpdateResponseメッセージに含まれている場合、それは次のASN.1のBER符号化を含んでいます。
OperationResults ::= SEQUENCE OF OperationResult
OperationResult ::= SEQUENCE {
operationNumber INTEGER,
ldapResult LDAPResult
}
An OperationResult is included for each operation from the UpdateOperationList that failed during processing.
OperationResultは、処理中に障害が発生したUpdateOperationListから各操作のために含まれています。
The operationNumber identifies the LDAP update operation from the UpdateOperationList of the LBURPUpdateRequest that failed. Operations are numbered beginning at 1.
operationNumberに失敗しましたLBURPUpdateRequestのUpdateOperationListからLDAP更新操作を識別します。操作は、1から始まる番号が付けられています。
The ldapResult included in the OperationResult is the same ldapResult that would be sent for the update operation that failed if it had failed while being processed as a normal LDAP update operation. LDAPResult is defined in [RFC2251], section 4.1.10.
OperationResultに含まldapResultは、それが通常のLDAP更新操作として処理されている間、失敗した場合には失敗した更新操作のために送られるのと同じldapResultです。 LDAPResultは[RFC2251]で定義され、セクション4.1.10。
The requestName of the EndLBURPRequest is the OID 1.3.6.1.1.17.3.
EndLBURPRequestのrequestNameはOID 1.3.6.1.1.17.3です。
The requestValue contains the BER-encoding of the following ASN.1:
requestValueは以下のASN.1のBERエンコードが含まれています。
EndLBURPRequestValue::= SEQUENCE {
sequenceNumber INTEGER (1 .. maxInt)
}
The value in sequenceNumber is one greater than the last LBURPUpdateRequest.sequenceNumber in the update stream. It allows the server to know when it has received all outstanding asynchronous LBURPUpdateRequests.
sequenceNumberがで値が更新ストリームの最後のLBURPUpdateRequest.sequenceNumberよりも大きいものです。それは、すべての未処理の非同期LBURPUpdateRequestsを受信した際に、サーバが知ることができます。
The responseName of the EndLBURPResponse is the OID 1.3.6.1.1.17.4.
EndLBURPResponseのresponseNameはOID 1.3.6.1.1.17.4です。
There is no response element in the EndLBURPResponse message.
EndLBURPResponseメッセージで応答要素がありません。
The initial state of entries in the consumer's DIT plus the LBURPUpdateRequest messages in the update stream collectively represent the desired final state of the consumer's DIT. All LDAP update operations defined in [RFC2251]--Add, Modify, Delete, and Modify DN--are allowed in the incremental update stream. All of the semantics of those operations are in effect, so for instance, an attempt to add an entry that already exists will fail just as it would during a normal LDAP Add operation.
消費者のDIT内のエントリに加え更新ストリーム内LBURPUpdateRequestメッセージの初期状態は、集合的に消費者のDITの所望の最終状態を表します。 、追加、変更、削除、および変更DN - - [RFC2251]で定義されたすべてのLDAP更新操作は、増分更新ストリームで許可されています。例えば、すでに存在しているエントリを追加しようとする試みは、それが通常のLDAP時の動作を追加するのと同じように失敗しますので、これらの操作の意味論のすべては、有効になっています。
The consumer server may take any action required to efficiently process the updates sent via LBURP, as long as the final state is equivalent to that which would have been achieved if the updates in the update stream had been applied to the DIT using normal LDAP update operations.
コンシューマサーバであれば、最終的な状態は、更新ストリームで更新が正常LDAP更新操作を使用して、DITに適用された場合に達成されたであろうものと同等であるように、効率的にLBURPを介して送信された更新を処理するために必要な行動をとることができます。
The LBURPUpdateRequest messages that form the update stream MAY be sent asynchronously by the supplier to the consumer. This means that the supplier need not wait for an LBURPUpdateResponse message for one LBURPUpdateRequest message before sending the next LBURPUpdateRequest message.
更新ストリームを形成LBURPUpdateRequestメッセージは、消費者への供給者が非同期的に送信されるかもしれません。これは、サプライヤーは、次のLBURPUpdateRequestメッセージを送信する前に1つのLBURPUpdateRequestメッセージのLBURPUpdateResponseメッセージを待つ必要がないことを意味します。
When the LBURP update stream contains a request that affects multiple Directory System Agents (DSAs), the consumer MAY choose to perform the request or return a resultCode value of affectsMultipleDSAs. As with any LDAP operation, a consumer MAY send a resultCode value of referral as part of the OperationResult element for any operation on an entry that it does not contain. If the consumer is configured to do so, it MAY chain on behalf of the supplier to complete the update operation instead.
LBURP更新ストリームは、複数のディレクトリシステムエージェント（のDSA）に影響を与える要求が含まれている場合、消費者は、要求を実行したり、affectsMultipleDSAsのにresultCode値を返すために選ぶかもしれません。任意のLDAP操作と同様に、消費者はそれが含まれていないエントリー上の任意の操作のためのOperationResult要素の一部として紹介のresultCodeが値を送信することができます。消費者がそのように設定されている場合、それはサプライヤーに代わってチェーンの代わりに、更新操作を完了することがあります。
While a consumer server is processing an LBURP update stream, it may choose not to service LDAP requests on other connections. This provision is designed to allow implementers the freedom to implement highly-efficient methods of handling the update stream without being constrained by the need to maintain a live, working DIT database while doing so.
コンシューマサーバがLBURP更新ストリームを処理しているが、それは他の接続上のLDAP要求にサービスを提供しないこともできます。この規定は、実装者が自由そうしながら、DITデータベースを作業、ライブを維持する必要性によって制約されることなく、更新ストリームを処理する高効率な方法を実装できるように設計されています。
If a consumer chooses to refuse LDAP operation requests from other suppliers during LBURP update, it is RECOMMENDED that the consumer refer those requests to another server that has the appropriate data to complete the operation.
消費者がLBURP更新中の他のサプライヤーからのLDAP操作要求を拒否することを選択した場合、消費者が操作を完了するために適切なデータを持っている別のサーバーにそれらの要求を指すことが推奨されます。
Unless attribute values specifying timestamps are included as part of the update stream, updates made using LBURP are treated the same as other LDAP operations wherein they are deemed to occur at the present. Consumers MAY store timestamp values sent by suppliers but are not required to do so.
タイムスタンプを指定する属性値が更新ストリームの一部として含まれていない限り、更新は、それらが現時点で起こると考えられる、前記他のLDAP操作と同じように扱われるLBURPを使用しました。消費者は取引先によって送信されたタイムスタンプ値を格納することができるが、その必要はありません。
Implementations may choose to perform the operations in the update stream with special permissions to improve performance.
実装は、パフォーマンスを向上させるために特別な権限を更新ストリームで操作を実行することもできます。
Consumer implementations should include functionality to detect and terminate connections on which an LBURP session has been initiated but information (such as the EndLBURPRequest) needed to complete the LBURP session is never received. A timeout is one mechanism that can be used to accomplish this.
消費者の実装はLBURPセッションが開始されているが（例えばEndLBURPRequestなど）の情報が受信されることはありませんLBURPセッションを完了するために必要なその上で接続を検出して終了する機能を含める必要があります。タイムアウトは、これを達成するために使用できる1つのメカニズムです。
Implementations should ensure that a supplier making an LBURP request is properly authenticated and authorized to make the updates requested. There is a potential for loss of data if updates are made to the DIT without proper authorization. If LBURP is used for replication, implementers should note that unlike other replication protocols, no existing replication agreement between supplier and consumer is required. These risks increase if the consumer server also processes the update stream with special permissions to improve performance. For these reasons, implementers should carefully consider which permissions should be required to perform LBURP operations and take steps to ensure that only connections with appropriate authorization are allowed to perform them.
実装はLBURP要求を行う業者が適切に認証され、要求された更新を行うことを許可されていることを確認する必要があります。更新は、適切な許可を持たずにDITに行われた場合、データの損失の可能性があります。 LBURPを複製するために使用されている場合、実装者は他のレプリケーション・プロトコルとは違って、サプライヤーと消費者の間には、既存のレプリケーションアグリーメントが必要とされないことに注意してください。コンシューマサーバは、パフォーマンスを向上させるために特別な権限を更新ストリームを処理する場合、これらのリスクが増加します。これらの理由から、実装者は慎重に権限がLBURP操作を実行し、適切な権限を持つ唯一の接続は、それらを実行するために許可されていることを確認するための措置をとることを必要とするかを検討すべきです。
The data contained in the update stream may contain passwords and other sensitive data. Care should be taken to properly safeguard this information while in transit between supplier and consumer. The StartTLS [RFC2830] operation is one mechanism that can be used to provide data confidentiality and integrity services for this purpose.
更新ストリームに含まれるデータは、パスワードやその他の機密データが含まれていてもよいです。ケアが適切に供給者と消費者の間で輸送中のときにこの情報を保護するために取られるべきです。 StartTLSを[RFC2830]の操作は、この目的のために、データの機密性と整合性のサービスを提供するために使用できる1つのメカニズムです。
As with any asynchronous LDAP operation, it may be possible for an LBURP supplier to send asynchronous LBURPUpdateRequest messages to the consumer faster than the consumer can process them. Consumer implementers should take steps to prevent LBURP suppliers from interfering with the normal operation of a consumer server by issuing a rapid stream of asynchronous LBURPUpdateRequest messages.
LBURPサプライヤが速く、消費者がそれらを処理できるよりも、消費者への非同期LBURPUpdateRequestメッセージを送信するための任意の非同期LDAP操作と同じように、それが可能です。消費者の実装は、非同期LBURPUpdateRequestメッセージの急速な流れを発行することによって、消費者のサーバーの正常な動作に干渉するLBURPサプライヤーを防止するための措置をとる必要があります。
Registration of the following values has been made by the IANA [RFC3383].
次の値の登録は、IANA [RFC3383]によって行われています。
The IANA has registered LDAP Object Identifiers identifying the protocol elements defined in this technical specification. The following registration template was provided:
IANAは、この技術仕様で定義されたプロトコル要素を識別するLDAPオブジェクト識別子を登録しました。以下の登録テンプレートが提供されていました。
Subject: Request for LDAP OID Registration Person & email address to contact for further information: Roger Harrison rharrison@novell.com Specification: RFC 4373 Author/Change Controller: IESG Comments: Seven delegations will be made under the assigned OID. The following 6 OIDs are Protocol Mechanism OIDs of type "E" (supportedExtension):
件名：詳細のために連絡するLDAP OID登録人とEメールアドレスの要求：ロジャー・ハリソンrharrison@novell.com仕様：RFC 4373著者/変更コントローラ：IESGはコメント：七つの代表団は、割り当てられたOIDの下に行われます。次の6つのOIDはタイプ「E」（supportedExtension）のプロトコルメカニズムのOIDです。
1.3.6.1.1.17.1 StartLBURPRequest LDAP ExtendedRequest message 1.3.6.1.1.17.2 StartLBURPResponse LDAP ExtendedResponse message 1.3.6.1.1.17.3 EndLBURPRequest LDAP ExtendedRequest message 1.3.6.1.1.17.4 EndLBURPResponse LDAP ExtendedResponse message 1.3.6.1.1.17.5 LBURPUpdateRequest LDAP ExtendedRequest message 1.3.6.1.1.17.6 LBURPUpdateResponse LDAP ExtendedResponse message
1.3.6.1.1.17.1 StartLBURPRequest LDAPのExtendedRequestメッセージ1.3.6.1.1.17.2 StartLBURPResponse LDAP ExtendedResponseメッセージ1.3.6.1.1.17.3 EndLBURPRequest LDAPのExtendedRequestメッセージ1.3.6.1.1.17.4 EndLBURPResponse LDAP ExtendedResponseメッセージ1.3.6.1.1.17。 5 LBURPUpdateRequest LDAPのExtendedRequestメッセージ1.3.6.1.1.17.6 LBURPUpdateResponse LDAP ExtendedResponseメッセージ
The following 1 OID is a Protocol Mechanism OID of type "F" (supportedFeature):
次の1 OIDはタイプ「F」（supportedFeature）のプロトコルメカニズムOIDです。
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3383] Zeilenga、K.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 3383、2002年9月。
[X.680] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation"
[X.680] ITU-T勧告X.680（07/2002）| ISO / IEC 8824から1：2002「情報技術 - 抽象構文記法1（ASN.1）：基本的な表記法の仕様」
[X.690] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2002.
[X.690] ITU-T勧告。 X.690（07/2002）| ISO / IEC 8825から1：2002、 "情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）"、2002年。
[RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[RFC2830]ホッジス、J.、モルガン、R.、およびM.ワール、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：トランスポート層セキュリティのための拡張"、RFC 2830、2000年5月。
Authors' Addresses
著者のアドレス
Roger Harrison Novell, Inc. 1800 S. Novell Place Provo, UT 84606
ロジャー・ハリソンノベル株式会社1800 S.ノベル場所プロボ、UT 84606
Phone: +1 801 861 2642 EMail: rharrison@novell.com
電話：+1 801 861 2642 Eメール：rharrison@novell.com
Jim Sermersheim Novell, Inc. 1800 S. Novell Place Provo, UT 84606
ジム・Sermersheimノベル株式会社1800 S.ノベル場所プロボ、UT 84606
Phone: +1 801 861 3088 EMail: jimse@novell.com
電話：+1 801 861 3088 Eメール：jimse@novell.com
Yulin Dong
Y U林洞
EMail: yulindong@gmail.com
メールアドレス：yulindong@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。