Résumé

  • RFC 1700 était explicitement une photographie d’octobre 1994, fabriquée à partir de fichiers tenus à jour par l’IANA. En 2002, RFC 3232 l’a rendu historique parce que ses valeurs étaient devenues incomplètes, parfois fausses.
  • Pour établir une attribution actuelle, il faut conserver la ligne du registre, son URL, l’heure de consultation, une copie hachée, la politique d’enregistrement et la chaîne de décision. Le RFC reste la preuve du contexte, non celle du présent.

Supposons qu’un audit doive répondre à une question apparemment banale : quelle utilisation était associée à telle valeur de paramètre au moment d’un incident ? Une table de RFC 1700 fournit une réponse nette. Le site de l’IANA en fournit une autre. Sans date de collecte ni historique des changements, l’équipe ne sait pas si elle a découvert une erreur, une réattribution, une correction ou simplement deux époques différentes.

C’est précisément le piège que RFC 3232 a désamorcé. Joyce K. Reynolds y constate que la publication périodique d’Assigned Numbers sous forme de RFC a été remplacée par une base en ligne. RFC 1700, daté d’octobre 1994, ne contenait plus toutes les valeurs et certaines étaient erronées. Il devait donc passer au statut Historic.

Cette décision ne diminuait pas l’archive. Elle lui retirait une mission impossible : rester l’image actuelle d’un système qui continuait de bouger.

Une publication née d’un état mouvant

RFC 1700, édité par Reynolds et Jon Postel, annonçait déjà sa limite. Le texte se présentait comme une photographie du processus d’attribution en cours. Les informations à jour résidaient dans des fichiers accessibles en ligne ; le RFC résultait de leur concaténation, assortie de la mise en forme nécessaire. Corrections et demandes continuaient d’être adressées à l’IANA, Reynolds figurant parmi les points de contact.

L’histoire plus ancienne rend ce mécanisme concret. RFC 900 recensait des numéros, mais signalait aussi des valeurs de transition et des références. Certaines entrées de réseau pouvaient changer, l’ancien numéro restant temporairement visible. La liste n’était donc pas une tablette gravée : elle accompagnait une activité administrative.

Le RFC donnait à chaque édition une identité durable, diffusable et citable. En contrepartie, chaque nouvelle attribution créait un écart avec cette édition. Une omission pouvait se comprendre comme un retard ; une correction révélait un danger plus sérieux, celui de prendre une donnée périmée pour une vérité normative.

Avec RFC 3232, Reynolds sépare proprement deux questions. « Que publiait-on en 1994 ? » appelle RFC 1700. « Quelle attribution le registre affiche-t-il aujourd’hui ? » appelle une observation datée du registre. Employer la même référence pour les deux réponses fabrique une ambiguïté que le document de 2002 avait justement supprimée.

Une valeur n’est pas seule

La base en ligne n’est pas authoritative par simple fraîcheur. Elle prend place dans une architecture de délégation. RFC 2860 prévoit que, pour les paramètres relevant de l’IETF, l’IANA attribue et enregistre selon les critères et procédures spécifiés dans les RFC. En cas d’ambiguïté, l’IESG donne l’orientation technique ; un différend peut remonter jusqu’à l’IAB.

Le même accord demande que les informations sur les attributions courantes soient disponibles en ligne et gratuitement, ainsi qu’un mécanisme public de demande. L’état publié est donc le résultat d’une procédure. Pour l’évaluer, il faut connaître non seulement la valeur, mais le registre exact, la règle applicable et l’autorité qui a validé la modification.

RFC 8126 fournit la grammaire de cette procédure. La création d’un registre doit préciser son nom, les champs requis, les valeurs initiales, le contrôle des changements et la politique des futures inscriptions. Premier arrivé, premier servi n’impose pas le même examen qu’Expert Review. Specification Required, RFC Required, IETF Review ou Standards Action organisent encore d’autres degrés de documentation et de consensus.

Une extraction réduite à deux colonnes, « valeur » et « signification », perd donc l’essentiel du régime de preuve. Le statut, la référence, le responsable du changement ou l’étendue réservée ne sont pas des décorations. Ils disent dans quelles conditions la ligne peut être invoquée et modifiée.

Donner une date au mot « actuel »

L’IANA présente aujourd’hui ses registres publics comme le moyen de maintenir la cohérence mondiale des identifiants et indique que ses fonctions sont exercées par Public Technical Identifiers, société affiliée à l’ICANN. Cette description a été observée le 10 septembre 2026. Elle doit être traitée comme une information actuelle et datée, non projetée rétrospectivement dans un RFC ancien.

Il en va de même pour chaque ligne. L’URL stable mène à une publication modifiable. Une référence peut être complétée, une valeur dépréciée, un intervalle reclassé. Une capture d’écran seule montre ce qu’un lecteur a vu mais se vérifie mal ; une requête structurée seule peut être retraitée sans laisser d’état intelligible.

Le dossier robuste conserve les deux formes lorsqu’elles existent : réponse brute et présentation lisible. Il note le nom canonique du registre, l’URI, l’horodatage avec fuseau, la ligne ou l’intervalle, le statut, les références, puis calcule un hachage du fichier capturé. La table normalisée dérivée doit pointer vers cette pièce, jamais la remplacer.

Il faut encore joindre l’histoire de décision. Demande initiale, avis d’expert, consensus de l’IETF, action de l’IANA et correction ultérieure sont des événements distincts. Un champ « source » qui les fusionne efface la responsabilité et l’ordre des faits.

Le rôle exact de Reynolds

L’Internet Hall of Fame a admis Joyce Reynolds à titre posthume en 2025. Il rappelle sa collaboration avec Postel à l’Information Sciences Institute de l’USC et sa codirection ultérieure du RFC Editor. Reynolds est morte en 2015 : rien dans ce portrait historique ne doit être transformé en fonction ou opinion présente.

Son geste dans RFC 3232 est d’autant plus instructif qu’elle connaissait de l’intérieur la fabrication des anciennes éditions. Elle ne choisit pas entre la mémoire et l’exploitation. Elle assigne à chacune sa bonne surface : au RFC la provenance durable, au registre maintenu l’état courant.

Une preuve exploitable reprend ce partage. Première couche : copie datée de l’état visible. Deuxième couche : politique et décisions qui l’ont produit. Troisième couche : documents d’archive qui ont créé l’espace de noms ou fixé ses règles. Chaque couche évolue à son propre rythme et reçoit son propre identifiant de version.

Lors d’une nouvelle collecte, on ne remplace pas silencieusement l’ancienne. On conserve les deux empreintes, puis on explique la différence. Une modification de politique sans changement de valeur devient un événement de gouvernance. Un changement de ligne sans nouveau RFC devient un événement de registre. C’est ainsi qu’une citation résiste au temps au lieu de le masquer.

Sources