source: draft-ietf-httpbis/orig/rfc4234.xml @ 11

Last change on this file since 11 was 11, checked in by fielding@…, 12 years ago

RFC 4234: Augmented BNF for Syntax Specifications: ABNF

Translated from text to XML by Julian Reschke.

  • Property svn:eol-style set to native
File size: 33.1 KB
Line 
1<?xml version="1.0" encoding="utf-8"?>
2<?rfc comments="yes"?>
3<?rfc inline="yes"?>
4<?rfc compact="yes" ?>
5<?rfc subcompact="no" ?>
6<?rfc toc="yes" ?>
7<?rfc tocdepth="2" ?>
8<?rfc tocindent="yes" ?>
9<?rfc symrefs="yes" ?>
10<?rfc sortrefs="yes"?>
11<?rfc iprnotified="no" ?>
12<?rfc-ext sec-no-trailing-dots="yes" ?>
13<?rfc strict="yes" ?>
14<?rfc editing="no" ?>
15<rfc category="std" number="4234" obsoletes="2234">
16   <front>
17      <title abbrev="ABNF">Augmented BNF for Syntax Specifications: ABNF</title>
18      <author fullname="Dave Crocker" initials="D." role="editor"
19         surname="Crocker">
20         <organization>Brandenburg InternetWorking</organization>
21         <address>
22            <postal>
23               <street>675 Spruce Dr.</street>
24               <city>Sunnyvale</city>
25               <region>CA</region>
26               <code>94086</code>
27               <country>US</country>
28            </postal>
29            <phone>+1.408.246.8253</phone>
30            <email>dcrocker@bbiw.net</email>
31         </address>
32      </author>
33      <author fullname="Paul Overell" initials="P." surname="Overell">
34         <organization>THUS plc.</organization>
35         <address>
36            <postal>
37               <street>1/2 Berkeley Square, </street>
38               <street>99 Berkeley Street</street>
39               <city>Glasgow</city>
40               <code>G3 7HR</code>
41               <country>UK</country>
42            </postal>
43            <email>paul.overell@thus.net</email>
44         </address>
45      </author>
46      <date month="October" year="2005"></date>
47      <keyword>ABNF</keyword>
48      <keyword>Augmented</keyword>
49      <keyword>Backus-Naur</keyword>
50      <keyword>Form</keyword>
51      <keyword>electronic</keyword>
52      <keyword>mail</keyword>
53      <abstract>
54                        <t>Internet technical specifications often need to define a formal     
55                        syntax.  Over the years, a modified version of Backus-Naur Form
56                        (BNF), called Augmented BNF (ABNF), has been popular among many
57                        Internet specifications.  The current specification documents ABNF.     
58                        It balances compactness and simplicity, with reasonable
59                        representational power.  The differences between standard BNF and       
60                        ABNF involve naming rules, repetition, alternatives, order-     
61                        independence, and value ranges.  This specification also supplies       
62                        additional rule definitions and encoding for a core lexical analyzer   
63                        of the type common to several Internet specifications.
64      </t>
65      </abstract>
66   </front>
67   <middle>
68      <section title="INTRODUCTION">
69         <t> Internet technical specifications often need to define a formal
70            syntax and are free to employ whatever notation their authors deem
71            useful. Over the years, a modified version of Backus-Naur Form
72            (BNF), called Augmented BNF (ABNF), has been popular among many
73            Internet specifications. It balances compactness and simplicity,
74            with reasonable representational power. In the early days of the
75            Arpanet, each specification contained its own definition of ABNF.
76            This included the email specifications, <xref target="RFC733"
77            ></xref> and then <xref target="RFC822"></xref>, which came to be the
78            common citations for defining ABNF.  The current document separates those
79            definitions to permit selective reference.  Predictably, it
80            also provides some modifications and enhancements.</t>
81         <t> The differences between standard BNF and ABNF involve naming rules,
82            repetition, alternatives, order-independence, and value ranges.
83               <xref target="CORE"></xref> supplies rule definitions and
84            encoding for a core lexical analyzer of the type common to several
85            Internet specifications. It is provided as a convenience and is
86            otherwise separate from the meta language defined in the body of
87            this document, and separate from its formal status. <list
88               style="hanging">
89               <t
90                  hangText="Changes since [RFC2234]:"></t>
91               <t>In <xref target="SpecRep"></xref>, the phrase: "That is,
92                  exactly &lt;N&gt; occurrences of
93                  &lt;element&gt;." was corrected to: "That is, exactly
94                  &lt;n&gt; occurrences of &lt;element&gt;."</t>
95               <t>Some continuation comment lines needed to be corrected to
96                  begin with comment character (";").</t>
97            </list>
98         </t>
99      </section>
100      <section title="RULE DEFINITION">
101         <section title="Rule Naming">
102            <t> The name of a rule is simply the name itself; that is, a
103               sequence of characters, beginning with an alphabetic character,
104               and followed by a combination of alphabetics, digits, and hyphens
105               (dashes).</t>
106            <t>
107               <list style="hanging">
108                  <t hangText="NOTE:  "></t>
109                  <t>Rule names are case-insensitive </t>
110               </list>
111            </t>
112            <t> The names &lt;rulename&gt;, &lt;Rulename&gt;,
113               &lt;RULENAME&gt;, and &lt;rUlENamE&gt; all refer
114               to the same rule.</t>
115            <t> Unlike original BNF, angle brackets ("&lt;", "&gt;") are
116               not required. However, angle brackets may be used around a rule
117               name whenever their presence facilitates in discerning the use
118               of a rule name. This is typically restricted to rule name
119               references in free-form prose, or to distinguish partial rules
120               that combine into a string not separated by white space, such as
121               shown in the discussion about repetition, below.</t>
122         </section>
123         <section title="Rule Form">
124            <t> A rule is defined by the following sequence:</t>
125            <figure>
126               <artwork type="example"><![CDATA[
127      name =  elements crlf ]]></artwork>
128            </figure>
129            <t> where &lt;name&gt; is the name of the rule,
130               &lt;elements&gt; is one or more rule names or terminal
131               specifications, and &lt;crlf&gt; is the end-of-line
132               indicator (carriage return followed by line feed). The equal sign
133               separates the name from the definition of the rule. The elements
134               form a sequence of one or more rule names and/or value
135               definitions, combined according to the various operators defined
136               in this document, such as alternative and repetition.</t>
137            <t> For visual ease, rule definitions are left aligned. When a rule
138               requires multiple lines, the continuation lines are indented. The
139               left alignment and indentation are relative to the first lines of
140               the ABNF rules and need not match the left margin of the
141               document.</t>
142         </section>
143         <section title="Terminal Values">
144            <t> Rules resolve into a string of terminal values, sometimes called
145               characters. In ABNF, a character is merely a non-negative integer.
146               In certain contexts, a specific mapping (encoding) of values into
147               a character set (such as ASCII) will be specified.</t>
148            <figure>
149               <preamble> Terminals are specified by one or more numeric
150                  characters, with the base interpretation of those characters
151                  indicated explicitly. The following bases are currently
152                  defined:</preamble>
153               <artwork type="example"><![CDATA[
154      b           =  binary
155
156      d           =  decimal
157
158      x           =  hexadecimal ]]></artwork>
159            </figure>
160            <figure>
161               <preamble> Hence:</preamble>
162               <artwork type="example"><![CDATA[
163      CR          =  %d13
164
165      CR          =  %x0D ]]></artwork>
166               <postamble> respectively specify the decimal and hexadecimal
167                  representation of <xref target="US-ASCII"></xref> for carriage
168                  return.</postamble>
169            </figure>
170            <figure>
171               <preamble> A concatenated string of such values is specified
172                  compactly, using a period (".") to indicate a separation of
173                  characters within that value. Hence:</preamble>
174               <artwork type="example"><![CDATA[
175      CRLF        =  %d13.10 ]]></artwork>
176            </figure>
177            <figure>
178               <preamble> ABNF permits the specification of literal text strings directly,
179                  enclosed in quotation-marks. Hence:</preamble>
180               <artwork type="example"><![CDATA[
181      command     =  "command string" ]]></artwork>
182            </figure>
183            <t> Literal text strings are interpreted as a concatenated set of
184               printable characters.</t>
185            <t>
186               <list style="hanging">
187                  <t hangText="NOTE:  "></t>
188                  <t>ABNF strings are case-insensitive and the character set for
189                     these strings is us-ascii. </t>
190               </list>
191            </t>
192            <figure>
193               <preamble> Hence:</preamble>
194               <artwork type="example"><![CDATA[
195      rulename = "abc" ]]></artwork>
196            </figure>
197            <figure>
198               <preamble> and:</preamble>
199               <artwork type="example"><![CDATA[
200      rulename = "aBc"
201]]></artwork>
202               <postamble> will match "abc", "Abc", "aBc", "abC", "ABc", "aBC",
203                  "AbC", and "ABC".</postamble>
204            </figure>
205            <t>
206               <list>
207                  <t> To specify a rule that IS case SENSITIVE, specify the
208                     characters individually. </t>
209               </list>
210            </t>
211            <figure>
212               <preamble> For example:</preamble>
213               <artwork type="example"><![CDATA[
214      rulename    =  %d97 %d98 %d99
215]]></artwork>
216            </figure>
217            <figure>
218               <preamble> or</preamble>
219               <artwork type="example"><![CDATA[
220      rulename    =  %d97.98.99
221]]></artwork>
222               <postamble> will match only the string that comprises only the
223                  lowercased characters, abc.</postamble>
224            </figure>
225         </section>
226         <section title="External Encodings">
227            <t> External representations of terminal value characters will vary
228               according to constraints in the storage or transmission
229               environment. Hence, the same ABNF-based grammar may have multiple
230               external encodings, such as one for a 7-bit US-ASCII environment,
231               another for a binary octet environment, and still a different one
232               when 16-bit Unicode is used. Encoding details are beyond the
233               scope of ABNF, although Appendix A (Core) provides definitions
234               for a 7-bit US-ASCII environment as has been common to much of
235               the Internet.</t>
236            <t> By separating external encoding from the syntax, it is intended
237               that alternate encoding environments can be used for the same
238               syntax.</t>
239         </section>
240      </section>
241      <section title="OPERATORS">
242         <section title="Concatenation:  Rule1 Rule2">
243            <t> A rule can define a simple, ordered string of values (i.e., a
244               concatenation of contiguous characters) by listing a sequence
245               of rule names. For example:</t>
246            <figure>
247               <artwork type="example"><![CDATA[
248      foo         =  %x61           ; a
249
250      bar         =  %x62           ; b
251
252      mumble      =  foo bar foo ]]></artwork>
253            </figure>
254            <t>
255              So that the rule &lt;mumble&gt; matches the
256              lowercase string "aba".
257            </t>
258            <t>
259                LINEAR WHITE SPACE: Concatenation is at the core of the
260                   ABNF parsing model. A string of contiguous characters
261                   (values) is parsed according to the rules defined in ABNF.
262                   For Internet specifications, there is some history of
263                   permitting linear white space (space and horizontal tab) to
264                   be freely and implicitly interspersed around major
265                   constructs, such as delimiting special characters or atomic
266                   strings.
267                   </t>
268               <t>NOTE:
269                <list>
270                  <t>
271                     This specification for ABNF does not provide for
272                     implicit specification of linear white space.</t>
273               </list>
274            </t>
275            <t> Any grammar that wishes to permit linear white space around
276               delimiters or string segments must specify it explicitly. It is
277               often useful to provide for such white space in "core" rules that
278               are then used variously among higher-level rules. The "core"
279               rules might be formed into a lexical analyzer or simply be part
280               of the main ruleset.</t>
281         </section>
282         <section anchor="Alternatives" title="Alternatives:  Rule1 / Rule2">
283            <t> Elements separated by a forward slash ("/") are alternatives.
284               Therefore,</t>
285            <figure>
286               <artwork type="example"><![CDATA[
287      foo / bar 
288]]></artwork>
289               <postamble> will accept &lt;foo&gt; or
290                  &lt;bar&gt;.</postamble>
291            </figure>
292            <t>
293               <list style="hanging">
294                  <t hangText="NOTE:  "></t>
295                  <t>A quoted string containing alphabetic characters is a special
296                     form for specifying alternative characters and is
297                     interpreted as a non-terminal representing the set of
298                     combinatorial strings with the contained characters, in the
299                     specified order but with any mixture of upper and lower
300                     case.</t>
301               </list>
302            </t>
303         </section>
304         <section anchor="Incremental"
305            title="Incremental Alternatives: Rule1 =/ Rule2">
306            <t> It is sometimes convenient to specify a list of alternatives in
307               fragments. That is, an initial rule may match one or more
308               alternatives, with later rule definitions adding to the set of
309               alternatives. This is particularly useful for otherwise,
310               independent specifications that derive from the same parent rule
311               set, such as often occurs with parameter lists. ABNF permits this
312               incremental definition through the construct:</t>
313            <figure>
314               <artwork type="example"><![CDATA[
315      oldrule     =/ additional-alternatives ]]></artwork>
316            </figure>
317            <figure>
318               <preamble> So that the rule set</preamble>
319               <artwork type="example"><![CDATA[
320      ruleset     =  alt1 / alt2
321
322      ruleset     =/ alt3
323
324      ruleset     =/ alt4 / alt5 ]]></artwork>
325            </figure>
326            <figure>
327               <preamble> is the same as specifying</preamble>
328               <artwork type="example"><![CDATA[
329      ruleset     =  alt1 / alt2 / alt3 / alt4 / alt5 ]]></artwork>
330            </figure>
331         </section>
332         <section anchor="Range" title="Value Range Alternatives:  %c##-##">
333            <figure>
334               <preamble> A range of alternative numeric values can be specified
335                  compactly, using dash ("-") to indicate the range of
336                  alternative values. Hence:</preamble>
337               <artwork type="example"><![CDATA[
338      DIGIT       =  %x30-39 ]]></artwork>
339            </figure>
340            <figure>
341               <preamble> is equivalent to:</preamble>
342               <artwork type="example"><![CDATA[
343      DIGIT       =  "0" / "1" / "2" / "3" / "4" / "5" / "6" /
344
345                     "7" / "8" / "9" ]]></artwork>
346            </figure>
347            <figure>
348               <preamble> Concatenated numeric values and numeric value ranges
349                  cannot be specified in the same string. A numeric value may
350                  use the dotted notation for concatenation or it may use the
351                  dash notation to specify one value range. Hence, to specify
352                  one printable character between end of line sequences, the
353                  specification could be:</preamble>
354               <artwork type="example"><![CDATA[
355      char-line = %x0D.0A %x20-7E %x0D.0A ]]></artwork>
356            </figure>
357         </section>
358         <section anchor="Sequence" title="Sequence Group:  (Rule1 Rule2)">
359            <figure>
360               <preamble> Elements enclosed in parentheses are treated as a
361                  single element, whose contents are STRICTLY ORDERED. Thus,</preamble>
362               <artwork type="example"><![CDATA[
363      elem (foo / bar) blat
364]]></artwork>
365               <postamble>matches (elem foo blat) or (elem bar
366               blat), and</postamble>
367            </figure>
368            <figure>
369               <artwork type="example"><![CDATA[
370      elem foo / bar blat
371]]></artwork>
372               <postamble> matches (elem foo) or (bar blat).</postamble>
373            </figure>
374            <t>
375               <list style="hanging">
376                  <t hangText="NOTE:  "></t>
377                  <t>It is strongly advised that grouping notation be used, rather
378                     than relying on the proper reading of "bare" alternations, when
379                     alternatives consist of multiple rule names or literals.
380                  </t>
381               </list>
382            </t>
383            <figure>
384               <preamble> Hence, it is recommended that the following form be used:</preamble>
385               <artwork type="example"><![CDATA[
386     (elem foo) / (bar blat)
387]]></artwork>
388               <postamble>It will avoid misinterpretation by casual
389                  readers.</postamble>
390            </figure>
391            <t> The sequence group notation is also used within free text to set
392               off an element sequence from the prose.</t>
393         </section>
394         <section anchor="VarRep" title="Variable Repetition:  *Rule">
395            <figure>
396               <preamble> The operator "*" preceding an element indicates
397                  repetition. The full form is:</preamble>
398               <artwork type="example"><![CDATA[
399      <a>*<b>element
400]]></artwork>
401               <postamble> where &lt;a&gt; and &lt;b&gt; are
402                  optional decimal values, indicating at least &lt;a&gt;
403                  and at most &lt;b&gt; occurrences of the
404               element.</postamble>
405            </figure>
406            <t> Default values are 0 and infinity so that
407               *&lt;element&gt; allows any number, including zero;
408               1*&lt;element&gt; requires at least one;
409               3*3&lt;element&gt; allows exactly 3 and
410               1*2&lt;element&gt; allows one or two.</t>
411         </section>
412         <section anchor="SpecRep" title="Specific Repetition:  nRule">
413            <figure>
414               <preamble> A rule of the form:</preamble>
415               <artwork type="example"><![CDATA[
416      <n>element ]]></artwork>
417          </figure>
418          <figure>
419             <preamble> is equivalent to</preamble>
420             <artwork type="example"><![CDATA[
421      <n>*<n>element ]]></artwork>
422          </figure>
423          <t> That is, exactly &lt;n&gt; occurrences of
424             &lt;element&gt;. Thus, 2DIGIT is a 2-digit number, and
425             3ALPHA is a string of three alphabetic characters.</t>
426         </section>
427         <section anchor="OptSeq" title="Optional Sequence:  [RULE]">
428            <figure>
429               <preamble> Square brackets enclose an optional element sequence:</preamble>
430               <artwork type="example"><![CDATA[
431      [foo bar] ]]></artwork>
432            </figure>
433            <figure>
434               <preamble> is equivalent to</preamble>
435               <artwork type="example"><![CDATA[
436      *1(foo bar). ]]></artwork>
437            </figure>
438         </section>
439         <section anchor="Comment" title="Comment:  ; Comment">
440            <t> A semi-colon starts a comment that continues to the end of line.
441               This is a simple way of including useful notes in parallel with
442               the specifications.</t>
443         </section>
444         <section title="Operator Precedence">
445            <t> The various mechanisms described above have the following
446               precedence, from highest (binding tightest) at the top, to lowest
447               (loosest) at the bottom: <list>
448                  <t>Strings, Names formation</t>
449                  <t>Comment</t>
450                  <t>Value range</t>
451                  <t>Repetition</t>
452                  <t>Grouping, Optional</t>
453                  <t>Concatenation</t>
454                  <t>Alternative</t>
455               </list>
456            </t>
457            <t> Use of the alternative operator, freely mixed with
458               concatenations, can be confusing.</t>
459            <t>
460               <list>
461                  <t> Again, it is recommended that the grouping operator be
462                     used to make explicit concatenation groups. </t>
463               </list>
464            </t>
465         </section>
466      </section>
467      <section title="ABNF DEFINITION OF ABNF">
468         <t>
469            <list style="hanging">
470               <t hangText="NOTES:">
471                  <list style="numbers">
472                     <t>This syntax requires a formatting of rules that is
473                        relatively strict. Hence, the version of a ruleset
474                        included in a specification might need preprocessing to
475                        ensure that it can be interpreted by an ABNF parser.</t>
476                     <t>This syntax uses the rules provided in <xref
477                           target="CORE"></xref> (Core).</t>
478                  </list>
479               </t>
480            </list>
481         </t>
482         <figure>
483            <artwork type="abnf"><![CDATA[
484      rulelist       =  1*( rule / (*c-wsp c-nl) )
485
486      rule           =  rulename defined-as elements c-nl
487                             ; continues if next line starts
488                             ;  with white space
489
490      rulename       =  ALPHA *(ALPHA / DIGIT / "-")
491
492      defined-as     =  *c-wsp ("=" / "=/") *c-wsp
493                             ; basic rules definition and
494                             ;  incremental alternatives
495
496      elements       =  alternation *c-wsp
497
498      c-wsp          =  WSP / (c-nl WSP)
499
500      c-nl           =  comment / CRLF
501                             ; comment or newline
502
503      comment        =  ";" *(WSP / VCHAR) CRLF
504
505      alternation    =  concatenation
506                        *(*c-wsp "/" *c-wsp concatenation)
507
508      concatenation  =  repetition *(1*c-wsp repetition)
509
510      repetition     =  [repeat] element
511
512      repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)
513
514      element        =  rulename / group / option /
515                        char-val / num-val / prose-val
516
517      group          =  "(" *c-wsp alternation *c-wsp ")"
518
519      option         =  "[" *c-wsp alternation *c-wsp "]"
520
521      char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
522                             ; quoted string of SP and VCHAR
523                             ;  without DQUOTE
524
525      num-val        =  "%" (bin-val / dec-val / hex-val)
526
527      bin-val        =  "b" 1*BIT
528                        [ 1*("." 1*BIT) / ("-" 1*BIT) ]
529                             ; series of concatenated bit values
530                             ;  or single ONEOF range
531
532      dec-val        =  "d" 1*DIGIT
533                        [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
534
535      hex-val        =  "x" 1*HEXDIG
536                        [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
537
538      prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
539                             ; bracketed string of SP and VCHAR
540                             ;  without angles
541                             ; prose description, to be used as
542                             ;  last resort ]]>
543</artwork>
544         </figure>
545      </section>
546      <section title="SECURITY CONSIDERATIONS">
547         <t> Security is truly believed to be irrelevant to this document.</t>
548      </section>
549   </middle>
550   <back>
551      <references title="Normative References">
552         <reference anchor="US-ASCII">
553            <front>
554               <title>Coded Character Set -- 7-bit American Standard Code for
555                  Information Interchange</title>
556               <author>
557                  <organization>American National Standards
558                  Institute</organization>
559               </author>
560               <date year="1986"></date>
561            </front>
562            <seriesInfo name="ANSI" value="X3.4"></seriesInfo>
563         </reference>
564      </references>
565      <references title="Informative References">
566         <reference anchor="RFC733">
567            <front>
568               <title>Standard for the format of ARPA network text messages</title>
569               <author fullname="David H. Crocker" initials="D."
570                  surname="Crocker">
571                  <organization>The Rand Corporation, Information Sciences
572                     Department</organization>
573                  <address>
574                     <postal>
575                        <street>1700 Main St</street>
576                        <city>Santa Monica</city>
577                        <region>CA</region>
578                        <code>90406</code>
579                        <country>US</country>
580                     </postal>
581                     <email>DCrocker@Rand-Unix</email>
582                  </address>
583               </author>
584               <author fullname="John J. Vittal" initials="J." surname="Vittal">
585                  <organization>Bolt Beranek and Newman Inc. (BBN)</organization>
586                  <address>
587                     <postal>
588                        <street>50 Moulton St.</street>
589                        <city>Cambridge</city>
590                        <region>MA</region>
591                        <code>02138</code>
592                        <country>US</country>
593                     </postal>
594                     <email>Vittal@BBN-TenexD</email>
595                  </address>
596               </author>
597               <author fullname="Kenneth T. Pogran" initials="K."
598                  surname="Pogran">
599                  <organization>Massachusets Institute of Technology (MIT),
600                     Laboratory for Computer Science</organization>
601                  <address>
602                     <postal>
603                        <street>545 Technology Square</street>
604                        <city>Cambridge</city>
605                        <region>MA</region>
606                        <code>02139</code>
607                        <country>US</country>
608                     </postal>
609                     <email>Pogran@MIT-Multics</email>
610                  </address>
611               </author>
612               <author fullname="D. Austin Henderson, Jr." initials="D."
613                  surname="Henderson">
614                  <organization>Bolt Beranek and Newman Inc. (BBN)</organization>
615                  <address>
616                     <postal>
617                        <street>50 Moulton St.</street>
618                        <city>Cambridge</city>
619                        <region>MA</region>
620                        <code>02138</code>
621                        <country>US</country>
622                     </postal>
623                     <email>Henderson@BBN-TenexD</email>
624                  </address>
625               </author>
626               <date day="21" month="November" year="1977"></date>
627            </front>
628            <seriesInfo name="RFC" value="733"></seriesInfo>
629         </reference>
630         <reference anchor="RFC822">
631            <front>
632               <title abbrev="Standard for ARPA Internet Text Messages">Standard
633                  for the format of ARPA Internet text messages</title>
634               <author fullname="David H. Crocker" initials="D.H."
635                  surname="Crocker">
636                  <organization>University of Delaware, Dept. of Electrical
637                     Engineering</organization>
638                  <address>
639                     <postal>
640                        <street></street>
641                        <city>Newark</city>
642                        <region>DE</region>
643                        <code>19711</code>
644                        <country>US</country>
645                     </postal>
646                     <email>DCrocker@UDel-Relay</email>
647                  </address>
648               </author>
649               <date day="13" month="August" year="1982"></date>
650            </front>
651            <seriesInfo name="STD" value="11"></seriesInfo>
652            <seriesInfo name="RFC" value="822"></seriesInfo>
653         </reference>
654         <reference anchor="RFC2234">
655            <front>
656               <title>Augmented BNF for Syntax Specifications: ABNF</title>
657               <author fullname="Dave Crocker" initials="D." surname="Crocker">
658                  <organization>Internet Mail Consortium</organization>
659               </author>
660               <author fullname="Paul Overell" initials="P." surname="Overell">
661                  <organization>Demon Internet Ltd.</organization>
662               </author>
663               <date month="November" year="1997"></date>
664            </front>
665            <seriesInfo name="RFC" value="2234"></seriesInfo>
666         </reference>
667      </references>
668      <section title="ACKNOWLEDGEMENTS">
669         <t> The syntax for ABNF was originally specified in RFC 733. Ken L.
670            Harrenstien, of SRI International, was responsible for re-coding the
671            BNF into an augmented BNF that makes the representation smaller and
672            easier to understand.</t>
673         <t> This recent project began as a simple effort to cull out the
674            portion of RFC 822 that has been repeatedly cited by non-email
675            specification writers, namely the description of augmented BNF.
676            Rather than simply and blindly converting the existing text into a
677            separate document, the working group chose to give careful
678            consideration to the deficiencies, as well as benefits, of the
679            existing specification and related specifications made available over the
680            last 15 years, and therefore to pursue enhancement. This turned the
681            project into something rather more ambitious than was first intended.
682            Interestingly, the result is not massively different from that
683            original, although decisions, such as removing the list notation, came
684            as a surprise.</t>
685         <t> This "separated" version of the specification was part of the DRUMS
686            working group, with significant contributions from Jerome Abela,
687            Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom
688            Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete
689            Resnick, and Henning Schulzrinne.</t>
690         <t>Julian Reschke warrants a special thanks for converting the Draft
691            Standard version to XML source form.</t>
692      </section>
693      <section anchor="CORE" title="APPENDIX - CORE ABNF OF ABNF">
694         <t> This Appendix is provided as a convenient core for specific
695            grammars. The definitions may be used as a core set of rules.</t>
696         <section title="Core Rules">
697            <t> Certain basic rules are in uppercase, such as SP, HTAB, CRLF,
698               DIGIT, ALPHA, etc.</t>
699            <figure>
700               <artwork type="abnf"><![CDATA[
701      ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z
702
703      BIT            =  "0" / "1"
704
705      CHAR           =  %x01-7F
706                             ; any 7-bit US-ASCII character,
707                             ;  excluding NUL
708
709      CR             =  %x0D
710                             ; carriage return
711
712      CRLF           =  CR LF
713                             ; Internet standard newline
714
715      CTL            =  %x00-1F / %x7F
716                             ; controls
717
718      DIGIT          =  %x30-39
719                             ; 0-9
720
721      DQUOTE         =  %x22
722                             ; " (Double Quote)
723
724      HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
725
726      HTAB           =  %x09
727                             ; horizontal tab
728
729      LF             =  %x0A
730                             ; linefeed
731
732      LWSP           =  *(WSP / CRLF WSP)
733                             ; linear white space (past newline)
734
735      OCTET          =  %x00-FF
736                             ; 8 bits of data
737
738      SP             =  %x20
739
740      VCHAR          =  %x21-7E
741                             ; visible (printing) characters
742
743      WSP            =  SP / HTAB
744                             ; white space ]]>
745</artwork>
746            </figure>
747         </section>
748         <section title="Common Encoding">
749            <t> Externally, data are represented as "network virtual ASCII"
750               (namely, 7-bit US-ASCII in an 8-bit field), with the high (8th) bit
751               set to zero. A string of values is in "network byte order", in which
752               the higher-valued bytes are represented on the left-hand side and
753               are sent over the network first.</t>
754         </section>
755      </section>
756   </back>
757</rfc>
Note: See TracBrowser for help on using the repository browser.