RFC4373 日本語訳

Network Working Group                                        R. Harrison
Request for Comments: 4373                                J. Sermersheim
Category: Informational                                     Novell, Inc.
                                                                 Y. Dong
                                                            January 2006

コメントを求めるワーキンググループR.ハリソンの要求をネットワークでつないでください: 4373年のJ.Sermersheimカテゴリ: 情報のノベルInc.Y.ドング2006年1月

             Lightweight Directory Access Protocol (LDAP)
                Bulk Update/Replication Protocol (LBURP)

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)の大量のアップデート/模写プロトコル(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).

Copyright(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クライアントはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)大量Update/模写プロトコル(LBURP)でLDAPサーバに大量のアップデートを実行できます。プロトコルは、縁どられたセットにおけるアップデート操作がクライアントがそれらを非同期に送るときさえ、処理の間すべての操作の注文を保存できるような方法で関係づけられるようにサーバに通知するためにLDAP拡大手術の1組以内で配列されたセットのアップデート操作を縁どっています。 クライアント/サーバコミュニケーションの効率を最大にするただ一つのプロトコルメッセージの中でアップデート操作を分類できます。

   The protocol is suitable for efficiently making a substantial set of
   updates to the entries in an LDAP server.

プロトコルは効率的にかなりのセットのアップデートをLDAPサーバにおけるエントリーにするのに適当です。

Harrison, et al.             Informational                      [Page 1]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[1ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

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

1. 序論…3 2. このドキュメントで中古のコンベンション…3 3. プロトコルの概要…3 3.1. 開始をアップデートしてください…4 3.2. ストリームをアップデートしてください…4 3.2.1. LBURPUpdateRequest…4 3.2.2. LBURPUpdateResponse…4 3.3. 終了をアップデートしてください…4 3.4. プロトコルの適用性…5 4. プロトコル流動の記述…5 5. プロトコルのElements…6 5.1. StartLBURPRequest…7 5.1.1updateStyleOID…7 5.2. StartLBURPResponse…7 5.2.1maxOperations…8 5.3. LBURPUpdateRequest…8 5.3.1sequenceNumber…8 5.3.2. UpdateOperationList…9 5.4. LBURPUpdateResponse…9 5.4.1. OperationResults…10 5.4.1.1operationNumber…10 5.4.1.2ldapResult…10 5.5. EndLBURPRequest…10 5.5.1sequenceNumber…10 5.6. EndLBURPResponse…11 6. アップデート増加様式の意味論…11 7. 一般LBURP意味論…11 8. セキュリティ問題…12 9. IANA問題…13 9.1. LDAPオブジェクト識別子登録証明書…13 10. 標準の参照…14 11. 有益な参照…14

Harrison, et al.             Informational                      [Page 2]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[2ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

1.  Introduction

1. 序論

   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)大量Update/模写プロトコル(LBURP)は、LDAPクライアントが効率的に大量のアップデートを提示するのを許容する必要性からLDAPサーバまで起こって、LDAPサーバにそれらを効率的に処理させます。 クライアントによって送られた更新要求が標準のLDAP[RFC2251]にアップデート操作をカプセル化するので、LBURPは最小新しい操作上の機能性をLDAPプロトコルに紹介します。 しかしながら、クライアントが、アップデート操作を非同期に送って、サーバが操作の適切な注文を維持するのをまだ許しているのを許容することによって、このプロトコルは大量のアップデートを大いに容易にします。 また、それで、サーバは潜在的に大きいアップデート操作を実行して、そして、より効率的に操作を処理するために加工戦略を変えるクライアントの意図を認識できます。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   Imperative keywords defined in RFC 2119 [RFC2119] are used in this
   document, and carry the meanings described there.

RFC2119[RFC2119]で定義された必須のキーワードは、本書では使用されて、そこで説明された意味を運びます。

   All Basic Encoding Rules (BER) [X.690] encodings follow the
   conventions found in section 5.1 of [RFC2251].

すべてのBasic Encoding Rules(BER)[X.690]encodingsが[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クライアントに適用する用語か1セットのアップデート操作を消費者に供給する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サーバに適用する用語。

3.  Overview of Protocol

3. プロトコルの概要

   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組の中のアップデートセットの首尾をマークする1セットのアップデート操作を縁どっています。 それぞれ一連番号と1のリストを含んでいて、LDAP拡大手術でこれらのアップデートを送るか、または消費者によって実行されるように、以上は操作をアップデートします。 それらが、より大きいLDAPメッセージの一部として一緒に分類されるという事実を除いて、LDAPが操作をアップデートして、[RFC2251]で指定されたLDAPの抽象的なSyntax Notation One(ASN.1)[X.680]メッセージタイプを使用するとき、各部分集合におけるアップデート操作はコード化されます。

Harrison, et al.             Informational                      [Page 3]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[3ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

3.1.  Update Initiation

3.1. アップデート開始

   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.

供給者が関連LBURPUpdateRequestsの小川が続くという通知としてStartLBURPRequest拡大手術を消費者に送るとき、プロトコルは開始されます。 供給者は、StartLBURPRequestに大量のアップデート/模写スタイルのObject Identifier(OID)を含んでいることによって、要求のこのストリームに意味論を関連づけます。 消費者はStartLBURPResponseメッセージでStartLBURPRequestに応じます。

3.2.  Update Stream

3.2. アップデートストリーム

   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に応じます。

3.2.1.  LBURPUpdateRequest

3.2.1. 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はディレクトリ情報Tree(DIT)に適用されるためにLDAPアップデート操作の規則正しいリストを含むアップデートストリームとUpdateOperationListの中で相対的な位置を特定する一連番号を含んでいます。 それらを非同期に送るときさえ、一連番号は、消費者がそれらが供給者によって送られたオーダーにおけるLBURPUpdateRequestメッセージを処理するのを可能にします。 UpdateOperationListでLDAPアップデート操作をオーダーにおけるDITに適用することによって記載された一連番号に従って、消費者は各LBURPUpdateRequestを処理します。

3.2.2.  LBURPUpdateResponse

3.2.2. LBURPUpdateResponse

   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を送ります。

3.3.  Update Termination

3.3. アップデート終了

   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と共に応じます、そして、アップデートは完全です。

Harrison, et al.             Informational                      [Page 4]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[4ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

3.4.  Applicability of Protocol

3.4. プロトコルの適用性

   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だけが模写に使用されるときだけ、独身のマスター模写環境ですべてのレプリカの間のデータの適切な集合を保証できます。

4.  Description of Protocol Flow

4. プロトコル流動の記述

   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).

1) LBURPのためのOIDはスタイルをアップデートします(セクション5.1.1を見てください)。

       C -> S: StartLBURPResponse message.  The parameter is:

C->S: StartLBURPResponseメッセージ。 パラメタは以下の通りです。

                  1) An optional maxOperations instruction
                     (see section 5.2.1).

1) 任意のmaxOperations指示(セクション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).

