Résumé

  • RFC 1292 est FYI 11, un mémorandum informationnel de janvier 1992. Il inventorie des descriptions de disponibilité et de capacité d'implémentations X.500 ; il ne définit pas une norme Internet et ne certifie pas les logiciels listés.
  • Une entrée par mot-clé rendait visible ce que l'auteur d'une description affirmait. Elle ne démontrait ni une installation, ni une configuration compatible, ni une connexion durable à un pilote, ni la valeur du logiciel pour une organisation donnée.

La question à laquelle répond RFC 1292 n'est pas « quel logiciel X.500 marche ? ». Elle est plus antérieure et plus prudente : « quelles options les participants à une communauté disent-ils offrir, et comment peut-on commencer à les distinguer ? » À une époque où les annuaires X.500 mêlaient logiciels commerciaux, distributions ouvertes, agents de système d'annuaire, agents utilisateurs, clients légers, transports OSI et TCP/IP, cette première question avait une réelle importance. Le manque d'information pouvait empêcher une comparaison avant même que l'on ait identifié les conditions d'un essai.

Le groupe Directory Information Services Infrastructure, ou DISI, a donc produit un catalogue. Le texte explique que l'objectif est de fournir de l'information sur la disponibilité et les capacités d'implémentations X.500. Il veut abaisser une barrière d'information, non l'abolir. Toute la différence tient dans ce verbe. Abaisser une barrière, c'est rendre une enquête possible. Ce n'est pas transporter automatiquement le lecteur de l'autre côté de l'enquête, vers l'installation, la validation ou l'exploitation.

Qui parle dans une ligne de catalogue ?

RFC 1292 répond explicitement à cette question. Les descriptions des implémentations ont été écrites par des implémenteurs et des fournisseurs, non par les membres de DISI. Le groupe a travaillé avec les auteurs pour améliorer la lisibilité, mais n'offre aucune garantie sur la validité des descriptions ni sur la valeur des implémentations. La formule caveat emptor place une frontière nette entre l'édition d'un texte et l'attestation d'un produit.

Cette provenance interdit une compression commode. Une description d'éditeur est un énoncé sur un logiciel. L'entrée que DISI lui associe est une décision de classement. Un test indépendant est une observation d'une version, d'une configuration, d'un pair et d'un moment. Une décision d'adoption est un jugement d'une organisation qui porte aussi sur ses compétences, ses contraintes, ses coûts et ses responsabilités. Quatre objets peuvent se ressembler dans une présentation commerciale ; ils ne possèdent pas la même source, la même portée ni le même responsable.

Le catalogue est donc précieux précisément parce qu'il ne prétend pas être les trois derniers objets. Il conserve ce que des auteurs déclaraient et les catégories à l'aide desquelles une communauté pouvait lire ces déclarations. Il ne donne pas le journal d'une association entre deux agents, la liste des attributs effectivement échangés, la politique d'accès d'un pilote ou le résultat d'une requête d'utilisateur.

X.500 rendait cette retenue particulièrement nécessaire. Une DSA n'était pas simplement une « application d'annuaire » : elle pouvait porter ou servir une part de l'arbre d'information. Une DUA était une autre pièce, tournée vers la demande d'annuaire. Un client DUA léger pouvait parler, avec un protocole applicatif non OSI, à une DUA qui communiquerait ensuite avec une DSA. Dire qu'une offre comprend une DSA, une DUA ou un client ne dit pas que les trois sont présents, qu'ils sont configurés ensemble ou qu'une chaîne entière aboutit à une réponse utilisable.

Un mot-clé classait une affirmation explicite

La méthode d'indexation de RFC 1292 est plus étroite que le raccourci moderne « le produit supporte X.500 ». Les mots-clés sont des attributs abrégés dérivés des descriptions. Une implémentation est indexée lorsqu'une capacité est mentionnée explicitement, et non implicitement, dans le texte, ou lorsque l'auteur de la description fournit lui-même l'information. Ce choix protège le catalogue contre une partie des extrapolations éditoriales : un voisinage technique n'est pas transformé en fonctionnalité déclarée.

Mais l'explicite ne devient pas, par ce seul fait, l'exécuté. Un mot-clé dit qu'un texte a porté une affirmation suffisamment précise pour être classée. Il ne fait pas lancer le programme, ne choisit pas les options, ne construit pas les schémas, ne vérifie pas les autorisations et ne confronte pas deux implémentations. La discipline du catalogue porte sur la représentation d'une description, non sur le comportement du logiciel au moment où un lecteur s'en sert.

