Ce document est une traduction du document RFC 5234 de l'IETF (Internet Engineering Task Force) ; il peut comporter des erreurs ou en introduire de nouvelles. Seul fait référence l'original disponible à ftp://ftp.rfc-editor.org/in-notes/rfc5234.txt.
La traduction est proposée sous licence Creative Commons.
Date de publication : 5 août 2008.

RFC 5234

Network Working Group                                    D. Crocker, Ed.
Document RFC : 5234 (errata)                 Brandenburg InternetWorking
STD          : 68                                             P. Overell
Remplace     : 4234                                            THUS plc.
Categorie    : Standards Track                              Janvier 2008

Forme BNF augmentée pour les spécifications de syntaxes : ABNF

Statut de ce mémoire

Ce document définit un protocole du circuit des standards Internet de la communauté Internet, et il appelle le débat et des suggestions d'amélioration. Veuillez consulter l'édition courante du document Internet Official Protocol Standards (STD 1) pour l'état de standardisation et le statut de ce protocole. La distribution de ce mémoire est libre.

Résumé

Souvent les spécifications techniques Internet définissent une syntaxe formelle. Au cours du temps, l'utilisation d'une version modifiée de la forme de Backus-Naur (BNF), dite forme BNF augmentée (ABNF), a eu la faveur de beaucoup de spécifications Internet. La présente spécification documente la forme ABNF. Elle constitue un compromis entre compacité et simplicité avec une capacité de représentation raisonnable. Les différences entre la forme BNF standard et la forme ABNF concernent les règles de nommage, la répétition, les alternatives (alternatives), l'indépendance d'ordre (order-independence) et les gammes de valeurs (value ranges). Cette spécification fournit également des définitions de règle et un codage supplémentaires pour un analyseur lexical de base (core lexical analyzer) du type commun de plusieurs spécifications Internet.

Table des matières

  1. 1. Introduction
  2. 2. Définition de règle
    1. 2.1. Nommage des règles
    2. 2.2. Forme des règles
    3. 2.3. Valeurs terminales
    4. 2.4. Codages externes
  3. 3. Opérateurs
    1. 3.1. Concaténation : Règle1 Règle2
    2. 3.2. Alternatives : Règle1 / Règle2
    3. 3.3. Alternatives incrémentales : Règle1 =/ Règle2
    4. 3.4. Alternatives de gammes de valeurs : %c##-##
    5. 3.5. Groupe de séquences : (Règle1 Règle2)
    6. 3.6. Répétition de variable : *Règle
    7. 3.7. Répétition spécifique : nRègle
    8. 3.8. Séquence optionnelle : [RÈGLE]
    9. 3.9. Commentaire : ; Commentaire
    10. 3.10. Priorité des opérateurs
  4. 4. Définition ABNF de ABNF
  5. 5. Observations sur la sécurité
  6. 6. Références
    1. 6.1. Références normatives
    2. 6.2. Références informatives
  7. Annexe A. Remerciements
  8. Annexe B. Noyau ABNF de ABNF
    1. B.1. Règles de base
    2. B.2. Codage commun

1. Introduction

Les spécifications techniques Internet ont souvent besoin de définir une syntaxe formelle et sont libres d'employer la notation jugée utile par leurs auteurs. Au cours du temps, une version modifiée de la forme de Backus-Naur (BNF), dite forme BNF augmentée (ABNF), a eu la faveur de nombreuses spécifications Internet. Elle constitue un compromis entre la compacité et la simplicité avec une puissance de représentation raisonnable. Au début de l'Arpanet, chaque spécification incluait sa propre définition de forme ABNF. En faisaient partie les spécifications de courrier électronique, [RFC733] puis [RFC822], qui devinrent les références communes pour définir ABNF. Le présent document distingue ces définitions afin de permettre une référence sélective. De façon prévisible, il présente également quelques modifications et améliorations.

Les différences entre la forme BNF standard et ABNF concernent les règles de nommage, la répétition, les alternatives, l'indépendance d'ordre et les gammes de valeurs. L'annexe B donne les définitions de règle et le codage d'un analyseur lexical de base du type commun de plusieurs spécifications Internet. Il est fourni à titre de commodité et par ailleurs distinct du métalangage défini dans le corps de ce document, et à part de son statut formel.

2. Définition de règle

2.1. Nommage des règles

