[要約] RFC 5805は、LDAPトランザクションのためのプロトコル拡張を定義しています。目的は、LDAP操作の複数の要求を単一のトランザクションとしてグループ化し、アトミック性と整合性を確保することです。

Independent Submission                                       K. Zeilenga
Request for Comments: 5805                                 Isode Limited
Category: Experimental                                        March 2010
ISSN: 2070-1721
        

Lightweight Directory Access Protocol (LDAP) Transactions

軽量ディレクトリアクセスプロトコル(LDAP)トランザクション

Abstract

概要

Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions.

軽量ディレクトリアクセスプロトコル(LDAP)ADD、DELETE、およびMODIFY操作などのアップデート操作は、原子、整合性、分離、耐久性(ACID)プロパティを持ちます。これらのアップデート操作のそれぞれはエントリに行動します。単一のインタラクション、トランザクション内の2つ以上のエントリを更新することがしばしば望ましい。トランザクションは、リソースプロビジョニングを含む多くのアプリケーションをサポートするために必要です。このドキュメントはトランザクションをサポートするためにLDAPを拡張します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

この文書は、インターネットコミュニティの実験的プロトコルを定義しています。これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版承認済みの文書は、インターネット規格のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5805.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、http://www.rfc-editor.org/info/rfc5805で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(C)2010 IETFの信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、この文書の公開日に有効なIETF文書(http://trustee.ietf.org/License-Info)に関するBCP 78およびIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。

1. Overview
1. 概要

This document extends the Lightweight Directory Access Protocol (LDAP) [RFC4510] to allow clients to relate a number of update operations [RFC4511] and have them performed as one unit of interaction, a transaction. As with distinct update operations, each transaction has atomic, consistency, isolation, and durability (ACID) properties [ACID].

この文書は、軽量ディレクトリアクセスプロトコル(LDAP)[RFC4510]を拡張して、クライアントはいくつかの更新操作を関連付けることができ、それらを1単位のインタラクション、トランザクションとして実行させることができます。異なる更新操作と同様に、各取引は原子、一貫性、絶縁、および耐久性(酸)のプロパティを有する。

This extension consists of two extended operations, one control, and one unsolicited notification message. The Start Transaction operation is used to obtain a transaction identifier. This identifier is then attached to multiple update operations to indicate that they belong to the transaction using the Transaction Specification control. The End Transaction is used to settle (commit or abort) the transaction. The Aborted Transaction Notice is provided by the server to notify the client that the server is no longer willing or able to process an outstanding transaction.

この拡張は、2つの拡張操作、1つの制御、および1つの迷惑な通知メッセージで構成されています。トランザクションの開始操作は、トランザクション識別子を取得するために使用されます。この識別子は、トランザクション仕様コントロールを使用してトランザクションに属することを示すために、複数の更新操作に添付されます。最終トランザクションは、トランザクションを解決(コミットまたは中止)するために使用されます。中止されたトランザクション通知は、サーバーが喜んでいないか、または未処理のトランザクションを処理できることをクライアントに通知するためにサーバーによって提供されます。

1.1. Conventions and Terminology
1.1. 表記法と用語

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 RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。

Protocol elements are described using ASN.1 [X.680] with implicit tags. The term "BER-encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC4511].

プロトコル要素は、暗黙のタグ付きのASN.1 [X.680]を使用して説明されています。「BERエンコード」という用語は、[RFC4511]のセクション5.1で詳細な制限の下で、基本エンコード規則[X.690]を使用して要素をエンコードすることを意味します。

DSA stands for "Directory System Agent" (a server). DSE stands for "DSA-specific entry".

DSAは "Directory System Agent"(サーバー)を表します。DSEは「DSA固有のエントリ」を表します。

2. Elements of an LDAP Transaction
2. LDAPトランザクションの要素
2.1. Start Transaction Request and Response
2.1. トランザクション要求と応答を開始します

A Start Transaction Request is an LDAPMessage of CHOICE extendedReq where the requestName is 1.3.6.1.1.21.1 and the requestValue is absent.