Les catégories de disponibilité le montrent bien. RFC 1292 distingue disponible via FTAM, disponible via FTP, disponible commercialement, gratuit, source, et Potentially Unavailable. Une source disponible peut encore coûter davantage ou ne pas se compiler dans l'environnement du lecteur. Une offre gratuite peut conserver d'autres restrictions. Une offre commerciale peut être achetable sans être appropriée, maintenue ou intégrable. Le mot-clé ne manque pas son objet : il décrit une modalité de disponibilité déclarée. L'erreur apparaît lorsqu'on lui attribue l'objet d'un contrat, d'un test de portabilité ou d'une décision technique.

Le libellé Potentially Unavailable est le plus instructif. Il signifie que l'implémentation n'était pas disponible au moment où le document a été écrit. Le catalogue admet donc qu'il capture une condition temporelle. Cela ne suffit pas pour dire ce qu'était devenue l'offre le mois suivant, ni pour conclure qu'une adresse ou une distribution reste accessible aujourd'hui. Une entrée historique peut être exacte comme trace d'un état rapporté et insuffisante comme guide d'action ultérieure. Il faut vérifier l'état correspondant à la question réellement posée.

Le transport annoncé ne réalise pas l'association

Le catalogue classe aussi des environnements d'interconnexion : CLNP, transport OSI, RFC 1006 et X.25. Une entrée RFC 1006 signifie, dans cette taxonomie, que la description indique l'usage d'un service de transport TCP/IP ; une entrée CLNP désigne le protocole réseau OSI annoncé. Ce sont de bons indices pour préparer une comparaison. Ils ne sont pas le récit d'une association réussie entre deux annuaires.

Pour qu'une opération d'annuaire fonctionne, bien d'autres conditions peuvent intervenir : profils actifs, versions, représentations de noms, schémas, classes d'objets, routes, résolution, accès, confiance entre pairs et comportement devant les références ou les erreurs. Le catalogue ne les élimine pas ; il ne les instruit pas. Le lecteur qui voit une même étiquette de transport sur deux lignes n'a établi qu'un point de départ pour une hypothèse de compatibilité.

Cette différence entre ingrédient et résultat est un garde-fou historiographique. Il serait tentant d'écrire qu'une offre indexée sous RFC 1006 « reliait X.500 à TCP/IP ». Le document permet d'écrire plus exactement qu'un auteur décrivait l'offre avec cette caractéristique et que le catalogue l'a classée ainsi. Une connexion suppose des hôtes, des versions, une configuration, une politique et un moment. Elle laisse des traces différentes d'une ligne d'index.

La connexion à un pilote avait un sens et une direction

Les définitions de connectivité aux pilotes sont particulièrement précises. La connectivité DUA signifie que la DUA peut être reliée au pilote et que des informations concernant une entrée du pilote peuvent être consultées ; la DUA peut afficher des attributs et classes d'objets standard, ainsi que ceux des schémas COSINE et Internet. La connectivité DSA signifie que la DSA est reliée à l'arbre d'information et que les informations qu'elle contient sont accessibles depuis toute DUA du pilote.

Ces deux catégories ne disent donc pas simplement « connecté au pilote ». Elles distinguent le côté qui demande et affiche de celui qui porte une information rendue accessible. Cette direction est essentielle : un client pouvant consulter une entrée n'est pas un serveur qui fournit la même partie de l'arbre ; une DSA annoncée accessible n'est pas l'observation de toute requête, depuis tout chemin et à toute date.

Même dans le cadre de la définition, il faut préserver l'origine du renseignement et le temps du catalogue. L'entrée exprime le type de connectivité associé à une implémentation. Elle ne nomme pas une DSA distante particulière, n'établit pas que la route reste ouverte, ne démontre pas que les attributs sont actuels, ni que toutes les DUA interprètent de la même manière un schéma donné. Elle ne prouve surtout pas qu'un utilisateur a reçu une information juste et utile. Entre la capacité d'afficher un attribut et l'utilisation responsable de cet attribut demeure une longue chaîne de conditions.

Le refus de recommander délimitait une responsabilité

