INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 3 May 2003
LDAP Cancel Extended Operation
- <draft-zeilenga-ldap-cancel-05.txt>
+ <draft-zeilenga-ldap-cancel-08.txt>
1. Status of this Memo
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 Extension Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ mailing list <ldapext@ietf.org>. Please send editorial comments
+ directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2002, The Internet Society. All Rights Reserved.
+ Copyright 2003, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
- This specification describes an LDAP (Lightweight Directory Access
- Protocol) extended operation to cancel (or abandon) an outstanding
- operation. Unlike the LDAP Abandon operation but like the X.511 DAP
- Abandon operation, this operation has a response which provides an
- indication of its outcome.
+ 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]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
Conventions
1. Background and Intent of Use
- LDAP [RFC2251] provides an Abandon operation which clients may use to
- cancel other operations. The Abandon operation does not have a
- response and also 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.
+ 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 DAP [X.511] provides an Abandon operation which does have a
- response and also requires the abandoned operation to return a
- response with indicating it was canceled. The Cancel operation is
- modeled after the DAP 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 Cancel
+ operation is modeled after the DAP Abandon operation.
The Cancel operation SHOULD be used instead of the LDAP Abandon
operation when the client needs an indication of the outcome. This
operations.
-4. Cancel Operation
+2. Cancel Operation
- The Cancel operation is defined as a LDAPv3 Extended Operation
- [RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID.
- This section details the syntax of the Cancel request and response
- messages and defines additional LDAP resultCodes.
-
- cancelOID OBJECT IDENTIFIER ::= IANA-ASSIGNED
+ 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
}
-4.1. Cancel Request
+2.1. Cancel Request
The Cancel request is an ExtendedRequest with the requestName field
+ containing the IANA-0IGNED-OID and a requestValue field which contains
Zeilenga LDAP Cancel [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
- containing cancelOID OID and a requestValue field which contains a
- cancelRequestValue value encoded per [RFC2251, Section 5.1]. The
- cancelID field contains the message id associated with the operation
- to be canceled.
+ a BER-encoded cancelRequestValue value. The cancelID field contains
+ the message id associated with the operation to be canceled.
-4.2. Cancel Response
+2.2. Cancel Response
A Cancel response is an ExtendedResponse where the responseName and
response fields are absent.
-4.3. Additional Result Codes
+2.3. Additional Result Codes
Implementations of this specification SHALL recognize the following
additional resultCode values:
cannotCancel (IANA-ASSIGNED-4)
-5. Operational Semantics
+3. Operational Semantics
The function of the Cancel Operation is to request that the server
cancel an outstanding operation issued within the same session.
a distinct message id. Clients SHOULD NOT request cancelation of an
operation multiple times.
- If the server is unable to parse the requestValue or the requestValue
- is absent, the server shall return protocolError.
-
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
non-success resultCode and SHALL NOT have impact upon the outstanding
operation (if it exists).
- The server SHALL return noSuchOperation if it has no knowledge of the
- operation requested to be canceled.
+ The protocolError resultCode is returned if the server is unable to
+ parse the requestValue or the requestValue is absent,
- The server SHALL return cannotCancel if the identified operation does
+ 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
+ does not support cancelation or the cancel operation could not be
+ performed. The following classes of operations are not cancelable:
Zeilenga LDAP Cancel [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
- 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 associate or disassociate authentication and/or
- operations which abandon or cancel other operations.
- Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
- operations are not cancelable.
+ Specifically, the Abandon, Bind, Start TLS [RFC2830], Unbind and
+ Cancel operations are not cancelable.
- If the result of the outstanding operation has been determined by the
- server, the outstanding operation SHALL NOT be canceled and the cancel
- operation SHALL result in tooLate.
+ 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 commited updates to the underlying datastore.
Servers SHOULD indicate their support for this extended operation by
- providing cancelOID 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 and/or has established
- the necessary security protections to use this operation. Clients
- SHOULD verify the server implements this extended operation prior to
- attempting the operation by asserting the supportedExtension attribute
- contains a value of cancelOID.
+ 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 this
+ operation.
-6. Security Considerations
+4. Security Considerations
This operation is intended to allow a user to cancel operations they
previously issued. No user should be allowed to cancel an operation
- issued by another user (within the same session or not). However, as
- this operation may only be used to cancel within the same session and
- LDAP requires operations to be abandoned upon bind requests, this is a
- non-issue.
+ issued by 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
+ extended operations and/or controls should disallow abandonment and
cancelation when appropriate.
-7. IANA Considerations
+5. IANA Considerations
+
+ Registration of the following values [RFC3383] is requested.
+
+5.1. Object Identifier
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier to identify the LDAP Cancel Extended Operation as
+ defined in this document.
Zeilenga LDAP Cancel [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
-
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
-7.1. Object Identifiers
- It is requested that IANA register a Directory Number OID for use in
- this document upon Standards Action by the IESG. This OID will be
- used to identify the LDAP Cancel extended operation as indicated
- above. The following registration template is suggested:
+ The following registration template is suggested:
- Subject: Request for LDAP OID Registration
+ Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFCXXX
+ Specification: RFCXXXX
Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Cancel Extended Operation
-7.2. LDAP Result Codes
+5.2. LDAP Protocol Mechanism
- It is requested that IANA register the LDAP result codes:
+ It is requested that IANA register upon Standards Action the LDAP
+ Protocol Mechanism described in this document.
+
+ Subject: Request for LDAP Protocol Mechansism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: LDAP Cancel Extended Operation
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+ in 2
- canceled (IANA-ASSIGNED-1)
- noSuchOperation (IANA-ASSIGNED-2)
- tooLate (IANA-ASSIGNED-3)
- cannotCancel (IANA-ASSIGNED-4)
- upon Standards Action by the IESG. The following registration
- template is suggested:
+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:
Comments: request four consecutive result codes be assigned
-8. Acknowledgment
+6. Acknowledgment
- This document is based upon input from the IETF LDAPext working group.
+ The LDAP Cancel operation is modeled after the X.511 DAP Abandon
-9. Normative References
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+Zeilenga LDAP Cancel [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+ operation.
-Zeilenga LDAP Cancel [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+7. Normative References
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
+ (v3): Technical Specification", RFC 3377, September 2002.
+
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
of Basic Notation", X.680, 1994.
Canonical, and Distinguished Encoding Rules", X.690, 1994.
-9. Informative References
+8. Informative References
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993.
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
+ September 2002.
+ [X.511] ITU-T, "The Directory: Abstract Service Definition", X.511,
+ 1993.
-11. Author's Address
+
+9. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
-Copyright 2002, The Internet Society. All Rights Reserved.
+Copyright 2003, The Internet Society. 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 implementation 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
+
+
+
+Zeilenga LDAP Cancel [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+
+
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
This document and the information contained herein is provided on an
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
-
-
-
-Zeilenga LDAP Cancel [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
-
-
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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
projects / openldap / blobdiff