Le nom d'une règle est simplement le nom même, c'est-à-dire une séquence de caractères commençant par un caractère alphabétique, suivi d'une combinaison de caractères alphabétiques, chiffres et traits-d'union.

Remarque :

Les noms de règle sont insensibles à la casse.

Les noms <rulename>, <Rulename>, <RULENAME> et <rUlENamE> désignent tous la même règle.

À la différence de la forme BNF originale, les caractères chevrons (« < », « > ») ne sont pas obligatoires. On peut toutefois placer des chevrons autour d'un nom de règle dès lors que leur présence aide à identifier l'utilisation d'un nom de règle. On le réserve typiquement aux références de noms de règle dans le texte, ou pour distinguer des règles partielles qui se combinent en une chaîne non séparée par des caractères blancs (whitespace), comme dans l'explication à propos de la répétition ci-dessous.

2.2. Forme des règles

Une règle est définie par la séquence suivante :

         name =  elements crlf

où <name> est le nom de la règle, <elements> représente un ou plusieurs noms de règles ou spécifications de terminaux, et <crlf> est l'indicateur de fin de ligne (retour chariot suivi d'un saut de ligne). Le SIGNE ÉGAL sépare le nom de la définition de la règle. Les éléments forment une séquence d'un ou plusieurs noms de règle ou définitions de valeurs, combinés par les divers opérateurs définis dans ce document, tels que l'alternative et la répétition.

Pour la lisibilité, les définitions de règle sont justifiées à gauche (left aligned). Lorsqu'une règle nécessite plusieurs lignes, les lignes de continuation sont indentées. La justification à gauche et l'indentation sont relatives aux premières lignes des règles ABNF et ne correspondent pas forcément à la marge gauche du document.

2.3. Valeurs terminales

Les règles se résolvent en une chaîne de valeurs terminales, appelées parfois des caractères. Dans la forme ABNF, un caractère est simplement un entier non négatif. Dans certains contextes, on indiquera une conversion spécifique (codage) des valeurs vers un jeu de caractères (tel que ASCII).

Les terminaux sont représentés par un ou plusieurs caractères numériques, en indiquant explicitement l'interprétation de base de ces caractères. Voici les bases actuellement définies :

         b           =  binary

         d           =  decimal

         x           =  hexadecimal

Ainsi :

         CR          =  %d13

         CR          =  %x0D

spécifie respectivement la représentation décimale et hexadécimale [US-ASCII] du retour chariot.

On spécifie une chaîne concaténée de telles valeurs de façon compacte en utilisant un POINT (« . ») pour indiquer une séparation des caractères dans cette valeur. Ainsi :

         CRLF        =  %d13.10

La forme ABNF permet de spécifier directement les chaînes textuelles littérales entre des guillemets. Par exemple :

         command     =  "command string"

Les chaînes textuelles littérales sont interprétées comme un ensemble de caractères imprimables (printable characters) concaténés.

Remarque :

Les chaînes ABNF sont insensibles à la casse et ont le jeu de caractères US-ASCII.

Ainsi :

         rulename = "abc"

et :

         rulename = "aBc"

correspondront à "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC" et "ABC".

Pour définir une règle qui soit sensible à la casse, spécifiez les caractères individuellement. Par exemple :

         rulename    =  %d97 %d98 %d99

ou :


         rulename    =  %d97.98.99

équivaudront seulement à la chaîne comprenant les caractères "abc" en minuscules.

2.4. Codages externes

Les représentations externes des caractères des valeurs terminales varieront selon les contraintes de l'environnement de stockage ou de transmission. De fait, la même grammaire fondée sur ABNF peut avoir plusieurs codages externes, ainsi un codage pour un environnement US-ASCII 7-bit, un autre pour un environnement d'octets binaires et encore un différent pour de l'Unicode 16-bit. Les détails du codage sortent du cadre de la forme ABNF, même si l'annexe B fournit des définitions pour un environnement US-ASCII 7-bit comme étant commun à tout l'internet.

En séparant le codage externe de la syntaxe, on prévoit la possibilité d'utiliser d'autres environnements de codage pour la même syntaxe.

3. Opérateurs

3.1. Concaténation : Règle1 Règle2

