Résumé

  • La RFC 832 partait des capacités déclarées dans la table des hôtes du NIC, puis testait séparément Telnet, FTP et SMTP et distinguait absence d'acceptation, refus, inaccessibilité, silence et acceptation.
  • Les résultats négatifs étaient retestés et l'enquête recommençait la semaine suivante : l'observation gardait une date, un trajet et un point de vue au lieu de devenir une étiquette permanente.
  • Depuis un autre réseau, la RFC 844 ne retrouva que 127 des 187 hôtes Telnet précédemment acceptants. Le code en service corrigeait le registre, sans pour autant prouver une accessibilité universelle ni une conformité complète.

Le registre et le guichet

La table du NIC du 2 décembre 1982 attribuait aux hôtes des capacités : TCP en général, ou plus précisément Telnet, FTP et SMTP. Ces mentions étaient utiles. Elles indiquaient où regarder et permettaient de préparer une migration. Mais la RFC 832 les intitula sans détour Claims, des déclarations.

À côté figuraient les résultats des tentatives de connexion. Cette disposition suffit à éviter une confusion institutionnelle fréquente : l'organisme qui tient la liste ne produit pas, par l'écriture d'une ligne, le service qui tourne sur la machine. Le registre décrit ; l'exécution répond.

Le plan de transition de la RFC 801 rend l'écart encore plus net. Son annexe rassemblait des informations fournies par les sites et les constructeurs : code disponible, expérimental, en développement ou annoncé. Le document prévenait que ces renseignements vieilliraient vite. Il rappelait aussi que certains raccourcis étaient inadmissibles : ne pas vérifier les sommes de contrôle, ne pas réassembler IP, ne pas remettre les segments TCP dans l'ordre, ignorer les options ou mal signaler les erreurs.

Une connexion ouverte ne contrôlait aucun de ces points. L'enquête posait donc une question plus modeste et plus solide : depuis cette machine d'essai, pendant cette plage horaire, quel résultat produit une tentative vers ce service ?

Refuser n'était pas se taire

La taxonomie des résultats empêchait d'aplatir tous les échecs. Refused signifiait qu'une réponse avait explicitement rejeté la connexion. Unreachable indiquait un échec de route porté par le réseau. Dead désignait l'absence de réponse utile dans les conditions de l'essai. Une case vide signifiait que le service n'avait pas été accepté sans autoriser un diagnostic plus fort. Accepted constatait seulement que le seuil de connexion avait été franchi.

FTP possédait une catégorie supplémentaire, accepted+, lorsque l'accès anonyme fonctionnait avec le mot de passe guest. Cette précision éclaire la faiblesse volontaire du simple accepted : il ne prouvait ni authentification, ni transfert, ni utilité, ni correction intégrale du serveur.

Les essais du 7 décembre se répartirent sur deux longues plages. Les hôtes morts, refusants ou inaccessibles furent retestés le lendemain. La reprise réduisait le poids d'une panne momentanée ; elle n'effaçait pas le caractère local de la mesure.

Sur 315 hôtes inscrits, 83 acceptèrent Telnet, 70 FTP et 63 SMTP. Le complément n'était pas une liste de coupables. Certains systèmes avaient une fonction spécialisée, certains étaient momentanément indisponibles, d'autres n'avaient aucune raison d'exposer les trois services.

La photographie suivante remplaçait la précédente

La RFC 833 recommença le 14 décembre. Elle signala que les doublons de la table avaient été éliminés autrement que la semaine précédente, ce qui modifiait légèrement les totaux de lignes. La méthode avait donc elle aussi un historique. Sans cette note, une variation de dénominateur aurait pu être prise pour une évolution du réseau.

Douze enquêtes furent finalement résumées dans la RFC 847. Entre le 7 décembre et le 22 février, les acceptations passèrent de 83 à 190 pour Telnet, de 70 à 181 pour FTP et de 63 à 178 pour SMTP. La bascule vers TCP acquérait une matérialité visible.

