Résumé

  • RFC 2234 a donné à l’ABNF un document autonome, alors que les spécifications Internet en reproduisaient auparavant leur définition.
  • Un langage grammatical commun facilite les références et la composition des règles ; il ne prouve pas que les logiciels interprètent chaque protocole de la même façon.

Une spécification pouvait décrire la syntaxe des messages d’un protocole et expliquer en même temps la notation employée. Cette répétition avait une histoire : RFC 2234 rappelle que, aux débuts de l’ARPANET, chaque spécification contenait sa propre définition de l’ABNF. Les documents de messagerie RFC 733, puis RFC 822, étaient devenus des références courantes. Mais une définition générale, nichée dans le texte d’un protocole particulier, n’était pas l’endroit le plus pratique où chercher le langage grammatical lui-même.

Publié en novembre 1997, RFC 2234 a séparé cette définition afin que d’autres spécifications puissent la citer au besoin. L’enjeu n’était pas d’adopter un analyseur unique pour tout Internet. Il s’agissait plutôt de fournir une référence partagée pour les noms de règles, les terminaux, les répétitions, les alternatives, les plages numériques et les groupes. La grammaire décrit des chaînes acceptables ; elle ne constitue pas une preuve de ce qu’un logiciel déployé accepte réellement.

Cette limite compte parce que plusieurs couches peuvent se ressembler sans se confondre. L’ABNF décrit une syntaxe. Le document de protocole choisit les règles qui définissent ses messages. L’environnement de transmission détermine l’encodage des valeurs terminales. Enfin, un analyseur met en œuvre ces choix. RFC 2234 précise qu’une même grammaire peut correspondre à plusieurs encodages externes et laisse ces encodages hors du périmètre de l’ABNF. La notation pouvait donc être réutilisée entre protocoles sans régler, à elle seule, toutes les questions des octets transmis.

La grammaire pouvait aussi être assemblée par fragments. L’opérateur =/ ajoute des alternatives à une règle définie ailleurs ; RFC 2234 indique que cela peut être utile à des spécifications indépendantes issues d’un jeu de règles parent commun. C’est une facilité de composition documentaire, pas une instruction demandant aux analyseurs de découvrir automatiquement des extensions. Les auteurs doivent encore préciser quels documents composent la règle et dans quel périmètre elle s’applique.

Voilà une forme modeste de coordination Internet : normaliser le vocabulaire qui sert à écrire des règles, distinguer les règles propres à chaque protocole et rendre visibles les choix d’encodage. RFC 2234 n’a pas fait disparaître les désaccords en leur donnant un nom ; il a rendu une couche de ces désaccords plus facile à désigner. La suite — RFC 4234, puis RFC 5234 — rappelle aussi que ce langage commun reste révisable. RFC 7405 a ensuite traité la syntaxe liée à UTF-8 ; il ne faut pas projeter ces évolutions sur le texte de 1997.

Cette histoire ne raconte donc pas le remplacement de la prose par les mathématiques. La prose explique encore le but et le contexte d’un protocole ; la grammaire donne une description compacte de sa forme. Le geste utile fut de placer la définition de la grammaire ailleurs que dans chaque protocole qui l’emploie. La réutilisation devenait citable, tandis que toute affirmation sur les implémentations restait à prouver par des éléments portant sur ces implémentations.

Sources : RFC 2234 ; fiche Datatracker RFC 2234 ; historique Datatracker RFC 2234 ; fiche RFC Editor RFC 2234 ; RFC 733 ; RFC 822 ; RFC 4234 ; fiche RFC Editor RFC 4234 ; RFC 5234 ; fiche RFC Editor RFC 5234 ; RFC 7405 ; RFC 2119 ; note sur la primauté du code en fonctionnement ; note sur la spécification initiale minimale ; note sur les couches de réalité.