スタートトランザクション要求は、requestNameが1.3.6.1.1.21.1であり、RequestValueが不在であるChoice ExtendedReqのLDAPMessageです。

A Start Transaction Response is an LDAPMessage of CHOICE extendedRes sent in response to a Start Transaction Request. Its responseName is absent. When the resultCode is success (0), responseValue is present and contains a transaction identifier. Otherwise, the responseValue is absent.

スタートトランザクション応答は、スタートトランザクション要求に応答して送信された選択拡張RESのLDAPMESSAGEです。その応答名は欠けています。resultCodeが成功したら(0)、ResponseValueが存在し、トランザクション識別子が含まれています。それ以外の場合は、ResponseValueが存在しません。

2.2. Transaction Specification Control
2.2. トランザクション仕様制御

A Transaction Specification Control is an LDAPControl where the controlType is 1.3.6.1.1.21.2, the criticality is TRUE, and the controlValue is a transaction identifier. The control is appropriate for update requests including Add, Delete, Modify, and ModifyDN (Rename) requests [RFC4511], as well as the Password Modify requests [RFC3062].

トランザクション仕様コントロールは、CONTROLTYPEが1.3.6.1.1.21.2であるLDAPControlです。クリティカル性はtrueで、ControlValueはトランザクション識別子です。コントロールは、追加、削除、変更、およびModifyDN(RENAME)要求(RFC4511]、およびパスワード変更要求[RFC3062]など、更新要求に適しています。

As discussed in Section 4, the Transaction Specification control can be used in conjunction with request controls appropriate for the update request.

セクション4で説明したように、トランザクション仕様制御は、更新要求に適した要求制御と組み合わせて使用できます。

2.3. End Transactions Request and Response
2.3. 最終トランザクション要求と応答

An End Transaction Request is an LDAPMessage of CHOICE extendedReq where the requestName is 1.3.6.1.1.21.3 and the requestValue is present and contains a BER-encoded txnEndReq.

最終トランザクション要求は、要求名が1.3.6.1.1.21.3であり、RequestValueが存在し、BERエンコードされたTXNENDREQが存在し、LDAPMESSEREQが選択されています。

      txnEndReq ::= SEQUENCE {
           commit         BOOLEAN DEFAULT TRUE,
           identifier     OCTET STRING }
        

A commit value of TRUE indicates a request to commit the transaction identified by the identifier. A commit value of FALSE indicates a request to abort the identified transaction.

TRUEのコミット値は、識別子によって識別されたトランザクションをコミットする要求を示します。falseのコミット値は、識別されたトランザクションを中止するための要求を示します。

An End Transaction Response is an LDAPMessage sent in response to a End Transaction Request. Its response name is absent. The responseValue when present contains a BER-encoded txnEndRes.

終了トランザクション応答は、終了トランザクション要求に応答して送信されたLDAPMessageです。その応答名は欠けています。存在する場合のResponseValueは、BERエンコードされたTXNENDRESを含みます。

      txnEndRes ::= SEQUENCE {
           messageID MessageID OPTIONAL,
                -- msgid associated with non-success resultCode
           updatesControls SEQUENCE OF updateControls SEQUENCE {
                messageID MessageID,
                     -- msgid associated with controls
                controls  Controls
           } OPTIONAL
      }
      -- where MessageID and Controls are as specified in RFC 4511
        

The txnEndRes.messageID provides the message id of the update request associated with a non-success response. txnEndRes.messageID is absent when resultCode of the End Transaction Response is success (0).

txnendres.messageIdは、成功しない応答に関連した更新要求のメッセージIDを提供します。TXNENDRES.MessageIDは、最終トランザクション応答のresultCodeが成功したときにはありません(0)。

The txnEndRes.updatesControls provides a facility for returning response controls that normally (i.e., in the absence of transactions) would be returned in an update response. The updateControls.messageID provides the message id of the update request associated with the response controls provided in updateControls.controls.

txnendres.updatesControlsは、通常、正常に(すなわち、トランザクションがない場合)、更新応答で返されることがある応答コントロールを返すための機能を提供します。UpdateControls.messageIdは、UpdateControls.Controlsに提供されている応答コントロールに関連付けられている更新要求のメッセージIDを提供します。