1) アップデートストリーム(セクション5.3.1を見る)における他のLBURPUpdateRequestメッセージに関してこのLBURPUpdateRequestの注文を指定する一連番号。

                  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を見る)のリスト。

Harrison, et al.             Informational                      [Page 5]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[5ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

               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メッセージを処理して、記載されていて、操作がオーダーに各LBURPUpdateRequestの中にDITに含んだ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.

1) アップデートストリームにおける、最後のLBURPUpdateRequestメッセージの一連番号よりすばらしい1つである一連番号。 これは、また、EndLBURPRequestが非同期に送られるのを許容します。

       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に対応してこれを送ります。

5.  Elements of Protocol

5. プロトコルのElements

   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.

LBURPはプロトコルを開始して、終える2つのLDAP ExtendedRequestメッセージ(StartLBURPRequestとEndLBURPRequest)を使用します。 3番目の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
        }

ExtendedRequest:、:= [アプリケーション23] 系列requestName[0]LDAPOIDで、requestValue[1]八重奏ストリング任意です。

   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
        }

ExtendedResponse:、:= [アプリケーション24] 系列LDAPResultのCOMPONENTS、responseName[10]LDAPOID OPTIONAL、応答[11]OCTET STRING OPTIONAL

Harrison, et al.             Informational                      [Page 6]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[6ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

5.1.  StartLBURPRequest

5.1. StartLBURPRequest

   The requestName value of the StartLBURPRequest is OID 1.3.6.1.1.17.1.

StartLBURPRequestのrequestName値はOID1.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
       }

StartLBURPRequestValue:、:= 系列updateStyleOID LDAPOID

   LDAPOID is defined in [RFC2251], section 4.1.2.

LDAPOIDは[RFC2251]、セクション4.1.2で定義されます。

