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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
Les éléments séparés par une BARRE OBLIQUE « / » sont des alternatives. Ainsi :
foo / bar
acceptera <foo> ou <bar>.
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.
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
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
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).
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.
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.
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.
Une séquence d'éléments optionnels est entourée par des crochets :
[foo bar]
équivaut à :
*1(foo bar).
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.
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) :
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.
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
La question de la sécurité est de fait estimée caduque concernant ce document.
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.
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.
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)
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.
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.