Résumé

  • Le principe initial répondait à l'imperfection des spécifications : émettre une forme soignée et accepter un défaut technique si le sens restait clair.
  • Une tolérance silencieuse supprimait le signal de correction. L'écart déployé devenait une règle que toute nouvelle implémentation devait copier.
  • La réponse moderne conserve la résilience, mais exige des erreurs définies, une maintenance active et des épreuves permanentes d'extensibilité.

L'ambiguïté précédait la maxime

RFC 760 reconnaissait qu'un texte explicite pouvait recevoir plusieurs interprétations. Dans un Internet encore construit par des équipes différentes, refuser tout datagramme techniquement imparfait aurait bloqué l'expérience avant que le texte et le code convergent. Le récepteur pouvait sauver l'échange quand l'intention demeurait certaine.

RFC 793 condensa ce compromis pour TCP : agir avec prudence, accepter avec libéralité. La formule perdit peu à peu son contexte de démarrage et prit l'allure d'une loi morale intemporelle.

Survivre n'est pas inventer un sens

RFC 1122 étendit le principe aux couches de l'hôte, tout en distinguant des obligations différentes. Un logiciel doit survivre aux entrées hostiles ou improbables. Une énumération doit tolérer un futur code inconnu. Un émetteur évite les options légales mais obscures qui réveillent les défauts d'un pair. Les erreurs doivent rester observables.

Ces protections ne donnent pas au récepteur le droit de deviner. Deux parseurs indulgents peuvent attribuer deux sens à la même forme fautive. Ils semblent interopérer jusqu'au moment où leur état diverge. RFC 1958 conserva la tolérance comme principe architectural, mais la charge de l'ambiguïté restait chez celui qui recevait.

Le bogue toléré gagna des clients

Sans rejet ni journal visible, l'émetteur n'a aucune raison de changer. D'autres récepteurs ajoutent l'exception, car interrompre un trafic existant ressemble à leur propre défaillance. L'écart entre dans les tests, les contrats et l'exploitation.

Le parc installé devient alors la véritable suite de conformité. Une nouvelle implémentation doit reproduire le bogue pour entrer dans l'écosystème. Le contrôle est inversé : l'émetteur produit l'écart, mais chaque pair futur finance sa réparation.

BGP nomma les conséquences

RFC 7606 montre une autre forme de robustesse. Pour des attributs BGP malformés, il définit précisément le retrait des routes concernées, l'abandon d'un attribut ou, dans les cas plus graves, l'action sur la session. Il exige aussi des moyens de diagnostic conservant l'UPDATE fautif.

Le récepteur ne fabrique pas une route plausible. Il limite le dommage, garde la preuve et rend le compromis révisable. La continuité n'est plus obtenue par une interprétation secrète.

TLS commença à tester l'avenir

Un point d'extension inutilisé peut mourir alors même qu'il reste écrit. Des serveurs intolérants aux valeurs inconnues prospèrent jusqu'au jour où une vraie nouveauté apparaît.

RFC 8701 réserve les valeurs GREASE et demande aux clients TLS de les émettre. Les serveurs prouvent ainsi continuellement qu'ils savent ignorer une extension inconnue. RFC 9170 généralise cette idée : seule l'utilisation active protège l'extensibilité ; une promesse jamais exercée s'ossifie.

La maintenance entra dans le contrat

RFC 9413 conserve la résistance aux bogues et aux attaques. Il refuse seulement de traiter toute entrée inattendue comme une invitation à deviner. La tolérance permanente crée une compatibilité « bogue pour bogue », enferme les implémentations établies et élève le coût d'un nouvel entrant.

La solution proposée est une maintenance active : signaler la divergence, corriger le texte et le code, définir le traitement des erreurs, rendre les échecs visibles quand cela reste sûr, documenter les contournements temporaires et planifier leur retrait. Une exclusion peut être nécessaire, mais elle doit être intentionnelle, fondée sur le protocole et accompagnée d'une migration.

Le document est informatif et sa section d’applicabilité suppose que les logiciels puissent être mis à jour. Un équipement figé peut justifier une exception bornée, jamais une loi silencieuse sans fin.

Sources et limites

La chaîne documentaire repose sur RFC 760, RFC 793, RFC 1122, RFC 1958, RFC 7606, RFC 8701, RFC 9170 et RFC 9413. Elle établit des règles et des mécanismes, non l'uniformité de tous les logiciels. La leçon est limitée : absorber un dommage borné, sans cacher une ambiguïté que d'autres devront hériter.