Mon blog

Écrire une norme, comme écrire n'importe quelle spécification, est un art. Ce RFC vise à améliorer la qualité des normes IETF en conseillant leurs auteurs sur ce qui fait une bonne norme.

On note que l'IETF s'impose une tâche qui n'est pas considérée comme telle par toutes les SDO : s'assurer que la norme soit lisible et que les implémenteurs la comprennent suffisamment bien pour que les implémentations soient interopérables.

Le RFC couvre donc les points suivants :

• La nécessité de se pencher de très près sur les problèmes de sécurité.
• La définition précise du comportement d'un logiciel lorsque celui avec qui il communique viole la spécification (les premiers RFC étaient écrits pour un monde parfait où tout le monde "jouait le jeu").
• La célèbre règle "Be liberal in what you accept, and conservative in what you send", spécifiée dans le RFC 791. Très souvent citée, parfois mal comprise, cette règle a permis le décollage d'un Internet composé de logiciels très variés, d'origine très différentes. Mais elle est aussi responsable de beaucoup de problèmes liés au laxisme des implémentations et notre RFC recommande donc la prudence en l'appliquant.
• Le choix des options : trop d'options et l'interopérabilité en souffre (car deux implémentations ne mettent pas forcément en œuvre les mêmes). Pas assez d'options et le protocole ne peut pas s'adapter.
• La spécification rigoureuse, presque juridique, des obligations et interdictions. Cela se fait par les mots-clés MUST, SHOULD et MAY, définis dans le RFC 2119, mots-clés qui sont écrits en majuscules pour montrer que ce n'est pas leur sens courant qui est utilisé.
• Les conventions de notation, par exemple pour les automates à états finis, utilisés dans de nombreux RFC.
• La nécessité de permettre la gestion du protocole, notamment via le protocole standard de l'IETF.
• La nécessité de s'adapter à un monde varié, non limité aux États-Unis et non limité aux anglophones.
• Et de nombreux autres points.

Des conseils pratiques apparaissent ensuite dans la section 3, pour décrire le format des paquets et les automates à états finis.

Notre RFC se clot sur une liste de choses à vérifier lorqu'on écrit une norme.

Globalement, les normes produites par l'IETF et distribuées dans les RFC sont d'une qualité très supérieure, notamment en terme de clarté et de précision, aux normes d'autres organismes. Le succès fulgurant de l'Internet en a été le résultat. Mais cela n'interdit pas de s'améliorer et ce document permet aux RFC d'être encore meilleurs.