The txnEndRes.updatesControls is absent when there are no update response controls to return.

txnendres.updatesControlsは、返信するための更新応答コントロールがない場合にはありません。

If both txnEndRes.messageID and txnEndRes.updatesControl are absent, the responseValue of the End Transaction Response is absent.

txnendres.messageIdとtxnendres.updateControlが存在しない場合は、最終トランザクション応答のResponseValueが存在しません。

2.4. Aborted Transaction Notice
2.4. 中止された取引通知

The Aborted Transaction Notice is an Unsolicited Notification message where the responseName is 1.3.6.1.1.21.4 and responseValue is present and contains a transaction identifier.

中止されたトランザクション通知は、応答名が1.3.6.1.1.21.2.4であり、ResponseValueが存在し、トランザクション識別子が存在する迷惑な通知メッセージです。

3. An LDAP Transaction
3. LDAPトランザクション
3.1. Extension Discovery
3.1. 拡張発見

To allow clients to discover support for this extension, servers implementing this specification SHOULD publish 1.3.6.1.1.21.1 and 1.3.6.1.1.21.3 as values of the 'supportedExtension' attribute [RFC4512] within the Root DSE, and publish the 1.3.6.1.1.21.2 as a value of the 'supportedControl' attribute [RFC4512] of the Root DSE.

クライアントがこの拡張のサポートを検出できるようにするには、この仕様を実装するサーバーは、ルートDSE内の 'SuppleedExtension'属性[RFC4512]の値として1.3.6.1.1.21.1.1.2.3を発行して公開する必要があります。1.3.6.1.1.21.2ルートDSEの 'supportedcontrol'属性[RFC4512]の値として。

A server MAY choose to advertise this extension only when the client is authorized to use it.

クライアントが使用する権限がある場合にのみ、サーバーはこの拡張を宣伝することを選択できます。

3.2. Starting a Transaction
3.2. トランザクションの開始

A client wishing to perform a sequence of directory updates as a transaction issues a Start Transaction Request. A server that is willing and able to support transactions responds to this request with a Start Transaction Response providing a transaction identifier and with a resultCode of success (0). Otherwise, the server responds with a Start Transaction Response with a resultCode other than success indicating the nature of the failure.

トランザクションとして一連のディレクトリ更新を実行することを望むクライアントは、スタートトランザクション要求を発行します。トランザクションをサポートする喜んでサポートするサーバーは、トランザクション識別子を提供し、成功の結果コード(0)を持つスタートトランザクション応答を使用してこの要求に応答します。それ以外の場合、サーバーは失敗の性質を示す成功以外の結果コードでトランザクション応答を開始して応答します。

The transaction identifier provided upon successful start of a transaction is used in subsequent protocol messages to identify this transaction.

トランザクションの開始時に提供されたトランザクション識別子は、このトランザクションを識別するために後続のプロトコルメッセージで使用されます。

3.3. Specification of a Transaction
3.3. トランザクションの指定

The client then can issue one or more update requests, each with a Transaction Specification control containing the transaction identifier indicating the updates are to be processed as part of the transaction. Each of these update requests MUST have a different MessageID value. If the server is unwilling or unable to attempt to process the requested update operation as part of the transaction, the server immediately returns the appropriate response to the request with a resultCode indicating the nature of the failure. Otherwise, the server immediately returns a resultCode of success (0) and the defers further processing of the operation is then deferred until settlement.

その後、クライアントは、更新を示すトランザクション識別子を含むトランザクション指定制御を持つ1つ以上の更新要求を発行できます。これらの更新要求のそれぞれには、さまざまなMessageID値が必要です。サーバーが不本意に、または要求された更新操作をトランザクションの一部として処理しようとしている場合、サーバーはすぐに失敗の性質を示すresultCodeを使用して適切な応答を返します。さもなければ、サーバーはすぐに成功の結果コード(0)を返し、その後の操作のさらなる処理は決済まで延期される。

