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

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

Update orig RFCs, also add 2145 and 5234

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