Résumé

  • La RFC 2000 classait chaque protocole selon deux dimensions indépendantes : son état de maturité dans le processus et son niveau d’exigence dans un domaine d’applicabilité.
  • Une présence dans la liste, un niveau élevé ou le mot Required prouvaient une décision institutionnelle datée, pas automatiquement le déploiement, l’interopérabilité, le trafic, l’achat ni la validité actuelle ; Historic n’effaçait pas les systèmes existants.

La RFC 2000 portait une consigne inhabituelle pour un Internet Standard : ne plus utiliser cette édition après le 16 juin 1997. Publiée en février comme STD 1, elle remplaçait la RFC 1920 et les inventaires antérieurs. En juin, la RFC 2200 l’a remplacée et a fixé une nouvelle date limite. L’autorité appartenait à l’édition courante, non à une liste figée pour toujours.

Cette limite oblige à lire les entrées comme un relevé institutionnel. Elles montrent la classification retenue à une date donnée, mais ne comptent ni logiciels ni routeurs. Le texte reconnaissait d’ailleurs que certains protocoles de fournisseurs étaient largement implémentés sans approbation de l’IESG. Adoption et statut formel pouvaient donc suivre des trajectoires différentes.

La première coordonnée, STATE, mesurait la maturité normative : Standard, Draft Standard, Proposed Standard, Experimental, Informational ou Historic. La seconde, STATUS, exprimait le niveau d’exigence : Required, Recommended, Elective, Limited Use ou Not Recommended. La matrice imprimée indiquait des combinaisons habituelles, pas une statistique de parts de marché.

Chaque degré de maturité avait une portée précise. Standard signifiait que l’IESG avait établi un standard officiel et lui avait attribué un numéro STD. Selon la RFC 2026, Draft Standard exigeait au moins deux implémentations indépendantes et interopérables issues de bases de code différentes, ainsi qu’une expérience opérationnelle réussie suffisante. Ce seuil ne garantissait pourtant pas l’absence de comportement imprévu à grande échelle. Proposed Standard était moins probant : en règle générale, ni implémentation ni expérience opérationnelle n’étaient requises.

Les catégories hors piste ne mesuraient pas davantage le terrain. Experimental conservait un travail de recherche ; sa présence servait la communauté, disait la RFC 2000, et ne démontrait aucune standardisation. Informational pouvait publier les travaux d’un autre organisme ou d’un fournisseur. Historic désignait une spécification supplantée ou devenue obsolète. Aucun de ces mots ne constatait la disparition du code installé.

L’axe d’exigence répondait à « qui devrait implémenter quoi, dans quel domaine ? ». Required signifiait nécessaire à la conformité minimale telle que définie par une Applicability Statement. Il ne s’agissait pas d’un ordre d’achat universel. Recommended restait souhaitable sans être nécessaire à cette conformité. Elective n’imposait pas l’implémentation, mais exigeait de suivre la spécification si la fonction était choisie. Limited Use et Not Recommended limitaient l’usage général pour plusieurs motifs possibles, sans révéler l’état du parc.

La RFC 2000 précisait que seule une modification de STATE faisait progresser un protocole sur la voie des standards ; STATUS pouvait être réexaminé à tout moment. La maturité d’un texte et son champ d’application étaient donc deux décisions, prises sur deux surfaces de contrôle différentes.

Le catalogue montrait même un décalage entre ses propres horloges. Sa première section appelait encore la RFC 1602 la description définitive du processus, tandis que sa liste des nouveaux RFC mentionnait déjà la RFC 2026, qui avait remplacé la RFC 1602 en octobre 1996. Cela ne permet pas d’inventer une cause, mais prouve qu’une compilation datée n’actualise pas nécessairement toutes ses parties au même instant.

Le cadre a continué d’évoluer. La RFC 6410 a réduit en 2011 les trois niveaux de la piste à Proposed Standard et Internet Standard, tout en maintenant pour le niveau supérieur les preuves d’implémentations indépendantes, d’interopérabilité, de déploiement étendu et d’expérience réussie. La RFC 7100 a retiré en 2013 le résumé périodique STD 1, qui n’était plus tenu à jour et avait cédé la place à la liste en ligne du RFC Editor.

La RFC 2000 reste ainsi une excellente source historique si l’on respecte sa frontière : elle prouve la classification officielle d’une fenêtre de 1997. Pour prouver usage, conformité, interopérabilité ou survie, il faut lui adjoindre inventaires d’implémentation, essais, télémétrie, périmètres d’achat et sources de statut actuelles.

Sources : RFC 2000, notice RFC Editor, RFC 1920, RFC 2026, RFC 2200, RFC 6410, RFC 7100.