If the server becomes unwilling or unable to continue the specification of a transaction, the server issues an Aborted Transaction Notice with a non-success resultCode indicating the nature of the failure. All operations that were to be processed as part of the transaction are implicitly abandoned. Upon receipt of an Aborted Transaction Notice, the client is to discontinue all use of the transaction identifier as the transaction is null and void. Any future use of identifier by the client will result in a response containing a non-success resultCode.

サーバーが不本意になった場合、またはトランザクションの指定を続けることができない場合、サーバーは失敗の性質を示す、成功していない結果コードで中止されたトランザクション通知を発行します。トランザクションの一部として処理されることになっていたすべての操作は暗黙的に放棄されます。中止されたトランザクション通知を受信すると、クライアントはトランザクションがNULLでvoidであるため、トランザクション識別子のすべての使用を中止することです。クライアントによる識別子の将来の使用は、成功していないRESULTCODEを含む応答をもたらします。

3.4. Transaction Settlement
3.4. 取引決済

A client requests settlement of transaction by issuing an End Transaction Request for the transaction indicating whether it desires the transaction to be committed or aborted.

クライアントは、コミットまたは中止されるトランザクションが望まれるかどうかを示すトランザクションの最終トランザクション要求を発行することによって、トランザクションの決済を要求します。

Upon receipt of a request to abort the transaction, the server is to abort the identified transaction (abandoning all operations that are part of the transaction) and indicate that it has done so by returning an End Transaction Response with a resultCode of success (0).

トランザクションを中止する要求を受信すると、サーバーは識別されたトランザクションを中止することです(トランザクションの一部であるすべての操作を放棄する)、成功の結果コードで終了トランザクション応答を返すことによって実行されたことを示します(0)。。

Upon receipt of a request to commit the transaction, the server processes all update operations of the transaction as one atomic, durable, isolated, and consistent action with each requested update being processed in turn. Either all of the requested updates are to be successfully applied or none of the requested are to be applied. The server returns an End Transaction Response with a resultCode of success (0) and no responseValue to indicate all the requested updates were applied. Otherwise, the server returns an End Transaction Response with a non-success resultCode indicating the nature of the failure. If the failure is associated with a particular update request, the txnEndRes.messageID in the responseValue is the message id of this update request. If the failure was not associated with any particular update request, no txnEnd.messageID is provided.

トランザクションをコミットするための要求を受信すると、サーバーはトランザクションのすべての更新操作を1つのアトミック、永続的、分離され、そして一貫したアクションとして処理され、各要求された更新は順番に処理されます。要求された更新プログラムのすべてが正常に適用されるか、または要求されていないものは適用されません。サーバーは、成功(0)のresultCodeを使用して終了トランザクション応答を返し、要求されたすべての更新プログラムを適用したことを示すResponseValueが返されます。それ以外の場合、サーバーは障害の性質を示す成功していない結果コードで終了トランザクション応答を返します。障害が特定の更新要求に関連付けられている場合、ResponseValueのTxNendRes.MessageIdはこの更新要求のメッセージIDです。障害が特定の更新要求に関連付けられていなかった場合、TXNEND.MessageIDは提供されていません。

There is no requirement that a server serialize transactions or updates requested outside of a transaction. That is, a server MAY process multiple commit requests (from one or more clients) acting upon different sets of entries concurrently. A server MUST avoid deadlock.

サーバーがトランザクションの外部で要求されたトランザクションまたは更新をシリアライズする必要はありません。すなわち、サーバは、異なるエントリセットに同時に行動する複数のコミット要求を処理することができる。サーバーはデッドロックを避ける必要があります。

3.5. Miscellaneous Issues
3.5. その他の問題

Transactions cannot be nested.

トランザクションを入れ子にすることはできません。

Each LDAP transaction should be initiated, specified, and settled within a stable security context. Between the Start Request and the End Response, the peers SHOULD avoid negotiating new security associations and/or layers.

各LDAPトランザクションは、安定したセキュリティコンテキスト内で開始、指定、および解決されるべきです。開始要求と終了応答の間に、ピアは新しいセキュリティアソシエーションやレイヤの交渉を避けるべきです。