5.1.1.  updateStyleOID

5.1.1. updateStyleOID

   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は追加アップデートスタイルの今後の拡張のためのプロトコルに含まれています。 例えば、将来の仕様は、すべての既存のエントリーを新しいエントリーに取り替えるために意味論でアップデートスタイルを定義するかもしれなくて、その結果、Add操作を許すだけです。

   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 Incremental UpdateスタイルのためのupdateStyleOIDはそうです。1.3 .6 .1 .1 .17 .7。 このアップデートスタイルの意味論はセクション6で説明されます。

5.2.  StartLBURPResponse

5.2. StartLBURPResponse

   The responseName of the StartLBURPResponse is the OID 1.3.6.1.1.17.2.

StartLBURPResponseのresponseNameはOID1.3です。.6 .1 .1 .17 .2。

   The optional response element contains the BER-encoding of the
   following ASN.1:

任意の応答要素は以下のASN.1のBER-コード化を含んでいます:

       StartLBURPResponseValue ::= maxOperations

StartLBURPResponseValue:、:= maxOperations

       maxOperations ::= INTEGER (0 .. maxInt)

maxOperations:、:= 整数(0maxInt)

       maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

maxInt整数:、:= 2147483647 -- (2^^31 - 1) --

Harrison, et al.             Informational                      [Page 7]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[7ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

5.2.1.  maxOperations

5.2.1. maxOperations

   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の値は、その数の1LBURPUpdateRequest.updateOperationListあたりのアップデート操作だけを送るよう供給者に命令します(セクション5.3.2を見てください)。 消費者がmaxOperations値を送らないなら、いろいろな1LBURPUpdateRequest.updateOperationListあたりのアップデート操作を受け入れるのは準備していなければなりません。 供給者は、発信しないかもしれませんが、maxOperationsが独身のLBURPUpdateRequest.updateOperationListで操作をアップデートするより発信してはいけません。

5.3.  LBURPUpdateRequest

5.3. LBURPUpdateRequest

   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メッセージが1セットのゼロを送るのに使用されるか、または、より多くのLDAPが消費者が複数の非同期なLBURPUpdateRequestメッセージの適切な配列を維持するのを可能にする情報を配列すると共に供給者から消費者までの操作をアップデートします。

   The requestName of the LBURPUpdateRequest is the OID 1.3.6.1.1.17.5.

LBURPUpdateRequestのrequestNameはOID1.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
       }

LBURPUpdateRequestValue:、:= 系列sequenceNumber整数(1maxInt)、updateOperationList UpdateOperationList

5.3.1.  sequenceNumber

5.3.1. sequenceNumber

   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.

sequenceNumber命令はLBURPOperation要求を関連づけました。 これは、消費者が供給者によって指定されたオーダーにおけるLBURPOperation要求を処理するのを可能にします。 供給者は、最初のLBURPUpdateRequestのsequenceNumberの値を1に設定しなければならなくて、sequenceNumberの値を続く各LBURPUpdateRequestあたり1つ増加しなければなりません。 ありそうもないイベントでは、maxIntの一連番号に続いて、LBURPUpdateRequestメッセージの数がmaxInt、1のsequenceNumber値を超えているのは続く一連番号であると考えられます。

Harrison, et al.             Informational                      [Page 8]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[8ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

5.3.2.  UpdateOperationList

5.3.2. UpdateOperationList

   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
       }

UpdateOperationList:、:= 系列の系列updateOperation CHOICE、addRequest AddRequest、modifyRequest ModifyRequest、delRequest DelRequest、modDNRequest ModifyDNRequestは[0] コントロールOPTIONALを制御します。

   AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are
   defined in [RFC2251], sections 4.6, 4.7, 4.8, and 4.9.

AddRequest、ModifyRequest、DelRequest、およびModifyDNRequestは[RFC2251]、セクション4.6、4.7、4.8、および4.9で定義されます。

   The LDAP update requests in the UpdateOperationList MUST be applied
   to the DIT in the order in which they are listed.

それらが記載されているオーダーにおけるDITにUpdateOperationListのLDAP更新要求を適用しなければなりません。

5.4.  LBURPUpdateResponse

5.4. LBURPUpdateResponse

   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.

