Augmented BNF for Syntax Specifications: ABNF

ABNF deliberately omits implicit linear white space, unlike some earlier Internet specifications that permitted space and horizontal tab to be freely interspersed around major constructs. Grammars that need such flexibility must make it explicit.

ABNF was extracted from RFC 822 (email format specification) because non-email specification writers repeatedly cited it for its ABNF notation. The separation allows selective reference and permits the notation to be enhanced independently of email standards.

email, process

External encoding (e.g., 7-bit ASCII, 8-bit octets, 16-bit Unicode) is intentionally separated from ABNF grammar definitions so the same grammar can be used across multiple encoding environments. Encoding details are explicitly out of scope for ABNF itself.

The core rules defined in Appendix B are only valid for ABNF encoded in 7-bit ASCII or character sets that are a superset of 7-bit ASCII. Specifications using other encodings must define their own core rules.

ABNF literal text strings enclosed in quotation marks are case insensitive and the character set is US-ASCII. To specify case-sensitive matching, characters must be specified individually using numeric values.

ABNF requires a relatively strict formatting of rules. A ruleset included in a specification may need preprocessing to ensure it can be interpreted by an ABNF parser before use.

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

Alternatives are specified by separating elements with a forward slash ('/'). A quoted alphabetic string is a special form representing all case combinations of those characters in order.

An ABNF rule name is a sequence of characters beginning with an alphabetic character, followed by a combination of alphabetics, digits, and hyphens. Rule names are case insensitive.

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

Core rule ALPHA covers %x41-5A / %x61-7A (A-Z and a-z); DIGIT covers %x30-39 (0-9); HEXDIG covers DIGIT plus 'A' through 'F'; BIT is '0' or '1'; CHAR is %x01-7F (any 7-bit US-ASCII excluding NUL).

Core rule CRLF = CR LF (%x0D %x0A) is the Internet standard newline. CR = %x0D, LF = %x0A, HTAB = %x09, SP = %x20, WSP = SP / HTAB, VCHAR = %x21-7E (visible/printing characters), CTL = %x00-1F / %x7F (controls), OCTET = %x00-FF.

Incremental alternatives use the '=/' operator to add alternatives to an existing rule definition across multiple rule statements, enabling independent specifications to extend a shared parent ruleset.

Operator precedence from highest to lowest: rule name/prose-val/terminal value; comment; value range; repetition; grouping/optional; concatenation; alternative. Mixing alternatives freely with concatenations can be confusing and grouping is recommended.

Sequence grouping with parentheses treats enclosed elements as a single element with strictly ordered contents, enabling unambiguous specification of alternatives that contain multiple rule names or literals.

Specific repetition '<n>element' is equivalent to '<n>*<n>element', meaning exactly n occurrences. Optional sequences '[RULE]' are equivalent to '*1(RULE)', meaning zero or one occurrence.

Terminal values are specified with a base prefix: %b for binary, %d for decimal, %x for hexadecimal. Concatenated values use '.' notation (e.g., %d13.10 for CRLF) and ranges use '-' notation (e.g., %x30-39 for digits).

The LWSP core rule permits linear white space including lines containing only whitespace via '*(WSP / CRLF WSP)'. The spec warns this is no longer legal in mail headers and has caused interoperability problems; it should not be used when defining mail headers.

email

Value range alternatives use the '%c##-##' notation (with a dash) to compactly specify a range of numeric values. Concatenated numeric values (dotted notation) and range notation cannot be mixed in the same string.

Variable repetition uses the '*' operator in the form '<a>*<b>element', meaning at least <a> and at most <b> occurrences. Defaults are 0 and infinity; '*element' allows any number including zero; '1*element' requires at least one.

The RFC authors state that security is believed to be irrelevant to this document, as ABNF is a meta-language for syntax specification with no direct protocol security implications.

security

A rule is defined by the form 'name = elements crlf', where the equal sign separates the name from its definition and CRLF terminates each rule. Continuation lines are indented.

Common encoding (Appendix B.2) specifies that externally, data are represented as 'network virtual ASCII': 7-bit US-ASCII in an 8-bit field with the high (8th) bit set to zero, in network byte order (higher-valued bytes on the left, sent first).

The ABNF self-description grammar defines: rulelist = 1*(rule / (*c-wsp c-nl)); rule = rulename defined-as elements c-nl; char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE; num-val = '%' (bin-val / dec-val / hex-val). The prose-val element '<' *(%x20-3D / %x3F-7E) '>' is a last-resort bracketed prose description.

The bin-val, dec-val, and hex-val rules each allow either a series of dot-concatenated values or a single dash-delimited range, but not both in the same value. The repeat rule is '1*DIGIT / (*DIGIT "*" *DIGIT)'.