rfc-2234

Augmented BNF for Syntax Specifications: ABNF

D. Crocker (Editor), P. Overell
date1997-11 streamIETF areaapp wgdrums statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc2234 doi10.17487/RFC2234 errataview
In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]

obsoleted by

Extracted elements (23)

design-rationale §1

ABNF was previously embedded in individual specifications (notably RFC 733 and RFC 822). This document separates the definition to permit selective reference and adds modifications and enhancements to the original form.

process

design-rationale §2.4

External encoding of terminal values is explicitly out of scope for ABNF. The same ABNF grammar may have multiple external encodings (7-bit ASCII, binary octet, 16-bit Unicode), enabling alternate encoding environments to use the same syntax.

design-rationale §7

The DRUMS working group deliberately removed the list notation (present in the earlier RFC 822 ABNF) during the revision process. This was described as a surprising outcome but was chosen after careful consideration of deficiencies in the existing specification.

interoperability-note §6.2

Common encoding for ABNF-based Internet specifications is 'network virtual ASCII': 7-bit US-ASCII in an 8-bit field with the high bit set to zero, transmitted in network byte order (most significant byte first).

interoperability-note §2.3

Literal text strings in ABNF are case-insensitive and must use US-ASCII. To specify a case-sensitive match, each character must be specified individually using numeric notation (e.g., %d97.98.99 for lowercase 'abc').

protocol-element §3.4

A range of alternative numeric values is expressed as '%c##-##' (e.g., %x30-39 for DIGIT). Concatenated numeric values and numeric value ranges cannot be mixed in the same string.

protocol-element §2.2

A rule is defined as 'name = elements crlf', where the equal sign separates the rule name from its definition, and continuation lines are indented for multi-line rules.

protocol-element §2.1

A 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.

protocol-element §3.9

A semicolon begins a comment that continues to the end of the line, providing a simple mechanism for inline notes parallel to rule specifications.

protocol-element §3.2

Alternatives are expressed with the forward slash operator (Rule1 / Rule2). A quoted string containing alphabetic characters is a special form representing all combinatorial case mixtures of those characters in order.

protocol-element §6.1

Appendix A defines core rules in uppercase: ALPHA (%x41-5A / %x61-7A), DIGIT (%x30-39), HEXDIG, BIT, CHAR (%x01-7F), CR (%x0D), LF (%x0A), CRLF, CTL, DQUOTE, HTAB (%x09), SP (%x20), VCHAR (%x21-7E), WSP, LWSP, and OCTET (%x00-FF).

protocol-element §3.1

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

protocol-element §3.5

Elements enclosed in parentheses form a sequence group treated as a single strictly-ordered element, e.g., '(Rule1 Rule2)'. Grouping is strongly recommended when alternatives consist of multiple rule names to avoid misinterpretation.

protocol-element §3.3

Incremental alternatives (=/) allow a rule's set of alternatives to be extended across multiple definitions. 'oldrule =/ additional-alternatives' appends to the existing alternatives without redefining the rule.

protocol-element §6.1

LWSP is defined as '*(WSP / CRLF WSP)', representing linear white space that may span past a newline when the continuation line starts with whitespace. This captures folded header-line conventions common in Internet mail formats.

email

protocol-element §3.10

Operator precedence from highest to lowest: strings/name formation, comment, value range, repetition, grouping/optional, concatenation, alternative. Mixing alternatives freely with concatenation is confusing; use grouping notation instead.

protocol-element §3.8

Optional sequences are enclosed in square brackets '[RULE]', equivalent to '*1(foo bar)'. This expresses zero or one occurrence of the bracketed element sequence.

protocol-element §3.7

Specific repetition '<n>element' requires exactly N occurrences, equivalent to '<n>*<n>element'. For example, '2DIGIT' is a 2-digit number and '3ALPHA' is a string of three alphabetic characters.

protocol-element §2.3

Terminal values are specified with an explicit base prefix: 'b' for binary, 'd' for decimal, 'x' for hexadecimal (e.g., %d13 or %x0D for carriage return). Concatenated values use a period separator (e.g., %d13.10 for CRLF).

protocol-element §3.6

Variable repetition is expressed as '<a>*<b>element', indicating 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.

security-consideration §5

The authors state that security is believed to be irrelevant to this document, as ABNF is a syntax notation metaspecification with no direct protocol behavior or data handling.

security

wire-format §4

The formal ABNF grammar of ABNF itself is given in Section 4. A rulelist is '1*(rule / (*c-wsp c-nl))'; a rule is 'rulename defined-as elements c-nl'; char-val is 'DQUOTE *(%x20-21 / %x23-7E) DQUOTE'; num-val is '"%%" (bin-val / dec-val / hex-val)'.

wire-format §4

The prose-val element '<*(%x20-3D / %x3F-7E)>' allows bracketed free-text prose descriptions to be used as a last resort when a formal rule cannot fully capture the intended constraint.