Résumé

  • La relation Obsoletes fait autorité sur la filiation documentaire : le nouveau RFC devient la référence générale pour comprendre la spécification ou la pratique courante, tandis que l’ancien demeure dans l’archive permanente.
  • Elle ne corrige aucun binaire, ne désactive aucune fonction, ne retire aucun produit et n’interdit juridiquement aucun usage. Ces effets relèvent d’acteurs et de preuves différents.
  • HTTP/2 et TLS montrent qu’une identité de protocole peut survivre au remplacement de son texte de référence et qu’une version formellement dépréciée peut rester assez longtemps en service pour opposer sécurité et interopérabilité.
  • La bonne réponse n’est ni l’obéissance fictive ni l’ajournement sans fin, mais un reçu de migration reliant filiation normative, état réellement chargé, dépendances, tests, exceptions, retour arrière et télémétrie.

Une publication sans bouton d’arrêt

Sur la première page du RFC 9113 figure une indication brève : le document rend obsolètes les RFC 7540 et 8740. Dans la Série des RFC, cet acte est substantiel. Le lecteur qui veut connaître HTTP/2 aujourd’hui doit partir du RFC 9113. La fiche du RFC 7540 indique désormais par quel texte il a été remplacé. Certaines références de registres sont réorientées. Une analyse de conformité doit tenir compte des changements du nouveau texte.

Rien de cela ne donne au rédacteur de la norme une session d’administration sur un serveur. Le jour de la publication, un équipement n’a pas supprimé de lui-même le mécanisme de mise à niveau en clair. Une bibliothèque déjà distribuée n’a pas acquis les nouvelles règles de validation. Un mandataire n’a pas oublié les anciennes sémantiques de priorité. L’événement normatif était réel, mais son premier objet était le dossier documentaire.

Ce constat ne réduit pas le rôle de l’IETF. Il le rend vérifiable. Une institution de normalisation doit pouvoir dire quel texte porte la spécification courante. L’éditeur doit préserver la chaîne d’autorité et l’historique. IANA doit maintenir des références exactes. La confusion commence lorsque ces fonctions de coordination sont présentées comme une capacité d’exécution sur des machines appartenant à d’autres.

Cette confusion offre un résultat très commode. Il suffit de remplacer un numéro dans un registre de conformité pour déclarer une transition achevée. Le comité de sécurité voit une case verte. Le fournisseur cite le dernier RFC. Le conseil d’administration entend que l’ancien comportement a disparu. Personne n’a encore prouvé quel logiciel traite le trafic, quelle option est active ni quel partenaire cessera de communiquer le jour où elle sera retirée.

Le catalogue décrit alors l’état souhaité. Le parc installé conserve l’état effectif. Faire témoigner le premier à la place du second transforme la normalisation en décor de contrôle.

Ce que la relation remplace réellement

L’explication publiée par le RFC Editor laisse peu de place à l’ambiguïté. Le texte d’un RFC publié ne change pas. Une révision ou un remplacement reçoit un nouveau numéro. Obsoletes signifie que le nouveau document remplace ceux qui sont énumérés comme point de départ général pour la spécification ou la pratique courante. Les anciens restent dans l’archive permanente de la Série.

Cette permanence a une fonction opérationnelle. Elle permet de reconstruire les attentes auxquelles répondait un logiciel lorsqu’il a été écrit. Elle permet de localiser l’origine d’une règle, de comparer deux états normatifs et d’expliquer après un incident pourquoi deux systèmes ont divergé. Effacer le texte ancien simplifierait la présentation, mais détruirait une partie de la preuve.

Le RFC 7322 classe les mentions Updates et Obsoletes dans l’en-tête. Il prévoit aussi qu’un document obsolète puisse encore être cité, en général avec sa version la plus récente. C’est la conséquence logique d’une série immuable : on crée des relations nouvelles au lieu de corriger silencieusement les objets anciens.

La relation n’est donc pas facultative. Un fabricant qui prétend mettre en œuvre le RFC 9113 ne peut pas choisir les passages du RFC 7540 qui l’arrangent et ignorer les modifications. Un lecteur qui ne suit pas la filiation risque de travailler sur une règle dépassée. Une revue d’architecture doit identifier la référence courante et les textes qui la mettent à jour.

