mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
396 lines
12 KiB
Plaintext
396 lines
12 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
INTERNET-DRAFT Kurt D. Zeilenga
|
||
Intended Category: Standard Track OpenLDAP Foundation
|
||
Expires in six months 3 May 2003
|
||
|
||
|
||
LDAP Cancel Extended Operation
|
||
<draft-zeilenga-ldap-cancel-08.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 <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
|
||
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 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 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-08 3 May 2003
|
||
|
||
|
||
Conventions
|
||
|
||
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].
|
||
|
||
Protocol elements are described using ASN.1 [X.680]. 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].
|
||
|
||
|
||
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 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
|
||
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
|
||
|
||
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]
|
||
|
||
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
|
||
|
||
|
||
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 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 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
|
||
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]
|
||
|
||
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
|
||
|
||
|
||
- operations which have no response,
|
||
|
||
- operations which associate or disassociate authentication and/or
|
||
authorization associations,
|
||
|
||
- operations which establish 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 commited updates to the underlying datastore.
|
||
|
||
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 this
|
||
operation.
|
||
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
|
||
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]
|
||
|
||
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
|
||
|
||
|
||
The following registration template is suggested:
|
||
|
||
Subject: Request for LDAP Object Identifier Registration
|
||
Person & email address to contact for further information:
|
||
Kurt Zeilenga <kurt@OpenLDAP.org>
|
||
Specification: RFCXXXX
|
||
Author/Change Controller: IESG
|
||
Comments:
|
||
Identifies the LDAP Cancel Extended 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 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
|
||
|
||
|
||
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 <kurt@OpenLDAP.org>
|
||
Result Code Name: canceled
|
||
Result Code Name: noSuchOperation
|
||
Result Code Name: tooLate
|
||
Result Code Name: cannotCancel
|
||
Specification: RFCXXXX
|
||
Author/Change Controller: IESG
|
||
Comments: request four consecutive result codes be assigned
|
||
|
||
|
||
6. Acknowledgment
|
||
|
||
The LDAP Cancel operation is modeled after the X.511 DAP Abandon
|
||
|
||
|
||
|
||
Zeilenga LDAP Cancel [Page 5]
|
||
|
||
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
|
||
|
||
|
||
operation.
|
||
|
||
|
||
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.
|
||
|
||
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
|
||
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.
|
||
|
||
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
|
||
Canonical, and Distinguished Encoding Rules", X.690, 1994.
|
||
|
||
|
||
8. Informative References
|
||
|
||
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
|
||
September 2002.
|
||
|
||
[X.511] ITU-T, "The Directory: Abstract Service Definition", X.511,
|
||
1993.
|
||
|
||
|
||
9. Author's Address
|
||
|
||
Kurt D. Zeilenga
|
||
OpenLDAP Foundation
|
||
<Kurt@OpenLDAP.org>
|
||
|
||
|
||
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]
|
||
|
||
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
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zeilenga LDAP Cancel [Page 7]
|
||
|