Une règle peut définir une chaîne de valeurs ordonnée simple (c'est-à-dire une concaténation de caractères contigus) en listant une séquence de noms de règle. Par exemple :

         foo         =  %x61           ; a

         bar         =  %x62           ; b

         mumble      =  foo bar foo

De sorte que la règle <mumble> filtre la chaîne "aba" en lettres minuscules.

Caractères blancs linéaires (linear white space) —  La concaténation est centrale au modèle d'analyse ABNF. Une chaîne de caractères contigus (valeurs) est analysée conformément aux règles définies en ABNF. Pour les spécifications Internet, il existe une tradition qui autorise d'intercaler librement et implicitement des caractères blancs linéaires (espace et tabulation horizontale) autour de structures majeures, tel que la délimitation de caractères spéciaux ou de chaînes atomiques.

Remarque :

Cette spécification de la forme ABNF ne pourvoit pas à la spécification implicite de caractères blancs linéaires.

Toute grammaire qui souhaite autoriser des caractères blancs linéaires autour de délimiteurs ou de segments de chaînes doit le spécifier explicitement. Il est souvent pratique de subvenir à de tels caractères blancs dans des règles « de base » ("core" rules) utilisées ensuite de diverses façons dans des règles de niveau supérieur. Les règles « de base » pourraient être formées au sein d'un analyseur lexical ou simplement faire partie de l'ensemble de règles principal (main ruleset).

3.2. Alternatives : Règle1 / Règle2

Les éléments séparés par une BARRE OBLIQUE « / » sont des alternatives. Ainsi :

         foo / bar

acceptera <foo> ou <bar>.

Remarque :

Une chaîne entre guillemets contenant des caractères alphabétiques est une forme spéciale pour indiquer des caractères alternatifs, et elle est interprétée comme un non-terminal représentant l'ensemble des chaînes combinées avec les caractères contenus, dans l'ordre indiqué mais dans n'importe quelle combinaison de lettres majuscules et minuscules.

3.3. Alternatives incrémentales : Règle1 =/ Règle2

Il est parfois commode de spécifier une liste d'alternatives dans des fragments. À savoir, qu'une règle initiale puisse filtrer une ou plusieurs alternatives, avec des définitions de règle ultérieures s'ajoutant à l'ensemble d'alternatives. Cela est particulièrement utile pour les spécifications sinon indépendantes qui dérivent du même ensemble de règles parent, comme cela se produit souvent avec les listes de paramètres. La forme ABNF permet une telle définition incrémentale au travers de la structure suivante :

         oldrule     =/ additional-alternatives

Ainsi, l'ensemble de règles :

         ruleset     =  alt1 / alt2

         ruleset     =/ alt3

         ruleset     =/ alt4 / alt5

équivaut à définir :

         ruleset     =  alt1 / alt2 / alt3 / alt4 / alt5

3.4. Gammes de valeurs alternatives : %c##-##

On peut définir une gamme de valeurs numériques alternatives de manière concise en utilisant un TRAIT-D'UNION (« - ») pour indiquer la gamme des valeurs alternatives. Ainsi :

         DIGIT       =  %x30-39

équivaut à :

         DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" /

                        "7" / "8" / "9"

On ne peut pas spécifier des valeurs numériques concaténées et des gammes de valeurs numériques dans la même chaîne. Une valeur numérique peut employer la notation à point (dotted notation) pour la concaténation ou employer la notation à trait (dash notation) pour indiquer une seule gamme de valeurs. Par conséquent, afin d'indiquer un caractère imprimable entre des séquences de fin de ligne, on spécifierait :

         char-line = %x0D.0A %x20-7E %x0D.0A

3.5. Groupe de séquences : (Règle1 Règle2)

Les éléments entre parenthèses sont traités comme un seul élément, dont le contenu est strictement ordonné. Ainsi :

         elem (foo / bar) blat

filtre (elem foo blat) ou (elem bar blat), et :

         elem foo / bar blat

filtre (elem foo) ou (bar blat).

Remarque :

Il est fortement recommandé d'utiliser une notation de groupe plutôt que de compter sur la bonne lecture des choix « nus », lorsque les alternatives se composent de noms de règles ou littéraux multiples.

L'utilisation de la forme suivante est donc recommandée :

        (elem foo) / (bar blat)

Elle évitera aux lecteurs occasionnels une interprétation erronée.

La notation de groupe de séquences sert également dans du texte libre (free text) pour mettre en valeur une séquence d'éléments dans le texte.

3.6. Répétition de variable : *Règle

L'opérateur "*" précédent un élément indique une répétition. La forme complète est la suivante :

         <a>*<b>element

où <a> et <b> sont des valeurs décimales optionnelles, indiquant au moins <a> et au plus <b> apparitions de l'élément.

Les valeurs par défaut sont 0 et l'infini, de sorte que *<element> admet un nombre quelconque y compris zéro ; 1*<element> exige au moins un ; 3*3<element> admet 3 exactement ; et 1*2<element> admet un ou deux.

3.7. Répétition spécifique : nRègle

Une règle de la forme :

         <n>element

équivaut à :

         <n>*<n>element

C'est-à-dire exactement <n> apparitions de <element>. Ainsi, 2DIGIT est un nombre de deux chiffres, et 3ALPHA est une chaîne de trois caractères alphabétiques.

3.8. Séquence optionnelle : [RÈGLE]

Une séquence d'éléments optionnels est entourée par des crochets :

         [foo bar]

équivaut à :

         *1(foo bar).

3.9. Commentaire : ; Commentaire

Un POINT-VIRGULE marque le début d'un commentaire, qui se poursuit jusqu'à la fin de la ligne. C'est une méthode simple pour inclure des notes utiles parallèlement aux spécifications.

3.10. Priorité des opérateurs

Les divers mécanismes décrits précédemment ont la priorité suivante, en haut la plus élevée (liaison la plus étroite) et en bas la plus faible (la plus lâche) :

  1. 1. Nom de règle, valeur de prose (prose-val), valeur terminale ;
  2. 2. Commentaire ;
  3. 3. Gamme de valeurs ;
  4. 4. Répétition ;
  5. 5. Regroupement, optionnel ;
  6. 6. Concaténation ;
  7. 7. Alternative

L'emploi de l'opérateur alternatif, mélangé librement à des concaténations, peut être ambigu.

À nouveau, il est recommandé d'utiliser l'opérateur de regroupement pour rendre explicites les groupes de concaténations.

4. Définition ABNF de ABNF

Remarques :
  1. 1. Cette syntaxe impose un formatage des règles relativement strict. De fait, la version d'un ensemble de règles incluse dans une spécification nécessitera peut-être un prétraitement pour s'assurer qu'elle est interprétable par un analyseur ABNF ;
  2. 2. Cette syntaxe utilise les règles fournies en annexe B.
         rulelist       =  1*( rule / (*c-wsp c-nl) )

         rule           =  rulename defined-as elements c-nl
                                ; continue si la ligne suivante commence
                                ;  par un caractère blanc

         rulename       =  ALPHA *(ALPHA / DIGIT / "-")

         defined-as     =  *c-wsp ("=" / "=/") *c-wsp
                                ; définitions de règles élémentaires
                                ;  et alternatives incrémentales

         elements       =  alternation *c-wsp

         c-wsp          =  WSP / (c-nl WSP)

         c-nl           =  comment / CRLF
                                ; commentaire ou saut de ligne

         comment        =  ";" *(WSP / VCHAR) CRLF

         alternation    =  concatenation
                           *(*c-wsp "/" *c-wsp concatenation)

         concatenation  =  repetition *(1*c-wsp repetition)

         repetition     =  [repeat] element

         repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)

         element        =  rulename / group / option /
                           char-val / num-val / prose-val

         group          =  "(" *c-wsp alternation *c-wsp ")"

         option         =  "[" *c-wsp alternation *c-wsp "]"

         char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                                ; chaîne entre guillemets de SP et VCHAR
                                ;  sans DQUOTE

         num-val        =  "%" (bin-val / dec-val / hex-val)

         bin-val        =  "b" 1*BIT
                           [ 1*("." 1*BIT) / ("-" 1*BIT) ]
                                ; série de valeurs de bit concaténées
                                ;  ou une seule gamme ONEOF

         dec-val        =  "d" 1*DIGIT
                           [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]

         hex-val        =  "x" 1*HEXDIG
                           [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]

         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                                ; chaîne de SP et VCHAR entre parenthèses
                                ;  sans chevrons
                                ; description en prose à utiliser
                                ;  en dernier ressort

