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.
�Rigurosidad
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.
�Identificaci�n
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.
�Codificaci�n
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.