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.
Either is represented by the interface Control. An application typically does not deal directly with the 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 (vendor-specific controls). The request control classes should have constructors that accept arguments in a type-safe and user-friendly manner, and 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. The next few pages include some examples of control implementation classes.
Criticality
When a client sends a request control to a server, it specifies the control's criticality. The criticality determines whether the server can ignore the request control. When it 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 can't reject the request simply because it does not support the control.
Whether a client specifies a request control as critical 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 "unsupported critical extension" error, 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.
You use Control.isCritical() to determine whether a control is critical.
Identification
A designer defining a control must assign it a unique object identifier (OID). For example, the 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 by using ASN.1 BER. Typically, an application does not need to deal with a control's encoding. This is because the implementation classes for a control deal with any encoding/decoding, as well as provide the application with type-friendly interfaces for constructing and accessing a control's fields. Service providers use Control.getEncodedValue() to retrieve a control's encoded value for transmission to the server.

Controls and Extensions