Résumé

  • RFC 1959 encodait dans une URL l’emplacement d’un serveur LDAP, un nom distinctif, les attributs demandés, la portée et le filtre ; les champs omis activaient des valeurs par défaut pour construire la recherche.
  • L’hôte pouvait être absent et le format ne permettait pas de transmettre des identifiants. Une même chaîne pouvait donc être résolue dans des contextes de serveur, de session et de contrôle d’accès différents.
  • L’URL disait comment poser une question. Elle ne prouvait ni le serveur contacté, ni les attributs autorisés, ni l’achèvement de la réponse, ni la décision prise ensuite par une application.

Une opération d’annuaire entre dans le monde des URL

En juin 1996, LDAP était encore présenté comme un accès léger à X.500. RFC 1959 voulait permettre à des clients Internet d’accéder directement au protocole tout en prévoyant aussi des serveurs LDAP autonomes. L’innovation n’abolissait pas l’annuaire : elle donnait à une recherche une forme que les logiciels savaient déjà transmettre.

La grammaire suivait un ordre précis. Après ldap:// venaient éventuellement l’hôte et le port, puis le nom distinctif. Trois positions séparées par des points d’interrogation pouvaient indiquer les attributs, la portée et le filtre. Chacune contrôlait une partie différente de la recherche.

Le nom d’hôte situait un serveur. Le nom distinctif fixait la base. La liste d’attributs exprimait ce que le client demandait. La portée distinguait l’objet de base, un niveau ou un sous-arbre. Le filtre sélectionnait les entrées susceptibles de correspondre.

Cette dernière position ne doit pas absorber le sujet de l’article déjà consacré à RFC 1558. Celui-ci traite de la représentation lisible d’un Filter qui reste un prédicat exécutable. RFC 1959 porte sur l’enveloppe extérieure qui associe ce filtre à une base, une portée, des attributs et, parfois, un serveur.

Le vide avait une sémantique

RFC 1959 attribuait un effet déterminé à plusieurs omissions. Sans port, le client utilisait TCP 389. Sans attributs, il devait demander tous les attributs des entrées. Sans portée, il supposait une recherche sur l’objet de base. Sans filtre, il utilisait (objectClass=*).

Ces choix complétaient une instruction. Ils ne décrivaient pas l’état de l’annuaire. Le filtre par défaut ne garantissait pas l’existence d’une entrée. L’absence de liste d’attributs ne constatait pas que tous les attributs existaient ou seraient divulgués. Une base de recherche n’était pas la preuve que l’objet nommé était présent.

L’exemple du sous-arbre de l’Université du Michigan conservait une position vide avec deux points d’interrogation consécutifs. Le champ des attributs était laissé au défaut, tandis que sub et le filtre occupaient leur place. L’absence n’était donc pas une erreur de saisie ; elle déléguait une décision à la norme.

Une trace opérationnelle qui ne garde que les valeurs visibles manque cette partie de la requête. Pour comprendre ce qui a été exécuté, il faut aussi savoir quels champs étaient absents et quelles valeurs le client leur a substituées.

La chaîne comportait en outre deux niveaux de syntaxe. Le nom distinctif et le filtre suivaient leurs propres règles. Les caractères interdits dans une URL étaient ensuite codés selon RFC 1738. L’erratum vérifié 528 corrige une référence erronée : la grammaire du nom distinctif devait renvoyer à RFC 1779 et non à RFC 1485.

Le codage en pourcentage rend une représentation transportable ; il ne la rend ni canonique, ni sûre, ni vraie. Le client doit décoder l’extérieur puis analyser l’intérieur. La chaîne reçue et l’objet d’annuaire finalement visé restent deux preuves séparées.

L’absence d’hôte laissait un choix à effectuer

Dans une URL commençant par ldap:///, aucun serveur n’est nommé. RFC 1959 indiquait que, si l’entrée appartenait à l’espace de noms X.500, un client pouvait contacter n’importe quel serveur LDAP offrant un accès frontal à X.500.

Cette faculté évitait d’attacher une référence à une machine unique. Elle ne consignait pas le choix réel. La chaîne ne disait pas quel serveur avait été contacté, quelle copie il présentait, s’il était joignable ou à quel moment la recherche avait eu lieu.

