7 Network Working Group D. Crocker, Ed.
8 Request for Comments: 4234 Brandenburg InternetWorking
9 Obsoletes: 2234 P. Overell
10 Category: Standards Track THUS plc.
14 Augmented BNF for Syntax Specifications: ABNF
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (C) The Internet Society (2005).
30 Internet technical specifications often need to define a formal
31 syntax. Over the years, a modified version of Backus-Naur Form
32 (BNF), called Augmented BNF (ABNF), has been popular among many
33 Internet specifications. The current specification documents ABNF.
34 It balances compactness and simplicity, with reasonable
35 representational power. The differences between standard BNF and
36 ABNF involve naming rules, repetition, alternatives, order-
37 independence, and value ranges. This specification also supplies
38 additional rule definitions and encoding for a core lexical analyzer
39 of the type common to several Internet specifications.
58 Crocker & Overell Standards Track [Page 1]
60 RFC 4234 ABNF October 2005
65 1. INTRODUCTION ....................................................2
66 2. RULE DEFINITION .................................................3
67 2.1. Rule Naming ................................................3
68 2.2. Rule Form ..................................................3
69 2.3. Terminal Values ............................................4
70 2.4. External Encodings .........................................5
71 3. OPERATORS .......................................................6
72 3.1. Concatenation: Rule1 Rule2 ................................6
73 3.2. Alternatives: Rule1 / Rule2 ...............................6
74 3.3. Incremental Alternatives: Rule1 =/ Rule2 ...................7
75 3.4. Value Range Alternatives: %c##-## .........................7
76 3.5. Sequence Group: (Rule1 Rule2) .............................8
77 3.6. Variable Repetition: *Rule ................................8
78 3.7. Specific Repetition: nRule ................................9
79 3.8. Optional Sequence: [RULE] .................................9
80 3.9. Comment: ; Comment ........................................9
81 3.10. Operator Precedence .......................................9
82 4. ABNF DEFINITION OF ABNF ........................................10
83 5. SECURITY CONSIDERATIONS ........................................11
84 6. References .....................................................11
85 6.1. Normative References ......................................11
86 6.2. Informative References ....................................11
87 Appendix A. ACKNOWLEDGEMENTS .....................................13
88 Appendix B. APPENDIX - CORE ABNF OF ABNF .........................13
89 B.1. Core Rules ...............................................13
90 B.2. Common Encoding ..........................................14
94 Internet technical specifications often need to define a formal
95 syntax and are free to employ whatever notation their authors deem
96 useful. Over the years, a modified version of Backus-Naur Form
97 (BNF), called Augmented BNF (ABNF), has been popular among many
98 Internet specifications. It balances compactness and simplicity,
99 with reasonable representational power. In the early days of the
100 Arpanet, each specification contained its own definition of ABNF.
101 This included the email specifications, [RFC733] and then [RFC822],
102 which came to be the common citations for defining ABNF. The current
103 document separates those definitions to permit selective reference.
104 Predictably, it also provides some modifications and enhancements.
106 The differences between standard BNF and ABNF involve naming rules,
107 repetition, alternatives, order-independence, and value ranges.
108 Appendix B supplies rule definitions and encoding for a core lexical
109 analyzer of the type common to several Internet specifications. It
110 is provided as a convenience and is otherwise separate from the meta
114 Crocker & Overell Standards Track [Page 2]
116 RFC 4234 ABNF October 2005
119 language defined in the body of this document, and separate from its
122 Changes since [RFC2234]:
124 In Section 3.7, the phrase: "That is, exactly <N> occurrences of
125 <element>." was corrected to: "That is, exactly <n> occurrences of
128 Some continuation comment lines needed to be corrected to begin
129 with comment character (";").
135 The name of a rule is simply the name itself; that is, a sequence of
136 characters, beginning with an alphabetic character, and followed by a
137 combination of alphabetics, digits, and hyphens (dashes).
141 Rule names are case-insensitive
143 The names <rulename>, <Rulename>, <RULENAME>, and <rUlENamE> all
144 refer to the same rule.
146 Unlike original BNF, angle brackets ("<", ">") are not required.
147 However, angle brackets may be used around a rule name whenever their
148 presence facilitates in discerning the use of a rule name. This is
149 typically restricted to rule name references in free-form prose, or
150 to distinguish partial rules that combine into a string not separated
151 by white space, such as shown in the discussion about repetition,
156 A rule is defined by the following sequence:
160 where <name> is the name of the rule, <elements> is one or more rule
161 names or terminal specifications, and <crlf> is the end-of-line
162 indicator (carriage return followed by line feed). The equal sign
163 separates the name from the definition of the rule. The elements
164 form a sequence of one or more rule names and/or value definitions,
165 combined according to the various operators defined in this document,
166 such as alternative and repetition.
170 Crocker & Overell Standards Track [Page 3]
172 RFC 4234 ABNF October 2005
175 For visual ease, rule definitions are left aligned. When a rule
176 requires multiple lines, the continuation lines are indented. The
177 left alignment and indentation are relative to the first lines of the
178 ABNF rules and need not match the left margin of the document.
182 Rules resolve into a string of terminal values, sometimes called
183 characters. In ABNF, a character is merely a non-negative integer.
184 In certain contexts, a specific mapping (encoding) of values into a
185 character set (such as ASCII) will be specified.
187 Terminals are specified by one or more numeric characters, with the
188 base interpretation of those characters indicated explicitly. The
189 following bases are currently defined:
203 respectively specify the decimal and hexadecimal representation of
204 [US-ASCII] for carriage return.
206 A concatenated string of such values is specified compactly, using a
207 period (".") to indicate a separation of characters within that
212 ABNF permits the specification of literal text strings directly,
213 enclosed in quotation-marks. Hence:
215 command = "command string"
217 Literal text strings are interpreted as a concatenated set of
218 printable characters.
226 Crocker & Overell Standards Track [Page 4]
228 RFC 4234 ABNF October 2005
233 ABNF strings are case-insensitive and the character set for these
244 will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
247 To specify a rule that IS case SENSITIVE, specify the characters
252 rulename = %d97 %d98 %d99
256 rulename = %d97.98.99
258 will match only the string that comprises only the lowercased
261 2.4. External Encodings
263 External representations of terminal value characters will vary
264 according to constraints in the storage or transmission environment.
265 Hence, the same ABNF-based grammar may have multiple external
266 encodings, such as one for a 7-bit US-ASCII environment, another for
267 a binary octet environment, and still a different one when 16-bit
268 Unicode is used. Encoding details are beyond the scope of ABNF,
269 although Appendix A (Core) provides definitions for a 7-bit US-ASCII
270 environment as has been common to much of the Internet.
272 By separating external encoding from the syntax, it is intended that
273 alternate encoding environments can be used for the same syntax.
282 Crocker & Overell Standards Track [Page 5]
284 RFC 4234 ABNF October 2005
289 3.1. Concatenation: Rule1 Rule2
291 A rule can define a simple, ordered string of values (i.e., a
292 concatenation of contiguous characters) by listing a sequence of rule
301 So that the rule <mumble> matches the lowercase string "aba".
303 LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing
304 model. A string of contiguous characters (values) is parsed
305 according to the rules defined in ABNF. For Internet specifications,
306 there is some history of permitting linear white space (space and
307 horizontal tab) to be freely and implicitly interspersed around major
308 constructs, such as delimiting special characters or atomic strings.
312 This specification for ABNF does not provide for implicit
313 specification of linear white space.
315 Any grammar that wishes to permit linear white space around
316 delimiters or string segments must specify it explicitly. It is
317 often useful to provide for such white space in "core" rules that are
318 then used variously among higher-level rules. The "core" rules might
319 be formed into a lexical analyzer or simply be part of the main
322 3.2. Alternatives: Rule1 / Rule2
324 Elements separated by a forward slash ("/") are alternatives.
329 will accept <foo> or <bar>.
338 Crocker & Overell Standards Track [Page 6]
340 RFC 4234 ABNF October 2005
345 A quoted string containing alphabetic characters is a special form
346 for specifying alternative characters and is interpreted as a
347 non-terminal representing the set of combinatorial strings with
348 the contained characters, in the specified order but with any
349 mixture of upper and lower case.
351 3.3. Incremental Alternatives: Rule1 =/ Rule2
353 It is sometimes convenient to specify a list of alternatives in
354 fragments. That is, an initial rule may match one or more
355 alternatives, with later rule definitions adding to the set of
356 alternatives. This is particularly useful for otherwise, independent
357 specifications that derive from the same parent rule set, such as
358 often occurs with parameter lists. ABNF permits this incremental
359 definition through the construct:
361 oldrule =/ additional-alternatives
365 ruleset = alt1 / alt2
369 ruleset =/ alt4 / alt5
371 is the same as specifying
373 ruleset = alt1 / alt2 / alt3 / alt4 / alt5
375 3.4. Value Range Alternatives: %c##-##
377 A range of alternative numeric values can be specified compactly,
378 using dash ("-") to indicate the range of alternative values. Hence:
384 DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
388 Concatenated numeric values and numeric value ranges cannot be
389 specified in the same string. A numeric value may use the dotted
390 notation for concatenation or it may use the dash notation to specify
394 Crocker & Overell Standards Track [Page 7]
396 RFC 4234 ABNF October 2005
399 one value range. Hence, to specify one printable character between
400 end of line sequences, the specification could be:
402 char-line = %x0D.0A %x20-7E %x0D.0A
404 3.5. Sequence Group: (Rule1 Rule2)
406 Elements enclosed in parentheses are treated as a single element,
407 whose contents are STRICTLY ORDERED. Thus,
409 elem (foo / bar) blat
411 matches (elem foo blat) or (elem bar blat), and
415 matches (elem foo) or (bar blat).
419 It is strongly advised that grouping notation be used, rather than
420 relying on the proper reading of "bare" alternations, when
421 alternatives consist of multiple rule names or literals.
423 Hence, it is recommended that the following form be used:
425 (elem foo) / (bar blat)
427 It will avoid misinterpretation by casual readers.
429 The sequence group notation is also used within free text to set off
430 an element sequence from the prose.
432 3.6. Variable Repetition: *Rule
434 The operator "*" preceding an element indicates repetition. The full
439 where <a> and <b> are optional decimal values, indicating at least
440 <a> and at most <b> occurrences of the element.
442 Default values are 0 and infinity so that *<element> allows any
443 number, including zero; 1*<element> requires at least one;
444 3*3<element> allows exactly 3 and 1*2<element> allows one or two.
450 Crocker & Overell Standards Track [Page 8]
452 RFC 4234 ABNF October 2005
455 3.7. Specific Repetition: nRule
465 That is, exactly <n> occurrences of <element>. Thus, 2DIGIT is a 2-
466 digit number, and 3ALPHA is a string of three alphabetic characters.
468 3.8. Optional Sequence: [RULE]
470 Square brackets enclose an optional element sequence:
478 3.9. Comment: ; Comment
480 A semi-colon starts a comment that continues to the end of line.
481 This is a simple way of including useful notes in parallel with the
484 3.10. Operator Precedence
486 The various mechanisms described above have the following precedence,
487 from highest (binding tightest) at the top, to lowest (loosest) at
490 Strings, Names formation
506 Crocker & Overell Standards Track [Page 9]
508 RFC 4234 ABNF October 2005
511 Use of the alternative operator, freely mixed with concatenations,
514 Again, it is recommended that the grouping operator be used to
515 make explicit concatenation groups.
517 4. ABNF DEFINITION OF ABNF
521 1. This syntax requires a formatting of rules that is relatively
522 strict. Hence, the version of a ruleset included in a
523 specification might need preprocessing to ensure that it can be
524 interpreted by an ABNF parser.
526 2. This syntax uses the rules provided in Appendix B (Core).
528 rulelist = 1*( rule / (*c-wsp c-nl) )
530 rule = rulename defined-as elements c-nl
531 ; continues if next line starts
534 rulename = ALPHA *(ALPHA / DIGIT / "-")
536 defined-as = *c-wsp ("=" / "=/") *c-wsp
537 ; basic rules definition and
538 ; incremental alternatives
540 elements = alternation *c-wsp
542 c-wsp = WSP / (c-nl WSP)
544 c-nl = comment / CRLF
547 comment = ";" *(WSP / VCHAR) CRLF
549 alternation = concatenation
550 *(*c-wsp "/" *c-wsp concatenation)
552 concatenation = repetition *(1*c-wsp repetition)
554 repetition = [repeat] element
556 repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)
562 Crocker & Overell Standards Track [Page 10]
564 RFC 4234 ABNF October 2005
567 element = rulename / group / option /
568 char-val / num-val / prose-val
570 group = "(" *c-wsp alternation *c-wsp ")"
572 option = "[" *c-wsp alternation *c-wsp "]"
574 char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE
575 ; quoted string of SP and VCHAR
578 num-val = "%" (bin-val / dec-val / hex-val)
581 [ 1*("." 1*BIT) / ("-" 1*BIT) ]
582 ; series of concatenated bit values
583 ; or single ONEOF range
585 dec-val = "d" 1*DIGIT
586 [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
588 hex-val = "x" 1*HEXDIG
589 [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
591 prose-val = "<" *(%x20-3D / %x3F-7E) ">"
592 ; bracketed string of SP and VCHAR
594 ; prose description, to be used as
597 5. SECURITY CONSIDERATIONS
599 Security is truly believed to be irrelevant to this document.
603 6.1. Normative References
605 [US-ASCII] American National Standards Institute, "Coded Character
606 Set -- 7-bit American Standard Code for Information
607 Interchange", ANSI X3.4, 1986.
609 6.2. Informative References
611 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
612 Specifications: ABNF", RFC 2234, November 1997.
618 Crocker & Overell Standards Track [Page 11]
620 RFC 4234 ABNF October 2005
623 [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
624 "Standard for the format of ARPA network text messages",
625 RFC 733, November 1977.
627 [RFC822] Crocker, D., "Standard for the format of ARPA Internet
628 text messages", STD 11, RFC 822, August 1982.
674 Crocker & Overell Standards Track [Page 12]
676 RFC 4234 ABNF October 2005
679 Appendix A. ACKNOWLEDGEMENTS
681 The syntax for ABNF was originally specified in RFC 733. Ken L.
682 Harrenstien, of SRI International, was responsible for re-coding the
683 BNF into an augmented BNF that makes the representation smaller and
684 easier to understand.
686 This recent project began as a simple effort to cull out the portion
687 of RFC 822 that has been repeatedly cited by non-email specification
688 writers, namely the description of augmented BNF. Rather than simply
689 and blindly converting the existing text into a separate document,
690 the working group chose to give careful consideration to the
691 deficiencies, as well as benefits, of the existing specification and
692 related specifications made available over the last 15 years, and
693 therefore to pursue enhancement. This turned the project into
694 something rather more ambitious than was first intended.
695 Interestingly, the result is not massively different from that
696 original, although decisions, such as removing the list notation,
699 This "separated" version of the specification was part of the DRUMS
700 working group, with significant contributions from Jerome Abela,
701 Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom
702 Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete
703 Resnick, and Henning Schulzrinne.
705 Julian Reschke warrants a special thanks for converting the Draft
706 Standard version to XML source form.
708 Appendix B. APPENDIX - CORE ABNF OF ABNF
710 This Appendix is provided as a convenient core for specific grammars.
711 The definitions may be used as a core set of rules.
715 Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT,
718 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
723 ; any 7-bit US-ASCII character,
730 Crocker & Overell Standards Track [Page 13]
732 RFC 4234 ABNF October 2005
739 ; Internet standard newline
750 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
758 LWSP = *(WSP / CRLF WSP)
759 ; linear white space (past newline)
767 ; visible (printing) characters
774 Externally, data are represented as "network virtual ASCII" (namely,
775 7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
776 zero. A string of values is in "network byte order", in which the
777 higher-valued bytes are represented on the left-hand side and are
778 sent over the network first.
786 Crocker & Overell Standards Track [Page 14]
788 RFC 4234 ABNF October 2005
793 Dave Crocker (editor)
794 Brandenburg InternetWorking
799 Phone: +1.408.246.8253
800 EMail: dcrocker@bbiw.net
811 EMail: paul.overell@thus.net
842 Crocker & Overell Standards Track [Page 15]
844 RFC 4234 ABNF October 2005
847 Full Copyright Statement
849 Copyright (C) The Internet Society (2005).
851 This document is subject to the rights, licenses and restrictions
852 contained in BCP 78, and except as set forth therein, the authors
853 retain all their rights.
855 This document and the information contained herein are provided on an
856 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
857 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
858 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
859 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
860 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
861 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
863 Intellectual Property
865 The IETF takes no position regarding the validity or scope of any
866 Intellectual Property Rights or other rights that might be claimed to
867 pertain to the implementation or use of the technology described in
868 this document or the extent to which any license under such rights
869 might or might not be available; nor does it represent that it has
870 made any independent effort to identify any such rights. Information
871 on the procedures with respect to rights in RFC documents can be
872 found in BCP 78 and BCP 79.
874 Copies of IPR disclosures made to the IETF Secretariat and any
875 assurances of licenses to be made available, or the result of an
876 attempt made to obtain a general license or permission for the use of
877 such proprietary rights by implementers or users of this
878 specification can be obtained from the IETF on-line IPR repository at
879 http://www.ietf.org/ipr.
881 The IETF invites any interested party to bring to its attention any
882 copyrights, patents or patent applications, or other proprietary
883 rights that may cover technology that may be required to implement
884 this standard. Please address the information to the IETF at ietf-
889 Funding for the RFC Editor function is currently provided by the
898 Crocker & Overell Standards Track [Page 16]