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