Date de publication du RFC : Janvier 2014
Auteur(s) du RFC : O. Kolkman (NLnet Labs), S. Bradner (Harvard University), S. Turner (IECA)
Première rédaction de cet article le 30 janvier 2014
En théorie, il existe à l'IETF une hiérarchie de normes. Un RFC publié sur le chemin des normes peut avoir plusieurs niveaux dans cette hiérarchie. Au nombre de trois à l'origine, ces niveaux ont été ramenés à deux par le RFC 6410. Le premier de ce niveau est « Proposition de Norme » (Proposed Standard), décrit par le RFC 2026. Sauf que la réalité est loin de ce que décrivent les documents officiels.
Le RFC 2026 est toujours le document qui décrit officiellement les normes issues de l'IETF. Sa section 4.1.1 raconte ce qui fait une « Proposition de Norme » mais ce récit est loin de ce qu'on observe en pratique. Ce nouveau RFC 7127 ne change pas le processus de normalisation, il se contente de remplacer la description des Propositions de Norme du RFC 2026 par un texte plus réaliste.
Pour atteindre le niveau Proposition de Norme, le premier niveau du chemin des normes, il faut une décision de l'IESG. Dans la vision originale, les normes allaient ensuite avancer par décisions successives, le long du chemin des normes, jusqu'au statut suprême, celui de « Norme Complète » (Internet Standard). En fait, des tas de protocoles très utilisés et très déployés n'ont jamais suivi cette progression et sont restés Proposition de Norme. Dans la liste des normes, on trouve ainsi, bloqués au niveau Proposition, des tas de protocoles très répandus et indiscutablement réussis, comme les communautés BGP du RFC 1997 ou comme le format OpenPGP du RFC 9580. Il serait donc ridicule et pédant d'écarter une Proposition de Norme en raison de son niveau sur le chemin des normes, alors que beaucoup de normes à ce niveau sont stables, bien testées, mises en œuvre dans beaucoup de programmes...
Donc, la section 3.1 de notre nouveau RFC propose une nouvelle description des Propositions de Norme, description qui remplace la section 4.1.1 du RFC 2026. Une Proposition de Norme est stable, les principaux choix de conception ont été faits et tranchés, elle a fait l'objet d'un examen détaillé par l'IETF, et elle est utile pour les internautes. Si la disponibilité d'une implémentation, et l'expérience opérationnelle de son utilisation, sont très recommandés pour recevoir le statut de Proposition de Norme, cela n'est pas stricto sensu indispensable. Par contre, si le protocole en question touche à une fonction essentielle de l'Internet, l'IESG peut exiger une telle expérience concrète.
Parfois, une norme sera publiée avec le statut de Proposition de Norme alors qu'il reste encore des problèmes non réglés. Dans ce cas, ces problèmes doivent être clairement documentés dans le texte de la norme (section 4 de notre RFC).
La description est plus courte que dans le RFC 2026 et ne contient plus les avertissements et mises en garde de l'ancien RFC.
Notre nouveau RFC ne change pas la description du second niveau, Norme Complète, qui reste présenté par la section 4.1.3 du RFC 2026.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)