Résumé

  • La RFC 880 décrivait chaque protocole par plusieurs champs autonomes : statut, spécification, problèmes connus, références, dépendances et contact.
  • Ses exemples empêchent de confondre classification et réalité : TCP était recommandé mais encore imparfaitement documenté ; TFTP était facultatif mais utilisé ; GGP était expérimental tout en servant aux passerelles du cœur.
  • Les textes ultérieurs ont séparé maturité et niveau d'exigence, puis abandonné le résumé RFC périodique au profit d'une liste en ligne, sans faire de cette liste une mesure du code en fonctionnement.

Un catalogue complaisant aurait rangé TCP dans la bonne colonne et refermé le dossier. La RFC 880, publiée en octobre 1983 sous le titre Official Protocols, faisait l'inverse. Après le statut « Recommended », elle mentionnait les erreurs du document, les ambiguïtés de Push, la taille maximale de segment, les connexions inactives et les données en attente à la fermeture.

L'inscription officielle ne tenait donc pas lieu de certificat. Elle ouvrait une fiche où plusieurs autorités pouvaient être distinguées : le texte qui définissait, la politique qui recommandait, l'implémentation qui exécutait et l'observation qui constatait.

Un inventaire devait d'abord réconcilier ses propres livres

La RFC 880 rattachait « en première approximation » les protocoles officiels au Internet Protocol Transition Workbook de mars 1982. Puis elle expliquait pourquoi cette approximation ne suffisait pas. Des protocoles utilisés n'y figuraient pas. D'autres avaient été révisés. Le courrier, Telnet et les conseils d'implémentation vivaient dans des volumes différents ; des options anciennes restaient dans le manuel ARPANET de 1978.

La liste ne révélait pas un texte unique et éternel. Elle dressait l'état daté d'un corpus dispersé. La RFC 840, publiée six mois plus tôt avec la même architecture de champs, venait d'être remplacée. L'obsolescence indiquait la version du catalogue, non la disparition instantanée de chaque système qui l'avait consulté.

Chaque fiche séparait STATUS, SPECIFICATION, COMMENTS, OTHER REFERENCES, DEPENDENCIES et CONTACT. Le statut exprimait une attente. La spécification nommait le document. Les commentaires gardaient les défauts et les écarts. Les dépendances rappelaient les couches nécessaires. Le contact donnait une destination aux questions.

Obligatoire, recommandé, facultatif et expérimental n'étaient pas quatre médailles

La RFC 880 définissait cinq états d'usage : Required, Recommended, Elective, Experimental et None. Un protocole Required devait être implémenté par tous les hôtes. Recommended était encouragé. Elective laissait le choix. Experimental réservait l'emploi aux participants coordonnés de l'expérience. None signifiait que l'entrée n'était pas un protocole.

IP et ICMP étaient obligatoires ; UDP et TCP, recommandés ; TFTP, facultatif ; EGP et GGP, expérimentaux. Le modèle Catenet recevait None parce qu'il exposait une architecture, non un protocole à exécuter.

Ce vocabulaire distribuait des attentes, pas des certificats de qualité. « Required » ne prouvait ni l'installation, ni l'activation, ni l'interopérabilité. « Elective » ne signifiait pas rare. « Experimental » ne signifiait pas absent du réseau.

La ligne TCP conservait les dettes du texte

Les commentaires de TCP parlaient de « document bugs » plutôt que de défauts nécessairement présents dans le protocole. La nuance était importante : une mise en œuvre pouvait devoir interpréter un texte imparfait sans que la fonction visée soit abandonnée.

Push gardait une saveur trompeuse de marque de record. La valeur par défaut de MSS demandait une clarification. La description des serveurs en écoute, de la fermeture, des données reçues mais pas encore remises à l'utilisateur et des segments hors ordre avait besoin de travail. La recommandation de TCP ne supprimait aucune de ces questions.

