mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
284 lines
9.9 KiB
Plaintext
284 lines
9.9 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
INTERNET-DRAFT Kurt D. Zeilenga
|
||
Intended Category: Standard Track OpenLDAP Foundation
|
||
Expires: 1 October 2001 1 April 2001
|
||
|
||
|
||
LDAP Cancel Extended Operation
|
||
<draft-zeilenga-ldap-cancel-03.txt>
|
||
|
||
|
||
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 Extension Working Group
|
||
mailing list <ietf-ldapext@netscape.com>. 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
|
||
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
|
||
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
|
||
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
|
||
|
||
Copyright 2001, The Internet Society. All Rights Reserved.
|
||
|
||
Please see the Copyright section near the end of this document for
|
||
more information.
|
||
|
||
|
||
2. Abstract
|
||
|
||
This specification describes an extended operation to cancel (or
|
||
abandon) an outstanding operation. Unlike the LDAP Abandon operation
|
||
[RFC2251] but like the DAP Abandon operation [X.511], this operation
|
||
has a response which provides an indication of its outcome.
|
||
|
||
The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
|
||
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
|
||
|
||
|
||
|
||
Zeilenga LDAP Cancel [Page 1]
|
||
|
||
INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
|
||
|
||
|
||
this document are to be interpreted as described in RFC 2119
|
||
[RFC2119].
|
||
|
||
|
||
3. Background and Intent of Use
|
||
|
||
LDAP 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.
|
||
|
||
DAP 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.
|
||
|
||
The Cancel operation is intended to be used instead of the LDAP
|
||
Abandon operation. This operation may be used to cancel both
|
||
interrogation and update operations.
|
||
|
||
|
||
4. 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 ::= 1.3.6.1.4.1.4203.1.11.2
|
||
|
||
cancelRequestValue ::= SEQUENCE {
|
||
cancelID MessageID
|
||
}
|
||
|
||
|
||
4.1. Cancel Request
|
||
|
||
The Cancel request is an ExtendedRequest with the requestName field
|
||
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.
|
||
|
||
|
||
4.2. Cancel Response
|
||
|
||
A Cancel response is an ExtendedResponse where the responseName and
|
||
|
||
|
||
|
||
Zeilenga LDAP Cancel [Page 2]
|
||
|
||
INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
|
||
|
||
|
||
response fields are absent.
|
||
|
||
|
||
4.3. Additional Result Codes
|
||
|
||
Implementations of this specification SHALL recognize the following
|
||
additional resultCode values:
|
||
|
||
canceled (72)
|
||
noSuchOperation (73)
|
||
tooLate (74)
|
||
cannotCancel (75)
|
||
|
||
|
||
5. 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 with the message id
|
||
identifying 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 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
|
||
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 server SHALL return noSuchOperation if it has no knowledge of the
|
||
operation requested to be canceled.
|
||
|
||
The server SHALL return cannotCancel 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 associate or disassociate authentication and/or
|
||
authorization associations,
|
||
|
||
- operations which establish or tear-down security services, and
|
||
|
||
|
||
|
||
Zeilenga LDAP Cancel [Page 3]
|
||
|
||
INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
|
||
|
||
|
||
- operations which abandon or cancel other operations.
|
||
|
||
Specifically, 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.
|
||
|
||
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.
|
||
|
||
|
||
6. 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.
|
||
|
||
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.
|
||
|
||
|
||
7. Copyright
|
||
|
||
Copyright 2001, 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
|
||
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
|
||
|
||
|
||
|
||
Zeilenga LDAP Cancel [Page 4]
|
||
|
||
INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
|
||
|
||
|
||
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.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
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,
|
||
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.
|
||
|
||
|
||
8. Bibliography
|
||
|
||
[RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
|
||
Requirement Levels", RFC 2119, March 1997.
|
||
|
||
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
|
||
Protocol (v3)", RFC 2251, December 1997.
|
||
|
||
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
|
||
Access Protocol (v3): Extension for Transport Layer
|
||
Security", RFC 2830, May 2000.
|
||
|
||
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
|
||
Definition", 1993. (not normative)
|
||
|
||
|
||
9. Acknowledgment
|
||
|
||
This document is based upon input from the IETF LDAPext working group.
|
||
|
||
|
||
10. Author's Address
|
||
|
||
Kurt D. Zeilenga
|
||
OpenLDAP Foundation
|
||
<Kurt@OpenLDAP.org>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zeilenga LDAP Cancel [Page 5]
|
||
|