Network Working Group R. Harrison
Request for Comments: 3771 Novell, Inc.
Updates: 2251 K. Zeilenga
Category: Standards Track OpenLDAP Foundation
April 2004
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）互联网协会（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.
本文档定义并描述了IntermediateResponse消息，这是一种在轻量级目录访问协议（LDAP）中定义单请求/多响应操作的通用机制。IntermediateResponse消息的定义方式确保维护现有LDAP操作的协议行为。此消息旨在与LDAP ExtendedRequest和ExtendedResponse结合使用，以定义新的单请求/多响应操作，或者在以要求它们返回中间响应信息的方式扩展现有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.
轻型目录访问协议（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]当前定义的操作中的一个除外）来说已经足够了，但直觉和实践经验都证实了这种范式对于其他操作是不够的。
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实现可以定义一个扩展操作来在服务器上创建管理区域的新副本，该操作分三个阶段完成：（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消息来承载中间响应信息。尽管ExtendedResponse消息是在LDAP中定义的，但它被定义为ExtendedRequest消息的唯一响应消息（[RFC2251]第4.12节）、主动通知的唯一响应消息（[RFC2251]第4.4节），以及为搜索操作返回中间响应的唯一响应消息（[RFC3377]第4.5.2节，另请参见下文第5节）。将ExtendedResponse作为一种通用的中间反应机制进行调整将是一个问题。特别是，现有的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 IntermediateResponse消息。此消息旨在与ExtendedRequest和ExtendedResponse结合使用，以定义新的单请求/多响应操作，或者在以要求它们返回中间响应信息的方式扩展现有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中间响应消息的一种用法。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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的protocolOp选项（[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 ::= [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.
除非客户发出特别要求返回的请求，否则不得将中间响应消息返回给客户。本文档定义了两种形式的请求：扩展操作和请求控制。
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在某些情况下是可选的，但中间响应消息通常具有预定义的responseName和responseValue。必须在描述使用它们的扩展操作或请求控件的文档中指定responseName的值（如果存在）、responseValue的语法（如果存在）以及与特定IntermediateResponse消息相关联的语义。第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.
可以使用单个ExtendedRequest消息来定义单个请求/多个响应操作，以请求零个或多个一种或多种中间响应消息，然后是ExtendedResponse消息。
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值，或通过在与扩展操作相关的每种中间响应消息的responseValue中包含标识信息来实现。
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操作都可以通过添加一个或多个控件来扩展（[RFC2251]第4.1.12节）。控件的语义可能包括在返回操作的最终结果代码之前返回零条或多条中间响应消息。可以发送一种或多种中间响应消息以响应请求控制。
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:
与请求控制相关的所有中间响应消息应包括响应名称。此要求可确保客户机在以下情况下能够正确识别中间响应消息的来源：
a) two or more controls using IntermediateResponse messages are included in a request for any LDAP operation or
a) 任何LDAP操作或请求中都包含两个或多个使用IntermediateResponse消息的控件
b) one or more controls using IntermediateResponse messages are included in a request with an LDAP extended operation that uses IntermediateResponse messages.
b) 使用中间响应消息的一个或多个控件包含在使用中间响应消息的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.
定义多种中间响应消息返回的请求控件必须为客户端提供并记录一种机制，以区分发送的中间响应消息的类型。这应通过为与请求控制相关的每种类型的中间响应消息使用不同的responseName值，或通过在与请求控制相关的每种类型的中间响应消息的responseValue中包含标识信息来实现。
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提供了一种公布服务器支持的扩展操作和控件的方法（使用根DSE的supportedExtension（[RFC2252]第5.2.3节）和supportedControl（[RFC2252]第5.2.4节）属性），不需要为中间响应消息提供单独的广告支持。
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.
需要注意的是，可以发送ExtendedResponse消息以响应带有控件的LDAP搜索操作（[RFC2251]第4.5.2节）。这种使用ExtendedResponse消息的方式应该被视为不推荐使用，而应该使用IntermediateResponse消息。
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中间响应消息。
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
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.
作者要感谢IETF LDAP Extensions（ldapext）工作组邮件列表的成员，他们对多响应范例可能对LDAP扩展请求有用的建议作出了回应。特别感谢两个人：David Wilbur，他首先在工作组名单上介绍了这一想法；Thomas Salter，他简要总结了工作组的讨论。
[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.Kille，“轻量级目录访问协议（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.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[RFC3377]Hodges，J.和R.Morgan，“轻量级目录访问协议（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.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，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
罗杰·哈里森·诺维尔公司，地址：美国犹他州普罗沃市诺维尔广场南1800号，邮编：84606
Phone: +1 801 861 2642
EMail: roger_harrison@novell.com
Phone: +1 801 861 2642
EMail: roger_harrison@novell.com
Kurt D. Zeilenga OpenLDAP Foundation
库尔特D.Zeeliga OpenLDAP基金会
EMail: Kurt@OpenLDAP.org
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）互联网协会（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。