Upon receipt of a Bind or Unbind request, the server SHALL abort any and all outstanding transactions without notice and nullify their identifiers.

バインドまたはアンバインド要求を受信すると、サーバーは予告なしに未処理のすべてのトランザクションを中止し、それらの識別子を無効にします。

4. Interaction with Other Extensions
4. 他の拡張子との対話

The LDAP Transaction extension may be used with many but not all LDAP control extensions designed to extend update (and possibly other) operations. The subsections that follow discuss interaction with a number of control extensions. Interaction with other control extensions may be discussed in other documents, in particular in control extension specifications.

LDAPトランザクション拡張機能は、更新(およびおそらく他の)操作を拡張するように設計されたすべてのLDAP制御拡張機能が多数使用できます。以下のサブセクションは、いくつかのコントロール拡張機能との対話について説明します。他の制御拡張との相互作用は、他の文書、特に制御拡張仕様において説明することができる。

4.1. Assertion Control
4.1. アサーションコントロール

The Assertion [RFC4528] control is appropriate for use with update requests specified as part of a transaction. The evaluation of the assertion is performed as part of the transaction.

アサーション[RFC4528]コントロールは、トランザクションの一部として指定された更新要求での使用に適しています。アサーションの評価はトランザクションの一部として実行されます。

The Assertion control is inappropriate for use with either the Start or End Transaction Extended operations.

アサーションコントロールは、開始または終了トランザクション拡張操作との使用には不適切です。

4.2. ManageDsaIT Control
4.2. ManagedSaitコントロール

The ManageDsaIT [RFC3296] control is appropriate for use with update requests specified as part of a transaction.

ManagedSait [RFC3296]コントロールは、トランザクションの一部として指定された更新要求での使用に適しています。

The ManageDsaIT control is inappropriate for use with either the Start or End Transaction Extended operations.

ManagedSaitコントロールは、開始または終了のトランザクション拡張操作との使用には不適切です。

4.4. Proxied Authorization Control
4.4. プロキシ認証管理

The Proxied Authorization [RFC4370] control is appropriate for use with the Start Transaction Extended operation, but not the End Transaction Extended operation or any update request specified as part of a transaction.

プロキシ認証[RFC4370]コントロールは、トランザクション拡張操作の開始との使用に適していますが、トランザクション拡張操作またはトランザクションの一部として指定された更新要求は適切です。

To request that a transaction be performed under a different authorization, the client provides a Proxied Authorization control with the Transaction Start Request. If the client is not authorized to assume the requested authorization identity, the server is to return the authorizationDenied (123) resultCode in its response. Otherwise, further processing of the request and transaction is performed under the requested authorization identity.

別の許可の下でトランザクションを実行するように要求するために、クライアントはトランザクション開始要求を使用してプロキシされた許可制御を提供します。クライアントが要求された許可IDを想定する権限がない場合、サーバーはその応答に許可を返す(123)履歴を返すことです。そうでなければ、要求およびトランザクションのさらなる処理は、要求された許可IDの下で実行される。

Any proxied authorization request attached to an update request specified as part of a transaction, or attached to a Transaction End Request, is to be regarded as a protocol error.

トランザクションの一部として指定された更新要求に添付されたプロキシ認証要求は、プロトコルエラーと見なされるべきである。

4.5. Read Entry Controls
4.5. エントリーコントロールを読み取ります

The Pre- and Post-Read Entry [RFC4527] request control are appropriate for use with update requests specified as part of a transaction.

前後のエントリ[RFC4527]要求制御は、トランザクションの一部として指定された更新要求での使用に適しています。

The response control produced in response to a Pre- or Post-Read Entry request control is returned in the txnEndRes.updatesControls field of responseValue of the End Transaction Response.

前または後読み取り後処理要求制御に応答して生成された応答制御は、最終トランザクション応答のResponseValueのtxnendres.updatesControlsフィールドに返されます。

The Pre- and Post-Read Entry controls are inappropriate for use in the LDAPMessage.controls field of the Transaction Start and End Request and Response messages.

