Summary

  • RFC 2377 propuso componentes dc derivados de DNS y valores uid ya existentes para evitar otro registro mundial, pero advirtió que un UID con forma de correo podía no ser un buzón válido; la aplicación debía consultar mail.
  • El dominio del UID y la ruta del DN podían diferir, el mismo DN podía existir en servidores independientes y el DN no localizaba ni autenticaba por sí solo un servicio LDAP.

Aprovechar la coordinación ya pagada

X.500 ofrecía jerarquía y delegación, pero su costumbre de formar nombres con territorios, razones sociales y nombres comunes imponía registros difíciles y colisiones frecuentes. En 1998, RFC 2377 ofreció un plan informativo y voluntario: acme.com podía convertirse en dc=acme,dc=com; debajo, uid o cn nombrarían las hojas.

La idea era evitar una segunda burocracia global. DNS, números internos, alias y direcciones RFC 822 ya aportaban identificadores dentro de ámbitos administrados. El plan no los elevaba a identidad universal ni prometía un único directorio mundial.

La arroba no garantizaba correo

El texto recomendó en ciertos casos elegir una dirección de correo “distinguida” como UID. Era reconocible y podía ser estable. Sin embargo, describió poblaciones donde todos recibían un identificador con ese formato aunque algunos no tuvieran buzón real.

Por eso prohibió la inferencia cómoda: uid no debía tratarse como buzón; había que comprobar mail. El UID seleccionaba una entrada. mail afirmaba una ruta de contacto. SMTP aportaba pruebas posteriores de encaminamiento y entrega. La autenticación y la autorización seguían siendo decisiones distintas.

El dominio del identificador no gobernaba el árbol

RFC 2377 permitía que uid=external-mailbox-shaped-identifier viviera bajo dc=mis,dc=acme,dc=com. El árbol podía reflejar partición o control de acceso y el UID conservar un identificador externo. Así, reorganizar el directorio no obligaba a cambiar el correo.

La consecuencia era importante: no se podía reconstruir mecánicamente un DN cortando el UID tras arroba, ni deducir del DN el buzón actual. Los componentes dc debían concatenarse en un dominio registrado para evitar conflictos, pero ese registro no autenticaba el servidor LDAP, la organización representada ni las personas del subárbol.

Un nombre no señalaba un único servidor

RFC 2247 definió la conversión reversible entre un dominio y un DN compuesto solo por dc. También excluyó expresamente el mecanismo para localizar el servidor LDAP y advirtió que un servidor no fiable podía atribuirse contextos no delegados.

RFC 2377 esperaba “islas” de servidores débilmente acoplados. Las referencias enlazaban servidores dentro de una isla; una URL LDAP añadía host y puerto al DN para cruzar islas. El endpoint era una prueba adicional, no una propiedad escondida en el DN.

Con proveedores competidores, los autores no consideraban viable un único DIT. Servidores administrados por separado podían guardar objetos diferentes con el mismo DN para un objeto del mundo real. La asociación entre conjunto de atributos y sujeto la realizaba la aplicación.

Nombrar tampoco era buscar. uid podía formar el RDN y cn seguir siendo esencial para hallar y mostrar personas. La reutilización de DNS añadía además una fuga posible: nombres públicos podían revelar la forma de ramas que las ACL impedían explorar.

RFC 4519 consolidó después las definiciones de uid, dc, dcObject y uidObject. Esa precisión de esquema no convirtió un UID en buzón, credencial o persona autenticada.

Reutilizar sin ascender la evidencia

La disciplina de capas de Lu Heng separa delegación DNS, DN estructurado, cadena visible, UID, atributo mail, URL LDAP, respuesta autenticada, decisión ACL y entrega. La primacía del código exige observar qué devolvieron los sistemas reales. La especificación inicial mínima explica el acierto histórico: una convención suficiente para empezar, sin expropiar decisiones locales.