Mais la portée directe s’arrête là. Le nouveau document ne prouve pas que le code ancien a été corrigé, qu’une fonction a été désactivée, qu’un contrat a changé ou qu’une autorité publique a prononcé une interdiction. Ces affirmations supplémentaires demandent leurs propres pièces.

Six décisions derrière un adjectif

Dans une conversation d’exploitation, le mot « obsolète » amalgame au moins six décisions.

La première est le remplacement documentaire. Le processus de normalisation désigne un texte plus récent comme référence générale. L’archive conserve les deux et enregistre leur relation.

La deuxième est une décision de statut ou d’applicabilité. Une spécification peut passer au statut Historic. Une Best Current Practice peut durcir les usages acceptables. Un texte d’applicabilité peut réserver une règle à une catégorie de protocoles ou de déploiements.

La troisième est la dépréciation d’une fonction. Le protocole peut survivre alors qu’un chemin particulier est retiré, déconseillé ou redéfini. Le nom négocié sur le réseau n’a pas nécessairement besoin de changer.

La quatrième est la modification de l’implémentation. Les responsables du logiciel modifient le code source, produisent une version, décident des branches prises en charge et préparent éventuellement un rétroportage. La présence d’un correctif dans un dépôt ne dit pas qu’il est chargé chez le client.

La cinquième est la décision de déploiement. L’opérateur inventorie, teste, configure, choisit les cohortes, surveille les pannes et garde ou refuse une exception. C’est à ce niveau que le coût de l’interruption et le risque résiduel sont acceptés.

La sixième est la contrainte extérieure. Un contrat, un assureur, un acheteur, un régulateur ou un tribunal peut exiger le retrait. Son mandat provient de sa propre base juridique ou contractuelle, pas du mot imprimé dans l’en-tête.

Ces actes se causent souvent les uns les autres. Une publication peut déclencher une version logicielle ; une recommandation de sécurité peut influencer un assureur ; la fin de support d’un fournisseur peut accélérer un calendrier. La causalité ne les transforme pas en une seule autorité.

La séparation vaut aussi contre l’excuse inverse. On ne peut pas qualifier un RFC de « simple document », ignorer sa règle puis continuer à revendiquer la conformité. La norme définit une condition technique réelle pour les systèmes qui choisissent d’y adhérer. Elle ne dispose simplement pas, par elle-même, des identifiants, de la fenêtre de maintenance et de la carte de dépendances nécessaires pour modifier un système déterminé.

HTTP/2 : le texte change, h2 reste

Le RFC 9113 est particulièrement instructif parce qu’il mêle continuité et rupture. Il devient la spécification courante de HTTP/2, intègre le traitement de TLS 1.3 auparavant décrit dans le RFC 8740, resserre certaines validations et revoit plusieurs mécanismes. Son annexe B expose des changements substantiels ; il ne s’agit pas d’une simple réimpression.

Dans le même temps, l’identifiant ALPN h2 demeure. Les registres des types de trame, paramètres et codes d’erreur continuent d’exister. IANA actualise les références vers le nouveau texte au lieu de créer une autre identité de protocole. Deux pairs ne négocient pas « RFC 9113 » : ils négocient une capacité sur le fil.

Certains éléments reçoivent un sort plus précis. Le champ HTTP2-Settings et le jeton de mise à niveau h2c sont marqués obsolètes. Le mécanisme de priorité du RFC 7540 est déprécié. Pourtant, le RFC 9113 conserve le format de certaines trames et renvoie à l’ancien RFC pour comprendre leur sémantique historique.

Ce renvoi est une leçon de gouvernance. Le texte remplacé n’est plus le point de départ général, mais il peut rester indispensable pour diagnostiquer un comportement encore observable. L’archive garde la mémoire, le nouveau RFC donne la direction, les développeurs et les opérateurs déterminent quand cette direction atteint la production.

