Summary

  • La RFC 2377 proposait des composants dc issus du DNS et des valeurs uid déjà connues afin d’éviter un nouveau registre mondial, mais elle interdisait de présumer qu’un UID ressemblant à une adresse était une boîte valide : il fallait consulter l’attribut mail.
  • Le domaine du UID et le chemin du DN pouvaient diverger, un même DN pouvait exister sur des serveurs indépendants, et le DN ne localisait ni n’authentifiait un service LDAP.

Réutiliser un registre au lieu d’en bâtir un autre

Le modèle X.500 offrait une hiérarchie distribuée, mais son nommage classique ajoutait une lourde étape administrative. Les raisons sociales étaient longues, les autorités d’enregistrement inégales et les noms communs entraient vite en collision. La RFC 2377, publiée en 1998 comme document informatif, proposa un chemin volontaire : transformer acme.com en dc=acme,dc=com, puis employer uid ou cn pour les feuilles.

Le gain venait du périmètre déjà coordonné par DNS et par les répertoires internes d’identifiants. Un opérateur n’avait plus à obtenir un deuxième nom mondial avant d’ouvrir son annuaire. Mais le texte ne promettait ni un DIT unique ni une identité universelle.

L’arobase ne fournissait pas une preuve de livraison

Pour une personne, le mémo recommandait parfois une adresse RFC 822 « distinguée » comme UID. La valeur était reconnaissable et souvent unique dans l’organisation. Pourtant certains employés pouvaient recevoir ce format d’identifiant sans posséder de boîte fonctionnelle.

La RFC en tirait une règle explicite : une application ne devait pas traiter uid comme une adresse de courrier ; elle devait vérifier mail. Le UID sélectionnait une entrée dans un contexte. mail affirmait une route de contact. SMTP produisait ensuite ses propres traces de routage et de livraison. L’authentification et l’autorisation appartenaient encore à d’autres couches.

Deux domaines pouvaient se séparer

Le domaine figurant après arobase ne commandait pas nécessairement les composants dc. uid=external-mailbox-shaped-identifier pouvait résider sous dc=mis,dc=acme,dc=com. Le chemin de l’annuaire pouvait organiser les droits ou le partitionnement, tandis que le UID conservait un identifiant externe.

Cette liberté évitait qu’une restructuration du DIT impose un changement d’adresse. Elle rendait cependant fausse toute reconstruction automatique du DN à partir du UID. Les composants dc devaient former un nom DNS enregistré afin d’éviter les collisions du plan, mais cet enregistrement ne prouvait ni le serveur LDAP, ni l’organisation décrite, ni les personnes placées dessous.

Le DN n’était pas un point de terminaison

La RFC 2247 définissait le passage réversible d’un domaine à un DN composé uniquement de dc. Elle excluait la découverte du serveur LDAP et signalait qu’un serveur non fiable pouvait revendiquer des contextes non délégués.

La RFC 2377 imaginait donc des « îles » de serveurs faiblement couplées. Les referrals reliaient une île ; une URL LDAP ajoutait hôte et port au DN pour franchir les îles. Le DN seul ne choisissait pas le serveur. Des opérateurs indépendants pouvaient même conserver des objets différents portant le même DN pour un même objet réel.

Le nom, la recherche et l’affichage restaient également séparés. uid pouvait nommer l’entrée tandis que cn servait à la retrouver et à la présenter. La reprise de DNS créait aussi une fuite possible : une branche masquée par les contrôles d’accès pouvait être devinée grâce aux noms publics.

La RFC 4519 a ensuite rendu définitives les définitions de uid, dc, dcObject et uidObject. Elle a consolidé le schéma, sans transformer un identifiant conforme en boîte, personne authentifiée ou décision autorisée.

Une coordination sans promotion sémantique

La lecture par couches de Lu Heng maintient la bonne échelle : délégation DNS, DN structuré, chaîne affichée, UID, attribut mail, URL LDAP, réponse authentifiée, décision ACL et message livré sont des reçus distincts. La priorité au code en fonctionnement exige d’observer les systèmes effectivement interrogés. La spécification initiale minimale explique le mérite du plan : ouvrir une convention commune sans supprimer les choix locaux.