source: draft-ietf-httpbis/orig/rfc5234.xml

Last change on this file was 1500, checked in by julian.reschke@…, 8 years ago

fix mime types

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