Une déclaration « RFC 7540 remplacé, RFC 9113 adopté » n’apporte donc qu’un indice. Il faut encore demander si le proxy refuse le chemin retiré, si la bibliothèque émet toujours les anciens signaux, si le micrologiciel de l’appliance a été chargé et si les clients historiques prennent une branche de compatibilité. Le numéro indique où lire la question. Il ne connaît pas la réponse locale.

TLS : trois temporalités au lieu d’une

TLS rend l’écart encore plus visible. Le RFC 8446, qui spécifie TLS 1.3, rend obsolète le RFC 5246 consacré à TLS 1.2. Il contient pourtant une longue annexe sur la compatibilité : négociation avec des serveurs et clients plus anciens, déploiements progressifs dans des grappes hétérogènes, pannes causées par des équipements intermédiaires.

Les auteurs n’ont pas supposé que la relation documentaire ferait disparaître l’ancienne version. Ils ont conçu la nouvelle pour rencontrer un parc mixte.

Le RFC 8996 accomplit ensuite un acte plus ferme. Il déprécie formellement TLS 1.0 et TLS 1.1, place les textes correspondants au statut Historic et exige qu’une implémentation ne les négocie pas. La conclusion de sécurité est explicite.

Même ce document ne se présente pas comme un outil de déploiement. Sa partie opérationnelle reconnaît l’existence possible de systèmes incapables d’utiliser TLS 1.2 ou une version supérieure. Appliquer la recommandation peut interrompre leur interopérabilité. La négliger maintient un risque de sécurité. Les responsables doivent apprécier ces deux risques, les mesures compensatoires et le danger de la mise à niveau pour décider de la vitesse d’adoption.

Ce passage n’accorde pas un droit permanent à TLS 1.0. Il désigne le lieu de la décision. L’IETF fixe la pratique courante. Le propriétaire du système doit trouver la dépendance, la remplacer, l’isoler ou accepter la coupure, puis démontrer que l’ancienne version n’est plus négociable.

Le RFC 9325 donne par ailleurs des recommandations distinctes pour TLS 1.2 et TLS 1.3 tout en interdisant le retour aux versions plus anciennes dépréciées. Le RFC 9852 relève ensuite l’exigence pour les nouveaux protocoles utilisant TLS. La pratique courante est donc un graphe de remplacements, de mises à jour et de périmètres, non un classement où le dernier numéro annule tout ce qui le précède.

Une exigence normative n’est pas un service système

Les mots normatifs en capitales sont parfois invoqués comme s’ils résolvaient la question. Un MUST NOT est bien davantage qu’un conseil. Dans le périmètre du texte, il définit le comportement requis d’une implémentation qui revendique la conformité.

Il n’est pas pour autant un service fonctionnant avec des privilèges administrateur sur chaque machine. Le mainteneur traduit la règle en code. Le fournisseur livre un artefact utilisable. L’opérateur l’installe ou le configure. Le partenaire doit supporter le résultat. L’auditeur teste l’état actif.

Cette chaîne sépare l’autorité normative de l’autorité d’exécution. La première peut dire ce que fait un système conforme. Elle ne possède pas automatiquement la machine, le contrat de maintenance ni la responsabilité de l’arrêt.

La distinction améliore l’attribution. Après un échec de migration, dire « le RFC l’exigeait » ne révèle ni le décideur du calendrier, ni le testeur, ni le propriétaire de l’exception. Lorsqu’une fonction ancienne demeure active, dire « elle était obsolète » ne révèle ni le fournisseur qui a omis le correctif, ni l’opérateur qui a gardé l’option.

Une norme utile décrit le comportement commun. Un reçu utile décrit l’acte de chaque responsable.

Le parc installé n’est ni une fiction ni un veto

Le RFC 2026 prévoit qu’une nouvelle version d’un Internet Standard remplace normalement l’ancienne. Il ajoute toutefois que les deux peuvent parfois rester des standards afin de respecter les besoins d’un parc installé, à condition d’expliciter leur relation.

Cette clause reconnaît qu’une interopérabilité existe entre des systèmes, pas seulement entre des paragraphes. Une norme parfaitement pure mais incapable de communiquer avec les pairs réels peut échouer dans sa fonction de coordination.