5. Observations sur la sécurité

La question de la sécurité est de fait estimée caduque concernant ce document.

6. Références

6.1. Références normatives

[US-ASCII]
American National Standards Institute, Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4, 1986.

6.2. Références informatives

[RFC733]
Crocker, D., Vittal, J., Pogran, K., and D. Henderson, Standard for the format of ARPA network text messages, RFC 733, November 1977.
[RFC822]
Crocker, D., Standard for the format of ARPA Internet text messages, STD 11, RFC 822, August 1982.

Annexe A. Remerciements

La syntaxe de la forme ABNF fut définie à l'origine dans le RFC 733. Ken L. Harrenstien, chez SRI International, fut chargé de recoder la forme BNF dans une forme BNF augmentée qui rend la représentation plus concise et plus facile à comprendre.

Ce projet récent commença comme un simple effort pour extraire la partie du RFC 822 citée à plusieurs reprises par les auteurs de spécifications sans rapport avec le courrier électronique (non-email specification), à savoir la description de la forme BNF augmentée. Plutôt que convertir simplement et aveuglément le texte existant en un document séparé, le groupe de travail choisit d'examiner soigneusement les faiblesses ainsi que les avantages de la spécification existante et des spécifications liées mises à disposition pendant les quinze dernières années, et donc de poursuivre les améliorations. Cela orienta le projet vers quelque chose de plus ambitieux que ce qui était prévu au départ. De manière intéressante, le résultat n'est pas énormément différent de l'original, bien que certaines décisions telles que supprimer la notation de liste furent inattendues.

