Dans son processus de normalisation,
l'IETF a toujours accordé une grande importance
au caractère réaliste et pratique de ses normes. Contrairement à
d'autres SDO, qui n'hésitent pas à publier
comme norme des pavés incompréhensible et inimplémentables, l'IETF
veille à ce que l'avancement d'une norme sur le chemin des
normes s'accompagne d'une vérification que cette norme peut
être mise en œuvre et que les différents programmeurs ont bien compris la même
chose. Cette vérification se traduit par des rapports analysant l'état
actuel des implémentations d'une norme et le but de ce RFC est de
guider les auteurs de ces rapports.
Le processus du chemin des normes est décrit
dans le (cf. section 1 de notre ).
Il comprenait trois étapes,
proposition de norme (Proposed
Standard), projet de norme (Draft
Standard) et enfin norme tout court
(Standard). Leur nombre a toutefois été réduit à deux par le . Lors du passage de la première à la
deuxième étape, pour devenir projet de norme, un RFC doit (section
4.1.2 du ) avoir été
mis en œuvre au moins deux fois, par des équipes indépendantes,
et ces deux mises en œuvre doivent interopérer (pouvoir
travailler ensemble).
Le dossier présenté à l'IESG pour
l'avancement d'une norme au statut de projet de norme doit comprendre
un rapport (même section 4.1.2 du )
décrivant les tests effectués entre ces mises en œuvre, leurs
résultats, etc. Historiquement, ces rapports, dont la forme n'était
spécifiée nulle part, ont été de qualité très variable ; certains
étaient très courts, se contentant de dire « On a testé et ça
marche ». D'autres détaillaient à l'extrême un aspect particulier des
tests mais oubliaient les résultats. Le but de ce
est de limiter cette variation. Il met donc à jour légèrement le . Lui-même a été amendé par le , qui a rendu ce rapport facultatif.
L'espoir est que ce RFC contribuera également à clarifier les
tâches à accomplir pour faire avancer une norme : aujourd'hui, peu de
gens s'y retrouvent et bien des normes stables et très utilisées sont
restées au début du chemin des normes car personne n'avait eu le
courage de lancer le processus d'avancement.
La section 2 définit donc ce que doit contenir le rapport
d'interopérabilité. Sur certains points, il est moins strict que le
. Par exemple, il n'est plus obligatoire
de nommer les implémentations testées (cela défrisait certains
vendeurs). Si seulement une partie des implémentations existantes est
testée, le rapport doit dire comment la sélection s'est faite.
Le parlait d'implémentations
« indépendantes » sans définir ce que voulait dire ce terme. Notre
précise que cela veut dire qu'elles ont été écrites
par des personnes différentes, dans des organisations différentes
et qu'elles n'aient pas de code
en commun (il est fréquent que plusieurs logiciels dérivent de la même
souche et n'aient donc guère de mérite à interopérer
correctement).
La section 3 décrit le format du rapport d'interopérabilité. C'est
le même que celui des RFC. La
section indique aussi les parties obligatoires et leur contenu. Un
résumé doit préciser les points importants. La méthodologie de test
doit être décrite. Les éventuelles exceptions (points de la norme sur
lesquels l'interopérabilité échoue) doivent être précisement
listées.
Un point délicat des rapports d'interopérabilité est la question
des fonctions qu'on teste. Faut-il tout tester dans le moindre détail
ou bien a t-on le droit d'omettre des fonctions qui sont dans la
norme ? La section 4 analyse la question. En gros, si on teste
seulement des grandes fonctions, on ne pousse pas les implémentations
dans leurs limites mais si on teste tous les détails et leurs combinaisons, la matrice des
tests explose, notamment pour les protocoles ayant beaucoup
d'options. Il faut donc trouver un niveau intermédiaire
raisonnable. Le RFC cite en exemple le rapport
sur RTP qui liste les fonctions testées sous forme de services
importants, et non pas sous la forme, trop détaillée, de chaque bit
possible de l'en-tête.
Le pragmatisme reste nécessaire. La section 5 explique comment
gérer des cas particuliers. Par exemple, si le protocole est déjà
largement déployé, on peut (section 5.1) privilégier l'analyse de son
fonctionnement réel plutôt que des tests en laboratoire. Une étude ou
un questionnaire sont donc sans doute la meilleure méthode. Par
contre, si le protocole n'a pas encore connu de déploiement
significatif (section 5.2), les tests sont la meilleure approche. Le RFC insiste
quand même sur le fait qu'il faut essayer d'anticiper les problèmes
opérationnels comme la congestion ou la
gestion.
Un autre cas particulier est celui des RFC qui normalisent des
formats et pas des protocoles, traité dans la section 5.3. Par
exemple, le normalise les grammairesABNF et le le
format de syndicationAtom. L'interopérabilité, dans ce cas, se juge notamment
à la capacité des différentes implémentations à considérer comme
corrects les mêmes fichiers (et même chose pour les incorrects). ABNF
a ainsi fait l'objet d'un rapport
de mise en œuvre.
Parmi les autres cas couverts par notre RFC, celui des protocoles
pour lesquels il existe une suite de
tests comme WebDAV, avec Litmus. Cette suite ne
permet pas forcément de tester l'interopérabilité (section 5.5) car
elle ne teste pas des vraies mises en œuvre les unes contre les
autres. Avec Litmus, par exemple, le client WebDAV est un client
artificiel, qui n'est pas forcément représentatif des vrais clients.
Tous les rapports de mise en œuvre existants sont disponibles
en ligne. La section 6 de notre cite quelques
exemples particulièrement instructifs comme le rapport
sur PPP-LCP pour sa concision ou celui
sur OSPF (publié également dans le ), jugé
trop long mais quand même de qualité. Celui sur
le « pipelining » SMTP est jugé très court, à la limite de la
taille minimale.