É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 . 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 , 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.