Cette version « séparée » de la spécification fut produite sous l'égide du groupe de travail DRUMS, avec les contributions remarquables de Jerome Abela, Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete Resnick et Henning Schulzrinne.

Julian Reschke mérite des remerciements particuliers pour sa conversion de la version préliminaire du standard vers la forme source XML.

Annexe B. Noyau ABNF de ABNF

Cette annexe contient quelques règles de base d'utilisation courante. Les règles de base sont en lettres majuscules. Notez que ces règles ne sont valides que pour du ABNF codé en ASCII 7-bit, ou dans des jeux de caractères qui sont des surensembles du jeu ASCII 7-bit.

B.1. Règles de base

Les règles de base sont en lettres majuscules, telles que SP, HTAB, CRLF, DIGIT, ALPHA, etc.

         ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z

         BIT            =  "0" / "1"

         CHAR           =  %x01-7F
                                ; tout caractères US-ASCII 7-bit,
                                ;  sauf NUL

         CR             =  %x0D
                                ; retour chariot

         CRLF           =  CR LF
                                ; saut de ligne standard Internet

         CTL            =  %x00-1F / %x7F
                                ; caractères de contrôle

         DIGIT          =  %x30-39
                                ; 0-9

         DQUOTE         =  %x22
                                ; " (guillemet double)

         HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

         HTAB           =  %x09
                                ; tabulation horizontale

         LF             =  %x0A
                                ; saut de ligne (linefeed)

         LWSP           =  *(WSP / CRLF WSP)
                                ; L'utilisation de cette règle des
                                ;  caractères blancs linéaires
                                ;  (linear-white-space)
                                ;  autorise des lignes contenant seulement
                                ;  des caractères blancs qui ne sont plus
                                ;  légaux dans les en-têtes de
                                ;  courrier électronique et ont causé
                                ;  des problèmes d'interopérabilité dans
                                ;  d'autres contextes.
                                ; Ne pas utiliser pour définir des en-têtes
                                ;  de courrier électronique et utiliser
                                ;  avec précaution dans d'autres contextes.

         OCTET          =  %x00-FF
                                ; 8 bits de données

         SP             =  %x20

         VCHAR          =  %x21-7E
                                ; caractères visibles (imprimables)

         WSP            =  SP / HTAB
                                ; caractères blancs (white space)

B.2. Codage commun

Du dehors, les données sont représentées en tant que « ASCII virtuel de réseau » (à savoir de l'US-ASCII 7-bit dans un champs 8-bit), avec le bit supérieur (le 8ème) mis à zéro. Une chaîne de valeurs est en « ordre d'octet de réseau » (network byte order), dans lequel les octets de valeur supérieure (higher-valued bytes) sont représentés à main gauche (on the left-hand side) et sont envoyés en premier sur le réseau.

Coordonnées des auteurs

Dave Crocker (editor)
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086
US

Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Paul Overell
THUS plc.
1/2 Berkeley Square,
99 Berkeley Street
Glasgow G3 7HR
UK

EMail: paul.overell@thus.net