Résumé

  • Un serveur WHOIS++ pouvait rendre des fiches ou indiquer d’autres serveurs à interroger ; le client choisissait de poursuivre ou non.
  • Le maillage acceptait plusieurs hiérarchies et des raccourcis, donc le client devait mémoriser les serveurs déjà visités pour supprimer les boucles.
  • Plus de parcours pouvait améliorer le rappel, mais aussi faire croître de façon exponentielle les ressources, le temps et parfois la facture.

La référence promettait une piste

Le RFC 1914 partait d’un échange modeste : ouvrir une connexion, envoyer une requête, lire la réponse, fermer. Pourtant, la réponse ne clôturait pas forcément la recherche. Un bloc SERVER-TO-ASK pouvait désigner un nouvel hôte et un port. Le serveur consulté affirmait ainsi qu’une autre destination méritait une question ; il n’affirmait ni qu’elle répondrait, ni qu’elle possédait la fiche, ni que son contenu serait exact.

Cette distinction distribuait l’autorité. Le serveur d’index contrôlait la recommandation. Le serveur de base contrôlait ses propres données. Le client contrôlait le passage de l’une à l’autre. L’utilisateur ne recevait un ensemble final qu’après cette série de décisions locales.

Le premier serveur devait être configuré aussi près que possible. Cette proximité constituait une politique de départ, pas une frontière géographique des données. Le document donne précisément le cas d’un serveur américain ayant indexé des fiches suédoises. Pour limiter une recherche aux États-Unis, il fallait écrire la contrainte de pays dans la requête. La localisation du guichet ne remplaçait pas le champ de recherche.

Le maillage n’était pas un arbre

Un dessin hiérarchique aurait permis de croire que chaque branche n’avait qu’un parent. WHOIS++ autorisait au contraire un serveur à participer à plusieurs hiérarchies, et des relations locales pouvaient raccourcir le chemin. La structure était un graphe. Elle pouvait donc contenir des cycles.

La suppression des boucles fut confiée entièrement au client. Avant de suivre une référence, celui-ci devait vérifier si la machine avait déjà été interrogée. L’algorithme du RFC séparait les serveurs connus au départ, ceux qui restaient à consulter, ceux qui avaient déjà été visités et les réponses accumulées.

Ces ensembles n’étaient pas de simples variables d’implémentation. Ils formaient la preuve d’une recherche. Si la liste finale est conservée sans la liste des serveurs visités, il devient impossible de distinguer une branche réellement épuisée d’une branche supprimée comme doublon. Si l’on garde l’hôte mais pas la référence qui l’a proposé, on perd l’auteur du choix de route.

Étendre la recherche, étendre le coût

Un résultat vide pouvait déclencher une expansion. Le client demandait les relations polled-by et polled-for, découvrait des index plus larges, puis répétait la requête d’origine. Le maillage révélait ainsi sa propre topologie à mesure que l’on cherchait.

Le RFC 1914 avertissait cependant qu’une expansion aveugle pouvait faire croître exponentiellement la consommation de ressources. Certaines parties du maillage envisageaient une tarification des réponses : la même décision pouvait donc accroître une facture réelle. L’automatisation totale n’était pas recommandée. Un client évolué devait pouvoir exclure un serveur trop coûteux, et l’utilisateur devait pouvoir interrompre une transaction trop longue.

Le compromis devenait visible. Une recherche rapide pouvait abandonner des réponses. Une recherche plus exhaustive pouvait accumuler retards, octets et paiements. Dire qu’un client était « complet » sans annoncer sa profondeur, ses exclusions, son budget et son délai revenait à masquer la décision essentielle.

Un répertoire des serveurs gardait encore un point de départ

Une seconde méthode de navigation utilisait le Directory of Servers. Ce serveur WHOIS++ particulier publiait des fiches de navigation : un handle stable, un nom d’hôte courant, un port et des descriptions. Mais son propre nom d’hôte et son port devaient être préconfigurés. La solution de découverte ne supprimait donc pas toute configuration initiale.