LBURPUpdateRequestのUpdateOperationListからのアップデート操作のすべてが完成したと合図して、アップデート操作のためにそのリストから結果を与えるためにLBURPUpdateResponseメッセージを消費者から供給者に送ります。

   The responseName of the LBURPUpdateResponse is the OID
   1.3.6.1.1.17.6.

LBURPUpdateResponseのresponseNameはOID1.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 SHALLから、この状況で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は応答要素が存在していると合図するために他に用意ができています。

Harrison, et al.             Informational                      [Page 9]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[9ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

5.4.1.  OperationResults

5.4.1. OperationResults

   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

OperationResults:、:= OperationResultの系列

       OperationResult ::= SEQUENCE {
          operationNumber    INTEGER,
          ldapResult         LDAPResult
       }

OperationResult:、:= 系列operationNumber整数、ldapResult LDAPResult

   An OperationResult is included for each operation from the
   UpdateOperationList that failed during processing.

OperationResultは処理の間に失敗したUpdateOperationListからの各操作のために含まれています。

5.4.1.1.  operationNumber

5.4.1.1. operationNumber

   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時に番号付の始めです。

5.4.1.2.  ldapResult

5.4.1.2. ldapResult

   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で定義されます。

5.5.  EndLBURPRequest

5.5. EndLBURPRequest

   The requestName of the EndLBURPRequest is the OID 1.3.6.1.1.17.3.

EndLBURPRequestのrequestNameはOID1.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)
        }

EndLBURPRequestValue:、:= 系列sequenceNumber整数(1maxInt)

5.5.1.  sequenceNumber

5.5.1. sequenceNumber

   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よりすばらしい1つです。 それで、サーバは、それがいつすべての傑出している非同期なLBURPUpdateRequestsを受けたかを知ることができます。

