doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc3909.txt b/doc/rfc/rfc3909.txt
new file mode 100644
index 0000000..7fdca66
--- /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 <kurt@OpenLDAP.org>
+      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 <kurt@openldap.org>
+      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 <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
+
+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]
+