Network Working Group K. Zeilenga
Request for Comments: 3909 OpenLDAP Foundation
Category: Standards Track October 2004
Network Working Group K. Zeilenga
Request for Comments: 3909 OpenLDAP Foundation
Category: Standards Track October 2004
Lightweight Directory Access Protocol (LDAP) Cancel Operation
轻型目录访问协议（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).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome.
本规范描述了用于取消（或放弃）未完成操作的轻量级目录访问协议（LDAP）扩展操作。与LDAP放弃操作不同，但与X.511目录访问协议（DAP）放弃操作一样，此操作有一个响应，该响应提供其结果的指示。
The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides an Abandon operation [RFC2251] which clients may use to cancel other operations. The Abandon operation does not have a response and requires no response from the abandoned operation. These semantics provide the client with no clear indication of the outcome of the Abandon operation.
轻量级目录访问协议（LDAP）[RFC3377]提供了一个放弃操作[RFC2251]，客户端可以使用该操作取消其他操作。放弃操作没有响应，也不需要放弃操作的响应。这些语义为客户机提供了放弃操作结果的明确指示。
The X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon operation which has a response and also requires the abandoned operation to return a response indicating it was canceled. The LDAP Cancel operation is modeled after the DAP Abandon operation.
X.511目录访问协议（DAP）[X.511]提供一个放弃操作，该操作有一个响应，并且还要求放弃的操作返回一个指示其已取消的响应。LDAP取消操作是在DAP放弃操作之后建模的。
The LDAP Cancel operation SHOULD be used instead of the LDAP Abandon operation when the client needs an indication of the outcome. This operation may be used to cancel both interrogation and update operations.
当客户端需要结果指示时，应使用LDAP取消操作而不是LDAP放弃操作。此操作可用于取消询问和更新操作。
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 [RFC2251].
协议元素使用带有隐式标记的ASN.1[X.680]进行描述。术语“BER编码”是指根据[RFC2251]第5.1节详述的限制，使用基本编码规则[X.690]对元素进行编码。
DSA stands for Directory System Agent (or server). DSE stands for DSA-specific Entry.
DSA代表目录系统代理（或服务器）。DSE代表DSA特定条目。
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 BCP 14 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
The Cancel operation is defined as an LDAP Extended Operation [RFC2251, Section 4.12] identified by the object identifier 1.3.6.1.1.8. This section details the syntax of the Cancel request and response messages and defines additional LDAP resultCodes.
取消操作被定义为由对象标识符1.3.6.1.1.8标识的LDAP扩展操作[RFC2251，第4.12节]。本节详细介绍取消请求和响应消息的语法，并定义其他LDAP结果代码。
The Cancel request is an ExtendedRequest with the requestName field containing 1.3.6.1.1.8 and a requestValue field which contains a BER-encoded cancelRequestValue value.
Cancel请求是一个ExtendedRequest，requestName字段包含1.3.6.1.1.8，requestValue字段包含BER编码的cancelRequestValue值。
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
-- MessageID is as defined in [RFC2251]
}
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
-- MessageID is as defined in [RFC2251]
}
The cancelID field contains the message ID associated with the operation to be canceled.
cancelID字段包含与要取消的操作关联的消息ID。
A Cancel response is an ExtendedResponse where the responseName and response fields are absent.
Cancel响应是一个ExtendedResponse，其中没有responseName和response字段。
Implementations of this specification SHALL recognize the following additional resultCode values:
本规范的实施应识别以下额外的resultCode值：
canceled (118) noSuchOperation (119) tooLate (120) cannotCancel (121)
已取消（118）无此操作（119）tooLate（120）无法取消（121）
The function of the Cancel Operation is to request that the server cancel an outstanding operation issued within the same session.
取消操作的功能是请求服务器取消在同一会话中发出的未完成操作。
The client requests the cancelation of an outstanding operation by issuing a Cancel Response with a cancelID set to the message ID of the outstanding operation. The Cancel Request itself has a distinct message ID. Clients SHOULD NOT request the cancelation of an operation multiple times.
客户端通过发出cancelID设置为未完成操作的消息ID的Cancel响应来请求取消未完成操作。取消请求本身具有不同的消息ID。客户端不应多次请求取消操作。
If the server is willing and able to cancel the outstanding operation identified by the cancelId, the server SHALL return a Cancel Response with a success resultCode, and the canceled operation SHALL fail with canceled resultCode. Otherwise the Cancel Response SHALL have a non-success resultCode and SHALL NOT have an impact upon the outstanding operation (if it exists).
如果服务器愿意并且能够取消cancelId标识的未完成操作，则服务器应返回一个带有成功resultCode的cancel响应，被取消的操作将带有取消的resultCode失败。否则，取消响应应具有非成功结果代码，并且不得对未完成的操作（如果存在）产生影响。
The protocolError resultCode is returned if the server is unable to parse the requestValue or the requestValue is absent,
如果服务器无法解析requestValue或requestValue不存在，则返回protocolError resultCode，
The noSuchOperation resultCode is returned if the server has no knowledge of the operation requested for cancelation.
如果服务器不知道请求取消的操作，则返回noSuchOperation resultCode。
The cannotCancel resultCode is returned if the identified operation does not support cancelation or the cancel operation could not be performed. The following classes of operations are not cancelable:
如果标识的操作不支持取消或无法执行取消操作，则返回cannotCancel resultCode。以下操作类别不可取消：
- operations which have no response,
- 没有反应的行动，
- operations which create, alter, or destroy authentication and/or authorization associations,
- 创建、更改或销毁身份验证和/或授权关联的操作，
- operations which establish, alter, or tear-down security services, and
- 建立、更改或拆除安全服务的操作，以及
- operations which abandon or cancel other operations.
- 放弃或取消其他操作的操作。
Specifically, the Abandon, Bind, Start TLS [RFC2830], Unbind, and Cancel operations are not cancelable.
具体而言，放弃、绑定、启动TLS[RFC2830]、取消绑定和取消操作是不可取消的。
The Cancel operation cannot be abandoned.
不能放弃取消操作。
The tooLate resultCode is returned to indicate that it is too late to cancel the outstanding operation. For example, the server may return tooLate for a request to cancel an outstanding modify operation which has already committed updates to the underlying data store.
返回tooLate resultCode以指示取消未完成的操作为时已晚。例如，服务器可能会返回tooLate请求取消已将更新提交到基础数据存储的未完成修改操作。
Servers SHOULD indicate their support for this extended operation by providing 1.3.6.1.1.8 as a value of the 'supportedExtension' attribute type in their root DSE. A server MAY choose to advertise this extension only when the client is authorized to use it.
服务器应通过在其根DSE中提供1.3.6.1.1.8作为“supportedExtension”属性类型的值来指示其对此扩展操作的支持。只有当客户机被授权使用此扩展时，服务器才可以选择公布此扩展。
This operation is intended to allow a user to cancel operations they previously issued during the current LDAP association. In certain cases, such as when the Proxy Authorization Control is in use, different outstanding operations may be processed under different LDAP associations. Servers MUST NOT allow a user to cancel an operation belonging to another user.
此操作旨在允许用户取消以前在当前LDAP关联期间发布的操作。在某些情况下，例如在使用代理授权控件时，可能会在不同的LDAP关联下处理不同的未完成操作。服务器不得允许用户取消属于其他用户的操作。
Some operations should not be cancelable for security reasons. This specification disallows the cancelation of the Bind operation and Start TLS extended operation so as to avoid adding complexity to authentication, authorization, and security layer semantics. Designers of future extended operations and/or controls should disallow abandonment and cancelation when appropriate.
出于安全原因，某些操作不应取消。本规范不允许取消绑定操作和启动TLS扩展操作，以避免增加身份验证、授权和安全层语义的复杂性。未来扩展操作和/或控制的设计者应在适当时不允许放弃和取消。
The following values [RFC3383] have been registered by the IANA.
IANA已注册了以下值[RFC3383]。
The IANA has registered upon Standards Action the LDAP Object Identifier 1.3.6.1.1.8 to identify the LDAP Cancel Operation as defined in this document.
IANA已在标准操作时注册了LDAP对象标识符1.3.6.1.1.8，以识别本文档中定义的LDAP取消操作。
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC 3909
Author/Change Controller: IESG
Comments:
Identifies the LDAP Cancel Operation
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC 3909
Author/Change Controller: IESG
Comments:
Identifies the LDAP Cancel Operation
The IANA has registered upon Standards Action the LDAP Protocol Mechanism described in this document.
IANA已根据本文档中描述的LDAP协议机制注册了标准操作。
Subject: LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.1.8
Description: LDAP Cancel Operation
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFC 3909
Author/Change Controller: IESG
Comments: none
Subject: LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.1.8
Description: LDAP Cancel Operation
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFC 3909
Author/Change Controller: IESG
Comments: none
The IANA has registered upon Standards Action the LDAP Result Codes described in this document.
IANA已根据标准行动注册了本文档中描述的LDAP结果代码。
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: canceled (118)
Result Code Name: noSuchOperation (119)
Result Code Name: tooLate (120)
Result Code Name: cannotCancel (121)
Specification: RFC 3909
Author/Change Controller: IESG
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: canceled (118)
Result Code Name: noSuchOperation (119)
Result Code Name: tooLate (120)
Result Code Name: cannotCancel (121)
Specification: RFC 3909
Author/Change Controller: IESG
The LDAP Cancel operation is modeled after the X.511 DAP Abandon operation.
LDAP取消操作是在X.511 DAP放弃操作之后建模的。
[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月。
[RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[RFC2830]Hodges，J.，Morgan，R.，和M.Wahl，“轻量级目录访问协议（v3）：传输层安全扩展”，RFC 2830，2000年5月。
[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月。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.680]国际电信联盟-电信标准化部门，“抽象语法符号1（ASN.1）-基本符号规范”，X.680（1997）（也称ISO/IEC 8824-1:1998）。
[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(1997) (also ISO/IEC 8825-1:1998).
[X.690]国际电信联盟-电信标准化部门，“ASN.1编码规则规范：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）”，X.690（1997）（另见ISO/IEC 8825-1:1998）。
[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月。
[X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993).
[X.511]国际电信联盟-电信标准化部门，“目录：抽象服务定义”，X.511（1993年）。
Kurt D. Zeilenga OpenLDAP Foundation
库尔特D.Zeeliga OpenLDAP基金会
EMail: Kurt@OpenLDAP.org
EMail: Kurt@OpenLDAP.org
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见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编辑功能的资金目前由互联网协会提供。