Mon blog

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 RFC 2026 (cf. section 1 de notre RFC 5657). 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 RFC 6410. Lors du passage de la première à la deuxième étape, pour devenir projet de norme, un RFC doit (section 4.1.2 du RFC 2026) 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 RFC 2026) 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 RFC 5657 est de limiter cette variation. Il met donc à jour légèrement le RFC 2026. Lui-même a été amendé par le RFC 6410, 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 RFC 2026. 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 RFC 2026 parlait d'implémentations « indépendantes » sans définir ce que voulait dire ce terme. Notre RFC 5657 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 RFC 5234 normalise les grammaires ABNF et le RFC 4287 le format de syndication Atom. 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 RFC 5657 cite quelques exemples particulièrement instructifs comme le rapport sur PPP-LCP pour sa concision ou celui sur OSPF (publié également dans le RFC 2329), 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.