前後のエントリ制御は、トランザクション開始と終了要求および応答メッセージのLDAPMessage.Controlsフィールドでの使用には不適切です。

5. Distributed Directory Considerations
5. 分散ディレクトリに関する考慮事項

The LDAP/X.500 models provide for distributed directory operations, including server-side chaining and client-side chasing of referrals.

LDAP / X.500モデルは、サーバーサイド連鎖と紹介のクライアント側の追跡など、分散ディレクトリ操作を提供します。

This document does not preclude servers from chaining operations that are part of a transaction. However, if a server does attempt such chaining, it MUST ensure that transaction semantics are provided.

この文書は、トランザクションの一部であるチェーン操作からサーバーを除外しません。ただし、サーバーがそのような連鎖を試みる場合は、トランザクションセマンティクスが提供されていることを確認する必要があります。

The mechanism defined by this document does not support client-side chasing. Transaction identifiers are specific to a particular LDAP association (as established via the LDAP Bind operation).

この文書によって定義されたメカニズムは、クライアント側の追跡をサポートしていません。トランザクション識別子は、特定のLDAPアソシエーションに固有のものです(LDAPバインド操作を介して確立されたもの)。

The LDAP/X.500 models provide for a single-master/multiple-shadow replication architecture. There is no requirement that changes made to the directory based upon processing a transaction be replicated as one atomic action. Hence, clients SHOULD NOT assume tight data consistency nor fast data convergence of shadow copies unless they have prior knowledge that these properties are provided. Note that DontUseCopy control [DONTUSECOPY] may be used in conjunction with the LDAP search request to ask for the return of the authoritative copy of the entry.

LDAP / X.500モデルは、単一マスター/マルチシャドウレプリケーションアーキテクチャを提供します。トランザクションの処理に基づいてディレクトリに加えられた変更を1つのアトミックアクションとして複製する必要はありません。したがって、クライアントは、これらのプロパティが提供されている以前の知識を持たない限り、厳密なデータの整合性もシャドウコピーの迅速なデータ収束を引き受けるべきではありません。Dontusecopy Control [Dontusecopy]は、エントリの信頼性の高いコピーの返品を要求するためのLDAP検索要求と組み合わせて使用できます。

6. Security Considerations
6. セキュリティに関する考慮事項

Transaction mechanisms may be the target of denial-of-service attacks, especially where implementations lock shared resources for the duration of a transaction.

トランザクションメカニズムは、特に実装がトランザクションの間に共有リソースをロックするサービス拒否攻撃のターゲットであり得る。

General security considerations [RFC4510], especially those associated with update operations [RFC4511], apply to this extension.

一般的なセキュリティ上の考慮事項[RFC4510]、特に更新操作に関する[RFC4511]は、この拡張子に適用されます。

7. IANA Considerations
7. IANAの考慮事項

The Internet Assigned Numbers Authority (IANA) has made the following assignments.

インターネット割り当てられた数字権限(IANA)は以下の割り当てを行った。

7.1. Object Identifier
7.1. オブジェクト識別子

IANA has assigned an LDAP Object Identifier (21) [RFC4520] to identify the protocol elements specified in this document.

このドキュメントで指定されたプロトコル要素を識別するには、IANAがLDAPオブジェクト識別子(21)[RFC4520]を割り当てました。

      Subject: Request for LDAP Object Identifier Registration
      Person & email address to contact for further information:
          Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
      Specification: RFC 5805
      Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
      Comments: Identifies protocol elements for LDAP Transactions
        
7.2. LDAP Protocol Mechanism
7.2. LDAPプロトコルメカニズム

IANA has registered the protocol mechanisms [RFC4520] specified in this document.

IANAはこの文書で指定されたプロトコルメカニズム[RFC4520]を登録しました。

Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: see table Description: see table Person & email address to contact for further information: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> Specification: RFC 5805 Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> Comments:

