Resumen

  • El MessageID de LDAP sólo debía ser distinto entre solicitudes todavía activas en una sesión. Una búsqueda devolvía muchas entradas y un resultado final con el mismo número, de modo que varias operaciones podían cruzarse.
  • Abandon llevaba un ID propio en su envoltura y otro ID para la operación objetivo, pero no producía respuesta. RFC 3909 creó Cancel cuando la aplicación necesitaba saber si la cancelación llegó, fracasó o llegó demasiado tarde.
  • La búsqueda paginada cambiaba de message ID en cada página y confiaba la continuidad a una cookie opaca. El número identificaba trabajo local; no autenticaba al actor, no nombraba una consulta duradera ni garantizaba una reversión.

Una búsqueda producía una corriente

La ligereza de LDAP reducía el coste de acceso al modelo de directorio X.500; no convertía todo en un diálogo de dos mensajes. Buscar un subárbol podía generar cero o muchas entradas, referencias a zonas que el servidor no había explorado y, por último, una conclusión de éxito o error.

El RFC 1487, de julio de 1993, envolvió cada operación en LDAPMessage. El campo común era messageID: un entero diferente de los demás pedidos pendientes en la misma sesión. El servidor debía copiarlo en todas las envolturas de respuesta relacionadas con el pedido.

El número no identificaba cada paquete. Identificaba la operación que reunía una pluralidad de mensajes. El distinguished name nombraba la entrada; el tipo protocolOp distinguía una entrada de un resultado. El ID permitía que el cliente conectara cada pieza recibida con el estado correcto que mantenía en memoria.

Tampoco pretendía ser universal. Dos conexiones podían usar el mismo valor, y una conexión podía reciclarlo después de un cierre inequívoco. La garantía era más pequeña y verificable: no debe haber dos trabajos simultáneos con el mismo número dentro del ámbito donde se comparan.

El orden del cable dejó de ser el orden del trabajo

El RFC 1777, en 1995, dijo expresamente que no se exigía sincronía. Peticiones y respuestas de varias operaciones podían intercambiarse en cualquier orden.

Una búsqueda 73 podía entregar una entrada, una comparación 74 podía completarse, y después podían llegar más entradas y el final de 73. TCP conservaba el orden de los bytes, no la pertenencia semántica de cada PDU. El ID convertía una secuencia de transporte en varias secuencias de operación.

El RFC 2251 trasladó el contrato a LDAPv3 en 1997. Fijó un máximo de 2^31−1, observó que los clientes solían incrementar un contador y prohibió repetir el valor antes de la respuesta final.

La forma de una búsqueda se volvió explícita: SearchResultEntry y SearchResultReference podían aparecer en distinto orden y un único SearchResultDone cerraba el flujo. Una entrada válida no certificaba que la búsqueda hubiera terminado bien. El mensaje final aportaba tanto el resultado como la frontera ordinaria para retirar el ID del conjunto activo.

El cero se reservó para el servidor

La revisión de 2006 reorganizó la especificación. El RFC 4510 documentó la sustitución del conjunto anterior y el RFC 4511 precisó el protocolo.

Las solicitudes pasaron a requerir un messageID distinto de cero. El cero quedó reservado para una notificación no solicitada del servidor, como Notice of Disconnection. Ese mensaje no responde a una petición anterior y no debe parecer parte de una operación inexistente.

La reserva no autentica al servidor ni autoriza el contenido. Sólo separa una clase de mensaje nacida fuera de las solicitudes del cliente. El tipo de operación y el OID de la notificación siguen siendo indispensables para interpretarla.

El tiempo de reutilización también depende del estado, no del reloj. El cliente sólo puede repetir un ID cuando determina que el servidor ya no atiende la solicitud anterior, normalmente tras la respuesta final o un Bind posterior completado. Un timeout local puede justificar cerrar o conciliar, pero no demuestra por sí solo que la otra parte haya olvidado la operación.

Abandon tenía un blanco exacto y un desenlace incierto

Abandon utiliza dos números con funciones diferentes. Su envoltura es una nueva solicitud y, por ello, lleva un MessageID propio. El contenido es otro MessageID, el de la operación anterior que se desea abandonar.

No hay respuesta de Abandon. El servidor puede abandonar el objetivo. Si se trata de una búsqueda que ya envía entradas, debe dejar de emitir nuevas entradas y no debe enviar SearchResultDone. Sin embargo, el cliente tiene que aceptar resultados que ya estuvieran en tránsito, y algunas operaciones no admiten abandono.

La ausencia de respuesta sirve a quien ya no necesita el resultado, pero impide convertir la señal en recibo. El silencio no diferencia una renuncia exitosa de trabajo que sigue sin completarse. El ID puede elegir exactamente el estado correcto sin revelar qué efecto tuvo la petición.

Por eso RFC 2251 aplazaba la reutilización de los IDs del Abandon y del objetivo hasta recibir respuesta de una solicitud posterior. Esa respuesta no confirmaba el abandono: sólo demostraba avance suficiente en la sesión para reducir una ambigüedad inmediata.

Cancel hizo explícito el resultado

El RFC 3909, de 2004, añadió la operación extendida Cancel para aplicaciones que necesitan conocer el desenlace. No cambió retroactivamente Abandon.

Cancel tiene un ID de envoltura y un cancelID que señala el trabajo pendiente. Si funciona, el servidor devuelve éxito para Cancel y el objetivo termina con código canceled. Si no, distingue un objetivo desconocido, una operación no cancelable o una solicitud que llegó demasiado tarde.

El ejemplo de tooLate es una modificación ya confirmada en el almacén subyacente. Aquí aparece la frontera económica: localizar con precisión una operación no concede capacidad para deshacer su efecto. Cancelar una intención y revertir una escritura son poderes distintos.

Bind, StartTLS, Unbind, Abandon y Cancel no pueden cancelarse. Esas operaciones construyen o desmontan la asociación y la seguridad que dan sentido al resto. Un número de correlación no puede gobernar sin límites el marco del que depende.

La continuidad de páginas vivía en otra cosa

El RFC 2696 demuestra que el número no es una identidad de consulta. El servidor devuelve una página y una cookie opaca dentro de SearchResultDone. Para pedir la página siguiente, el cliente repite los valores de búsqueda, cambia el messageID, entrega la última cookie y puede variar el tamaño.

Cada página es una operación nueva. La cookie conserva la posición que el servidor permite reanudar. Una cookie antigua puede dejar de valer; una vacía cierra la serie. Abandon puede cortar la página en curso y a la vez inutilizar la cookie. Para cerrar ordenadamente la serie paginada se envía otra búsqueda de tamaño cero con la última cookie.

Así quedan separadas tres autoridades: el ID correlaciona mensajes con una operación en curso; la cookie habilita continuidad entre operaciones; el nombre de directorio identifica el objeto. Ninguna de ellas acredita a la persona que consulta ni confirma que los datos sean verdaderos.

Fuentes y límite de inferencia

La secuencia histórica procede de RFC 1487, RFC 1777, RFC 2251, RFC 2696, RFC 3909, RFC 4510 y RFC 4511. Los documentos prueban reglas y evolución; no miden adopción actual, no certifican productos y no resuelven el resultado de una operación capturada.

El campo perduró porque su mandato era estrecho. Unía mensajes con estado comprobable. Cuando se necesitaba prueba de finalización, cancelación, continuación, autenticación o permiso, el protocolo exigía evidencia diferente.