L’argument du parc installé peut néanmoins être détourné. Quelques dépendances non mesurées deviennent un prétexte pour maintenir partout une surface d’attaque. Un fournisseur transfère indéfiniment le coût de modernisation. Une exception survit à son propriétaire et perd son échéance.

La charge de la preuve doit donc évoluer. Au début, celui qui propose le retrait montre que le remplacement fonctionne et que les modes de panne sont connus. Avec l’accumulation d’alternatives prises en charge, de retours d’expérience et de preuves de risque, le détenteur de l’exception doit expliquer sa nécessité, son isolement et sa date de fin.

La télémétrie permet ce renversement. L’inventaire indique où une capacité pourrait exister. Les traces de négociation montrent où elle sert encore. Les essais indiquent ce qui casse. La version chargée prouve que le changement a atteint le processus qui porte le trafic. Le RFC déclenche la question ; ces observations y répondent.

Le reçu qui manque aux tableaux de conformité

Une migration défendable commence par la filiation : nouveau RFC, relations Updates et Obsoletes, BCP ultérieures et comportement exact concerné. « Passer au RFC 9113 » est trop vague si la décision porte sur une seule voie de mise à niveau.

Vient ensuite l’état chargé : version, construction, micrologiciel et configuration qui traitent effectivement les connexions. Un correctif disponible ou téléchargé ne prouve pas son exécution.

Le troisième élément est la carte des dépendances : clients, serveurs, intermédiaires, systèmes embarqués et partenaires qui utilisent encore l’ancien comportement. Une zone aveugle doit être déclarée comme telle ; l’absence d’observation n’est pas un zéro mesuré.

Le reçu précise aussi le risque et l’autorité. Pourquoi retire-t-on la fonction ? Qui accepte la conséquence ? L’échéance appartient-elle à l’opérateur, à un client, à un fournisseur ou à une règle publique ? La norme peut donner le fondement technique sans fournir le mandat externe.

Il faut enfin le test, le retour arrière et la garde de l’exception. Les pannes attendues, les cohortes, le seuil d’arrêt, la durée de repli, le propriétaire, la compensation et l’expiration doivent être enregistrés. Un retour arrière qui réactive silencieusement un risque ne peut pas être automatique.

La clôture vient de la preuve de retrait : la fonction n’est plus négociée, les alertes ne sont pas seulement masquées et le chemin de remplacement transporte bien le service. La fin d’une transition est une proposition sur l’exécution.

Les deux mensonges symétriques

Le premier mensonge est celui de l’achèvement automatique. Le nouveau RFC existe ; l’ancien comportement est donc déclaré absent. Le risque sort du registre avant de sortir du réseau. La conformité est attestée par une référence au lieu d’un test.

Ce mensonge séduit les administrations centrales parce que le catalogue est propre et peu coûteux. Le parc réel est distribué, conflictuel et rempli d’exceptions. Confondre les deux fait paraître le contrôle plus puissant qu’il ne l’est.

Le second mensonge est celui de l’option permanente. Puisqu’un document ne peut pas modifier une machine, l’opérateur traite toute migration comme indéfiniment facultative. Les exigences normatives deviennent des commentaires, les vulnérabilités des problèmes de compatibilité et les exceptions des droits acquis.

La position honnête tient les deux preuves ensemble. La relation RFC fait autorité sur la ligne documentaire courante. Le système actif fait autorité sur l’état déployé. Entre les deux doit exister une décision attribuable, limitée et testée.

Lorsqu’un tableau indique « obsolète », il faut donc demander : quelle règle a changé ? Quel comportement ancien reste possible ? Qui contrôle les systèmes concernés ? Quelle mesure prouve la disparition sur le fil ?

Le RFC Editor doit conserver l’archive. L’IETF doit exprimer la spécification courante. IANA doit tenir des références exactes. Les mainteneurs doivent produire le code. Les opérateurs doivent décider et vérifier. Les autorités extérieures doivent nommer leur propre mandat. Ce partage n’est pas une faiblesse ; c’est la chaîne de garde de la transition.

La mention Obsoletes nous dit où commence la lecture actuelle. Elle devient un abus seulement lorsque quelqu’un prétend que toute l’exécution s’y termine.

Sources