rfc-4234

Augmented BNF for Syntax Specifications: ABNF

D. Crocker (Editor), P. Overell
date2005-10 streamIETF wgnon working group statusDRAFT STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc4234 doi10.17487/RFC4234 errataview
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

obsoleted by

obsoletes

Extracted elements (27)

design-rationale §3.1

ABNF does not provide for implicit specification of linear white space in concatenation, unlike historical Internet specifications that allowed it freely around delimiters. Grammars requiring such white space must specify it explicitly, typically in 'core' rules used across higher-level rules.

design-rationale §1

ABNF was extracted from RFC 822 to allow selective reference by non-email specifications. The design balances compactness and simplicity with reasonable representational power, diverging from standard BNF in naming rules, repetition, alternatives, order-independence, and value ranges.

design-rationale §2.4

External encoding of terminal values is intentionally outside ABNF's scope, so the same grammar can be used in multiple encoding environments (7-bit ASCII, binary octet, 16-bit Unicode). Appendix B provides definitions for the common 7-bit US-ASCII case as a convenience.

design-rationale §Appendix A

The list notation present in earlier specifications was deliberately removed during the enhancement process. The working group considered deficiencies and benefits of existing specifications over 15 years before pursuing changes, resulting in a spec not massively different from RFC 822's original.

interoperability-note §4

The ABNF self-description syntax in Section 4 requires relatively strict formatting of rules; a ruleset included in a specification may need preprocessing to be interpretable by an ABNF parser. The syntax also relies on the core rules defined in Appendix B.

normative-requirement §2.3 MUST

ABNF literal text strings (quoted strings) are case-insensitive and the character set is US-ASCII. To specify a case-sensitive match, characters must be specified individually using numeric terminal notation.

protocol-element §2.2

A rule is defined as 'name = elements crlf', where name is the rule name, elements is one or more rule names or terminal specifications, and crlf is the end-of-line indicator (CR LF). Rule definitions are left-aligned; continuation lines are indented.

protocol-element §3.9

A semicolon begins a comment that continues to the end of the line, providing a way to include notes in parallel with rule specifications.

protocol-element §3.2

Alternatives are expressed by separating elements with a forward slash (Rule1 / Rule2). A quoted alphabetic string is a special form representing all case combinations of the contained characters in order.

protocol-element §3.1

Concatenation is expressed by listing rule names in sequence (Rule1 Rule2). ABNF does not provide implicit linear white space; any grammar permitting whitespace around delimiters must specify it explicitly.

protocol-element §B.1

Core rule ALPHA is defined as %x41-5A / %x61-7A (A-Z / a-z). DIGIT is %x30-39 (0-9). HEXDIG is DIGIT / 'A' / 'B' / 'C' / 'D' / 'E' / 'F'. These are uppercase-named basic terminal rules used throughout Internet specifications.

protocol-element §B.1

Core rule CRLF is defined as CR LF (%x0D %x0A), the Internet standard newline. CR is %x0D; LF is %x0A. WSP is SP / HTAB (%x20 / %x09). LWSP allows linear white space past a newline as *(WSP / CRLF WSP).

protocol-element §B.1

Core rule DQUOTE is %x22 (double-quote character). SP is %x20 (space). HTAB is %x09 (horizontal tab). BIT is '0' / '1'.

protocol-element §B.1

Core rule VCHAR is defined as %x21-7E (visible/printing characters). CTL is %x00-1F / %x7F (control characters). OCTET is %x00-FF (8 bits of data). CHAR is %x01-7F (any 7-bit US-ASCII character excluding NUL).

protocol-element §3.3

Incremental alternatives use the '=/' operator to append alternatives to an existing rule across separate definitions (oldrule =/ additional-alternatives), enabling independent specifications sharing a common parent ruleset to extend it.

protocol-element §3.10

Operator precedence from highest to lowest: strings/names formation, comment, value range, repetition, grouping/optional, concatenation, alternative. Freely mixing alternatives with concatenation is confusing; use of grouping operator is recommended.

protocol-element §3.8

Optional sequences are enclosed in square brackets: [foo bar] is equivalent to *1(foo bar), meaning zero or one occurrence of the bracketed sequence.

protocol-element §3.5

Parentheses form a sequence group whose contents are strictly ordered: (Rule1 Rule2). Use of grouping is strongly recommended when alternatives consist of multiple rule names or literals to avoid ambiguity with bare alternation.

protocol-element §2.1

Rule names are case-insensitive sequences beginning with an alphabetic character followed by any combination of alphabetics, digits, and hyphens. Angle brackets are optional but may be used for clarity in prose.

protocol-element §3.7

Specific repetition <n>element is equivalent to <n>*<n>element, meaning exactly n occurrences of the element. For example, 2DIGIT is a 2-digit number.

protocol-element §2.3

Terminal values are specified as non-negative integers with explicit base notation: %b for binary, %d for decimal, %x for hexadecimal. Concatenated values use dot notation (e.g., %d13.10 for CRLF); value ranges use dash notation (e.g., %x30-39 for DIGIT).

protocol-element §3.4

Value range alternatives are expressed compactly as %c##-## using a dash to indicate a range (e.g., %x30-39 for decimal digits 0–9). Concatenated numeric values and numeric value ranges cannot appear in the same string.

protocol-element §3.6

Variable repetition is expressed as <a>*<b>element, meaning at least <a> and at most <b> occurrences. Default values are 0 and infinity; *element allows any number including zero, 1*element requires at least one.

security-consideration §5

Security is stated to be irrelevant to this document. ABNF is a meta-language for syntax specification and introduces no network-facing protocol behavior.

security

wire-format §4

char-val is a DQUOTE-enclosed string of printable characters (%x20-21 / %x23-7E) excluding double-quote. num-val starts with '%' followed by bin-val, dec-val, or hex-val. prose-val is a '<...>'-enclosed description for last-resort use.

wire-format §B.2

The common encoding for ABNF grammars represents data externally as 'network virtual ASCII': 7-bit US-ASCII in an 8-bit field with the high (8th) bit set to zero. Multi-byte strings use network byte order (higher-valued bytes on the left, sent first).

wire-format §4

The complete ABNF grammar for ABNF itself is provided in Section 4. A rulelist consists of one or more rules or blank/comment lines; a rule is 'rulename defined-as elements c-nl'. The defined-as operator is '=' for new rules or '=/' for incremental alternatives.