Controls

In the LDAP v3, a control can be either a request control or a response control. A request control is sent from the client to the server along with an LDAP operation. A response control is sent from the server to the client along with an LDAP response.
An LDAP v3 control, either a request control or a response control, is represented by the interface Control .
An application typically does not deal directly with this interface. Instead, it deals with classes that implement this interface. The application gets control classes either as part of a repertoire of controls standardized through the IETF, or from directory vendors for vendor-specific controls. The request control classes should have constructors that accept arguments in a type-safe and user-friendly manner, while the response control classes should have access methods for getting the data of the response in a type-safe and user-friendly manner. Internally, the request/response control classes deal with encoding and decoding BER values. There are some examples of control implementation classes in the next few pages.
Criticality
When a client sends a request control to a server, it specifies the criticality of the control. The criticality determines whether the server can ignore the request control. When a server receives a critical request control, it must either process the request with the control or reject the entire request. When a server receives a noncritical request control, it must process the request either with the control or by ignoring the control. It cannot reject the request based on the fact that it does not support the control.
Whether a client specifies a request control as critical or not depends mainly on the nature of the control and how it is intended to be used. A designer who defines a control typically dictates or recommends whether the control be sent as critical or noncritical. When a server does not support a critical control, it is supposed to send back an "unsupportedCriticalExtension", which maps to the JNDI exception OperationNotSupportedException . However, some servers, such as the Microsoft Active Directory, might be nonconformant and send back a protocol error ( CommunicationException) instead.
Use Control.isCritical() to determine whether a control is critical.
Identification
When a designer defines a control, he must assign it a unique object identifier (OID). For example, the server-side sort control has an identifier of "1.2.840.113556.1.4.473".
You use Control.getID() to get a control's identifier.
Encoding
A control's definition specifies how it is to be encoded and transmitted between client and server. This encoding is done using ASN.1 BER. Typically, an application need not deal with a control's encoding. The implementation classes for a control deal with any encoding/decoding and provide the application with type-friendly interfaces for constructing or accessing fields of a control. The method Control.getEncodedValue() is used by service providers to retrieve a control's encoded value for transmission to the server.

Controls and Extensions