Résumé

  • La RFC 1280 était un état de coordination, pas un inventaire en temps réel : elle demandait de rechercher l’édition à jour et interdisait d’utiliser celle-ci après le 31 juillet 1992.
  • L’état indiquait la maturité de la normalisation ; le statut indiquait l’exigence d’implémentation. Aucun des deux ne prouvait le déploiement ou le bon fonctionnement.

Un catalogue devient d’autant plus risqué qu’il est utile. L’opérateur qui voulait savoir où se situait un protocole dans le processus Internet avait besoin d’une référence commune, et non d’une collection de RFC isolées. La RFC 1280 voulait fournir cette référence : elle réunissait les protocoles, expliquait les étapes de normalisation, attribuait des niveaux d’exigence et renvoyait aux documents détaillés. Mais l’IAB avait inscrit une limite à sa propre autorité : l’édition de mars 1992 devait paraître environ chaque trimestre et ne devait plus être utilisée après le 31 juillet.

Cette échéance ne signifiait pas que tous les protocoles changeraient le 1er août. Elle bornait la valeur documentaire de ce numéro. L’IAB demandait aux lecteurs de rechercher la version en vigueur auprès du Network Information Center ou de l’IANA et de consulter les notes de changements. La RFC 1360 a ensuite remplacé la RFC 1280 en septembre. Une liste pouvait donc faire foi à la date de publication tout en étant dépassée pour une décision ultérieure.

La liste séparait aussi deux notions souvent confondues. STATE décrivait la maturité : standard, projet de norme, proposition, expérimental, informatif ou historique. STATUS exprimait le niveau d’exigence : requis, recommandé, facultatif, usage limité ou déconseillé. Un protocole proposé pouvait être facultatif ; une spécification informative pouvait être recommandée. Le premier axe situait un texte dans un processus ; le second précisait l’attente envers certaines catégories de systèmes.

Ni l’un ni l’autre ne constituait un recensement. La RFC 1280 reconnaissait que certains protocoles de fournisseurs étaient largement déployés sans recommandation de l’IESG ni ratification de l’IAB. À l’inverse, « expérimental » servait à documenter des travaux de recherche, pas à avaliser leur emploi opérationnel. La publication ne prouvait donc pas l’adoption, pas plus qu’un label de normalisation ne démontrait la popularité. Il fallait d’autres traces : implémentations indépendantes, interopérabilité et expérience opérationnelle.

Les références voisines n’étaient pas actualisées simultanément. Assigned Numbers, Gateway Requirements et Host Requirements suivaient des calendriers distincts ; en cas de divergence, le document le plus récent devait prévaloir. La RFC 1280 organisait les références et aidait à trouver la RFC courante d’un protocole, mais ne synchronisait pas toutes les spécifications sous-jacentes.

Le calendrier et les deux axes sont donc aussi importants que les lignes du catalogue. La RFC 1310 décrivait le processus de normalisation et qualifiait le relevé périodique de source faisant autorité pour une spécification. La RFC 1280 apportait cet état tout en en indiquant l’échéance. Une entrée historique dit ce que l’IAB consignait alors ; elle ne permet pas d’affirmer ce qu’un protocole fait aujourd’hui, ce que les opérateurs ont installé ni si un service a répondu.

Sources : RFC 1280 ; RFC 1310 ; RFC 1360.