Résumé

  • RFC 3499 rendait consultable l’intervalle nominal 3400–3499, mais la proximité des numéros ne créait ni architecture commune, ni hiérarchie, ni dépendance technique.
  • Le marqueur général [STANDARDS TRACK], l’avertissement sur l’évolution des statuts et la mention honnête de RFC 3400 « jamais publié » séparaient l’identité archivistique de la validité présente.

Un catalogue peut être exact tout en refusant de répondre à la question du moment. RFC 3499 le disait dès sa note introductive : les statuts des RFC engagés sur la voie des standards pouvaient évoluer. Il n’inscrivait donc pas pour chacun une maturité supposée définitive. Il se contentait du marqueur [STANDARDS TRACK] et renvoyait vers l’édition la plus récente des standards officiels pour connaître l’état courant.

Ce refus était une qualité, pas une lacune. Publié en décembre 2003 par Sandy Ginoza à l’ISI, le document se présentait comme une liste légèrement annotée des positions 3400 à 3499. Il était informatif, ne spécifiait aucune norme Internet et se décrivait lui-même en deux mots : « This memo. » Son rôle était de rendre une tranche du corpus visible.

La tranche n’avait aucune unité technique. En quelques pages, on passait de la commutation de protection SONET à la vidéo RTP, de MPLS à DHCP, puis aux sockets IPv6, à l’IDNA, à STUN, à SIP, à TCP sur réseaux mobiles, à XML, au DNS, aux rapports de courrier, à SNMP et à DDDS. Ces textes partageaient une fenêtre de publication. Ils ne partageaient pas nécessairement un chemin de paquets, une équipe, une autorité ou un calendrier de déploiement.

Deux numéros voisins ne sont donc pas deux modules adjacents. RFC 3498 ne dépend pas de RFC 3497 parce qu’il le suit. Un texte de la tranche peut modifier une spécification ancienne, être remplacé bien plus tard ou dépendre de documents situés ailleurs dans la série. Le classement numérique est un instrument d’identité permanente, non une topologie du système.

La borne basse rend ce principe visible. RFC 3400 n’a jamais été publié. RFC 3499 l’inscrit comme tel. Entre 3400 et 3499, il existe cent positions numériques, mais seulement quatre-vingt-dix-neuf publications émises si l’on compte RFC 3499 lui-même. Le catalogue ne comble pas la case vide par un artefact fictif. Il préserve une absence vérifiable.

Une base de données pourrait être tentée de « réparer » cette irrégularité. Elle créerait un objet sans texte, lui attribuerait une date ou le relierait mécaniquement à 3401. Elle obtiendrait une table plus régulière et une histoire moins vraie. Ici, la qualité archivistique consiste précisément à laisser le trou intact.

Les résumés ont une limite comparable. Ils permettent de repérer un document et parfois intègrent les corrections éditoriales effectuées lors de la publication. Ils ne remplacent ni les prescriptions normatives, ni les définitions référencées, ni les errata, ni les liens « Updated By » ou « Obsoleted By ». Ils ne disent pas quel sous-ensemble un fournisseur a codé, quel paramètre un opérateur a activé ou quel résultat un utilisateur a observé.

Le produit éditorial avait lui-même une histoire. RFC 1099 inaugura en décembre 1991 la publication d’un résumé tous les cent numéros. RFC 3299 couvrit 3200–3299. RFC 3399 ne parut pas. RFC 3499 et RFC 3599 furent publiés, puis la série s’arrêta. La convention du suffixe 99 avait organisé le catalogue; elle n’était pas propriétaire de ces nombres.

Un Internet-Draft de 2013 proposa de mettre officiellement fin aux résumés xx99. Il expliquait que les résumés consultables par moteur de recherche avaient rendu le livret périodique inutile et que les numéros finissant par 99 pourraient reprendre un usage ordinaire. Mais le draft expira. Il renseigne l’intention de l’éditeur et le changement de pratique; il ne constitue pas une règle adoptée. Le confondre avec un RFC publié reviendrait à confondre projet et effet.

Il faut aussi distinguer cette série xx99 des instantanés xx00 intitulés « Internet Official Protocol Standards ». RFC 7100 retira à STD 1 sa fonction de résumé, devenue obsolète. RFC 7101 expliqua que la page web remplaçait les instantanés xx00. Les deux évolutions témoignent du passage d’un état imprimé périodique à des vues en ligne maintenues, mais elles concernent des produits différents.

La page moderne du RFC Editor rend cette architecture temporelle plus explicite. Un RFC publié ne change pas. Une révision devient un nouveau RFC. Les relations de mise à jour et d’obsolescence guident vers la pratique courante. Les errata vérifiés restent associés au texte sans réécrire silencieusement le fichier historique. Les identifiants STD ou BCP peuvent demeurer stables alors que les RFC qui les composent évoluent.

La chaîne de preuves doit donc rester typée. Attribution ou absence d’un numéro; publication d’un texte; présence dans le résumé; métadonnées actuelles; fermeture des dépendances; sélection des exigences; code; interopérabilité; déploiement; résultat de service. La vérité d’une étape ne se transmet pas automatiquement à la suivante.

RFC 3499 appartient à l’histoire d’Internet parce qu’il montre une institution pratiquant la modestie documentaire. Il ordonne sans gouverner. Il facilite la recherche sans prétendre être l’architecture. Il conserve des abstracts sans les faire passer pour du code. Il sait qu’un état de 2003 est utile à condition de porter sa date.

Cette minceur rejoint une règle plus générale : la visibilité n’est pas la souveraineté. Une couche d’indexation peut réduire les coûts de compréhension; elle ne devient pas pour autant la source de l’état technique qu’elle décrit. Quand un catalogue est élevé au rang d’autorité opérationnelle, les symboles commencent à produire de fausses réalités.

Le bon lecteur conserve alors les séparations. Le numéro prouve l’identité du document. Le catalogue prouve son inscription dans une tranche. Les métadonnées actuelles éclairent son statut. Les dépendances expliquent la spécification complète. Seuls le code, les tests et l’observation prouvent ce que le réseau fait.

Sources