Le document préférait alors présenter les choix à la personne plutôt que laisser le logiciel sélectionner automatiquement l’entrée. Cette prudence reconnaissait qu’un meilleur point de départ dépendait de l’intention de la requête, de la proximité et du coût, pas seulement d’un classement global.

Le handle servait aussi quand une référence vieillissait. Le nom d’hôte transmis par un index pouvait dater de plusieurs semaines. Après un échec de connexion, le client consultait le répertoire au moyen du handle pour obtenir le dernier nom connu. Cette continuité était utile, mais elle ne transformait pas une information « dernière connue » en preuve de disponibilité présente.

Le centroïde ne contenait pas la fiche

Le RFC 1913 décrivait le résumé qui rendait ces références possibles. Un centroïde énumérait les modèles, les attributs et chaque mot observé au moins une fois dans les fiches d’un serveur. Un index pouvait vérifier ce vocabulaire compact et orienter une requête sans recopier toute la base.

Mais un mot présent dans le centroïde ne prouvait pas quelle fiche le contenait. Il ne prouvait pas que deux termes se trouvaient dans la même fiche, que la donnée était récente ou que le champ disait vrai. Le centroïde autorisait une piste, puis le serveur de base devait encore répondre.

La chaîne de preuve devait donc préserver la version du centroïde, l’index qui l’avait reçu, la référence produite, la connexion réellement tentée et la fiche effectivement rendue. Fusionner ces étapes faisait passer une possibilité de correspondance pour un résultat.

Refuser une machine ne validait pas les autres

Le RFC conseillait une liste noire parce qu’un faux serveur WHOIS++ pouvait apparaître. Le client acquérait un pouvoir de refus. Mais l’absence d’un serveur dans la liste noire ne l’authentifiait pas. Entre « interdit » et « digne de confiance » restait une vaste zone inconnue.

La sécurité demeurait donc composée. Un index affirmait le chemin. Le répertoire affirmait un dernier point de contact. DNS produisait une adresse. Le réseau permettait ou non la connexion. Le serveur distant fournissait ses propres preuves. Enfin, la politique locale décidait si la réponse entrait dans l’ensemble présenté.

CIP conserva le choix du client

Trois ans plus tard, le RFC 2651 généralisa l’idée avec le Common Indexing Protocol. Il admit que le « travail difficile » semblait repoussé vers le client, puis défendit ce transfert : contrôler le parcours, c’était aussi contrôler la taille du résultat, la vitesse et la profondeur. L’architecture refusait encore une racine unique pour des raisons d’échelle.

Ce prolongement ne prouve pas un déploiement universel de WHOIS++. Le RFC 2968, consacré aux scénarios TISDAG, était lui-même informatif et discutait des maillages de services. Ces textes montrent seulement que la question de coordination survécut : éviter une base centrale n’évitait ni les accords sur les index, ni les traductions de requêtes, ni la sélection d’un point d’entrée.

Le RFC 1914 est aujourd’hui Historic et le groupe WNILS est clos. Ce sont des états administratifs vérifiables, non une mesure d’usage ni une date d’extinction. L’histoire défendable est celle d’un contrat qui rendait le coût de découverte explicite.

L’absence avait besoin de son itinéraire

Pour soutenir « aucune fiche trouvée », il faudrait garder la requête exacte, les contraintes explicites, le serveur initial, les références, la version des index, les handles, les résolutions DNS, les âges de cache, les échecs, les doublons reconnus, les exclusions, le prix, la durée et la décision d’arrêt.

Sans ce journal, le vide final peut signifier plusieurs choses : aucune fiche locale, aucun mot dans le centroïde, une référence périmée, un hôte inaccessible, une branche chère refusée, une boucle déjà parcourue ou une interruption humaine. Le maillage distribuait les données ; il ne supprimait pas la responsabilité de qualifier l’absence.

Sources