Harrison, et al.             Informational                     [Page 10]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[10ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

5.6.  EndLBURPResponse

5.6. EndLBURPResponse

   The responseName of the EndLBURPResponse is the OID 1.3.6.1.1.17.4.

EndLBURPResponseのresponseNameはOID1.3です。.6 .1 .1 .17 .4。

   There is no response element in the EndLBURPResponse message.

EndLBURPResponseメッセージには応答要素が全くありません。

6.  Semantics of the Incremental Update Style

6. アップデート増加様式の意味論

   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の必要な最終的な州をまとめて代表します。 すべてのLDAPが[RFC2251]--加える、Modify、Delete、およびModify DNで定義された操作をアップデートします--アップデート増加ストリームでは、許容されています。 事実上、あまりに例えば、それらの操作の意味論のすべてはちょうど通常のLDAP Add操作の間、試みるように既に存在するエントリーが失敗すると言い足す試みです。

7.  General LBURP Semantics

7. 一般LBURP意味論

   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.

消費者サーバは効率的にLBURPを通して送られたアップデートを処理するためにどんな必要な行動も取るかもしれません、最終的な状態がアップデートストリームにおけるアップデートが通常のLDAPアップデート操作を使用することでDITに適用されたなら達成されたそれに同等である限り。

   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アップデートストリームが複数のディレクトリSystemエージェント(DSAs)に影響する要求を含むとき、消費者は、要求を実行するか、または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データベースを維持する必要性によって抑制されないで取り扱いの高能率的なメソッドがアップデートストリームであると実装する自由をimplementersに許容するように設計されています。

Harrison, et al.             Informational                     [Page 11]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[11ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

   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に拒否するのを選ぶなら、消費者が操作を完了するのに適切なデータを持っている別のサーバへのそれらの要求を参照するのは、RECOMMENDEDです。

   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.

タイムスタンプを指定する属性値がアップデートストリームの一部として含まれていない場合、LBURPを使用することでされたアップデートは同じようにそれらがプレゼントに起こると考えられる他のLDAP操作として扱われます。 消費者は、供給者によって送られたタイムスタンプ値を保存するかもしれませんが、そうする必要はありません。

   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セッションが開始されましたが、LBURPセッションを終了するのに必要である情報(EndLBURPRequestなどの)が決して受け取られない接続を検出して、終えるために機能性を含むべきです。 タイムアウトはこれを達成するのに使用できる1つのメカニズムです。

8.  Security Considerations

8. セキュリティ問題

   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が模写に使用されるなら、implementersは、他の模写プロトコルと異なって、供給者と消費者とのどんな既存の模写協定も必要でないことに注意するはずです。 また、消費者サーバが性能を向上させるために特別な許容でアップデートストリームを処理するなら、これらの危険は増加します。 これらの理由で、implementersは、どの許容が適切な承認との関係だけが彼らを実行できるのを保証するために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.

どんな非同期なLDAP操作ならも、LBURP供給者が消費者がそれらを処理できるより速く非同期なLBURPUpdateRequestメッセージを消費者に送るのは、可能であるかもしれません。 消費者implementersは、LBURP供給者が非同期なLBURPUpdateRequestメッセージの急流を発行することによって消費者サーバの通常操作を妨げるのを防ぐために手を打つはずです。

Harrison, et al.             Informational                     [Page 12]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[12ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

9.  IANA Considerations

9. IANA問題

   Registration of the following values has been made by the IANA
   [RFC3383].

以下の値の登録はIANA[RFC3383]によってされました。

9.1.  LDAP Object Identifier Registrations

9.1. LDAPオブジェクト識別子登録証明書

   The IANA has registered LDAP Object Identifiers identifying the
   protocol elements defined in this technical specification.  The
   following registration template was provided:

IANAはこの技術仕様書に基づき定義されたプロトコル要素を特定するLDAP Object Identifiersを登録しました。 以下の登録テンプレートを提供しました:

   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):

Subject: 詳細のために連絡するLDAP OID Registration PersonとEメールアドレスのために以下を要求してください。 ロジャーハリソン rharrison@novell.com Specification: RFC4373作者/変化コントローラ: IESGはコメントします: 7つの委譲が割り当てられたOIDの下で作られるでしょう。 以下の6OIDsがタイプ「E」(supportedExtension)のプロトコルMechanism OIDsです:

   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.2StartLBURPResponse LDAP ExtendedResponseメッセージ1.3.6.1.1.17.3EndLBURPRequest LDAP ExtendedRequestメッセージ1.3.6.1.1.17.4EndLBURPResponse LDAP ExtendedResponseメッセージ1.3.6.1.1.17.5LBURPUpdateRequest LDAP ExtendedRequestメッセージ1.3.6.1.1.17.6LBURPUpdateResponse LDAP ExtendedResponseメッセージ

   The following 1 OID is a Protocol Mechanism OID of type "F"
   (supportedFeature):

以下の1OIDがタイプ「F」(supportedFeature)のプロトコルMechanism OIDです:

   1.3.6.1.1.17.7 LBURP Incremental Update style OID

1.3.6.1.1.17.7 LBURP Incremental UpdateスタイルOID

Harrison, et al.             Informational                     [Page 13]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[13ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

10.  Normative References

10. 引用規格

   [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 the Lightweight Directory Access
              Protocol (LDAP)", BCP 64, RFC 3383, September 2002.

[RFC3383]Zeilenga、K.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC3383、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/IEC8824-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 Rec。 X.690(07/2002)| ISO/IEC8825-1: 2002 「情報技術--ASN.1コード化は以下を統治します」。 「基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様」、2002。

11.  Informative References

11. 有益な参照

   [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)について議定書の中で述べます」。 「トランスポート層セキュリティのための拡大」(RFC2830)は2000がそうするかもしれません。

Harrison, et al.             Informational                     [Page 14]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[14ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

Authors' Addresses

作者のアドレス

   Roger Harrison
   Novell, Inc.
   1800 S. Novell Place
   Provo, UT 84606

ロジャーハリソンノベルInc.1800秒間ノベルPlaceプロボ(ユタ)84606

   Phone: +1 801 861 2642
   EMail: rharrison@novell.com

以下に電話をしてください。 +1 2642年の801 861メール: rharrison@novell.com

   Jim Sermersheim
   Novell, Inc.
   1800 S. Novell Place
   Provo, UT 84606

ジムSermersheimノベルInc.1800秒間ノベルPlaceプロボ(ユタ)84606

   Phone: +1 801 861 3088
   EMail: jimse@novell.com

以下に電話をしてください。 +1 3088年の801 861メール: jimse@novell.com

   Yulin Dong

ユーリンDong

   EMail: yulindong@gmail.com

メール: yulindong@gmail.com

Harrison, et al.             Informational                     [Page 15]

RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006

ハリソン、他 情報[15ページ]のRFC4373LDAPはアップデート/模写プロトコル2006年1月に膨れます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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 procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Harrison, et al.             Informational                     [Page 16]

ハリソン、他 情報[16ページ]