Résumé

  • Le RFC 1107 proposait trois étapes pour un annuaire de personnes destiné à Internet et au National Research Network. Il précisait que cette proposition ne constituait pas une activité de recherche engagée par la communauté.
  • Le premier travail devait comparer plusieurs services en conditions limitées avant de choisir une mise en œuvre et d’organiser le déploiement. La qualité des données, le contrôle des noms, les droits d’accès et les clients restaient à résoudre.

Un annuaire téléphonique n’est pas seulement un index. Il faut recueillir les coordonnées, les corriger, maintenir leur fraîcheur et déterminer qui peut les consulter. Le « White Pages » imaginé par le RFC 1107 devait aider à retrouver une personne et les informations permettant de la joindre : boîte aux lettres électronique, calendrier ou serveur de fichiers. Le « Yellow Pages » voisin visait, lui, la découverte de ressources par attributs. On ne cherchait donc pas simplement à ajouter les personnes au service de noms des machines.

Publié en juillet 1989 sous le titre « A Plan for Internet Directory Services », le texte de Karen Sollins rend compte d’une réunion de deux jours tenue en février, où un petit groupe représentait des intérêts universitaires, commerciaux et publics. Les participants estimaient qu’un service pouvait être obtenu en trois ans, avec des financements et un soutien solides. Mais le statut du RFC dit explicitement que la proposition est soumise aux commentaires et ne représente pas une activité de recherche déjà engagée par la communauté Internet. Le délai est un objectif de programme, pas la preuve d’un budget, d’un lancement ou d’un service livré.

Le choix technique devait rester ouvert pendant les essais. X.500 paraissait le candidat le plus probable, grâce à ses sémantiques riches et à son statut de norme internationale en devenir. Le rapport signalait aussi ses lacunes et le poids d’une hiérarchie stricte. La première étape devait donc confronter X.500 — avec Quipu, l’implémentation jugée assez avancée à ce moment-là — à Profile et à DNANS, le service de noms de DEC. Profile permettait des noms descriptifs dans une structure non hiérarchique ; DNANS avait conçu des mécanismes de contrôle d’accès, de réplication et de cache.

Une seconde implémentation X.500 aurait aidé à distinguer les défauts de la norme de ceux d’un logiciel particulier.

Pour que la comparaison ait un sens, les essais devaient partager les données. Le RFC proposait un format commun pour les informations recueillies et un même outillage de gestion ; les différentes plateformes auraient ainsi pu fonctionner côte à côte avec des entrées comparables. Les essais devaient aussi faire apparaître les questions que X.500 ne tranchait pas : collecte et mise à jour des données, distribution et réplication, accès en lecture et en écriture, intégrité, charge, interfaces clientes et transport sur plusieurs protocoles.

Une expérience pouvait comparer des comportements dans ces conditions ; elle ne prouvait pas que les organisations adopteraient les règles proposées.

Les hypothèses d’échelle donnaient du relief à ces choix. Le RFC estimait à dix millions le nombre d’utilisateurs des sciences et de la recherche. À dix recherches par personne et par semaine, il calculait 10^8 recherches hebdomadaires, environ 170 par seconde en moyenne, avec des pointes bien supérieures, et demandait une capacité minimale de 10^7 entrées. Ce sont des projections de conception, non des mesures d’un service en exploitation. Le rapport jugeait qu’une architecture distribuée serait nécessaire pour absorber les pointes et la croissance.

Il avertissait aussi que le coût d’une recherche ne devait pas croître avec la taille totale du système. Cache, répartition des serveurs et fréquence des mises à jour influenceraient les performances ; des coordonnées obsolètes auraient rendu l’annuaire inutile même si le logiciel répondait correctement.

Le calendrier associait environ un an aux essais, deux ans à l’implémentation et trois au déploiement à grande échelle. Pourtant, les étapes devaient démarrer dès que possible et avancer en parallèle. La deuxième aurait pu retenir un service ou combiner des fonctions observées pendant les essais, puis produire des serveurs fiables et plusieurs interfaces humaines ou programmatiques. La troisième restait la moins détaillée : la réunion n’en avait pas défini le plan.

Il fallait encore collecter les informations, installer les serveurs, distribuer et expliquer les clients, gérer le service et déléguer l’autorité sur les branches du répertoire et leur contenu.

C’est ici que l’annuaire devient une question d’organisation. Qui décide qu’une branche appartient à telle institution ? Qui peut modifier une fiche ou consulter des données de personnel ? Le RFC reconnaît que des organisations pouvaient refuser de céder le contrôle de leur espace de noms et que des personnes ou employeurs pouvaient limiter l’accès aux informations. Pourtant, la valeur de l’annuaire dépendait de la possibilité de retrouver des interlocuteurs au-delà d’une seule organisation. Le plan devait rapprocher interopérabilité et autonomie locale sans prétendre qu’un protocole résoudrait cette tension.

Le RFC 1107 fixe un programme de réflexion sérieux, pas le constat d’une réalisation. Son apport est de rendre la décision séquentielle et vérifiable : expérimenter, évaluer, puis bâtir le service. Le délai de trois ans ne devenait crédible qu’avec des données fiables, une autorité acceptée et des responsabilités de déploiement. Le texte laisse précisément ouverte la preuve que ces conditions aient été réunies.

Sources