In computer science, augmented BackusâÂÂNaur form (ABNF) is a metalanguage based on BackusâÂÂNaur form (BNF) but consisting of its own syntax and derivation rules. The motivation for ABNF is to define an easily usable tool for defining the format of communications protocol payload objects and protocol units. It is defined by Internet Standard 68 ("STD 68", type case sic), which was , and it often serves as the definition language for IETF communication protocols.
supersedes . updates it, adding a syntax for specifying case-sensitive string literals.
An ABNF specification is a set of derivation rules, written as
where rule is a case-insensitive nonterminal, the definition consists of sequences of symbols that define the rule, a comment for documentation, and ending with a carriage return and line feed.
Rule names are case-insensitive: <code><rulename></code>, <code><Rulename></code>, <code><RULENAME></code>, and <code><rUlENamE></code> all refer to the same rule. Rule names consist of a letter followed by letters, numbers, and hyphens.
Angle brackets (<code><</code>, <code>></code>) are not required around rule names (as they are in BNF). However, they may be used to delimit a rule name when used in prose to discern a rule name.
Terminal symbols are the basic building blocks in ABNF. The nonterminal symbols are built on top of them. They specify a sequence of characters that are literally matched. (Technically the actual terminal symbol in ABNF is the individual character [which to ABNF is no more than a non-negative integer], but for ease of writing the syntax has been extended to allow matching sequences of characters.)
Terminal values may be specified numerically, in which case it corresponds to a character code or a sequence of codes. Such a value is specified as the percent sign <code>%</code>, followed by the base (<code>b</code> = binary, <code>d</code> = decimal, and <code>x</code> = hexadecimal), followed by the value, or concatenation of values (indicated by <code>.</code>). For example, a carriage return is specified by <code>%d13</code> in decimal or <code>%x0D</code> in hexadecimal. A carriage return followed by a line feed may be specified with concatenation as <code>%d13.10</code>.
Literal text is specified through the use of a string enclosed in quotation marks (<code>"</code>). These strings are case-insensitive, and the character set used is (US-)ASCII. Therefore, the string <code>"abc"</code> will match "abc", "Abc", "aBc", "abC", "ABc", "AbC", "aBC", and "ABC". RFC 7405 added a syntax for case-sensitive strings: <code>%s"aBc"</code> will only match "aBc". Prior to that, a case-sensitive string could only be specified by listing the individual characters: to match "aBc", the definition would be <code>%d97.66.99</code>. A string can also be explicitly specified as case-insensitive with a <code>%i</code> prefix.
A further type of building-block value is the "prose-val", a bracketed string describing what a rule is meant to match in natural language prose. This is only to be used as a last resort as ABNF grammar that use such a construct cannot be automatically implemented by a computer program.
White space is used to separate elements of a definition; for space to be recognized as a delimiter, it must be explicitly included. The explicit reference for a single whitespace character is <code>WSP</code> (linear white space), and <code>LWSP</code> is for zero or more whitespace characters with newlines permitted.
Definitions are left-aligned. When multiple lines are required (for readability), continuation lines are indented by whitespace.
<code>; comment</code>
A semicolon (<code>;</code>) starts a comment that continues to the end of the line.
<code>Rule1 Rule2</code>
A rule may be defined by listing a sequence of rule names.
To match the string âÂÂabaâÂÂ, the following rules could be used:
<code>Rule1 / Rule2</code>
A rule may be defined by a list of alternative rules separated by a solidus (<code>/</code>).
To accept the rule fu or the rule bar, the following rule could be constructed:
<code>Rule1 =/ Rule2</code>
Additional alternatives may be added to a rule through the use of <code>=/</code> between the rule name and the definition.
The rule
is therefore equivalent to
<code>%c##-##</code>
A range of numeric values may be specified through the use of a hyphen (<code>-</code>).
The rule
is equivalent to
<code>(Rule1 Rule2)</code>
Elements may be placed in parentheses to group rules in a definition.
To match "a b d" or "a c d", the following rule could be constructed:
To match âÂÂa bâ or âÂÂc dâÂÂ, the following rules could be constructed:
<code>n*nRule</code>
To indicate repetition of an element, the form <code><a>*<b>element</code> is used. The optional <code><a></code> gives the minimal number of elements to be included (with the default of 0). The optional <code><b></code> gives the maximal number of elements to be included (with the default of infinity).
Use <code>*element</code> for zero or more elements, <code>*1element</code> for zero or one element, <code>1*element</code> for one or more elements, and <code>2*3element</code> for two or three elements, cf. regular expressions <code>e*</code>, <code>e?</code>, <code>e+</code> and <code>e{2,3}</code>.
<code>nRule</code>
To indicate an explicit number of elements, the form <code><a>element</code> is used and is equivalent to <code><a>*<a>element</code>.
Use <code>2DIGIT</code> to get two numeric digits, and <code>3DIGIT</code> to get three numeric digits. (<code>DIGIT</code> is defined below under "Core rules". Also see zip-code in the example below.)
<code>[Rule]</code>
To indicate an optional element, the following constructions are equivalent:
The following operators have the given precedence from tightest binding to loosest binding:
Use of the alternative operator with concatenation may be confusing, and it is recommended that grouping be used to make explicit concatenation groups.
The core rules are defined in the ABNF standard. They provide definitions for commonly-used constructs. The exact content of the core rules depends on the code page in use, but for the Internet's common baseline of 7-bit ASCII (or a superset of it), it is defined as:
The ABNF language originated in , the 1977 standard for ARPA NETWORK TEXT MESSAGES, an early form of email. It defined the "linear-white-space" as a deliminator in mail headers:
The ABNF language was described independently of email in of 1997. It included the "LWSP" rule in the modern form, which does not have the <code>1</code> part specifying the minimum repetition. This is quite unusual because logically speaking, at least one whitespace character is needed to form a delimiter between two fields. This difference was noticed in RFC Erratum 3096 of 2012 (filed for RFC 5234, which inherited this construct), but by then it was too late to change the definition as other standards had already used the <code>LWSP</code> rule for their own purposes.
of 2008 adds a warning in conjunction to the definition of LWSP as follows, referring to its departure from email standards:
The contemporary email standard, of 2008, does not use such a term as "linear white space", nor does it use the predefined LWSP value. In its place it uses folding whitespace (FWS):
The (U.S.) postal address example given in the augmented BackusâÂÂNaur form (ABNF) page may be specified as follows:
ABNF's syntax itself may be represented with a ABNF like the following: