Résumé

  • CLDAP réduisait le coût de connexion pour de petites lectures d’annuaire grâce à UDP et à un ensemble d’opérations restreint, mais la fiabilité et la fraîcheur des réponses restaient à la charge des déploiements.
  • La RFC 3352 n’attribuait pas son recul à une cause unique : elle recensait des raisons probables, notamment l’absence d’intégrité et de confidentialité, puis recommandait de placer la RFC 1798 dans la catégorie Historic pendant que l’expérimentation se poursuivait.

Une économie de connexion qui avait un prix

La RFC 1798 partait d’un problème concret : pour lire quelques attributs d’une seule entrée, l’application pouvait attendre davantage les étapes de connexion et de session que la recherche elle-même. CLDAP proposait un chemin plus court pour ce cas étroit. Dérivé de LDAP, il transportait ses messages sur UDP ou un autre transport sans connexion et ne gardait qu’un sous-ensemble des opérations. Son exemple décrivait quatre paquets, ou deux dans certaines configurations locales ou avec cache. Ce sont des séquences illustratives, pas un benchmark.

Le document présentait CLDAP comme un complément à DAP et LDAP, non comme leur remplacement. Dès qu’un datagramme peut être perdu, le client doit régler temporisation et répétition des demandes. Le RFC laissait volontairement ces algorithmes aux implémentations. Le cache réduisait la latence, mais la chaîne DAP ne proposait ni protocole d’invalidation ni contrôle dontUseCopy. La rapidité impliquait donc des choix séparés sur la fiabilité et l’ancienneté acceptable des données. RFC 1798

La limite de sécurité était encore plus nette. CLDAP ne prévoyait pas d’authentification des requêtes. Une note éditoriale de la RFC 1798 rapporte que l’ajout d’identifiants a été discuté, puis écarté parce que son surcoût aurait pu annuler l’avantage du mode sans connexion. Le texte déconseille CLDAP aux applications nécessitant un accès authentifié. Ce n’était pas une propriété découverte plus tard : le compromis figurait déjà dans la spécification.

Les raisons consignées en 2003

La RFC 3352, publiée en mars 2003, revient sur la RFC 1798 de juin 1995. Elle écrit que CLDAP ne s’était pas largement déployé sur Internet pendant les sept années écoulées. Cette phrase est l’appréciation contemporaine du RFC, non un recensement chiffré, la preuve qu’aucune implémentation n’existait ou une mesure de l’usage actuel.

L’auteur énumère des raisons probables sans établir de classement causal : opérations anonymes et en lecture seule, résultats limités, absence d’intégrité et de confidentialité, internationalisation insuffisante, faible extensibilité et absence de plusieurs implémentations indépendantes. Ces limites se renforcent. Un petit résultat peut suffire, mais une interface difficile à protéger, à étendre et à interopérer est plus difficile à maintenir comme contrat commun. La RFC ne prouve ni que chaque défaut a pesé de la même manière ni qu’il a touché chaque déploiement. RFC 3352

Le statut rencontrait aussi un problème de maintenance documentaire : des références normatives pointaient vers des spécifications devenues obsolètes, notamment d’anciens textes X.500 et RFC 1487. Sans mise à jour, ces références empêchaient la RFC 1798 de rester sur la voie des normes. Le groupe LDAP Extensions, créé en 1997, achevait ses travaux sans actualiser CLDAP ; aucun effort de normalisation pour le mettre à jour ne subsistait alors.

La recommandation était donc de faire passer RFC 1798 à Historic, non de publier un successeur. La RFC 3352 reconnaît un intérêt persistant pour les annuaires sans connexion, mais juge nécessaire de poursuivre l’expérimentation, surtout sur la sécurité. Elle cite un brouillon LDAP-sur-UDP comme travail en cours, pas comme une norme de remplacement. La mise en statut Historic de LDAPv2, spécifié par RFC 1777, constitue une action distincte consignée plus tard dans RFC 3494. La RFC 3352 ne retire pas LDAP dans son ensemble.

Les textes LDAPv3 ultérieurs offrent un contexte technique différent ; ils ne prouvent pas ce que les produits CLDAP ont réellement exécuté.

Historic ne signifie pas effacé

Un statut décrit la place d’un texte dans le registre des normes. À lui seul, il ne désinstalle aucun serveur, n’annule pas un déploiement local et ne prouve pas que tous les opérateurs ont cessé d’utiliser une vieille interface. La RFC 3352 formule une recommandation et son propre jugement sur l’absence d’impact du retrait sur la sécurité d’Internet. Cette dernière phrase n’est pas la preuve que CLDAP était sûr ni qu’aucun risque local n’existait.

L’intérêt de cet épisode tient au cycle de vie. CLDAP optimisait un coût visible — établir une connexion — mais laissait ouvertes les questions de protection, de perte, de fraîcheur, de résultats et d’évolution. L’expérience rapportée n’a pas fait apparaître de voie de révision et d’implémentation indépendante capable de porter ces coûts jusqu’à une norme maintenable. La décision de statut rend cette limite lisible ; elle ne transforme pas une recommandation en adoption ni en arrêt universel.

La doctrine de Heng Lu sur la spécification initiale minimale et la primauté du code en fonctionnement sert ici de grille éditoriale déclarée, pas de constat de l’IETF. Elle invite à distinguer le texte publié, l’adoption réellement observée et les choix que peuvent continuer à faire les opérateurs. Cette lecture reste bornée : aucune donnée disponible ici n’établit le nombre d’installations, les raisons d’un produit particulier ou la date à laquelle un opérateur a migré.

Sources

Documents principaux : RFC 3352, RFC Editor, Datatracker ; protocole initial et contexte : RFC 1798, RFC Editor, RFC 1777, RFC 3377, RFC 3494, RFC 4510, RFC 4511, RFC 4513, RFC 2026. Grilles éditoriales attribuées : Heng Lu, Note 64 et Note 65.