yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Network Working Group                                    D. Crocker, Ed.
yuuji@0: Request for Comments: 5234                   Brandenburg InternetWorking
yuuji@0: STD: 68                                                       P. Overell
yuuji@0: Obsoletes: 4234                                                THUS plc.
yuuji@0: Category: Standards Track                                   January 2008
yuuji@0: 
yuuji@0: 
yuuji@0:              Augmented BNF for Syntax Specifications: ABNF
yuuji@0: 
yuuji@0: Status of This Memo
yuuji@0: 
yuuji@0:    This document specifies an Internet standards track protocol for the
yuuji@0:    Internet community, and requests discussion and suggestions for
yuuji@0:    improvements.  Please refer to the current edition of the "Internet
yuuji@0:    Official Protocol Standards" (STD 1) for the standardization state
yuuji@0:    and status of this protocol.  Distribution of this memo is unlimited.
yuuji@0: 
yuuji@0: Abstract
yuuji@0: 
yuuji@0:    Internet technical specifications often need to define a formal
yuuji@0:    syntax.  Over the years, a modified version of Backus-Naur Form
yuuji@0:    (BNF), called Augmented BNF (ABNF), has been popular among many
yuuji@0:    Internet specifications.  The current specification documents ABNF.
yuuji@0:    It balances compactness and simplicity with reasonable
yuuji@0:    representational power.  The differences between standard BNF and
yuuji@0:    ABNF involve naming rules, repetition, alternatives, order-
yuuji@0:    independence, and value ranges.  This specification also supplies
yuuji@0:    additional rule definitions and encoding for a core lexical analyzer
yuuji@0:    of the type common to several Internet specifications.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 1]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: Table of Contents
yuuji@0: 
yuuji@0:    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
yuuji@0:    2.  Rule Definition  . . . . . . . . . . . . . . . . . . . . . . .  3
yuuji@0:      2.1.  Rule Naming  . . . . . . . . . . . . . . . . . . . . . . .  3
yuuji@0:      2.2.  Rule Form  . . . . . . . . . . . . . . . . . . . . . . . .  4
yuuji@0:      2.3.  Terminal Values  . . . . . . . . . . . . . . . . . . . . .  4
yuuji@0:      2.4.  External Encodings . . . . . . . . . . . . . . . . . . . .  6
yuuji@0:    3.  Operators  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
yuuji@0:      3.1.  Concatenation:  Rule1 Rule2  . . . . . . . . . . . . . . .  6
yuuji@0:      3.2.  Alternatives:  Rule1 / Rule2 . . . . . . . . . . . . . . .  7
yuuji@0:      3.3.  Incremental Alternatives: Rule1 =/ Rule2 . . . . . . . . .  7
yuuji@0:      3.4.  Value Range Alternatives:  %c##-## . . . . . . . . . . . .  8
yuuji@0:      3.5.  Sequence Group:  (Rule1 Rule2) . . . . . . . . . . . . . .  8
yuuji@0:      3.6.  Variable Repetition:  *Rule  . . . . . . . . . . . . . . .  9
yuuji@0:      3.7.  Specific Repetition:  nRule  . . . . . . . . . . . . . . .  9
yuuji@0:      3.8.  Optional Sequence:  [RULE] . . . . . . . . . . . . . . . .  9
yuuji@0:      3.9.  Comment:  ; Comment  . . . . . . . . . . . . . . . . . . .  9
yuuji@0:      3.10. Operator Precedence  . . . . . . . . . . . . . . . . . . . 10
yuuji@0:    4.  ABNF Definition of ABNF  . . . . . . . . . . . . . . . . . . . 10
yuuji@0:    5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
yuuji@0:    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
yuuji@0:      6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
yuuji@0:      6.2.  Informative References . . . . . . . . . . . . . . . . . . 12
yuuji@0:    Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 13
yuuji@0:    Appendix B.  Core ABNF of ABNF . . . . . . . . . . . . . . . . . . 13
yuuji@0:      B.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
yuuji@0:      B.2.  Common Encoding  . . . . . . . . . . . . . . . . . . . . . 15
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 2]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: 1.  Introduction
yuuji@0: 
yuuji@0:    Internet technical specifications often need to define a formal
yuuji@0:    syntax and are free to employ whatever notation their authors deem
yuuji@0:    useful.  Over the years, a modified version of Backus-Naur Form
yuuji@0:    (BNF), called Augmented BNF (ABNF), has been popular among many
yuuji@0:    Internet specifications.  It balances compactness and simplicity with
yuuji@0:    reasonable representational power.  In the early days of the Arpanet,
yuuji@0:    each specification contained its own definition of ABNF.  This
yuuji@0:    included the email specifications, [RFC733] and then [RFC822], which
yuuji@0:    came to be the common citations for defining ABNF.  The current
yuuji@0:    document separates those definitions to permit selective reference.
yuuji@0:    Predictably, it also provides some modifications and enhancements.
yuuji@0: 
yuuji@0:    The differences between standard BNF and ABNF involve naming rules,
yuuji@0:    repetition, alternatives, order-independence, and value ranges.
yuuji@0:    Appendix B supplies rule definitions and encoding for a core lexical
yuuji@0:    analyzer of the type common to several Internet specifications.  It
yuuji@0:    is provided as a convenience and is otherwise separate from the meta
yuuji@0:    language defined in the body of this document, and separate from its
yuuji@0:    formal status.
yuuji@0: 
yuuji@0: 2.  Rule Definition
yuuji@0: 
yuuji@0: 2.1.  Rule Naming
yuuji@0: 
yuuji@0:    The name of a rule is simply the name itself, that is, a sequence of
yuuji@0:    characters, beginning with an alphabetic character, and followed by a
yuuji@0:    combination of alphabetics, digits, and hyphens (dashes).
yuuji@0: 
yuuji@0:    NOTE:
yuuji@0: 
yuuji@0:       Rule names are case insensitive.
yuuji@0: 
yuuji@0:    The names <rulename>, <Rulename>, <RULENAME>, and <rUlENamE> all
yuuji@0:    refer to the same rule.
yuuji@0: 
yuuji@0:    Unlike original BNF, angle brackets ("<", ">") are not required.
yuuji@0:    However, angle brackets may be used around a rule name whenever their
yuuji@0:    presence facilitates in discerning the use of a rule name.  This is
yuuji@0:    typically restricted to rule name references in free-form prose, or
yuuji@0:    to distinguish partial rules that combine into a string not separated
yuuji@0:    by white space, such as shown in the discussion about repetition,
yuuji@0:    below.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 3]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: 2.2.  Rule Form
yuuji@0: 
yuuji@0:    A rule is defined by the following sequence:
yuuji@0: 
yuuji@0:          name =  elements crlf
yuuji@0: 
yuuji@0:    where <name> is the name of the rule, <elements> is one or more rule
yuuji@0:    names or terminal specifications, and <crlf> is the end-of-line
yuuji@0:    indicator (carriage return followed by line feed).  The equal sign
yuuji@0:    separates the name from the definition of the rule.  The elements
yuuji@0:    form a sequence of one or more rule names and/or value definitions,
yuuji@0:    combined according to the various operators defined in this document,
yuuji@0:    such as alternative and repetition.
yuuji@0: 
yuuji@0:    For visual ease, rule definitions are left aligned.  When a rule
yuuji@0:    requires multiple lines, the continuation lines are indented.  The
yuuji@0:    left alignment and indentation are relative to the first lines of the
yuuji@0:    ABNF rules and need not match the left margin of the document.
yuuji@0: 
yuuji@0: 2.3.  Terminal Values
yuuji@0: 
yuuji@0:    Rules resolve into a string of terminal values, sometimes called
yuuji@0:    characters.  In ABNF, a character is merely a non-negative integer.
yuuji@0:    In certain contexts, a specific mapping (encoding) of values into a
yuuji@0:    character set (such as ASCII) will be specified.
yuuji@0: 
yuuji@0:    Terminals are specified by one or more numeric characters, with the
yuuji@0:    base interpretation of those characters indicated explicitly.  The
yuuji@0:    following bases are currently defined:
yuuji@0: 
yuuji@0:          b           =  binary
yuuji@0: 
yuuji@0:          d           =  decimal
yuuji@0: 
yuuji@0:          x           =  hexadecimal
yuuji@0: 
yuuji@0:    Hence:
yuuji@0: 
yuuji@0:          CR          =  %d13
yuuji@0: 
yuuji@0:          CR          =  %x0D
yuuji@0: 
yuuji@0:    respectively specify the decimal and hexadecimal representation of
yuuji@0:    [US-ASCII] for carriage return.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 4]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0:    A concatenated string of such values is specified compactly, using a
yuuji@0:    period (".") to indicate a separation of characters within that
yuuji@0:    value.  Hence:
yuuji@0: 
yuuji@0:          CRLF        =  %d13.10
yuuji@0: 
yuuji@0:    ABNF permits the specification of literal text strings directly,
yuuji@0:    enclosed in quotation marks.  Hence:
yuuji@0: 
yuuji@0:          command     =  "command string"
yuuji@0: 
yuuji@0:    Literal text strings are interpreted as a concatenated set of
yuuji@0:    printable characters.
yuuji@0: 
yuuji@0:    NOTE:
yuuji@0: 
yuuji@0:       ABNF strings are case insensitive and the character set for these
yuuji@0:       strings is US-ASCII.
yuuji@0: 
yuuji@0:    Hence:
yuuji@0: 
yuuji@0:          rulename = "abc"
yuuji@0: 
yuuji@0:    and:
yuuji@0: 
yuuji@0:          rulename = "aBc"
yuuji@0: 
yuuji@0:    will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
yuuji@0:    "ABC".
yuuji@0: 
yuuji@0:       To specify a rule that is case sensitive, specify the characters
yuuji@0:       individually.
yuuji@0: 
yuuji@0:    For example:
yuuji@0: 
yuuji@0:          rulename    =  %d97 %d98 %d99
yuuji@0: 
yuuji@0:    or
yuuji@0: 
yuuji@0:          rulename    =  %d97.98.99
yuuji@0: 
yuuji@0:    will match only the string that comprises only the lowercase
yuuji@0:    characters, abc.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 5]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: 2.4.  External Encodings
yuuji@0: 
yuuji@0:    External representations of terminal value characters will vary
yuuji@0:    according to constraints in the storage or transmission environment.
yuuji@0:    Hence, the same ABNF-based grammar may have multiple external
yuuji@0:    encodings, such as one for a 7-bit US-ASCII environment, another for
yuuji@0:    a binary octet environment, and still a different one when 16-bit
yuuji@0:    Unicode is used.  Encoding details are beyond the scope of ABNF,
yuuji@0:    although Appendix B provides definitions for a 7-bit US-ASCII
yuuji@0:    environment as has been common to much of the Internet.
yuuji@0: 
yuuji@0:    By separating external encoding from the syntax, it is intended that
yuuji@0:    alternate encoding environments can be used for the same syntax.
yuuji@0: 
yuuji@0: 3.  Operators
yuuji@0: 
yuuji@0: 3.1.  Concatenation:  Rule1 Rule2
yuuji@0: 
yuuji@0:    A rule can define a simple, ordered string of values (i.e., a
yuuji@0:    concatenation of contiguous characters) by listing a sequence of rule
yuuji@0:    names.  For example:
yuuji@0: 
yuuji@0:          foo         =  %x61           ; a
yuuji@0: 
yuuji@0:          bar         =  %x62           ; b
yuuji@0: 
yuuji@0:          mumble      =  foo bar foo
yuuji@0: 
yuuji@0:    So that the rule <mumble> matches the lowercase string "aba".
yuuji@0: 
yuuji@0:    Linear white space: Concatenation is at the core of the ABNF parsing
yuuji@0:    model.  A string of contiguous characters (values) is parsed
yuuji@0:    according to the rules defined in ABNF.  For Internet specifications,
yuuji@0:    there is some history of permitting linear white space (space and
yuuji@0:    horizontal tab) to be freely and implicitly interspersed around major
yuuji@0:    constructs, such as delimiting special characters or atomic strings.
yuuji@0: 
yuuji@0:    NOTE:
yuuji@0: 
yuuji@0:       This specification for ABNF does not provide for implicit
yuuji@0:       specification of linear white space.
yuuji@0: 
yuuji@0:    Any grammar that wishes to permit linear white space around
yuuji@0:    delimiters or string segments must specify it explicitly.  It is
yuuji@0:    often useful to provide for such white space in "core" rules that are
yuuji@0:    then used variously among higher-level rules.  The "core" rules might
yuuji@0:    be formed into a lexical analyzer or simply be part of the main
yuuji@0:    ruleset.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 6]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: 3.2.  Alternatives:  Rule1 / Rule2
yuuji@0: 
yuuji@0:    Elements separated by a forward slash ("/") are alternatives.
yuuji@0:    Therefore,
yuuji@0: 
yuuji@0:          foo / bar
yuuji@0: 
yuuji@0:    will accept <foo> or <bar>.
yuuji@0: 
yuuji@0:    NOTE:
yuuji@0: 
yuuji@0:       A quoted string containing alphabetic characters is a special form
yuuji@0:       for specifying alternative characters and is interpreted as a non-
yuuji@0:       terminal representing the set of combinatorial strings with the
yuuji@0:       contained characters, in the specified order but with any mixture
yuuji@0:       of upper- and lowercase.
yuuji@0: 
yuuji@0: 3.3.  Incremental Alternatives: Rule1 =/ Rule2
yuuji@0: 
yuuji@0:    It is sometimes convenient to specify a list of alternatives in
yuuji@0:    fragments.  That is, an initial rule may match one or more
yuuji@0:    alternatives, with later rule definitions adding to the set of
yuuji@0:    alternatives.  This is particularly useful for otherwise independent
yuuji@0:    specifications that derive from the same parent ruleset, such as
yuuji@0:    often occurs with parameter lists.  ABNF permits this incremental
yuuji@0:    definition through the construct:
yuuji@0: 
yuuji@0:          oldrule     =/ additional-alternatives
yuuji@0: 
yuuji@0:    So that the ruleset
yuuji@0: 
yuuji@0:          ruleset     =  alt1 / alt2
yuuji@0: 
yuuji@0:          ruleset     =/ alt3
yuuji@0: 
yuuji@0:          ruleset     =/ alt4 / alt5
yuuji@0: 
yuuji@0:    is the same as specifying
yuuji@0: 
yuuji@0:          ruleset     =  alt1 / alt2 / alt3 / alt4 / alt5
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 7]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: 3.4.  Value Range Alternatives:  %c##-##
yuuji@0: 
yuuji@0:    A range of alternative numeric values can be specified compactly,
yuuji@0:    using a dash ("-") to indicate the range of alternative values.
yuuji@0:    Hence:
yuuji@0: 
yuuji@0:          DIGIT       =  %x30-39
yuuji@0: 
yuuji@0:    is equivalent to:
yuuji@0: 
yuuji@0:          DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" /
yuuji@0: 
yuuji@0:                         "7" / "8" / "9"
yuuji@0: 
yuuji@0:    Concatenated numeric values and numeric value ranges cannot be
yuuji@0:    specified in the same string.  A numeric value may use the dotted
yuuji@0:    notation for concatenation or it may use the dash notation to specify
yuuji@0:    one value range.  Hence, to specify one printable character between
yuuji@0:    end-of-line sequences, the specification could be:
yuuji@0: 
yuuji@0:          char-line = %x0D.0A %x20-7E %x0D.0A
yuuji@0: 
yuuji@0: 3.5.  Sequence Group:  (Rule1 Rule2)
yuuji@0: 
yuuji@0:    Elements enclosed in parentheses are treated as a single element,
yuuji@0:    whose contents are strictly ordered.  Thus,
yuuji@0: 
yuuji@0:          elem (foo / bar) blat
yuuji@0: 
yuuji@0:    matches (elem foo blat) or (elem bar blat), and
yuuji@0: 
yuuji@0:          elem foo / bar blat
yuuji@0: 
yuuji@0:    matches (elem foo) or (bar blat).
yuuji@0: 
yuuji@0:    NOTE:
yuuji@0: 
yuuji@0:       It is strongly advised that grouping notation be used, rather than
yuuji@0:       relying on the proper reading of "bare" alternations, when
yuuji@0:       alternatives consist of multiple rule names or literals.
yuuji@0: 
yuuji@0:    Hence, it is recommended that the following form be used:
yuuji@0: 
yuuji@0:         (elem foo) / (bar blat)
yuuji@0: 
yuuji@0:    It will avoid misinterpretation by casual readers.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 8]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0:    The sequence group notation is also used within free text to set off
yuuji@0:    an element sequence from the prose.
yuuji@0: 
yuuji@0: 3.6.  Variable Repetition:  *Rule
yuuji@0: 
yuuji@0:    The operator "*" preceding an element indicates repetition.  The full
yuuji@0:    form is:
yuuji@0: 
yuuji@0:          <a>*<b>element
yuuji@0: 
yuuji@0:    where <a> and <b> are optional decimal values, indicating at least
yuuji@0:    <a> and at most <b> occurrences of the element.
yuuji@0: 
yuuji@0:    Default values are 0 and infinity so that *<element> allows any
yuuji@0:    number, including zero; 1*<element> requires at least one;
yuuji@0:    3*3<element> allows exactly 3; and 1*2<element> allows one or two.
yuuji@0: 
yuuji@0: 3.7.  Specific Repetition:  nRule
yuuji@0: 
yuuji@0:    A rule of the form:
yuuji@0: 
yuuji@0:          <n>element
yuuji@0: 
yuuji@0:    is equivalent to
yuuji@0: 
yuuji@0:          <n>*<n>element
yuuji@0: 
yuuji@0:    That is, exactly <n> occurrences of <element>.  Thus, 2DIGIT is a
yuuji@0:    2-digit number, and 3ALPHA is a string of three alphabetic
yuuji@0:    characters.
yuuji@0: 
yuuji@0: 3.8.  Optional Sequence:  [RULE]
yuuji@0: 
yuuji@0:    Square brackets enclose an optional element sequence:
yuuji@0: 
yuuji@0:          [foo bar]
yuuji@0: 
yuuji@0:    is equivalent to
yuuji@0: 
yuuji@0:          *1(foo bar).
yuuji@0: 
yuuji@0: 3.9.  Comment:  ; Comment
yuuji@0: 
yuuji@0:    A semicolon starts a comment that continues to the end of line.  This
yuuji@0:    is a simple way of including useful notes in parallel with the
yuuji@0:    specifications.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                     [Page 9]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: 3.10.  Operator Precedence
yuuji@0: 
yuuji@0:    The various mechanisms described above have the following precedence,
yuuji@0:    from highest (binding tightest) at the top, to lowest (loosest) at
yuuji@0:    the bottom:
yuuji@0: 
yuuji@0:       Rule name, prose-val, Terminal value
yuuji@0: 
yuuji@0:       Comment
yuuji@0: 
yuuji@0:       Value range
yuuji@0: 
yuuji@0:       Repetition
yuuji@0: 
yuuji@0:       Grouping, Optional
yuuji@0: 
yuuji@0:       Concatenation
yuuji@0: 
yuuji@0:       Alternative
yuuji@0: 
yuuji@0:    Use of the alternative operator, freely mixed with concatenations,
yuuji@0:    can be confusing.
yuuji@0: 
yuuji@0:       Again, it is recommended that the grouping operator be used to
yuuji@0:       make explicit concatenation groups.
yuuji@0: 
yuuji@0: 4.  ABNF Definition of ABNF
yuuji@0: 
yuuji@0:    NOTES:
yuuji@0: 
yuuji@0:       1.  This syntax requires a formatting of rules that is relatively
yuuji@0:           strict.  Hence, the version of a ruleset included in a
yuuji@0:           specification might need preprocessing to ensure that it can
yuuji@0:           be interpreted by an ABNF parser.
yuuji@0: 
yuuji@0:       2.  This syntax uses the rules provided in Appendix B.
yuuji@0: 
yuuji@0: 
yuuji@0:          rulelist       =  1*( rule / (*c-wsp c-nl) )
yuuji@0: 
yuuji@0:          rule           =  rulename defined-as elements c-nl
yuuji@0:                                 ; continues if next line starts
yuuji@0:                                 ;  with white space
yuuji@0: 
yuuji@0:          rulename       =  ALPHA *(ALPHA / DIGIT / "-")
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                    [Page 10]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0:          defined-as     =  *c-wsp ("=" / "=/") *c-wsp
yuuji@0:                                 ; basic rules definition and
yuuji@0:                                 ;  incremental alternatives
yuuji@0: 
yuuji@0:          elements       =  alternation *c-wsp
yuuji@0: 
yuuji@0:          c-wsp          =  WSP / (c-nl WSP)
yuuji@0: 
yuuji@0:          c-nl           =  comment / CRLF
yuuji@0:                                 ; comment or newline
yuuji@0: 
yuuji@0:          comment        =  ";" *(WSP / VCHAR) CRLF
yuuji@0: 
yuuji@0:          alternation    =  concatenation
yuuji@0:                            *(*c-wsp "/" *c-wsp concatenation)
yuuji@0: 
yuuji@0:          concatenation  =  repetition *(1*c-wsp repetition)
yuuji@0: 
yuuji@0:          repetition     =  [repeat] element
yuuji@0: 
yuuji@0:          repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)
yuuji@0: 
yuuji@0:          element        =  rulename / group / option /
yuuji@0:                            char-val / num-val / prose-val
yuuji@0: 
yuuji@0:          group          =  "(" *c-wsp alternation *c-wsp ")"
yuuji@0: 
yuuji@0:          option         =  "[" *c-wsp alternation *c-wsp "]"
yuuji@0: 
yuuji@0:          char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
yuuji@0:                                 ; quoted string of SP and VCHAR
yuuji@0:                                 ;  without DQUOTE
yuuji@0: 
yuuji@0:          num-val        =  "%" (bin-val / dec-val / hex-val)
yuuji@0: 
yuuji@0:          bin-val        =  "b" 1*BIT
yuuji@0:                            [ 1*("." 1*BIT) / ("-" 1*BIT) ]
yuuji@0:                                 ; series of concatenated bit values
yuuji@0:                                 ;  or single ONEOF range
yuuji@0: 
yuuji@0:          dec-val        =  "d" 1*DIGIT
yuuji@0:                            [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
yuuji@0: 
yuuji@0:          hex-val        =  "x" 1*HEXDIG
yuuji@0:                            [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                    [Page 11]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0:          prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
yuuji@0:                                 ; bracketed string of SP and VCHAR
yuuji@0:                                 ;  without angles
yuuji@0:                                 ; prose description, to be used as
yuuji@0:                                 ;  last resort
yuuji@0: 
yuuji@0: 5.  Security Considerations
yuuji@0: 
yuuji@0:    Security is truly believed to be irrelevant to this document.
yuuji@0: 
yuuji@0: 6.  References
yuuji@0: 
yuuji@0: 6.1.  Normative References
yuuji@0: 
yuuji@0:    [US-ASCII]  American National Standards Institute, "Coded Character
yuuji@0:                Set -- 7-bit American Standard Code for Information
yuuji@0:                Interchange", ANSI X3.4, 1986.
yuuji@0: 
yuuji@0: 6.2.  Informative References
yuuji@0: 
yuuji@0:    [RFC733]    Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
yuuji@0:                "Standard for the format of ARPA network text messages",
yuuji@0:                RFC 733, November 1977.
yuuji@0: 
yuuji@0:    [RFC822]    Crocker, D., "Standard for the format of ARPA Internet
yuuji@0:                text messages", STD 11, RFC 822, August 1982.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                    [Page 12]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: Appendix A.  Acknowledgements
yuuji@0: 
yuuji@0:    The syntax for ABNF was originally specified in RFC 733.  Ken L.
yuuji@0:    Harrenstien, of SRI International, was responsible for re-coding the
yuuji@0:    BNF into an Augmented BNF that makes the representation smaller and
yuuji@0:    easier to understand.
yuuji@0: 
yuuji@0:    This recent project began as a simple effort to cull out the portion
yuuji@0:    of RFC 822 that has been repeatedly cited by non-email specification
yuuji@0:    writers, namely the description of Augmented BNF.  Rather than simply
yuuji@0:    and blindly converting the existing text into a separate document,
yuuji@0:    the working group chose to give careful consideration to the
yuuji@0:    deficiencies, as well as benefits, of the existing specification and
yuuji@0:    related specifications made available over the last 15 years, and
yuuji@0:    therefore to pursue enhancement.  This turned the project into
yuuji@0:    something rather more ambitious than was first intended.
yuuji@0:    Interestingly, the result is not massively different from that
yuuji@0:    original, although decisions, such as removing the list notation,
yuuji@0:    came as a surprise.
yuuji@0: 
yuuji@0:    This "separated" version of the specification was part of the DRUMS
yuuji@0:    working group, with significant contributions from Jerome Abela,
yuuji@0:    Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom
yuuji@0:    Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete
yuuji@0:    Resnick, and Henning Schulzrinne.
yuuji@0: 
yuuji@0:    Julian Reschke warrants a special thanks for converting the Draft
yuuji@0:    Standard version to XML source form.
yuuji@0: 
yuuji@0: Appendix B.  Core ABNF of ABNF
yuuji@0: 
yuuji@0:    This appendix contains some basic rules that are in common use.
yuuji@0:    Basic rules are in uppercase.  Note that these rules are only valid
yuuji@0:    for ABNF encoded in 7-bit ASCII or in characters sets that are a
yuuji@0:    superset of 7-bit ASCII.
yuuji@0: 
yuuji@0: B.1.  Core Rules
yuuji@0: 
yuuji@0:    Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT,
yuuji@0:    ALPHA, etc.
yuuji@0: 
yuuji@0:          ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
yuuji@0: 
yuuji@0:          BIT            =  "0" / "1"
yuuji@0: 
yuuji@0:          CHAR           =  %x01-7F
yuuji@0:                                 ; any 7-bit US-ASCII character,
yuuji@0:                                 ;  excluding NUL
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                    [Page 13]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0:          CR             =  %x0D
yuuji@0:                                 ; carriage return
yuuji@0: 
yuuji@0:          CRLF           =  CR LF
yuuji@0:                                 ; Internet standard newline
yuuji@0: 
yuuji@0:          CTL            =  %x00-1F / %x7F
yuuji@0:                                 ; controls
yuuji@0: 
yuuji@0:          DIGIT          =  %x30-39
yuuji@0:                                 ; 0-9
yuuji@0: 
yuuji@0:          DQUOTE         =  %x22
yuuji@0:                                 ; " (Double Quote)
yuuji@0: 
yuuji@0:          HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
yuuji@0: 
yuuji@0:          HTAB           =  %x09
yuuji@0:                                 ; horizontal tab
yuuji@0: 
yuuji@0:          LF             =  %x0A
yuuji@0:                                 ; linefeed
yuuji@0: 
yuuji@0:          LWSP           =  *(WSP / CRLF WSP)
yuuji@0:                                 ; Use of this linear-white-space rule
yuuji@0:                                 ;  permits lines containing only white
yuuji@0:                                 ;  space that are no longer legal in
yuuji@0:                                 ;  mail headers and have caused
yuuji@0:                                 ;  interoperability problems in other
yuuji@0:                                 ;  contexts.
yuuji@0:                                 ; Do not use when defining mail
yuuji@0:                                 ;  headers and use with caution in
yuuji@0:                                 ;  other contexts.
yuuji@0: 
yuuji@0:          OCTET          =  %x00-FF
yuuji@0:                                 ; 8 bits of data
yuuji@0: 
yuuji@0:          SP             =  %x20
yuuji@0: 
yuuji@0:          VCHAR          =  %x21-7E
yuuji@0:                                 ; visible (printing) characters
yuuji@0: 
yuuji@0:          WSP            =  SP / HTAB
yuuji@0:                                 ; white space
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                    [Page 14]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: B.2.  Common Encoding
yuuji@0: 
yuuji@0:    Externally, data are represented as "network virtual ASCII" (namely,
yuuji@0:    7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
yuuji@0:    zero.  A string of values is in "network byte order", in which the
yuuji@0:    higher-valued bytes are represented on the left-hand side and are
yuuji@0:    sent over the network first.
yuuji@0: 
yuuji@0: Authors' Addresses
yuuji@0: 
yuuji@0:    Dave Crocker (editor)
yuuji@0:    Brandenburg InternetWorking
yuuji@0:    675 Spruce Dr.
yuuji@0:    Sunnyvale, CA  94086
yuuji@0:    US
yuuji@0: 
yuuji@0:    Phone: +1.408.246.8253
yuuji@0:    EMail: dcrocker@bbiw.net
yuuji@0: 
yuuji@0: 
yuuji@0:    Paul Overell
yuuji@0:    THUS plc.
yuuji@0:    1/2 Berkeley Square,
yuuji@0:    99 Berkeley Street
yuuji@0:    Glasgow  G3 7HR
yuuji@0:    UK
yuuji@0: 
yuuji@0:    EMail: paul.overell@thus.net
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                    [Page 15]
yuuji@0: 
yuuji@0: RFC 5234                          ABNF                      January 2008
yuuji@0: 
yuuji@0: 
yuuji@0: Full Copyright Statement
yuuji@0: 
yuuji@0:    Copyright (C) The IETF Trust (2008).
yuuji@0: 
yuuji@0:    This document is subject to the rights, licenses and restrictions
yuuji@0:    contained in BCP 78, and except as set forth therein, the authors
yuuji@0:    retain all their rights.
yuuji@0: 
yuuji@0:    This document and the information contained herein are provided on an
yuuji@0:    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0:    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
yuuji@0:    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
yuuji@0:    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
yuuji@0:    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0:    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0: 
yuuji@0: Intellectual Property
yuuji@0: 
yuuji@0:    The IETF takes no position regarding the validity or scope of any
yuuji@0:    Intellectual Property Rights or other rights that might be claimed to
yuuji@0:    pertain to the implementation or use of the technology described in
yuuji@0:    this document or the extent to which any license under such rights
yuuji@0:    might or might not be available; nor does it represent that it has
yuuji@0:    made any independent effort to identify any such rights.  Information
yuuji@0:    on the procedures with respect to rights in RFC documents can be
yuuji@0:    found in BCP 78 and BCP 79.
yuuji@0: 
yuuji@0:    Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0:    assurances of licenses to be made available, or the result of an
yuuji@0:    attempt made to obtain a general license or permission for the use of
yuuji@0:    such proprietary rights by implementers or users of this
yuuji@0:    specification can be obtained from the IETF on-line IPR repository at
yuuji@0:    http://www.ietf.org/ipr.
yuuji@0: 
yuuji@0:    The IETF invites any interested party to bring to its attention any
yuuji@0:    copyrights, patents or patent applications, or other proprietary
yuuji@0:    rights that may cover technology that may be required to implement
yuuji@0:    this standard.  Please address the information to the IETF at
yuuji@0:    ietf-ipr@ietf.org.
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: 
yuuji@0: Crocker & Overell           Standards Track                    [Page 16]
yuuji@0: