From: Kurt Zeilenga Date: Sat, 9 Oct 2004 02:11:47 +0000 (+0000) Subject: RFC 3909: LDAP Cancel Operation X-Git-Tag: OPENLDAP_REL_ENG_2_3_0ALPHA~440 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=275ee6f13d2439888994b79d98b88068303078b5;p=openldap RFC 3909: LDAP Cancel Operation --- diff --git a/doc/drafts/draft-zeilenga-ldap-cancel-xx.txt b/doc/drafts/draft-zeilenga-ldap-cancel-xx.txt deleted file mode 100644 index c0558dbaa4..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-cancel-xx.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 25 October 2003 - - - LDAP Cancel Operation - - - -1. Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extensions mailing list - . Please send editorial comments directly to the - author . - - Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - Please see the Full Copyright section near the end of this document - for more information. - - -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. - - - - -Zeilenga LDAP Cancel [Page 1] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003 - - -Terminology - - 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]. - - DSA stands for Directory System Agent (or server). - DSE stands for DSA-specific Entry. - - 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]. - - -1. Background and Intent of Use - - 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 calls - for there to be no response of the abandoned operation. These - semantics provide the client with no clear indication of the outcome - of the Abandon operation. - - X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon - operation which does have 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. - - 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. - - -2. Cancel Operation - - The Cancel operation is defined as a LDAP Extended Operation [RFC2251, - Section 4.12] identified by the IANA-ASSIGNED-OID. This section - details the syntax of the Cancel request and response messages and - defines additional LDAP resultCodes. - - cancelRequestValue ::= SEQUENCE { - cancelID MessageID - } - - -2.1. Cancel Request - - - -Zeilenga LDAP Cancel [Page 2] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003 - - - The Cancel request is an ExtendedRequest with the requestName field - containing the IANA-ASSIGNED-OID and a requestValue field which - contains a BER-encoded cancelRequestValue value. The cancelID field - contains the message id associated with the operation to be canceled. - - -2.2. Cancel Response - - A Cancel response is an ExtendedResponse where the responseName and - response fields are absent. - - -2.3. Additional Result Codes - - Implementations of this specification SHALL recognize the following - additional resultCode values: - - canceled (IANA-ASSIGNED-1) - noSuchOperation (IANA-ASSIGNED-2) - tooLate (IANA-ASSIGNED-3) - cannotCancel (IANA-ASSIGNED-4) - - -3. Operational Semantics - - 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 cancelation of an operation - multiple times. - - 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 impact upon the outstanding - operation (if it exists). - - The protocolError resultCode is returned if the server is unable to - parse the requestValue or the requestValue is absent, - - The noSuchOperation resultCode is returned if the server has no - knowledge of the operation requested to be canceled. - - The cannotCancel resultCode is returned if the identified operation - - - -Zeilenga LDAP Cancel [Page 3] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003 - - - does not support cancelation or the cancel operation could not be - performed. The following classes of operations are not cancelable: - - - 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. - - 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 - as already committed updates to the underlying data store. - - Servers SHOULD indicate their support for this extended operation by - providing IANA-ASSIGNED-OID 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. - - -4. Security Considerations - - This operation is intended to allow 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. - - Some operations should not be cancelable for security reasons. This - specification disallows cancelation of 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. - - -5. IANA Considerations - - Registration of the following values [RFC3383] is requested. - - - - -Zeilenga LDAP Cancel [Page 4] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003 - - -5.1. Object Identifier - - It is requested that IANA register upon Standards Action an LDAP - Object Identifier to identify the LDAP Cancel Operation as defined in - this document. - - Subject: Request for LDAP Object Identifier Registration - Person & email address to contact for further information: - Kurt Zeilenga - Specification: RFC XXXX - Author/Change Controller: IESG - Comments: - Identifies the LDAP Cancel Operation - - -5.2. LDAP Protocol Mechanism - - It is requested that IANA register upon Standards Action the LDAP - Protocol Mechanism described in this document. - - Subject: Request for LDAP Protocol Mechanism Registration - Object Identifier: IANA-ASSIGNED-OID - Description: LDAP Cancel Operation - Person & email address to contact for further information: - Kurt Zeilenga - Usage: Extended Operation - Specification: RFC XXXX - Author/Change Controller: IESG - Comments: none - in 2 - - -5.3. LDAP Result Codes - - It is requested that IANA register upon Standards Action the LDAP - Result Codes described in this document. - - Subject: LDAP Result Code Registration - Person & email address to contact for further information: - Kurt Zeilenga - Result Code Name: canceled - Result Code Name: noSuchOperation - Result Code Name: tooLate - Result Code Name: cannotCancel - Specification: RFC XXXX - Author/Change Controller: IESG - Comments: request four consecutive result codes be assigned - - - - -Zeilenga LDAP Cancel [Page 5] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003 - - -6. Acknowledgment - - The LDAP Cancel operation is modeled after the X.511 DAP Abandon - operation. - - -7. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight - Directory Access Protocol (v3): Extension for Transport - Layer Security", RFC 2830, May 2000. - - [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, - September 2002. - - [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.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). - - -8. Informative References - - [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64 - (also RFC 3383), September 2002. - - [X.511] International Telecommunication Union - - Telecommunication Standardization Sector, "The - Directory: Abstract Service Definition", X.511(1993). - - -9. Author's Address - - Kurt D. Zeilenga - - - -Zeilenga LDAP Cancel [Page 6] - -INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003 - - - OpenLDAP Foundation - - - - -Intellectual Property Rights - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it has made any - effort to identify any such rights. Information on the IETF's - procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can be obtained - from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - -Full Copyright - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be followed, - or as required to translate it into languages other than English. - - - - - - -Zeilenga LDAP Cancel [Page 7] - diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index 5f00a1c6ca..763c2d9b79 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -46,6 +46,7 @@ rfc3771.txt LDAP: Intermediate Response Message (PS) rfc3829.txt LDAP Authorization Identity Controls (I) rfc3866.txt Language Tag and Ranges in LDAP (PS) rfc3876.txt Returning Matched Values with LDAP (PS) +rfc3909.txt LDAP Cancel Operation (PS) Legend: STD Standard diff --git a/doc/rfc/rfc3909.txt b/doc/rfc/rfc3909.txt new file mode 100644 index 0000000000..7fdca6643c --- /dev/null +++ b/doc/rfc/rfc3909.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3909 OpenLDAP Foundation +Category: Standards Track October 2004 + + + Lightweight Directory Access Protocol (LDAP) + Cancel Operation + +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. + +Copyright Notice + + Copyright (C) The Internet Society (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. + +1. Background and Intent of Use + + 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. + + 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. + + 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. + + + + + +Zeilenga Standards Track [Page 1] + +RFC 3909 LDAP Cancel Operation October 2004 + + + 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]. + + DSA stands for Directory System Agent (or server). + DSE stands for DSA-specific Entry. + + 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]. + +2. Cancel Operation + + 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. + +2.1. Cancel Request + + 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. + + cancelRequestValue ::= SEQUENCE { + cancelID MessageID + -- MessageID is as defined in [RFC2251] + } + + The cancelID field contains the message ID associated with the + operation to be canceled. + +2.2. Cancel Response + + A Cancel response is an ExtendedResponse where the responseName and + response fields are absent. + +2.3. Additional Result Codes + + Implementations of this specification SHALL recognize the following + additional resultCode values: + + canceled (118) + noSuchOperation (119) + tooLate (120) + cannotCancel (121) + + + + +Zeilenga Standards Track [Page 2] + +RFC 3909 LDAP Cancel Operation October 2004 + + +3. Operational Semantics + + 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. + + 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). + + The protocolError resultCode is returned if the server is unable to + parse the requestValue or the requestValue is absent, + + The noSuchOperation resultCode is returned if the server has no + knowledge of the operation requested for cancelation. + + 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: + + - 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. + + 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. + + + + +Zeilenga Standards Track [Page 3] + +RFC 3909 LDAP Cancel Operation October 2004 + + + 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. + +4. Security Considerations + + 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. + + 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. + +5. IANA Considerations + + The following values [RFC3383] have been registered by the IANA. + +5.1. Object Identifier + + 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. + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Kurt Zeilenga + Specification: RFC 3909 + Author/Change Controller: IESG + Comments: + Identifies the LDAP Cancel Operation + + + + + + + + + + + + + +Zeilenga Standards Track [Page 4] + +RFC 3909 LDAP Cancel Operation October 2004 + + +5.2. LDAP Protocol Mechanism + + The IANA has registered upon Standards Action the LDAP Protocol + Mechanism described in this document. + + 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 + Usage: Extended Operation + Specification: RFC 3909 + Author/Change Controller: IESG + Comments: none + +5.3. LDAP Result Codes + + The IANA has registered upon Standards Action the LDAP Result Codes + described in this document. + + Subject: LDAP Result Code Registration + Person & email address to contact for further information: + Kurt Zeilenga + 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 + +6. Acknowledgment + + The LDAP Cancel operation is modeled after the X.511 DAP Abandon + operation. + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 5] + +RFC 3909 LDAP Cancel Operation October 2004 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight + Directory Access Protocol (v3): Extension for Transport + Layer Security", RFC 2830, May 2000. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [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.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). + +7.2. Informative References + + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 3383, September 2002. + + [X.511] International Telecommunication Union - Telecommunication + Standardization Sector, "The Directory: Abstract Service + Definition", X.511(1993). + +8. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 3909 LDAP Cancel Operation October 2004 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (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. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Zeilenga Standards Track [Page 7] +