件名:LDAPプロトコルメカニズムの要求:登録オブジェクト識別子:テーブルの説明:テーブルの個人&メールアドレスを参照してください。kurt.zeilenga@isode.com>コメント:

      Object Identifier   Type  Description
      ------------------- ----  ----------------------------------
      1.3.6.1.1.21.1      E     Start Transaction Extended Request
      1.3.6.1.1.21.2      C     Transaction Specification Control
      1.3.6.1.1.21.3      E     End Transaction Extended Request
      1.3.6.1.1.21.4      N     Aborted Transaction Notice
        
      Legend
      ------------------------
      C => supportedControl
      E => supportedExtension
      N => Unsolicited Notice
        
8. Acknowledgments
8. 謝辞

The author gratefully acknowledges the contributions made by Internet Engineering Task Force participants.

作者は、インターネットエンジニアリングタスクフォースの参加者によって行われた貢献を感謝しています。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", RFC 3062, February 2001.

[RFC3062] Zeilenga、K。、「LDAPパスワード修正拡張操作」、RFC 3062、2001年2月。

[RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories", RFC 3296, July 2002.

[RFC3296] Zeilenga、K。、「軽量ディレクトリアクセスプロトコル(LDAP)ディレクトリ(LDAP)ディレクトリ(LDAP)ディレクトリ(LDAP)ディレクトリ(LDAP)ディレクトリ(LDAP)ディレクトリ(RFC 3296)。

[RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control", RFC 4370, February 2006.

[RFC4370] Weltman、R.、「Lightweight Directory Access Protocol(LDAP)プロキシ承認制御」、RFC 4370、2006年2月。

[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.

[RFC4510] Zeilenga、K.、ED。、「軽量ディレクトリアクセスプロトコル(LDAP):技術仕様ロードマップ」、RFC 4510、2006年6月。

[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4511] SermerSheim、J.、Ed。、「Lightweight Directory Access Protocol(LDAP):プロトコル」、RFC 4511、2006年6月。

[RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.

[RFC4512] Zeilenga、K.、ED。、「LDAP):Directory Information Models」、RFC 4512、2006年6月。

[RFC4527] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Read Entry Controls", RFC 4527, June 2006.

[RFC4527] Zeilenga、K.、 "Lightweight Directory Access Protocol(LDAP)読み取りエントリーコントロール"、RFC 4527、2006年6月。

[RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Assertion Control", RFC 4528, June 2006.

[RFC4528] Zeilenga、K。、「LDAP)アサーションコントロール(LDAP)アサーションコントロール」、RFC 4528、2006年6月。

[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).

[X.680]国際電気通信ユニオン - 電気通信標準化セクター「抽象構文表記1(ASN.1) - 基本表記の仕様」、X.680(2002)(ISO / IEC 8824-1:2002)。

[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(2002) (also ISO/IEC 8825-1:2002).

[X.690] International Telecommunication Union - 電気通信標準化セクター「ASN.1の符号化規則の仕様:基本符号化規則(BER)、正規符号化規則(CER)、および識別符号化規則(DER)」、X.690(2002年))(ISO / IEC 8825-1:2002も)(ISO / IEC 8825-1)。

9.2. Informative References
9.2. 参考引用

[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

[RFC4520] Zeilenga、K。、「インターネット割り当て番号局(IANA)軽量ディレクトリアクセスプロトコル(LDAP)」、BCP 64、RFC 4520、2006年6月。

[ACID] "Information technology -- Open Systems Interconnection -- Distributed Transaction Processing -- Part 1: OSI TP Model", Section 4, ISO/IEC 10026-1:1992.

[Acid] "情報技術 - オープンシステム相互接続 - 分散トランザクション処理 - 第1部:OSI TPモデル"、第4節、ISO / IEC 10026-1:1992。

[DONTUSECOPY] Zeilenga, K., "The LDAP Don't Use Copy Control", Work in Progress, December 2009.

[Dontusecopy] Zeilenga、K.、「LDAPはコピーコントロールを使用しない」、2009年12月の進行中の仕事。

Author's Address

著者の住所

Kurt D. Zeilenga Isode Limited

Kurt D. Zeilenga iSode Limited

   EMail: Kurt.Zeilenga@Isode.COM