La section de portée annonce que RFC 1292 ne fournit pas d'instructions pour installer, exécuter ou administrer les implémentations. Elle n'émet pas de recommandations, car les besoins et les environnements informatiques des organisations diffèrent considérablement. Cette absence n'est pas une lacune accidentelle. Elle dessine le bord de l'autorité de DISI.

Recommander ne consiste pas seulement à comparer des cases. Il faut retenir des critères, leur donner un poids, accepter les conséquences d'un choix et parfois rendre compte d'une dépendance durable. Une organisation peut considérer décisifs la compétence disponible, une liaison existante, le schéma local, les obligations de sécurité, la licence, le support, le coût de migration ou l'effet sur ses utilisateurs. Un catalogue peut fournir des mots pour explorer ces questions. Il ne peut pas choisir leurs poids sans devenir partie à la décision.

Un index bien présenté produit toutefois une illusion de rang. Les options semblent placées côte à côte, comme si leur visibilité les rendait comparables selon une même mesure. L'absence d'une ligne peut paraître une évaluation négative, alors qu'elle peut seulement révéler l'absence de soumission. La bonne lecture conserve les verbes de RFC 1292 : le document décrit et classe ; il n'installe pas, ne gère pas, ne recommande pas et ne garantit pas.

La fraîcheur dépendait d'une chaîne de maintenance

Les éditeurs invitent à envoyer commentaires, critiques, nouvelles descriptions et descriptions mises à jour. DISI produirait de nouvelles versions après réception d'un nombre de changements jugé suffisant par le président de DISI. Cette règle subjective rend visible ce que les catalogues dissimulent souvent : le monde ne met pas à jour une liste en changeant ; des personnes doivent remarquer un changement, le signaler, l'évaluer, préparer une nouvelle édition et la diffuser.

Entre deux éditions, une capacité peut avoir changé, une offre peut avoir disparu, une distribution peut être devenue indisponible ou un nouveau concurrent peut manquer. L'ancien document ne devient pas pour autant mensonger. Il reste une trace de ce qui a été déclaré et publié selon une procédure à un moment donné. En revanche, il cesse d'être une base suffisante pour une décision qui porte sur un autre moment. La différence entre validité historique et fraîcheur opérationnelle doit rester explicite.

Cette maintenance possède aussi une dimension de gouvernance. Les auteurs contrôlent les renseignements qu'ils soumettent. Les éditeurs contrôlent la forme, le classement et le rythme de publication. Les opérateurs de pilote contrôlent leur accès et leurs politiques. Les organisations contrôlent leurs installations et leurs décisions. Une édition de catalogue coordonne ces voix sans les absorber dans une même autorité.

Le mémorandum n'atteste pas la sécurité ni l'issue

RFC 1292 parle de disponibilité et de capacité, non d'une assurance de sécurité. Il n'établit pas les propriétés d'authentification, de confidentialité, d'intégrité ou de vulnérabilité d'une implémentation. Il ne dit pas qu'une connexion à un pilote est autorisée, qu'une entrée d'annuaire est exacte, qu'un fournisseur honore un support ou qu'une organisation tire un bénéfice de son choix.

La portée historique devient plus nette lorsqu'on résiste à ces prolongements. Le mémorandum montre qu'une communauté de 1992 cherchait à rendre visibles des options X.500 et à leur donner un vocabulaire comparatif. Il ne transforme pas ce vocabulaire en certification, en recensement de déploiement ni en conseil actuel. Le catalogue est une forme d'infrastructure informationnelle ; il n'est pas lui-même le service d'annuaire dont il décrit les candidats.

Source et limites de preuve

Cet article s'appuie sur RFC 1292 — A Catalog of Available X.500 Implementations. La source étaye son statut FYI/informationnel de janvier 1992, le but du catalogue DISI, les distinctions DSA/DUA/client, la sollicitation par listes, la provenance implémenteur/fournisseur, l'absence de garantie, le classement par affirmation explicite, les catégories de disponibilité, transport et pilote, l'absence d'instructions ou de recommandation, et le seuil subjectif de révision. Elle n'établit pas une installation, une disponibilité ultérieure, un support actuel, une licence, une compilation, un hôte joignable, une connexion de pilote, une interopérabilité, une sécurité, une adéquation, une recommandation, une consultation aboutie ou un résultat organisationnel.