Lightweight Directory Access Protocol (LDAP) Cancel Operation
Extracted elements (18)
The Abandon, Bind, Start TLS, Unbind, and Cancel operations are explicitly made non-cancelable to avoid adding complexity to authentication, authorization, and security layer semantics. Additionally, the Cancel operation itself cannot be abandoned.
The LDAP Cancel operation is modeled after the X.511 DAP Abandon operation, which unlike LDAP Abandon provides a response and requires the abandoned operation to return a response indicating it was canceled. This design was chosen to give clients a clear indication of the outcome of the cancel request.
Clients SHOULD NOT request the cancellation of an operation multiple times.
If the server cannot cancel the operation, the Cancel Response SHALL have a non-success resultCode and SHALL NOT have an impact upon the outstanding operation.
If the server is willing and able to cancel the outstanding operation identified by cancelId, the server SHALL return a Cancel Response with a success resultCode, and the canceled operation SHALL fail with the canceled resultCode.
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.
The cannotCancel resultCode is returned if the identified operation does not support cancellation. Non-cancelable operations include those with no response, those that create/alter/destroy authentication or authorization associations, those that establish/alter/tear-down security services, and operations that abandon or cancel other operations.
The LDAP Cancel operation SHOULD be used instead of the LDAP Abandon operation when the client needs an indication of the outcome.
The noSuchOperation resultCode is returned if the server has no knowledge of the operation requested for cancellation.
The protocolError resultCode is returned if the server is unable to parse the requestValue or the requestValue is absent.
The tooLate resultCode is returned to indicate it is too late to cancel the outstanding operation, for example when a modify operation has already committed updates to the underlying data store.
Four new LDAP result codes are defined: canceled (118), noSuchOperation (119), tooLate (120), and cannotCancel (121). Implementations SHALL recognize all four values.
The Cancel operation is an LDAP Extended Operation identified by OID 1.3.6.1.1.8. It allows a client to cancel an outstanding operation within the same session and, unlike the LDAP Abandon operation, provides a response indicating the outcome.
IANA registered LDAP Object Identifier 1.3.6.1.1.8 to identify the LDAP Cancel Operation, and registered it as an LDAP Protocol Mechanism (Extended Operation). Four new LDAP result codes were also registered: canceled (118), noSuchOperation (119), tooLate (120), and cannotCancel (121).
Servers MUST NOT allow a user to cancel an operation belonging to another user. This is particularly relevant when the Proxy Authorization Control is in use, where different outstanding operations may be processed under different LDAP associations.
The Bind operation and Start TLS extended operation are disallowed from cancellation to avoid adding complexity to authentication, authorization, and security layer semantics. Designers of future extended operations and/or controls should disallow abandonment and cancellation when appropriate.
The Cancel request is an ExtendedRequest with requestName set to 1.3.6.1.1.8 and requestValue containing a BER-encoded cancelRequestValue, which is a SEQUENCE containing a single cancelID field of type MessageID identifying the operation to be canceled.
The Cancel response is an ExtendedResponse where both the responseName and response fields are absent; only the standard resultCode is returned.