Pourtant, les chiffres reculèrent certaines semaines. Telnet passa de 103 à 102, puis à 95 pendant trois observations de décembre. Un réseau vivant ne suit pas une courbe administrative. Les heures de mesure, les routes, les pannes, les versions de la table et les politiques d'ouverture modifiaient la photographie.

La RFC 846, dernière enquête de la série, nomma encore la table source du 18 février, l'observateur ISI-VAXA, la journée d'essai du 22 et la reprise du lendemain. Elle n'annonça pas une conformité achevée ; elle publia un nouveau point vérifiable.

Deux points de vue, deux propositions

La RFC 844 changea volontairement le lieu de l'expérience. La RFC 843 avait trouvé 187 hôtes acceptant Telnet depuis ISI-VAXA les 8 et 9 février. Trois jours plus tard, une console BBN située sur le réseau de classe C 192.1.2.0/24 tenta de les joindre.

Ce second trajet exigeait davantage qu'un serveur à l'écoute. Les passerelles devaient savoir renvoyer vers cette adresse, l'hôte devait traiter la classe d'adresse, et ICMP participait au diagnostic. Sur les 187 candidats, 127 furent marqués OK, soit 67,9 %.

Les soixante autres ne devinrent pas pour autant des machines « sans TCP ». La RFC 844 précise que les connexions furent saisies manuellement, que trois passages seulement eurent lieu et que des hôtes arrêtés pouvaient avoir été manqués. L'essai démontrait une dépendance au point de vue, pas une essence de la machine.

La première proposition était : ce service a accepté depuis ISI dans cette fenêtre. La seconde était : il reste joignable depuis un réseau de classe C à travers ce chemin et ces comportements de routage. Garder les deux phrases distinctes vaut mieux que choisir arbitrairement l'une comme réalité totale.

Le tableau de synthèse pouvait lui aussi se tromper

La RFC 847 rendit la série lisible en rapprochant numérateurs, populations et pourcentages. Elle estima aussi que 37 hôtes, soit 11 %, avaient des fonctions spéciales et ne devaient pas offrir les trois services. Le plafond raisonnable était donc 89 %, non 100 %. Être un hôte Internet ne signifiait pas ouvrir Telnet, FTP et SMTP.

Mais la synthèse conserve des anomalies visibles. Elle imprime 70 acceptations FTP sur 315 comme 26 %, alors que le rapport est proche de 22 %. Un total Telnet de la RFC 842 devient 382 là où les autres services indiquent 328 ; un total FTP de la RFC 843 devient 389 au lieu de la population de 329 ; la date FTP de la RFC 845 recule en 1982.

Ces erreurs ne rendent pas l'enquête inutile. Elles montrent pourquoi il faut conserver la fraction, la méthode et la source sous le pourcentage calculé. Une donnée imparfaite mais traçable peut être corrigée ; une valeur lisse sans provenance impose seulement la confiance.

Observer sans gouverner

Le mesureur choisissait les ports, le calendrier et la nomenclature des résultats. Les sites distants gardaient la maîtrise de leurs logiciels et de leur exposition. Une acceptation ne donnait aucun droit d'agir sur l'hôte. Un silence ne transférait ni propriété ni compétence réglementaire.

Le code en service avait bien priorité sur la déclaration pour répondre à une question d'exécution. Mais cette priorité restait proportionnée : un socket ouvert attestait une acceptation depuis un endroit. Il ne certifiait pas toutes les exigences TCP, l'identité de l'opérateur, la qualité du service ou l'accès depuis tout l'Internet.

La force historique de la RFC 832 tient à cette chaîne publique : déclaration, essai, résultat typé, reprise, nouvelle édition. Le registre n'était pas humilié par la mesure ; il devenait le point de départ d'une réalité contrôlable.

Sources et limites des preuves

Ces RFC documentent des plans, des déclarations datées, des tentatives de connexion et une synthèse. Elles ne prouvent ni déploiement actuel, ni conformité complète, ni identité, ni autorisation, ni succès d'une transaction. Tout résultat négatif reste lié au point de mesure, au trajet, à la méthode et au moment déclarés.