Resumen

  • RFC 1959 reunió en una URL el servidor, el nombre distinguido, los atributos, el alcance y el filtro de una búsqueda LDAP; omitir campos activaba reglas predeterminadas para construir la consulta.
  • El host podía no figurar y la URL no tenía lugar para credenciales. La misma cadena podía ejecutarse contra distintos servidores, sesiones y políticas de acceso.
  • La URL describía la pregunta, no demostraba el servidor elegido, la información autorizada, el final correcto de la búsqueda ni la actuación de un sistema dependiente.

El valor estaba en transportar la pregunta

En junio de 1996, LDAP todavía se explicaba como una puerta ligera hacia X.500. RFC 1959 quiso que los clientes de Internet llegaran directamente al protocolo y, al mismo tiempo, dejó la forma abierta para servidores LDAP autónomos. La consulta adquirió un envoltorio que documentos y clientes web podían transportar, sin convertir el directorio en una página web.

La gramática imponía un orden. Después de ldap:// podía aparecer un host y un puerto; tras la barra venía el nombre distinguido; después, separados por signos de interrogación, podían venir los atributos, el alcance y el filtro.

Cada parte respondía a una pregunta diferente. El host localizaba un servidor. El nombre distinguido fijaba el punto de partida. La lista de atributos expresaba qué datos quería recibir el cliente. El alcance escogía el objeto base, un nivel o todo un subárbol. El filtro indicaba qué entradas coincidían.

El artículo existente sobre RFC 1558 ya estudia el filtro legible como predicado ejecutable. Esta historia se queda en la capa exterior: cómo ese filtro viajó junto con los demás parámetros. Un filtro no elige servidor ni permisos; una URL tampoco cambia la gramática interna del filtro.

Un campo vacío podía producir una orden concreta

RFC 1959 definió varios valores implícitos. Sin puerto, el destino era TCP 389. Sin lista de atributos, el cliente solicitaba todos. Sin alcance, hacía una búsqueda sobre el objeto base. Sin filtro, aplicaba (objectClass=*).

Esos valores completaban la consulta. No eran observaciones sobre el directorio. Pedir todos los atributos no significaba que todos existieran o fueran visibles. El filtro predeterminado no verificaba identidad, actualidad ni permiso. La base nombrada podía no existir.

El ejemplo de búsqueda bajo la Universidad de Michigan mostraba dos signos de interrogación consecutivos. La posición de atributos quedaba vacía para usar su regla predeterminada, mientras sub y el filtro permanecían en sus posiciones. La ausencia estaba diseñada, no olvidada.

Por eso, registrar únicamente los campos escritos es insuficiente. Para reconstruir la operación hay que guardar también qué faltaba y qué valor introdujo el cliente. Una omisión desplaza una decisión; no la elimina.

La representación tenía dos gramáticas superpuestas. El nombre distinguido y el filtro conservaban reglas LDAP propias, y los caracteres no permitidos por una URL se codificaban según RFC 1738. La errata verificada 528 corrige la referencia de la gramática del DN: debía señalar RFC 1779, no RFC 1485.

La codificación porcentual permite transportar caracteres. No hace canónico el nombre, seguro el filtro ni verdadero el valor decodificado. Primero se abre el envoltorio URL y después se interpreta la estructura LDAP. La cadena recibida y la entrada encontrada siguen siendo hechos separados.

Sin host, la elección no estaba documentada

Una forma como ldap:///o=University%20of%20Michigan,c=US no nombra servidor. RFC 1959 decía que, si la entrada pertenecía al espacio X.500, podía consultarse cualquier servidor LDAP con acceso de fondo a X.500.

La referencia se volvía menos dependiente de una máquina, pero el recibo quedaba incompleto. La URL no mostraba qué servidor escogió el cliente, qué réplica o vista ofreció, si estaba disponible ni cuándo respondió.

“Cualquiera” no quería decir “todos” ni “el servidor con autoridad universal”. Era una ruta de resolución bajo una hipótesis concreta de X.500. Tampoco volvía intercambiables a todos los servidores LDAP autónomos.

RFC 2255 aclaró más tarde que, sin host, el cliente necesitaba conocimiento previo de un servidor adecuado. Podía abrir o reutilizar una conexión, elegir servicios de seguridad y autenticación, y fijar otros campos de SearchRequest ausentes de la URL, como límites de tamaño y tiempo o tratamiento de alias.

La aclaración posterior revela lo que el formato inicial dejó fuera. No autoriza a decir que RFC 1959 ya transportaba una política de selección, un historial de conexión, un límite o una decisión sobre alias.

La referencia no contenía una identidad

La sección de seguridad de RFC 1959 fijó un límite tajante: no había forma de indicar credenciales en la URL, por lo que se esperaba una consulta no autenticada. Resolver la URL tenía los riesgos de cualquier consulta LDAP.

No autenticado no equivale automáticamente a ilegítimo. Un directorio puede ofrecer datos públicos a una sesión anónima. Pero tampoco equivale a autorización para recibir todo lo pedido. El servidor aplica las reglas de acceso de la sesión actual.

Así debe leerse la regla de “todos los atributos”. El cliente hace una solicitud amplia; no obliga a publicar valores restringidos. RFC 4511 explicaría después que las entradas y los atributos están sujetos a control de acceso y que una entrada devuelta puede no contener ningún valor.

La misma URL tampoco convierte a dos lectores en la misma persona. Una sesión anónima, una sesión autenticada permitida y una política modificada pueden producir datos públicos, una vista más amplia o un error. La diferencia pertenece al contexto de ejecución.

El resultado era una secuencia posterior

En RFC 4511, una búsqueda devuelve cero o más entradas y referencias antes de un SearchResultDone con éxito o error. RFC 1959 no guardó esa secuencia dentro de la URL ni creó una instantánea del directorio.

Una cadena archivada puede probar qué base, alcance, filtro y atributos se pretendían usar. No prueba que el servidor evaluara los mismos datos en otro momento, que ningún límite recortara la búsqueda, que se siguieran referencias ni que llegara un resultado final correcto.

Una sola entrada tampoco demuestra totalidad. Solo muestra lo que un servidor emitió a un cliente en un punto de la secuencia. El consumidor aún debe decidir si basta, qué significa una ausencia, si sigue una referencia y qué consecuencias admite.

RFC 4516, norma actual para URL LDAPv3, advierte expresamente que el formato no puede representar todos los parámetros de SearchRequest. La dirección continúa siendo menor que la operación y menor que la decisión.

La “especificación inicial mínima” de Heng Lu ayuda a conservar esa proporción: una superficie común pequeña facilita la coordinación, pero no debe acumular poderes que no define. La primacía del código operativo exige pruebas independientes para la cadena, su interpretación, la conexión, las respuestas y la acción.

RFC 1959 consiguió que la pregunta viajara. No consiguió que la pregunta mandara.

Fuentes y límites

La identidad y el estado del documento constan en IETF Datatracker y la ficha de RFC Editor. El texto está en HTML y formato plano; la errata 528 corrige la referencia del DN. El contexto procede de RFC 1777, RFC 1558 y RFC 1738. Los límites posteriores se comprueban en RFC 2255, RFC 4511 y RFC 4516.

El marco editorial se apoya en Running-Code Primacy, Minimum Initial Specification y Reality Layers. Esos ensayos separan representación, ejecución y autoridad; no prueban un despliegue LDAP.

Las fuentes establecen los textos y sus límites declarados. No prueban la adopción actual, la conformidad de un producto, un resultado real, una filtración, una política contemporánea ni la decisión de una aplicación.