« N’importe lequel » ne voulait dire ni « tous » ni « autorité universelle ». La phrase reposait sur l’hypothèse d’un espace X.500 accessible derrière plusieurs serveurs. Elle ne rendait pas tous les serveurs LDAP autonomes interchangeables.

RFC 2255, qui remplaça RFC 1959 en 1997, exposa mieux cette séparation. Sans hôte, le client devait connaître à l’avance un serveur approprié. Il pouvait ouvrir ou réutiliser une connexion, choisir les services de sécurité et l’authentification, puis régler des champs absents de l’URL, comme les limites de taille et de temps ou le traitement des alias.

Ces précisions ultérieures éclairent le partage des responsabilités. Elles ne doivent pas être attribuées rétroactivement au format de 1996. RFC 1959 ne transportait ni algorithme de sélection, ni historique de connexion, ni limites d’exécution, ni politique d’alias.

Une requête sans identifiants n’accordait aucun droit

La section de sécurité de RFC 1959 est brève et décisive : aucun emplacement ne permettait de préciser des identifiants, et les requêtes étaient donc censées ne pas être authentifiées. Le risque était celui de toute requête LDAP.

Non authentifié ne signifie pas nécessairement interdit. Un annuaire peut publier certaines informations à un client anonyme. Mais la chaîne ne donne pas pour autant droit à tout ce qu’elle demande. La politique d’accès du serveur décide quelles entrées et quelles valeurs sont visibles dans la session considérée.

La demande implicite de « tous les attributs » doit donc être lue au niveau du client. Elle élargit la sélection demandée ; elle ne contraint pas le serveur à révéler les valeurs protégées. RFC 4511 formulera plus tard explicitement que les résultats restent soumis au contrôle d’accès et que même une entrée retournée peut ne contenir aucune valeur.

Deux détenteurs de la même URL ne partagent pas automatiquement la même identité. Une session anonyme, une session authentifiée autorisée et une politique modifiée peuvent produire une vue publique, une vue restreinte ou une erreur. La différence ne vient pas nécessairement de la chaîne, mais du contexte d’exécution.

Une recherche est une séquence, pas une photographie

RFC 4511 décrit le résultat d’une recherche comme zéro ou plusieurs entrées et références, suivies d’un SearchResultDone indiquant le succès ou une erreur. RFC 1959 n’a pas placé cette séquence dans l’URL et n’a pas transformé l’adresse en instantané.

Une URL conservée peut montrer la base, la portée, le filtre et les attributs prévus. Elle ne montre pas qu’un serveur ultérieur a évalué les mêmes données, qu’aucune limite n’a interrompu le travail, que les références ont été suivies ou qu’un résultat final de succès a été reçu.

Même une entrée renvoyée n’établit pas la totalité. Elle atteste ce qu’un serveur a envoyé à un client à un point de la séquence. L’application qui consomme la réponse doit encore décider si une entrée suffit, si une absence est significative, si une référence doit être suivie et si une action est justifiée.

RFC 4516, aujourd’hui applicable à LDAPv3, rappelle d’ailleurs que tous les paramètres d’une SearchRequest ne peuvent pas être exprimés par une URL. La représentation est volontairement plus petite que l’opération et que son environnement.

La lecture proposée par Heng Lu aide à maintenir cette proportion. Une spécification initiale minimale peut rendre la coordination plus simple sans créer une autorité permanente. La primauté du code en fonctionnement exige ensuite une preuve pour chaque transition : chaîne, interprétation, connexion, messages de résultat et action.

RFC 1959 a rendu la question portable. Il n’a pas rendu sa réponse souveraine.

Sources et périmètre

L’identité et l’historique du texte sont établis par l’IETF Datatracker et la notice RFC Editor. Le texte original se trouve en HTML et en texte brut ; l’erratum 528 corrige la référence du DN. Le contexte vient de RFC 1777, RFC 1558 et RFC 1738. Les limites ultérieures sont précisées par RFC 2255, RFC 4511 et RFC 4516.

Le cadre analytique reprend Running-Code Primacy, Minimum Initial Specification et Reality Layers de Heng Lu. Ces essais ne constituent pas la preuve d’un déploiement LDAP.

Les sources établissent les textes et leurs frontières. Elles ne prouvent ni l’adoption actuelle, ni la conformité d’un produit, ni un résultat réel, ni une fuite, ni une politique d’accès contemporaine, ni la décision d’une application.