Resumen

  • CLDAP redujo el coste de conexión para consultas pequeñas de directorio al usar UDP y un conjunto limitado de operaciones, pero trasladó la fiabilidad y la vigencia de las respuestas a las decisiones de cada despliegue.
  • La RFC 3352 no atribuyó el desenlace a una sola causa: enumeró límites probables —en particular, la ausencia de integridad y confidencialidad— y recomendó llevar la RFC 1798 a Historic mientras continuaba la experimentación.

Una consulta más corta, una promesa más estrecha

La RFC 1798 partía de una pregunta práctica: ¿por qué establecer una conexión y una sesión completas para leer unos pocos atributos de una sola entrada? Su propuesta, CLDAP, reutilizaba estructuras de LDAP, pero transportaba los mensajes mediante UDP u otro transporte sin conexión y restringía las operaciones disponibles. La especificación ilustraba una consulta en cuatro paquetes, o en dos bajo ciertas condiciones locales o con caché. Era un ejemplo de secuencia, no un resultado de pruebas comparativas.

CLDAP se presentaba como complemento de DAP y LDAP, no como sustituto general. Sin conexión, un datagrama podía perderse; el cliente tenía que decidir sus propios tiempos de espera y reintentos. La RFC no impuso un único algoritmo. El servidor podía guardar resultados para responder más rápido, pero la ruta DAP carecía de un protocolo de invalidación de caché y del control dontUseCopy. Así, la rapidez trasladaba decisiones sobre fiabilidad y antigüedad aceptable de los datos a las implementaciones. RFC 1798

La frontera de seguridad era más tajante. CLDAP no incluía autenticación de solicitudes. Una nota editorial registra el debate sobre añadir credenciales y explica por qué se descartaron: su coste podía anular la ventaja del diseño sin conexión. La RFC concluye que las aplicaciones que necesitan acceso autenticado al directorio no deben usar CLDAP. El compromiso no fue una sorpresa descubierta años más tarde; ya estaba escrito en la especificación inicial.

Las razones que quedaron en el registro

La RFC 3352, publicada en marzo de 2003, revisó la RFC 1798, de junio de 1995. Afirmó que CLDAP no se había desplegado ampliamente en Internet durante esos siete años. Esa es la evaluación contemporánea del autor, no un censo de instalaciones, una prueba de que no existiera ninguna implementación ni una medición del uso actual.

El documento enumeró razones probables, no una jerarquía causal demostrada: acceso anónimo y de solo lectura, resultados pequeños, ausencia de integridad y confidencialidad, internacionalización inadecuada, poca extensibilidad y falta de varias implementaciones desarrolladas de forma independiente. Los límites se combinaban. Una consulta pequeña podía resultar útil, pero una interfaz difícil de proteger, extender y hacer interoperable tenía menos posibilidades de convertirse en un contrato compartido sostenible. La RFC no demuestra cuánto pesó cada defecto ni que todos afectaran a cada despliegue. RFC 3352

También había un problema de mantenimiento documental. La RFC 3352 señalaba referencias normativas a especificaciones obsoletas, entre ellas documentos antiguos de X.500 y la RFC 1487. Sin una actualización, esas referencias impedían que la RFC 1798 siguiera en Standards Track. El grupo de trabajo LDAP Extensions, creado en 1997, estaba concluyendo sin actualizar CLDAP y ya no quedaba un esfuerzo de normalización para hacerlo.

La recomendación fue mover la RFC 1798 a Historic, no publicar un protocolo sucesor. La RFC 3352 reconoce que seguía existiendo interés en el acceso a directorios sin conexión, pero considera necesaria más experimentación, especialmente en seguridad. Menciona un borrador de LDAP sobre UDP como trabajo en curso, no como estándar de reemplazo. La retirada de LDAPv2, especificado en la RFC 1777, fue una acción distinta que quedó registrada en la RFC 3494. La RFC 3352 no retiró LDAP en su conjunto. Los documentos posteriores de LDAPv3 ofrecen otro contexto técnico, pero no prueban qué ejecutaban los productos CLDAP.

Historic no significa desinstalado

El estado Historic describe cómo debe leerse una especificación en el registro de estándares. Por sí solo no desinstala un servidor, no invalida una instalación local ni demuestra que todos los operadores dejaran de usar la interfaz. La RFC 3352 formula una recomendación y afirma que retirar CLDAP no afectaría a la seguridad de Internet. Esa última frase es la valoración del autor, no una prueba de que CLDAP fuera seguro o de que ningún despliegue implicara riesgos.

El episodio es, por tanto, una historia de ciclo de vida, no solo de obsolescencia. CLDAP optimizó un coste visible —abrir una conexión— y dejó sin resolver la protección, la pérdida de paquetes, la vigencia de los datos, el tamaño de respuesta y la evolución. La evaluación documentada no encontró una vía viable para revisar el protocolo y sostenerlo con implementaciones independientes. El cambio de estado hizo visible ese límite; no convirtió una recomendación en adopción ni en una orden universal de apagado.

La doctrina de Heng Lu sobre especificación inicial mínima y primacía del código en funcionamiento se utiliza aquí como lente editorial declarada, no como conclusión del IETF. Ayuda a separar lo que RFC 1798 especificó, lo que RFC 3352 consideró que la comunidad había aprendido y lo que un operador concreto pudo seguir ejecutando. No hay en este expediente datos sobre el número de instalaciones, productos particulares ni fechas de migración.

Fuentes

Registro principal: RFC 3352, RFC Editor y Datatracker; protocolo original y contexto: RFC 1798, RFC Editor, RFC 1777, RFC 3377, RFC 3494, RFC 4510, RFC 4511, RFC 4513, RFC 2026. Lentes editoriales atribuidas: Heng Lu, Note 64 y Note 65.