[要約] RFC 3771は、LDAPの中間応答メッセージに関する仕様であり、LDAPサーバーからの応答を処理するための標準化された方法を提供します。このRFCの目的は、LDAPプロトコルの拡張性と柔軟性を向上させ、クライアントとサーバー間の通信を効率化することです。
Network Working Group R. Harrison
Request for Comments: 3771 Novell, Inc.
Updates: 2251 K. Zeilenga
Category: Standards Track OpenLDAP Foundation
April 2004
The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message
軽量ディレクトリアクセスプロトコル（LDAP）中間応答メッセージ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). The IntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information.
このドキュメントでは、LightWeight Directory Access Protocol（LDAP）で単一リケスト/多逆応答操作を定義するための一般的なメカニズムである中間患者応答メッセージを定義および説明します。中間症のメッセージは、既存のLDAP操作のプロトコル動作が維持されるように定義されます。このメッセージは、LDAP ExtendedRequestと拡張されたレスポンスと組み合わせて使用することを目的としています。これは、新しいシングルリクエスト/多重応答操作を定義するか、中間応答情報を返す必要がある方法で既存のLDAP操作を拡張するときにコントロールと組み合わせて使用することを目的としています。
The Lightweight Directory Access Protocol (LDAP), version 3 [RFC3377] is an extensible protocol. Extended operations ([RFC2251] Section 4.12) are defined to allow for the addition of operations to LDAP, without requiring revisions of the protocol. Similarly, controls ([RFC2251] Section 4.1.12) are defined to extend or modify the behavior of existing LDAP operations.
Lightweight Directory Access Protocol（LDAP）、バージョン3 [RFC3377]は、拡張可能なプロトコルです。拡張操作（[RFC2251]セクション4.12）は、プロトコルの改訂を必要とせずに、LDAPへの操作を追加できるように定義されています。同様に、コントロール（[RFC2251]セクション4.1.12）は、既存のLDAP操作の動作を拡張または変更するために定義されます。
LDAP is a client-request/server-response based protocol. With the exception of the search operation, the entire response to an operation request is returned in a single protocol data unit (i.e., LDAP message). While this single-request/single-response paradigm is sufficient for many operations (including all but one of those currently defined by [RFC3377]), both intuition and practical experience validate the notion that it is insufficient for others.
LDAPは、クライアントレクエスト/サーバー応答ベースのプロトコルです。検索操作を除き、操作要求に対する応答全体が単一のプロトコルデータユニット（つまり、LDAPメッセージ）で返されます。この単一の要求/単一応答パラダイムは、多くの操作（現在[RFC3377]によって定義されているものの1つを除くすべてを除くすべてを含む）で十分ですが、直観と実践的な経験は、他の人にとっては不十分であるという概念を検証します。
For example, the LDAP delete operation could be extended via a subtree control to mean that an entire subtree is to be deleted. A subtree delete operation needs to return continuation references based upon subordinate knowledge information contained in the server so that the client can complete the operation. Returning references as they are found, instead of with the final result, allows the client to perform the operation more efficiently because it does not have to wait for the final result to get this continuation reference information.
たとえば、LDAP削除操作は、サブツリーコントロールを介して拡張して、サブツリー全体が削除されることを意味します。サブツリー削除操作は、クライアントが操作を完了できるように、サーバーに含まれる下位の知識情報に基づいて継続的な参照を返す必要があります。参照を返すように、最終結果ではなく、クライアントがこの継続的な参照情報を取得するために最終結果を待つ必要がないため、クライアントがより効率的に操作を実行できるようにします。
Similarly, an engineer might choose to design the subtree delete operation as an extended operation of its own rather than using a subtree control in conjunction with the delete operation. Once again, the same continuation reference information is needed by the client to complete the operation, and sending the continuation references as they are found would allow the client to perform the operation more efficiently.
同様に、エンジニアは、削除動作と組み合わせてサブツリーコントロールを使用するのではなく、独自の拡張操作としてサブツリー削除操作を設計することを選択できます。繰り返しますが、クライアントが操作を完了するために同じ継続参照情報が必要であり、継続的な参照を送信すると、クライアントがより効率的に操作を実行できるようになります。
Operations that are completed in stages or that progress through various states as they are completed might want to send intermediate responses to the client, thereby informing it of the status of the operation. For example, an LDAP implementation might define an extended operation to create a new replica of an administrative area on a server, and the operation is completed in three stages: (1) begin creation of replica, (2) send replica data to server, (3) replica creation complete. Intermediate messages might be sent from the server to the client at the beginning of each stage with the final response for the extended operation being sent after stage (3) is complete.
段階的に完了した操作、または完了したさまざまな状態を経て進行する操作は、クライアントに中級の応答を送信し、それによって操作のステータスを通知することをお勧めします。たとえば、LDAPの実装は、サーバー上の管理領域の新しいレプリカを作成するための拡張操作を定義する場合があり、操作は3つの段階で完了します。（1）レプリカの作成を開始する、（2）レプリカデータをサーバーに送信します、（3）レプリカ作成が完了しました。中間メッセージは、各ステージの開始時にサーバーからクライアントに送信される場合があり、ステージ（3）が完了した後に拡張操作の最終的な応答が完了します。
As LDAP [RFC3377] is currently defined, there is no general LDAP message type that can be used to return intermediate results. A single, reusable LDAP message for carrying intermediate response information is desired to avoid repeated modification of the protocol. Although the ExtendedResponse message is defined in LDAP, it is defined to be the one and only response message to an ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited notifications ([RFC2251] Section 4.4), and to return intermediate responses for the search operation ([RFC3377] Section 4.5.2, also see Section 5 below). The adaptation of ExtendedResponse as a general intermediate response mechanism would be problematic. In particular, existing APIs would likely have to be redesigned. It is believed (based upon operational experience) that the addition of a new message to carry intermediate result information is easier to implement and is less likely to cause interoperability problems with existing deployed implementations.
LDAP [RFC3377]が現在定義されているため、中間結果を返すために使用できる一般的なLDAPメッセージタイプはありません。プロトコルの繰り返しの変更を避けるために、中間応答情報を運ぶための単一の再利用可能なLDAPメッセージが望まれます。ExtendEdendResponseメッセージはLDAPで定義されていますが、拡張されたレクエストメッセージ（[RFC2251]セクション4.12）への1つの唯一の応答メッセージ（[RFC2251]セクション4.4）、および中間応答の中間応答を返すために定義されています。検索操作（[RFC3377]セクション4.5.2、以下のセクション5を参照してください）。一般的な中間応答メカニズムとしての拡張リスポンスの適応には問題があります。特に、既存のAPIを再設計する必要がある可能性があります。中間結果情報を運ぶための新しいメッセージを追加すると実装が容易であり、既存の展開された実装で相互運用性の問題を引き起こす可能性が低いと考えられています（運用経験に基づいています）。
This document defines and describes the LDAP IntermediateResponse message. This message is intended to be used in conjunction with ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information.
このドキュメントでは、LDAP中間体験メッセージを定義および説明します。このメッセージは、新しいシングルリクエスト/多重応答操作を定義するために、または中間応答情報を返す必要がある方法で既存のLDAP操作を拡張する際にコントロールと併せて、拡張レクエストと拡張レスポンスと組み合わせて使用することを目的としています。
It is intended that the definitions and descriptions of extended operations and controls using the IntermediateResponse message will define the circumstances in which an IntermediateResponse message can be sent by a server and the associated meaning of the IntermediateResponse message sent in a particular circumstance. Similarly, it is intended that clients will explicitly solicit IntermediateResponse messages by issuing operations that specifically call for their return.
拡張された操作とコントロールの定義と記述は、中間患者応答メッセージを使用して、サーバーによって中間症のメッセージを送信できる状況と、特定の状況で送信された中間科医メッセージの関連する意味を定義することを意図しています。同様に、クライアントは、特に返品を要求する運用を発行することにより、中間の中間メッセージを明示的に勧誘することを意図しています。
The LDAP Content Sync Operation [ZEILENGA] demonstrates one use of LDAP Intermediate Response messages.
LDAPコンテンツ同期操作[Zeilenga]は、LDAP中間応答メッセージの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 [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The term "request control" is used to describe a control that is included in an LDAP request message sent from an LDAP client to an LDAP server.
「リクエストコントロール」という用語は、LDAPクライアントからLDAPサーバーに送信されたLDAP要求メッセージに含まれるコントロールを記述するために使用されます。
This document extends the protocolOp CHOICE of LDAPMessage ([RFC2251] Section 4.1.1) to include the field:
このドキュメントでは、LDAPMESSAGEのプロトコロップ選択（[RFC2251]セクション4.1.1）を拡張して、フィールドを含めます。
intermediateResponse IntermediateResponse
中間体中間体中間体
where IntermediateResponse is defined as:
ここで、中間症は次のように定義されています。
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
IntermediateResponse messages SHALL NOT be returned to the client unless the client issues a request that specifically solicits their return. This document defines two forms of solicitation: extended operation and request control.
クライアントがリターンを具体的に募集する要求を発行しない限り、中間症のメッセージはクライアントに返されてはなりません。このドキュメントでは、2つの形式の勧誘が定義されています。拡張操作とリクエスト制御です。
Although the responseName and responseValue are optional in some circumstances, IntermediateResponse messages usually have a predefined responseName and a responseValue. The value of the responseName (if present), the syntax of the responseValue (if present) and the semantics associated with a particular IntermediateResponse message MUST be specified in documents describing the extended operation or request control that uses them. Sections 3.1 and 3.2 describe additional requirements for the inclusion of responseName and responseValue in IntermediateResponse messages.
ResponseNameとResponseValueは状況によってはオプションですが、通常、中間症のメッセージには事前定義されたResponseLameとResponseValueがあります。ResponseNameの値（存在する場合）、ResponseValueの構文（存在する場合）、および特定の中間症のメッセージに関連付けられたセマンティクスは、それらを使用する拡張操作または要求コントロールを説明するドキュメントで指定する必要があります。セクション3.1および3.2は、中間患者応答メッセージにResponseNameとResponseValueを含めるための追加要件について説明します。
A single-request/multiple-response operation may be defined using a single ExtendedRequest message to solicit zero or more IntermediateResponse messages, of one or more kinds, followed by an ExtendedResponse message.
単一のリクエスト/複数回応答操作は、単一の拡張レクエストメッセージを使用して定義され、1つ以上の種類のゼロ以上の中間体験メッセージを求め、その後に拡張リスポンスメッセージが続きます。
An extended operation that defines the return of multiple kinds of IntermediateResponse messages MUST provide and document a mechanism for the client to distinguish the kind of IntermediateResponse message being sent. This SHALL be accomplished by using different responseName values for each type of IntermediateResponse message associated with the extended operation or by including identifying information in the responseValue of each type of IntermediateResponse message associated with the extended operation.
複数の種類の中間体験メッセージの返品を定義する拡張操作は、クライアントが送信される種類の中間体験メッセージを区別するメカニズムを提供し、文書化する必要があります。これは、拡張操作に関連付けられた各タイプの中間患者応答メッセージに対して異なるresponseName値を使用するか、拡張操作に関連付けられた各タイプの中間患者応答メッセージの応答数値に情報を識別することによって達成されるものとします。
Any LDAP operation may be extended by the addition of one or more controls ([RFC2251] Section 4.1.12). A control's semantics may include the return of zero or more IntermediateResponse messages prior to returning the final result code for the operation. One or more kinds of IntermediateResponse messages may be sent in response to a request control.
LDAP操作は、1つ以上のコントロールを追加することで拡張できます（[RFC2251]セクション4.1.12）。コントロールのセマンティクスには、操作の最終結果コードを返す前に、ゼロ以上の中間中間体験メッセージの返却が含まれる場合があります。リクエストコントロールに応じて、1つまたは複数の種類の中間型メッセージを送信できます。
All IntermediateResponse messages associated with request controls SHALL include a responseName. This requirement ensures that the client can correctly identify the source of IntermediateResponse messages when:
リクエストコントロールに関連付けられたすべての中間型メッセージには、ressponseformnameが含まれます。この要件により、クライアントは、次の場合に、中間症のメッセージのソースを正しく識別できることが保証されます。
a) two or more controls using IntermediateResponse messages are included in a request for any LDAP operation or
a) 中間症のメッセージを使用した2つ以上のコントロールは、LDAP操作のリクエストまたは
b) one or more controls using IntermediateResponse messages are included in a request with an LDAP extended operation that uses IntermediateResponse messages.
b) 中間型メッセージを使用した1つまたは複数のコントロールは、中間患者応答メッセージを使用するLDAP拡張操作を備えたリクエストに含まれています。
A request control that defines the return of multiple kinds of IntermediateResponse messages MUST provide and document a mechanism for the client to distinguish the kind of IntermediateResponse message being sent. This SHALL be accomplished by using different responseName values for each type of IntermediateResponse message associated with the request control or by including identifying information in the responseValue of each type of IntermediateResponse message associated with the request control.
複数の種類の中間体験メッセージの返品を定義するリクエストコントロールは、クライアントが送信される種類の中間体験メッセージを区別するメカニズムを提供し、文書化する必要があります。これは、リクエストコントロールに関連付けられた各タイプの中間症のメッセージに対して異なるRESPENSNAME値を使用するか、リクエストコントロールに関連付けられた各タイプの中間患者応答メッセージの応答数値に情報を識別することによって達成されるものとします。
Because IntermediateResponse messages are associated with extended operations or controls and LDAP provides a means for advertising the extended operations and controls supported by a server (using the supportedExtension ([RFC2252] Section 5.2.3) and supportedControl ([RFC2252] Section 5.2.4) attributes of the root DSE), there is no need for a separate means of advertising support for intermediate response messages.
中間患者メッセージは拡張操作またはコントロールに関連付けられており、LDAPはサーバーによってサポートされている拡張操作とコントロールを宣伝するための手段を提供します（サポートエクステンテンション（[RFC2252]セクション5.2.3）およびサポートコントロール（[RFC2252]セクション5.2.4）ルートDSEの属性）、中間応答メッセージのサポートを広告する別の手段は必要ありません。
It is noted that ExtendedResponse messages may be sent in response to LDAP search operations with controls ([RFC2251] Section 4.5.2). This use of ExtendedResponse messages SHOULD be viewed as deprecated, in favor of use of the IntermediateResponse messages.
コントロールを備えたLDAP検索操作に応じて、拡張リスポンスメッセージが送信される可能性があることに注意してください（[RFC2251]セクション4.5.2）。この拡張リスポンスメッセージの使用は、中間型メッセージの使用を支持して、非推奨と見なす必要があります。
This document describes an enhancement to LDAP. All security considerations of [RFC3377] apply to this document; however, it does not introduce any new security considerations to LDAP.
このドキュメントでは、LDAPの拡張について説明しています。[RFC3377]のすべてのセキュリティ上の考慮事項は、このドキュメントに適用されます。ただし、LDAPに新しいセキュリティ上の考慮事項は導入されません。
Security considerations specific to each extension using this protocol mechanism shall be discussed in the technical specification detailing the extension.
このプロトコルメカニズムを使用して各拡張機能に固有のセキュリティ上の考慮事項については、拡張機能を詳述する技術仕様で説明するものとします。
Registration of the following value has been completed [RFC3383].
次の値の登録が完了しました[RFC3383]。
The IANA has registered an LDAP Message Type (25) to identify the LDAP IntermediateResponse message as defined in section 3 of this document.
IANAは、LDAPメッセージタイプ（25）を登録して、このドキュメントのセクション3で定義されているLDAP Intermediateresponseメッセージを識別しました。
The following registration template is suggested:
次の登録テンプレートをお勧めします。
Subject: Request for LDAP Message Type Registration
Person & email address to contact for further information:
Roger Harrison <roger_harrison@novell.com>
Specification: RFC3771
Author/Change Controller: IESG
Comments: Identifies the LDAP IntermediateResponse Message
The authors would like to acknowledge the members of the IETF LDAP Extensions (ldapext) working group mail list who responded to the suggestion that a multiple-response paradigm might be useful for LDAP extended requests. Special thanks to two individuals: David Wilbur who first introduced the idea on the working group list, and Thomas Salter, who succinctly summarized the group's discussion.
著者は、多重応答パラダイムがLDAP拡張リクエストに役立つ可能性があるという提案に応答したIETF LDAP拡張機能（LDAPEXT）ワーキンググループメールリストのメンバーに感謝します。ワーキンググループリストで最初にアイデアを紹介したDavid Wilburと、グループの議論を簡潔に要約したThomas Salterの2人に感謝します。
[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月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[RFC2252] Wahl、M.、Coulbeck、A.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）：属性構文定義」、RFC 2252、1997年12月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377] Hodges、J。およびR. Morgan、「Lightweight Directory Access Protocol（V3）：技術仕様」、RFC 3377、2002年9月。
[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。、「Internet Assigned Numbers Authority（IANA）のLightweight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 3383、2002年9月。
[ZEILENGA] Zeilenga, K., "LDAP Content Synchronization Operation", Work in Progress, February 2004.
[Zeilenga] Zeilenga、K。、「LDAPコンテンツ同期操作」、2004年2月に進行中の作業。
Roger Harrison Novell, Inc. 1800 S. Novell Place Provo, UT 84606
Roger Harrison Novell、Inc。1800 S. Novell Place Provo、UT 84606
Phone: +1 801 861 2642
EMail: roger_harrison@novell.com
Kurt D. Zeilenga OpenLDAP Foundation
Kurt D. Zeilenga OpenLdap Foundation
EMail: Kurt@OpenLDAP.org
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。