Un système de conformité qui ne conserverait que la valeur du statut perdrait donc l'information officielle la plus utile. La fiche ne disait pas seulement « adoptez ». Elle disait aussi où l'adoption pouvait diverger.

Un protocole expérimental pouvait déjà porter du trafic central

GGP fournit l'exemple le plus net. Son statut était Experimental. Le commentaire affirmait pourtant qu'il était alors utilisé dans les passerelles du cœur. EGP portait le même statut, mais était décrit comme le protocole de passerelle en cours de développement.

Ces phrases ne mesurent ni le nombre de machines, ni leur conformité, ni leur disponibilité. Elles prouvent seulement que le statut et l'exécution n'étaient pas le même axe. Une expérience pouvait toucher une infrastructure opérationnelle ; une présence opérationnelle ne transformait pas automatiquement la spécification en norme achevée.

Le Stream Protocol montrait l'autre sens de l'écart : son implémentation avait évolué et pouvait ne plus correspondre au texte. Le code existant ne pouvait donc pas témoigner seul de sa conformité.

TFTP était Elective, tandis que la fiche signalait son usage sur plusieurs réseaux locaux. La liberté d'adopter et le fait d'avoir adopté restaient deux observations.

Telnet possédait une colonne pour l'usage réel

Le tableau des options Telnet indiquait le document RFC ou NIC, la présence dans le nouveau livret, celle dans l'ancien manuel et une colonne USE. Certaines options, comme Echo ou Suppress Go Ahead, étaient fréquemment implémentées. Beaucoup d'autres ne l'étaient pas généralement.

L'ensemble restait Elective. Pourtant, la liste ne déduisait pas de ce statut la présence de chaque option. Elle regardait séparément la documentation, la republication et l'usage. Dire qu'un produit « supportait Telnet » ne suffisait pas à prédire la négociation d'une option précise.

La colonne USE n'était pas une télémétrie universelle. Elle avait cependant une vertu : elle reconnaissait qu'une inscription documentaire ne peut produire à elle seule un fait d'exécution.

Les dépendances empêchaient l'option de flotter seule

SMTP et Telnet dépendaient de TCP ; TFTP, d'UDP ; les protocoles de passerelle, d'IP. La présence d'une application dans le catalogue ne dispensait pas d'établir la chaîne qui la rendait utilisable.

Le contact jouait un rôle comparable pour la responsabilité. Les usages expérimentaux devaient être coordonnés. Une ambiguïté avait un interlocuteur. Il ne s'agissait pas de conférer une souveraineté personnelle sur tous les réseaux, mais d'éviter qu'un label abstrait remplace le travail de maintenance.

La RFC 991 poursuivit cette lignée en 1986 et se présenta comme un rapport officiel de statut. La succession des éditions faisait de la révision une propriété du système.

La maturité et l'obligation finirent par recevoir deux axes

En 1991, la RFC 1200 distinguait explicitement l'état de normalisation — Standard, Draft Standard, Proposed Standard, Experimental, Informational, Historic — du statut d'exigence — Required, Recommended, Elective, Limited Use, Not Recommended.

La RFC 2026 développa les niveaux de maturité et l'applicabilité. La RFC 6410 réduisit ensuite la filière des normes à deux niveaux. Ces changements organisaient la décision documentaire ; ils ne comptaient pas les implémentations.

Enfin, la publication périodique elle-même devint le maillon périmé. La RFC 7100 retira le dernier résumé et STD 1, délaissés au profit de la liste en ligne du RFC Editor. Un support plus facile à mettre à jour améliorait le registre. Il ne transformait toujours pas le registre en sonde du réseau.

Sources et limites

Le dossier repose sur les RFC 840, RFC 880, RFC 991, RFC 1200, RFC 2026, RFC 6410 et RFC 7100. Ces textes établissent une histoire des listes et du processus. Ils ne prouvent ni parts de déploiement actuelles, ni conformité d'un produit nommé, ni incident, ni politique d'un opérateur.