1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc5234.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,899 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                    D. Crocker, Ed.
    1.11 +Request for Comments: 5234                   Brandenburg InternetWorking
    1.12 +STD: 68                                                       P. Overell
    1.13 +Obsoletes: 4234                                                THUS plc.
    1.14 +Category: Standards Track                                   January 2008
    1.15 +
    1.16 +
    1.17 +             Augmented BNF for Syntax Specifications: ABNF
    1.18 +
    1.19 +Status of This Memo
    1.20 +
    1.21 +   This document specifies an Internet standards track protocol for the
    1.22 +   Internet community, and requests discussion and suggestions for
    1.23 +   improvements.  Please refer to the current edition of the "Internet
    1.24 +   Official Protocol Standards" (STD 1) for the standardization state
    1.25 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.26 +
    1.27 +Abstract
    1.28 +
    1.29 +   Internet technical specifications often need to define a formal
    1.30 +   syntax.  Over the years, a modified version of Backus-Naur Form
    1.31 +   (BNF), called Augmented BNF (ABNF), has been popular among many
    1.32 +   Internet specifications.  The current specification documents ABNF.
    1.33 +   It balances compactness and simplicity with reasonable
    1.34 +   representational power.  The differences between standard BNF and
    1.35 +   ABNF involve naming rules, repetition, alternatives, order-
    1.36 +   independence, and value ranges.  This specification also supplies
    1.37 +   additional rule definitions and encoding for a core lexical analyzer
    1.38 +   of the type common to several Internet specifications.
    1.39 +
    1.40 +
    1.41 +
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Crocker & Overell           Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 5234                          ABNF                      January 2008
    1.64 +
    1.65 +
    1.66 +Table of Contents
    1.67 +
    1.68 +   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    1.69 +   2.  Rule Definition  . . . . . . . . . . . . . . . . . . . . . . .  3
    1.70 +     2.1.  Rule Naming  . . . . . . . . . . . . . . . . . . . . . . .  3
    1.71 +     2.2.  Rule Form  . . . . . . . . . . . . . . . . . . . . . . . .  4
    1.72 +     2.3.  Terminal Values  . . . . . . . . . . . . . . . . . . . . .  4
    1.73 +     2.4.  External Encodings . . . . . . . . . . . . . . . . . . . .  6
    1.74 +   3.  Operators  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
    1.75 +     3.1.  Concatenation:  Rule1 Rule2  . . . . . . . . . . . . . . .  6
    1.76 +     3.2.  Alternatives:  Rule1 / Rule2 . . . . . . . . . . . . . . .  7
    1.77 +     3.3.  Incremental Alternatives: Rule1 =/ Rule2 . . . . . . . . .  7
    1.78 +     3.4.  Value Range Alternatives:  %c##-## . . . . . . . . . . . .  8
    1.79 +     3.5.  Sequence Group:  (Rule1 Rule2) . . . . . . . . . . . . . .  8
    1.80 +     3.6.  Variable Repetition:  *Rule  . . . . . . . . . . . . . . .  9
    1.81 +     3.7.  Specific Repetition:  nRule  . . . . . . . . . . . . . . .  9
    1.82 +     3.8.  Optional Sequence:  [RULE] . . . . . . . . . . . . . . . .  9
    1.83 +     3.9.  Comment:  ; Comment  . . . . . . . . . . . . . . . . . . .  9
    1.84 +     3.10. Operator Precedence  . . . . . . . . . . . . . . . . . . . 10
    1.85 +   4.  ABNF Definition of ABNF  . . . . . . . . . . . . . . . . . . . 10
    1.86 +   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
    1.87 +   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
    1.88 +     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
    1.89 +     6.2.  Informative References . . . . . . . . . . . . . . . . . . 12
    1.90 +   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 13
    1.91 +   Appendix B.  Core ABNF of ABNF . . . . . . . . . . . . . . . . . . 13
    1.92 +     B.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
    1.93 +     B.2.  Common Encoding  . . . . . . . . . . . . . . . . . . . . . 15
    1.94 +
    1.95 +
    1.96 +
    1.97 +
    1.98 +
    1.99 +
   1.100 +
   1.101 +
   1.102 +
   1.103 +
   1.104 +
   1.105 +
   1.106 +
   1.107 +
   1.108 +
   1.109 +
   1.110 +
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Crocker & Overell           Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 5234                          ABNF                      January 2008
   1.120 +
   1.121 +
   1.122 +1.  Introduction
   1.123 +
   1.124 +   Internet technical specifications often need to define a formal
   1.125 +   syntax and are free to employ whatever notation their authors deem
   1.126 +   useful.  Over the years, a modified version of Backus-Naur Form
   1.127 +   (BNF), called Augmented BNF (ABNF), has been popular among many
   1.128 +   Internet specifications.  It balances compactness and simplicity with
   1.129 +   reasonable representational power.  In the early days of the Arpanet,
   1.130 +   each specification contained its own definition of ABNF.  This
   1.131 +   included the email specifications, [RFC733] and then [RFC822], which
   1.132 +   came to be the common citations for defining ABNF.  The current
   1.133 +   document separates those definitions to permit selective reference.
   1.134 +   Predictably, it also provides some modifications and enhancements.
   1.135 +
   1.136 +   The differences between standard BNF and ABNF involve naming rules,
   1.137 +   repetition, alternatives, order-independence, and value ranges.
   1.138 +   Appendix B supplies rule definitions and encoding for a core lexical
   1.139 +   analyzer of the type common to several Internet specifications.  It
   1.140 +   is provided as a convenience and is otherwise separate from the meta
   1.141 +   language defined in the body of this document, and separate from its
   1.142 +   formal status.
   1.143 +
   1.144 +2.  Rule Definition
   1.145 +
   1.146 +2.1.  Rule Naming
   1.147 +
   1.148 +   The name of a rule is simply the name itself, that is, a sequence of
   1.149 +   characters, beginning with an alphabetic character, and followed by a
   1.150 +   combination of alphabetics, digits, and hyphens (dashes).
   1.151 +
   1.152 +   NOTE:
   1.153 +
   1.154 +      Rule names are case insensitive.
   1.155 +
   1.156 +   The names <rulename>, <Rulename>, <RULENAME>, and <rUlENamE> all
   1.157 +   refer to the same rule.
   1.158 +
   1.159 +   Unlike original BNF, angle brackets ("<", ">") are not required.
   1.160 +   However, angle brackets may be used around a rule name whenever their
   1.161 +   presence facilitates in discerning the use of a rule name.  This is
   1.162 +   typically restricted to rule name references in free-form prose, or
   1.163 +   to distinguish partial rules that combine into a string not separated
   1.164 +   by white space, such as shown in the discussion about repetition,
   1.165 +   below.
   1.166 +
   1.167 +
   1.168 +
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Crocker & Overell           Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 5234                          ABNF                      January 2008
   1.176 +
   1.177 +
   1.178 +2.2.  Rule Form
   1.179 +
   1.180 +   A rule is defined by the following sequence:
   1.181 +
   1.182 +         name =  elements crlf
   1.183 +
   1.184 +   where <name> is the name of the rule, <elements> is one or more rule
   1.185 +   names or terminal specifications, and <crlf> is the end-of-line
   1.186 +   indicator (carriage return followed by line feed).  The equal sign
   1.187 +   separates the name from the definition of the rule.  The elements
   1.188 +   form a sequence of one or more rule names and/or value definitions,
   1.189 +   combined according to the various operators defined in this document,
   1.190 +   such as alternative and repetition.
   1.191 +
   1.192 +   For visual ease, rule definitions are left aligned.  When a rule
   1.193 +   requires multiple lines, the continuation lines are indented.  The
   1.194 +   left alignment and indentation are relative to the first lines of the
   1.195 +   ABNF rules and need not match the left margin of the document.
   1.196 +
   1.197 +2.3.  Terminal Values
   1.198 +
   1.199 +   Rules resolve into a string of terminal values, sometimes called
   1.200 +   characters.  In ABNF, a character is merely a non-negative integer.
   1.201 +   In certain contexts, a specific mapping (encoding) of values into a
   1.202 +   character set (such as ASCII) will be specified.
   1.203 +
   1.204 +   Terminals are specified by one or more numeric characters, with the
   1.205 +   base interpretation of those characters indicated explicitly.  The
   1.206 +   following bases are currently defined:
   1.207 +
   1.208 +         b           =  binary
   1.209 +
   1.210 +         d           =  decimal
   1.211 +
   1.212 +         x           =  hexadecimal
   1.213 +
   1.214 +   Hence:
   1.215 +
   1.216 +         CR          =  %d13
   1.217 +
   1.218 +         CR          =  %x0D
   1.219 +
   1.220 +   respectively specify the decimal and hexadecimal representation of
   1.221 +   [US-ASCII] for carriage return.
   1.222 +
   1.223 +
   1.224 +
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Crocker & Overell           Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 5234                          ABNF                      January 2008
   1.232 +
   1.233 +
   1.234 +   A concatenated string of such values is specified compactly, using a
   1.235 +   period (".") to indicate a separation of characters within that
   1.236 +   value.  Hence:
   1.237 +
   1.238 +         CRLF        =  %d13.10
   1.239 +
   1.240 +   ABNF permits the specification of literal text strings directly,
   1.241 +   enclosed in quotation marks.  Hence:
   1.242 +
   1.243 +         command     =  "command string"
   1.244 +
   1.245 +   Literal text strings are interpreted as a concatenated set of
   1.246 +   printable characters.
   1.247 +
   1.248 +   NOTE:
   1.249 +
   1.250 +      ABNF strings are case insensitive and the character set for these
   1.251 +      strings is US-ASCII.
   1.252 +
   1.253 +   Hence:
   1.254 +
   1.255 +         rulename = "abc"
   1.256 +
   1.257 +   and:
   1.258 +
   1.259 +         rulename = "aBc"
   1.260 +
   1.261 +   will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
   1.262 +   "ABC".
   1.263 +
   1.264 +      To specify a rule that is case sensitive, specify the characters
   1.265 +      individually.
   1.266 +
   1.267 +   For example:
   1.268 +
   1.269 +         rulename    =  %d97 %d98 %d99
   1.270 +
   1.271 +   or
   1.272 +
   1.273 +         rulename    =  %d97.98.99
   1.274 +
   1.275 +   will match only the string that comprises only the lowercase
   1.276 +   characters, abc.
   1.277 +
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Crocker & Overell           Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 5234                          ABNF                      January 2008
   1.288 +
   1.289 +
   1.290 +2.4.  External Encodings
   1.291 +
   1.292 +   External representations of terminal value characters will vary
   1.293 +   according to constraints in the storage or transmission environment.
   1.294 +   Hence, the same ABNF-based grammar may have multiple external
   1.295 +   encodings, such as one for a 7-bit US-ASCII environment, another for
   1.296 +   a binary octet environment, and still a different one when 16-bit
   1.297 +   Unicode is used.  Encoding details are beyond the scope of ABNF,
   1.298 +   although Appendix B provides definitions for a 7-bit US-ASCII
   1.299 +   environment as has been common to much of the Internet.
   1.300 +
   1.301 +   By separating external encoding from the syntax, it is intended that
   1.302 +   alternate encoding environments can be used for the same syntax.
   1.303 +
   1.304 +3.  Operators
   1.305 +
   1.306 +3.1.  Concatenation:  Rule1 Rule2
   1.307 +
   1.308 +   A rule can define a simple, ordered string of values (i.e., a
   1.309 +   concatenation of contiguous characters) by listing a sequence of rule
   1.310 +   names.  For example:
   1.311 +
   1.312 +         foo         =  %x61           ; a
   1.313 +
   1.314 +         bar         =  %x62           ; b
   1.315 +
   1.316 +         mumble      =  foo bar foo
   1.317 +
   1.318 +   So that the rule <mumble> matches the lowercase string "aba".
   1.319 +
   1.320 +   Linear white space: Concatenation is at the core of the ABNF parsing
   1.321 +   model.  A string of contiguous characters (values) is parsed
   1.322 +   according to the rules defined in ABNF.  For Internet specifications,
   1.323 +   there is some history of permitting linear white space (space and
   1.324 +   horizontal tab) to be freely and implicitly interspersed around major
   1.325 +   constructs, such as delimiting special characters or atomic strings.
   1.326 +
   1.327 +   NOTE:
   1.328 +
   1.329 +      This specification for ABNF does not provide for implicit
   1.330 +      specification of linear white space.
   1.331 +
   1.332 +   Any grammar that wishes to permit linear white space around
   1.333 +   delimiters or string segments must specify it explicitly.  It is
   1.334 +   often useful to provide for such white space in "core" rules that are
   1.335 +   then used variously among higher-level rules.  The "core" rules might
   1.336 +   be formed into a lexical analyzer or simply be part of the main
   1.337 +   ruleset.
   1.338 +
   1.339 +
   1.340 +
   1.341 +Crocker & Overell           Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 5234                          ABNF                      January 2008
   1.344 +
   1.345 +
   1.346 +3.2.  Alternatives:  Rule1 / Rule2
   1.347 +
   1.348 +   Elements separated by a forward slash ("/") are alternatives.
   1.349 +   Therefore,
   1.350 +
   1.351 +         foo / bar
   1.352 +
   1.353 +   will accept <foo> or <bar>.
   1.354 +
   1.355 +   NOTE:
   1.356 +
   1.357 +      A quoted string containing alphabetic characters is a special form
   1.358 +      for specifying alternative characters and is interpreted as a non-
   1.359 +      terminal representing the set of combinatorial strings with the
   1.360 +      contained characters, in the specified order but with any mixture
   1.361 +      of upper- and lowercase.
   1.362 +
   1.363 +3.3.  Incremental Alternatives: Rule1 =/ Rule2
   1.364 +
   1.365 +   It is sometimes convenient to specify a list of alternatives in
   1.366 +   fragments.  That is, an initial rule may match one or more
   1.367 +   alternatives, with later rule definitions adding to the set of
   1.368 +   alternatives.  This is particularly useful for otherwise independent
   1.369 +   specifications that derive from the same parent ruleset, such as
   1.370 +   often occurs with parameter lists.  ABNF permits this incremental
   1.371 +   definition through the construct:
   1.372 +
   1.373 +         oldrule     =/ additional-alternatives
   1.374 +
   1.375 +   So that the ruleset
   1.376 +
   1.377 +         ruleset     =  alt1 / alt2
   1.378 +
   1.379 +         ruleset     =/ alt3
   1.380 +
   1.381 +         ruleset     =/ alt4 / alt5
   1.382 +
   1.383 +   is the same as specifying
   1.384 +
   1.385 +         ruleset     =  alt1 / alt2 / alt3 / alt4 / alt5
   1.386 +
   1.387 +
   1.388 +
   1.389 +
   1.390 +
   1.391 +
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Crocker & Overell           Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 5234                          ABNF                      January 2008
   1.400 +
   1.401 +
   1.402 +3.4.  Value Range Alternatives:  %c##-##
   1.403 +
   1.404 +   A range of alternative numeric values can be specified compactly,
   1.405 +   using a dash ("-") to indicate the range of alternative values.
   1.406 +   Hence:
   1.407 +
   1.408 +         DIGIT       =  %x30-39
   1.409 +
   1.410 +   is equivalent to:
   1.411 +
   1.412 +         DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" /
   1.413 +
   1.414 +                        "7" / "8" / "9"
   1.415 +
   1.416 +   Concatenated numeric values and numeric value ranges cannot be
   1.417 +   specified in the same string.  A numeric value may use the dotted
   1.418 +   notation for concatenation or it may use the dash notation to specify
   1.419 +   one value range.  Hence, to specify one printable character between
   1.420 +   end-of-line sequences, the specification could be:
   1.421 +
   1.422 +         char-line = %x0D.0A %x20-7E %x0D.0A
   1.423 +
   1.424 +3.5.  Sequence Group:  (Rule1 Rule2)
   1.425 +
   1.426 +   Elements enclosed in parentheses are treated as a single element,
   1.427 +   whose contents are strictly ordered.  Thus,
   1.428 +
   1.429 +         elem (foo / bar) blat
   1.430 +
   1.431 +   matches (elem foo blat) or (elem bar blat), and
   1.432 +
   1.433 +         elem foo / bar blat
   1.434 +
   1.435 +   matches (elem foo) or (bar blat).
   1.436 +
   1.437 +   NOTE:
   1.438 +
   1.439 +      It is strongly advised that grouping notation be used, rather than
   1.440 +      relying on the proper reading of "bare" alternations, when
   1.441 +      alternatives consist of multiple rule names or literals.
   1.442 +
   1.443 +   Hence, it is recommended that the following form be used:
   1.444 +
   1.445 +        (elem foo) / (bar blat)
   1.446 +
   1.447 +   It will avoid misinterpretation by casual readers.
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Crocker & Overell           Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 5234                          ABNF                      January 2008
   1.456 +
   1.457 +
   1.458 +   The sequence group notation is also used within free text to set off
   1.459 +   an element sequence from the prose.
   1.460 +
   1.461 +3.6.  Variable Repetition:  *Rule
   1.462 +
   1.463 +   The operator "*" preceding an element indicates repetition.  The full
   1.464 +   form is:
   1.465 +
   1.466 +         <a>*<b>element
   1.467 +
   1.468 +   where <a> and <b> are optional decimal values, indicating at least
   1.469 +   <a> and at most <b> occurrences of the element.
   1.470 +
   1.471 +   Default values are 0 and infinity so that *<element> allows any
   1.472 +   number, including zero; 1*<element> requires at least one;
   1.473 +   3*3<element> allows exactly 3; and 1*2<element> allows one or two.
   1.474 +
   1.475 +3.7.  Specific Repetition:  nRule
   1.476 +
   1.477 +   A rule of the form:
   1.478 +
   1.479 +         <n>element
   1.480 +
   1.481 +   is equivalent to
   1.482 +
   1.483 +         <n>*<n>element
   1.484 +
   1.485 +   That is, exactly <n> occurrences of <element>.  Thus, 2DIGIT is a
   1.486 +   2-digit number, and 3ALPHA is a string of three alphabetic
   1.487 +   characters.
   1.488 +
   1.489 +3.8.  Optional Sequence:  [RULE]
   1.490 +
   1.491 +   Square brackets enclose an optional element sequence:
   1.492 +
   1.493 +         [foo bar]
   1.494 +
   1.495 +   is equivalent to
   1.496 +
   1.497 +         *1(foo bar).
   1.498 +
   1.499 +3.9.  Comment:  ; Comment
   1.500 +
   1.501 +   A semicolon starts a comment that continues to the end of line.  This
   1.502 +   is a simple way of including useful notes in parallel with the
   1.503 +   specifications.
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Crocker & Overell           Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 5234                          ABNF                      January 2008
   1.512 +
   1.513 +
   1.514 +3.10.  Operator Precedence
   1.515 +
   1.516 +   The various mechanisms described above have the following precedence,
   1.517 +   from highest (binding tightest) at the top, to lowest (loosest) at
   1.518 +   the bottom:
   1.519 +
   1.520 +      Rule name, prose-val, Terminal value
   1.521 +
   1.522 +      Comment
   1.523 +
   1.524 +      Value range
   1.525 +
   1.526 +      Repetition
   1.527 +
   1.528 +      Grouping, Optional
   1.529 +
   1.530 +      Concatenation
   1.531 +
   1.532 +      Alternative
   1.533 +
   1.534 +   Use of the alternative operator, freely mixed with concatenations,
   1.535 +   can be confusing.
   1.536 +
   1.537 +      Again, it is recommended that the grouping operator be used to
   1.538 +      make explicit concatenation groups.
   1.539 +
   1.540 +4.  ABNF Definition of ABNF
   1.541 +
   1.542 +   NOTES:
   1.543 +
   1.544 +      1.  This syntax requires a formatting of rules that is relatively
   1.545 +          strict.  Hence, the version of a ruleset included in a
   1.546 +          specification might need preprocessing to ensure that it can
   1.547 +          be interpreted by an ABNF parser.
   1.548 +
   1.549 +      2.  This syntax uses the rules provided in Appendix B.
   1.550 +
   1.551 +
   1.552 +         rulelist       =  1*( rule / (*c-wsp c-nl) )
   1.553 +
   1.554 +         rule           =  rulename defined-as elements c-nl
   1.555 +                                ; continues if next line starts
   1.556 +                                ;  with white space
   1.557 +
   1.558 +         rulename       =  ALPHA *(ALPHA / DIGIT / "-")
   1.559 +
   1.560 +
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Crocker & Overell           Standards Track                    [Page 10]
   1.566 +
   1.567 +RFC 5234                          ABNF                      January 2008
   1.568 +
   1.569 +
   1.570 +         defined-as     =  *c-wsp ("=" / "=/") *c-wsp
   1.571 +                                ; basic rules definition and
   1.572 +                                ;  incremental alternatives
   1.573 +
   1.574 +         elements       =  alternation *c-wsp
   1.575 +
   1.576 +         c-wsp          =  WSP / (c-nl WSP)
   1.577 +
   1.578 +         c-nl           =  comment / CRLF
   1.579 +                                ; comment or newline
   1.580 +
   1.581 +         comment        =  ";" *(WSP / VCHAR) CRLF
   1.582 +
   1.583 +         alternation    =  concatenation
   1.584 +                           *(*c-wsp "/" *c-wsp concatenation)
   1.585 +
   1.586 +         concatenation  =  repetition *(1*c-wsp repetition)
   1.587 +
   1.588 +         repetition     =  [repeat] element
   1.589 +
   1.590 +         repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)
   1.591 +
   1.592 +         element        =  rulename / group / option /
   1.593 +                           char-val / num-val / prose-val
   1.594 +
   1.595 +         group          =  "(" *c-wsp alternation *c-wsp ")"
   1.596 +
   1.597 +         option         =  "[" *c-wsp alternation *c-wsp "]"
   1.598 +
   1.599 +         char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
   1.600 +                                ; quoted string of SP and VCHAR
   1.601 +                                ;  without DQUOTE
   1.602 +
   1.603 +         num-val        =  "%" (bin-val / dec-val / hex-val)
   1.604 +
   1.605 +         bin-val        =  "b" 1*BIT
   1.606 +                           [ 1*("." 1*BIT) / ("-" 1*BIT) ]
   1.607 +                                ; series of concatenated bit values
   1.608 +                                ;  or single ONEOF range
   1.609 +
   1.610 +         dec-val        =  "d" 1*DIGIT
   1.611 +                           [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
   1.612 +
   1.613 +         hex-val        =  "x" 1*HEXDIG
   1.614 +                           [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
   1.615 +
   1.616 +
   1.617 +
   1.618 +
   1.619 +
   1.620 +
   1.621 +Crocker & Overell           Standards Track                    [Page 11]
   1.622 +
   1.623 +RFC 5234                          ABNF                      January 2008
   1.624 +
   1.625 +
   1.626 +         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
   1.627 +                                ; bracketed string of SP and VCHAR
   1.628 +                                ;  without angles
   1.629 +                                ; prose description, to be used as
   1.630 +                                ;  last resort
   1.631 +
   1.632 +5.  Security Considerations
   1.633 +
   1.634 +   Security is truly believed to be irrelevant to this document.
   1.635 +
   1.636 +6.  References
   1.637 +
   1.638 +6.1.  Normative References
   1.639 +
   1.640 +   [US-ASCII]  American National Standards Institute, "Coded Character
   1.641 +               Set -- 7-bit American Standard Code for Information
   1.642 +               Interchange", ANSI X3.4, 1986.
   1.643 +
   1.644 +6.2.  Informative References
   1.645 +
   1.646 +   [RFC733]    Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
   1.647 +               "Standard for the format of ARPA network text messages",
   1.648 +               RFC 733, November 1977.
   1.649 +
   1.650 +   [RFC822]    Crocker, D., "Standard for the format of ARPA Internet
   1.651 +               text messages", STD 11, RFC 822, August 1982.
   1.652 +
   1.653 +
   1.654 +
   1.655 +
   1.656 +
   1.657 +
   1.658 +
   1.659 +
   1.660 +
   1.661 +
   1.662 +
   1.663 +
   1.664 +
   1.665 +
   1.666 +
   1.667 +
   1.668 +
   1.669 +
   1.670 +
   1.671 +
   1.672 +
   1.673 +
   1.674 +
   1.675 +
   1.676 +
   1.677 +Crocker & Overell           Standards Track                    [Page 12]
   1.678 +
   1.679 +RFC 5234                          ABNF                      January 2008
   1.680 +
   1.681 +
   1.682 +Appendix A.  Acknowledgements
   1.683 +
   1.684 +   The syntax for ABNF was originally specified in RFC 733.  Ken L.
   1.685 +   Harrenstien, of SRI International, was responsible for re-coding the
   1.686 +   BNF into an Augmented BNF that makes the representation smaller and
   1.687 +   easier to understand.
   1.688 +
   1.689 +   This recent project began as a simple effort to cull out the portion
   1.690 +   of RFC 822 that has been repeatedly cited by non-email specification
   1.691 +   writers, namely the description of Augmented BNF.  Rather than simply
   1.692 +   and blindly converting the existing text into a separate document,
   1.693 +   the working group chose to give careful consideration to the
   1.694 +   deficiencies, as well as benefits, of the existing specification and
   1.695 +   related specifications made available over the last 15 years, and
   1.696 +   therefore to pursue enhancement.  This turned the project into
   1.697 +   something rather more ambitious than was first intended.
   1.698 +   Interestingly, the result is not massively different from that
   1.699 +   original, although decisions, such as removing the list notation,
   1.700 +   came as a surprise.
   1.701 +
   1.702 +   This "separated" version of the specification was part of the DRUMS
   1.703 +   working group, with significant contributions from Jerome Abela,
   1.704 +   Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom
   1.705 +   Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete
   1.706 +   Resnick, and Henning Schulzrinne.
   1.707 +
   1.708 +   Julian Reschke warrants a special thanks for converting the Draft
   1.709 +   Standard version to XML source form.
   1.710 +
   1.711 +Appendix B.  Core ABNF of ABNF
   1.712 +
   1.713 +   This appendix contains some basic rules that are in common use.
   1.714 +   Basic rules are in uppercase.  Note that these rules are only valid
   1.715 +   for ABNF encoded in 7-bit ASCII or in characters sets that are a
   1.716 +   superset of 7-bit ASCII.
   1.717 +
   1.718 +B.1.  Core Rules
   1.719 +
   1.720 +   Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT,
   1.721 +   ALPHA, etc.
   1.722 +
   1.723 +         ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
   1.724 +
   1.725 +         BIT            =  "0" / "1"
   1.726 +
   1.727 +         CHAR           =  %x01-7F
   1.728 +                                ; any 7-bit US-ASCII character,
   1.729 +                                ;  excluding NUL
   1.730 +
   1.731 +
   1.732 +
   1.733 +Crocker & Overell           Standards Track                    [Page 13]
   1.734 +
   1.735 +RFC 5234                          ABNF                      January 2008
   1.736 +
   1.737 +
   1.738 +         CR             =  %x0D
   1.739 +                                ; carriage return
   1.740 +
   1.741 +         CRLF           =  CR LF
   1.742 +                                ; Internet standard newline
   1.743 +
   1.744 +         CTL            =  %x00-1F / %x7F
   1.745 +                                ; controls
   1.746 +
   1.747 +         DIGIT          =  %x30-39
   1.748 +                                ; 0-9
   1.749 +
   1.750 +         DQUOTE         =  %x22
   1.751 +                                ; " (Double Quote)
   1.752 +
   1.753 +         HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
   1.754 +
   1.755 +         HTAB           =  %x09
   1.756 +                                ; horizontal tab
   1.757 +
   1.758 +         LF             =  %x0A
   1.759 +                                ; linefeed
   1.760 +
   1.761 +         LWSP           =  *(WSP / CRLF WSP)
   1.762 +                                ; Use of this linear-white-space rule
   1.763 +                                ;  permits lines containing only white
   1.764 +                                ;  space that are no longer legal in
   1.765 +                                ;  mail headers and have caused
   1.766 +                                ;  interoperability problems in other
   1.767 +                                ;  contexts.
   1.768 +                                ; Do not use when defining mail
   1.769 +                                ;  headers and use with caution in
   1.770 +                                ;  other contexts.
   1.771 +
   1.772 +         OCTET          =  %x00-FF
   1.773 +                                ; 8 bits of data
   1.774 +
   1.775 +         SP             =  %x20
   1.776 +
   1.777 +         VCHAR          =  %x21-7E
   1.778 +                                ; visible (printing) characters
   1.779 +
   1.780 +         WSP            =  SP / HTAB
   1.781 +                                ; white space
   1.782 +
   1.783 +
   1.784 +
   1.785 +
   1.786 +
   1.787 +
   1.788 +
   1.789 +Crocker & Overell           Standards Track                    [Page 14]
   1.790 +
   1.791 +RFC 5234                          ABNF                      January 2008
   1.792 +
   1.793 +
   1.794 +B.2.  Common Encoding
   1.795 +
   1.796 +   Externally, data are represented as "network virtual ASCII" (namely,
   1.797 +   7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
   1.798 +   zero.  A string of values is in "network byte order", in which the
   1.799 +   higher-valued bytes are represented on the left-hand side and are
   1.800 +   sent over the network first.
   1.801 +
   1.802 +Authors' Addresses
   1.803 +
   1.804 +   Dave Crocker (editor)
   1.805 +   Brandenburg InternetWorking
   1.806 +   675 Spruce Dr.
   1.807 +   Sunnyvale, CA  94086
   1.808 +   US
   1.809 +
   1.810 +   Phone: +1.408.246.8253
   1.811 +   EMail: dcrocker@bbiw.net
   1.812 +
   1.813 +
   1.814 +   Paul Overell
   1.815 +   THUS plc.
   1.816 +   1/2 Berkeley Square,
   1.817 +   99 Berkeley Street
   1.818 +   Glasgow  G3 7HR
   1.819 +   UK
   1.820 +
   1.821 +   EMail: paul.overell@thus.net
   1.822 +
   1.823 +
   1.824 +
   1.825 +
   1.826 +
   1.827 +
   1.828 +
   1.829 +
   1.830 +
   1.831 +
   1.832 +
   1.833 +
   1.834 +
   1.835 +
   1.836 +
   1.837 +
   1.838 +
   1.839 +
   1.840 +
   1.841 +
   1.842 +
   1.843 +
   1.844 +
   1.845 +Crocker & Overell           Standards Track                    [Page 15]
   1.846 +
   1.847 +RFC 5234                          ABNF                      January 2008
   1.848 +
   1.849 +
   1.850 +Full Copyright Statement
   1.851 +
   1.852 +   Copyright (C) The IETF Trust (2008).
   1.853 +
   1.854 +   This document is subject to the rights, licenses and restrictions
   1.855 +   contained in BCP 78, and except as set forth therein, the authors
   1.856 +   retain all their rights.
   1.857 +
   1.858 +   This document and the information contained herein are provided on an
   1.859 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.860 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   1.861 +   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   1.862 +   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   1.863 +   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.864 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.865 +
   1.866 +Intellectual Property
   1.867 +
   1.868 +   The IETF takes no position regarding the validity or scope of any
   1.869 +   Intellectual Property Rights or other rights that might be claimed to
   1.870 +   pertain to the implementation or use of the technology described in
   1.871 +   this document or the extent to which any license under such rights
   1.872 +   might or might not be available; nor does it represent that it has
   1.873 +   made any independent effort to identify any such rights.  Information
   1.874 +   on the procedures with respect to rights in RFC documents can be
   1.875 +   found in BCP 78 and BCP 79.
   1.876 +
   1.877 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.878 +   assurances of licenses to be made available, or the result of an
   1.879 +   attempt made to obtain a general license or permission for the use of
   1.880 +   such proprietary rights by implementers or users of this
   1.881 +   specification can be obtained from the IETF on-line IPR repository at
   1.882 +   http://www.ietf.org/ipr.
   1.883 +
   1.884 +   The IETF invites any interested party to bring to its attention any
   1.885 +   copyrights, patents or patent applications, or other proprietary
   1.886 +   rights that may cover technology that may be required to implement
   1.887 +   this standard.  Please address the information to the IETF at
   1.888 +   ietf-ipr@ietf.org.
   1.889 +
   1.890 +
   1.891 +
   1.892 +
   1.893 +
   1.894 +
   1.895 +
   1.896 +
   1.897 +
   1.898 +
   1.899 +
   1.900 +
   1.901 +Crocker & Overell           Standards Track                    [Page 16]
   1.902 +