Résumé

  • L’édition de mars 1993 des standards officiels de l’IAB, RFC 1410, disait de cesser de l’utiliser après le 31 juillet 1993. Le classement publié était daté.
  • Pour avancer, un protocole avait besoin d’une recommandation de l’IESG et de la ratification de l’IAB. Sans cette dernière, le travail retournait à l’IETF ; délais minimaux et preuves d’implémentation s’ajoutaient au parcours.

Une liste officielle qui annonce sa propre date de péremption inspire davantage confiance qu’un tableau qui prétend durer toujours. Le RFC 1410 demandait au lecteur de vérifier qu’il avait l’édition courante, puis fixait au 31 juillet 1993 la fin d’usage de celle publiée en mars. Les statuts des protocoles pouvaient changer. Le document voulait que la confiance dans son tableau change avec eux.

Les groupes de travail de l’IETF réalisaient l’essentiel du développement. La progression suivait trois niveaux : Proposed Standard, Draft Standard, puis Standard. À chaque passage, l’Internet Engineering Steering Group devait recommander l’avancement ; l’Internet Architecture Board devait le ratifier. Si l’IAB ne ratifiait pas, le protocole repartait vers l’IETF pour retravail. Deux instances, deux actes vérifiables, et une marche arrière prévue.

Le calendrier empêchait une promotion dans la foulée d’une bonne réunion. L’IAB imposait au moins six mois entre Proposed et Draft, puis quatre mois au moins entre Draft et Standard, pour laisser à la communauté le temps de réagir. Le texte ajoutait qu’un Draft signalait une probable promotion en six mois si aucune objection majeure ni faille n’apparaissait. Cette prévision n’était pas une date de promotion automatique.

Les preuves ne se limitaient pas aux procès-verbaux. La pratique générale de l’IAB exigeait au moins deux implémentations indépendantes avant de passer de Proposed à Draft. Le passage de Draft à Standard demandait généralement une expérience opérationnelle et une interopérabilité démontrée entre au moins deux implémentations. Une équipe pouvait écrire une excellente spécification ; une autre devait encore pouvoir construire un programme qui lui parle.

En cas d’incertitude, l’IAB pouvait réunir des experts de l’IETF, de l’IRTF et de l’IAB dans une commission spéciale chargée de recommander une action explicite. Ce détour renforçait l’examen sans effacer la ratification prévue. L’édition conservait aussi des protocoles marqués Historic lorsqu’ils étaient remplacés ou inutilisés, et signalait par un astérisque les lignes nouvelles ou modifiées. Le tableau montrait ses retouches au lieu de faire semblant d’être une liste gravée dans le marbre.

Le registre RFC Editor classe désormais cette édition comme Historic et indique son remplacement par RFC 1500. Un autre article sur RFC 1311 raconte pourquoi un numéro de RFC ne donnait pas à lui seul un numéro STD. Ici, la question est celle du pouvoir de faire monter un protocole : qui recommande, qui peut le renvoyer, et quels logiciels ont réellement été éprouvés ?

Le document de 1993 donnait sa réponse et sa limite temporelle dans la même brochure. Une recommandation ne valait pas ratification ; un vote ne faisait pas fonctionner deux programmes ; et une liste correcte en mars pouvait devenir périmée en août.