Mon blog

Contrairement à d'autres SDO, l'IETF utilise relativement peu de langages formels dans ses normes. Beaucoup de protocoles réseaux sont normalisés uniquement en langage naturel. Malgré les efforts des chercheurs qui ont développé de nombreux langages de spécification comme Lotos ou le désormais abandoné Estelle, malgré l'exemple de SDO qui dépendent de langages comme SDL/Z100, l'IETF reste fidèle aux langues humaines. Parfois, un langage formel est quand même utilisé pour une partie d'une norme. Souhaitons donc la bienvenue à RBNF (Routing Backus-Naur Form), nouveau venu dans cette famille.

Les langages formels n'étaient pas du tout utilisés au début des RFC. Petit à petit, certains sont arrivés comme ROHC-FN (RFC 4997) mais ils sont loin d'avoir pénétré partout. L'IETF n'a ainsi toujours pas de langage formel standard pour les machines à états, ni pour le format des paquets, toujours spécifiés par de l'art ASCII. Il y a plusieurs raisons à cet état de fait, l'une étant que les langages formels existants sont souvent de grosses usines à gaz assez irréalistes (l'apprentissage du langage devient une contrainte et plus une aide) et n'ont souvent même pas une seule mise en œuvre en logiciel libre.

Mais un des grands succès IETF en matière de langage formel est un langage pour écrire des grammaires, ABNF (RFC 5234). Il est utilisé pour de très nombreux RFC. Comme souvent à l'IETF, son utilisation n'est toutefois pas obligatoire et on peut constater que plusieurs RFC dans le domaine du routage ont choisi une autre forme de BNF, qui n'était pas normalisée jusque là. C'est ainsi que (section 1.2) les RFC 2205, RFC 3473, RFC 4204, RFC 5440 et bien d'autres utilisent un dialecte désormais nommé RBNF pour Routing Backus-Naur Form. Ce dialecte vient d'être normalisé dans notre RFC 5511. Son usage est conseillé pour des RFC reprenant et étendant les techniques décrites dans les RFC cités plus haut. Mais, pour des projets complètement nouveaux, il est plutôt conseillé de regarder ABNF (section 1.3).

La définition complète du langage figure en section 2. Il est plus proche de la BNF classique qu'ABNF ; par exemple, la définition d'une règle utilise ::= et pas = comme en ABNF (section 2.2.1). Les noms des règles sont systématiquement entre chevrons (section 2.1.1), par exemple (tous les exemples sont tirés du RFC 5440) <request-list> ou bien <Keepalive Message>. Les définitions terminales sont typiquement écrites en majuscules et sans espaces (section 2.1.2) comme <BANDWIDTH> ou <NO-PATH>. Les règles peuvent être combinées par des opérateurs par exemple la concaténation (section 2.2.2) notée simplement en mettant les noms des règles à la queue-leu-leu ou bien le choix (section 2.2.4) noté |. La répétition peut se faire par récursion par exemple <request-list> ::= <request> [<request-list>] (section 2.2.5).

Avec uniquement ces opérateurs, il pourrait y avoir un risque de confusion avec des règles comme celle, hypothétique, <truc> ::= <machin> | <chose> <bidule>. Est-ce que <machin> seul est légal ? Tout dépend de la précédence entre le choix et la concaténation. Les règles exactes de précédences sont normalisées dans la section 2.4 mais tous les lecteurs ne les connaissent pas forcément sur le bout des doigts et il est donc demandé de groupe explicitement les règles avec des parenthèses (section 2.2.6). La concaténation lie plus fortement que l'alternative et, donc, la bonne interprétation de la règle ci-dessus est <truc> ::= <machin> | (<chose> <bidule>).

Selon la section 3, consacrée à la validation automatique des grammaires, il n'y a malheureusement pas encore d'outil automatique pour RBNF comme il en existe pour ABNF. Un jour où j'aurai le temps, je modifierai Eustathius pour cela...