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

Last change on this file since 598 was 598, checked in by julian.reschke@…, 10 years ago

fix Makefile, add RFC 2817/2818, re-gen HTML

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