En el LDAP v3, un control puede ser un control de petición o un control de respuesta. Un control de petición se envía desde el cliente al servidor junto con una operación LDAP. Un control de respuesta se envía desde el servidor al cliente junto con una respuesta LDAP.

Los dos están representados por el interface Control. Una aplicación normalmente no trata directamente con el interface. En su lugar, trata con clases que lo implementan. La aplicación obtiene clases de control como parte del repertorio de controles estandarizados a través del IETF o desde el directorio de vendedores (controles específicos del vendedor). Las clases de controles de petición deberían tener constructores que acepten argumentos de un tipo-seguro y de una forma amigable para el usuario, y las clases de controles de respuesta deberían tener métodos de acceso para obtener los datos de la respuesta de una forma segura y amigable para el usuario. Internamente las clases de controles petición/respuesta tratan con valores BER codificados y decodificados. Las siguientes páginas incluyen algunos ejemplos de implementaciones de clases de controles.

Cuando un cliente envía un control de petición a un servidor, especifica lo crítico que es el control. La rigurosidad determina si el servidor puede ignorar el control de petición. Cuando el servidor recibe una petición de control crítica, debe procesar la petición con el control o rechazar toda la petición. Cuando un servidor recibe una petición de control no-crítica, debe procesar la petición con o sin el control. No puede rechazar la petición simplemente porque no soporta el control.

Si un cliente especifica un control de petición como crítico depende principalmente de la naturaleza del control y cómo se ha pensado utilizarlo. Un diseñador que define un control normalmente dicta o recomienda si el control debe enviarse como crítico o no-crítico. Cuando un servidor no soporta un control crítico, se supone que debe enviar de vuelta un error "unsupported critical extension", que se mapea a la excepción JNDI OperationNotSupportedException. Sin embargo, algunos servidores, como el Microsoft Active Directory, podrían no cumplir esto y enviar de vuelta un error de protocolo (CommunicationException).

Usamos Control.isCritical() para determinar si un control es crítico.

Un diseñador que defina un control debe asirgnarle un identificador de objeto único (OID). Por ejemplo, el control Sort tiene el identificador 1.2.840.113556.1.4.473.

Usamos Control.getID() para obtener el identificador de un control.

Una definición de control especifica cómo se debe codificar y trasmitir entre el cliente y el servidor. Esta codificación se hace usando ASN.1 BER. Normalmente una aplicación no necesita tratar con la codificación del control. Esto es así porque las clases de implementación para un control tratan con cualquier codificación/decodificación, y proporcionan a la aplicación interfaces amigables para construir y acceder a los campos del control. Los proveedores de servicio usan Control.getEncodedValue() para recuperar el valor codificado para transmitirlo al servidor.