]>
Commit | Line | Data |
---|---|---|
b19ccc9e MS |
1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group D. Crocker, Ed. | |
8 | Request for Comments: 4234 Brandenburg InternetWorking | |
9 | Obsoletes: 2234 P. Overell | |
10 | Category: Standards Track THUS plc. | |
11 | October 2005 | |
12 | ||
13 | ||
14 | Augmented BNF for Syntax Specifications: ABNF | |
15 | ||
16 | Status of This Memo | |
17 | ||
18 | This document specifies an Internet standards track protocol for the | |
19 | Internet community, and requests discussion and suggestions for | |
20 | improvements. Please refer to the current edition of the "Internet | |
21 | Official Protocol Standards" (STD 1) for the standardization state | |
22 | and status of this protocol. Distribution of this memo is unlimited. | |
23 | ||
24 | Copyright Notice | |
25 | ||
26 | Copyright (C) The Internet Society (2005). | |
27 | ||
28 | Abstract | |
29 | ||
30 | Internet technical specifications often need to define a formal | |
31 | syntax. Over the years, a modified version of Backus-Naur Form | |
32 | (BNF), called Augmented BNF (ABNF), has been popular among many | |
33 | Internet specifications. The current specification documents ABNF. | |
34 | It balances compactness and simplicity, with reasonable | |
35 | representational power. The differences between standard BNF and | |
36 | ABNF involve naming rules, repetition, alternatives, order- | |
37 | independence, and value ranges. This specification also supplies | |
38 | additional rule definitions and encoding for a core lexical analyzer | |
39 | of the type common to several Internet specifications. | |
40 | ||
41 | ||
42 | ||
43 | ||
44 | ||
45 | ||
46 | ||
47 | ||
48 | ||
49 | ||
50 | ||
51 | ||
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | Crocker & Overell Standards Track [Page 1] | |
59 | \f | |
60 | RFC 4234 ABNF October 2005 | |
61 | ||
62 | ||
63 | Table of Contents | |
64 | ||
65 | 1. INTRODUCTION ....................................................2 | |
66 | 2. RULE DEFINITION .................................................3 | |
67 | 2.1. Rule Naming ................................................3 | |
68 | 2.2. Rule Form ..................................................3 | |
69 | 2.3. Terminal Values ............................................4 | |
70 | 2.4. External Encodings .........................................5 | |
71 | 3. OPERATORS .......................................................6 | |
72 | 3.1. Concatenation: Rule1 Rule2 ................................6 | |
73 | 3.2. Alternatives: Rule1 / Rule2 ...............................6 | |
74 | 3.3. Incremental Alternatives: Rule1 =/ Rule2 ...................7 | |
75 | 3.4. Value Range Alternatives: %c##-## .........................7 | |
76 | 3.5. Sequence Group: (Rule1 Rule2) .............................8 | |
77 | 3.6. Variable Repetition: *Rule ................................8 | |
78 | 3.7. Specific Repetition: nRule ................................9 | |
79 | 3.8. Optional Sequence: [RULE] .................................9 | |
80 | 3.9. Comment: ; Comment ........................................9 | |
81 | 3.10. Operator Precedence .......................................9 | |
82 | 4. ABNF DEFINITION OF ABNF ........................................10 | |
83 | 5. SECURITY CONSIDERATIONS ........................................11 | |
84 | 6. References .....................................................11 | |
85 | 6.1. Normative References ......................................11 | |
86 | 6.2. Informative References ....................................11 | |
87 | Appendix A. ACKNOWLEDGEMENTS .....................................13 | |
88 | Appendix B. APPENDIX - CORE ABNF OF ABNF .........................13 | |
89 | B.1. Core Rules ...............................................13 | |
90 | B.2. Common Encoding ..........................................14 | |
91 | ||
92 | 1. INTRODUCTION | |
93 | ||
94 | Internet technical specifications often need to define a formal | |
95 | syntax and are free to employ whatever notation their authors deem | |
96 | useful. Over the years, a modified version of Backus-Naur Form | |
97 | (BNF), called Augmented BNF (ABNF), has been popular among many | |
98 | Internet specifications. It balances compactness and simplicity, | |
99 | with reasonable representational power. In the early days of the | |
100 | Arpanet, each specification contained its own definition of ABNF. | |
101 | This included the email specifications, [RFC733] and then [RFC822], | |
102 | which came to be the common citations for defining ABNF. The current | |
103 | document separates those definitions to permit selective reference. | |
104 | Predictably, it also provides some modifications and enhancements. | |
105 | ||
106 | The differences between standard BNF and ABNF involve naming rules, | |
107 | repetition, alternatives, order-independence, and value ranges. | |
108 | Appendix B supplies rule definitions and encoding for a core lexical | |
109 | analyzer of the type common to several Internet specifications. It | |
110 | is provided as a convenience and is otherwise separate from the meta | |
111 | ||
112 | ||
113 | ||
114 | Crocker & Overell Standards Track [Page 2] | |
115 | \f | |
116 | RFC 4234 ABNF October 2005 | |
117 | ||
118 | ||
119 | language defined in the body of this document, and separate from its | |
120 | formal status. | |
121 | ||
122 | Changes since [RFC2234]: | |
123 | ||
124 | In Section 3.7, the phrase: "That is, exactly <N> occurrences of | |
125 | <element>." was corrected to: "That is, exactly <n> occurrences of | |
126 | <element>." | |
127 | ||
128 | Some continuation comment lines needed to be corrected to begin | |
129 | with comment character (";"). | |
130 | ||
131 | 2. RULE DEFINITION | |
132 | ||
133 | 2.1. Rule Naming | |
134 | ||
135 | The name of a rule is simply the name itself; that is, a sequence of | |
136 | characters, beginning with an alphabetic character, and followed by a | |
137 | combination of alphabetics, digits, and hyphens (dashes). | |
138 | ||
139 | NOTE: | |
140 | ||
141 | Rule names are case-insensitive | |
142 | ||
143 | The names <rulename>, <Rulename>, <RULENAME>, and <rUlENamE> all | |
144 | refer to the same rule. | |
145 | ||
146 | Unlike original BNF, angle brackets ("<", ">") are not required. | |
147 | However, angle brackets may be used around a rule name whenever their | |
148 | presence facilitates in discerning the use of a rule name. This is | |
149 | typically restricted to rule name references in free-form prose, or | |
150 | to distinguish partial rules that combine into a string not separated | |
151 | by white space, such as shown in the discussion about repetition, | |
152 | below. | |
153 | ||
154 | 2.2. Rule Form | |
155 | ||
156 | A rule is defined by the following sequence: | |
157 | ||
158 | name = elements crlf | |
159 | ||
160 | where <name> is the name of the rule, <elements> is one or more rule | |
161 | names or terminal specifications, and <crlf> is the end-of-line | |
162 | indicator (carriage return followed by line feed). The equal sign | |
163 | separates the name from the definition of the rule. The elements | |
164 | form a sequence of one or more rule names and/or value definitions, | |
165 | combined according to the various operators defined in this document, | |
166 | such as alternative and repetition. | |
167 | ||
168 | ||
169 | ||
170 | Crocker & Overell Standards Track [Page 3] | |
171 | \f | |
172 | RFC 4234 ABNF October 2005 | |
173 | ||
174 | ||
175 | For visual ease, rule definitions are left aligned. When a rule | |
176 | requires multiple lines, the continuation lines are indented. The | |
177 | left alignment and indentation are relative to the first lines of the | |
178 | ABNF rules and need not match the left margin of the document. | |
179 | ||
180 | 2.3. Terminal Values | |
181 | ||
182 | Rules resolve into a string of terminal values, sometimes called | |
183 | characters. In ABNF, a character is merely a non-negative integer. | |
184 | In certain contexts, a specific mapping (encoding) of values into a | |
185 | character set (such as ASCII) will be specified. | |
186 | ||
187 | Terminals are specified by one or more numeric characters, with the | |
188 | base interpretation of those characters indicated explicitly. The | |
189 | following bases are currently defined: | |
190 | ||
191 | b = binary | |
192 | ||
193 | d = decimal | |
194 | ||
195 | x = hexadecimal | |
196 | ||
197 | Hence: | |
198 | ||
199 | CR = %d13 | |
200 | ||
201 | CR = %x0D | |
202 | ||
203 | respectively specify the decimal and hexadecimal representation of | |
204 | [US-ASCII] for carriage return. | |
205 | ||
206 | A concatenated string of such values is specified compactly, using a | |
207 | period (".") to indicate a separation of characters within that | |
208 | value. Hence: | |
209 | ||
210 | CRLF = %d13.10 | |
211 | ||
212 | ABNF permits the specification of literal text strings directly, | |
213 | enclosed in quotation-marks. Hence: | |
214 | ||
215 | command = "command string" | |
216 | ||
217 | Literal text strings are interpreted as a concatenated set of | |
218 | printable characters. | |
219 | ||
220 | ||
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Crocker & Overell Standards Track [Page 4] | |
227 | \f | |
228 | RFC 4234 ABNF October 2005 | |
229 | ||
230 | ||
231 | NOTE: | |
232 | ||
233 | ABNF strings are case-insensitive and the character set for these | |
234 | strings is us-ascii. | |
235 | ||
236 | Hence: | |
237 | ||
238 | rulename = "abc" | |
239 | ||
240 | and: | |
241 | ||
242 | rulename = "aBc" | |
243 | ||
244 | will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and | |
245 | "ABC". | |
246 | ||
247 | To specify a rule that IS case SENSITIVE, specify the characters | |
248 | individually. | |
249 | ||
250 | For example: | |
251 | ||
252 | rulename = %d97 %d98 %d99 | |
253 | ||
254 | or | |
255 | ||
256 | rulename = %d97.98.99 | |
257 | ||
258 | will match only the string that comprises only the lowercased | |
259 | characters, abc. | |
260 | ||
261 | 2.4. External Encodings | |
262 | ||
263 | External representations of terminal value characters will vary | |
264 | according to constraints in the storage or transmission environment. | |
265 | Hence, the same ABNF-based grammar may have multiple external | |
266 | encodings, such as one for a 7-bit US-ASCII environment, another for | |
267 | a binary octet environment, and still a different one when 16-bit | |
268 | Unicode is used. Encoding details are beyond the scope of ABNF, | |
269 | although Appendix A (Core) provides definitions for a 7-bit US-ASCII | |
270 | environment as has been common to much of the Internet. | |
271 | ||
272 | By separating external encoding from the syntax, it is intended that | |
273 | alternate encoding environments can be used for the same syntax. | |
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Crocker & Overell Standards Track [Page 5] | |
283 | \f | |
284 | RFC 4234 ABNF October 2005 | |
285 | ||
286 | ||
287 | 3. OPERATORS | |
288 | ||
289 | 3.1. Concatenation: Rule1 Rule2 | |
290 | ||
291 | A rule can define a simple, ordered string of values (i.e., a | |
292 | concatenation of contiguous characters) by listing a sequence of rule | |
293 | names. For example: | |
294 | ||
295 | foo = %x61 ; a | |
296 | ||
297 | bar = %x62 ; b | |
298 | ||
299 | mumble = foo bar foo | |
300 | ||
301 | So that the rule <mumble> matches the lowercase string "aba". | |
302 | ||
303 | LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing | |
304 | model. A string of contiguous characters (values) is parsed | |
305 | according to the rules defined in ABNF. For Internet specifications, | |
306 | there is some history of permitting linear white space (space and | |
307 | horizontal tab) to be freely and implicitly interspersed around major | |
308 | constructs, such as delimiting special characters or atomic strings. | |
309 | ||
310 | NOTE: | |
311 | ||
312 | This specification for ABNF does not provide for implicit | |
313 | specification of linear white space. | |
314 | ||
315 | Any grammar that wishes to permit linear white space around | |
316 | delimiters or string segments must specify it explicitly. It is | |
317 | often useful to provide for such white space in "core" rules that are | |
318 | then used variously among higher-level rules. The "core" rules might | |
319 | be formed into a lexical analyzer or simply be part of the main | |
320 | ruleset. | |
321 | ||
322 | 3.2. Alternatives: Rule1 / Rule2 | |
323 | ||
324 | Elements separated by a forward slash ("/") are alternatives. | |
325 | Therefore, | |
326 | ||
327 | foo / bar | |
328 | ||
329 | will accept <foo> or <bar>. | |
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Crocker & Overell Standards Track [Page 6] | |
339 | \f | |
340 | RFC 4234 ABNF October 2005 | |
341 | ||
342 | ||
343 | NOTE: | |
344 | ||
345 | A quoted string containing alphabetic characters is a special form | |
346 | for specifying alternative characters and is interpreted as a | |
347 | non-terminal representing the set of combinatorial strings with | |
348 | the contained characters, in the specified order but with any | |
349 | mixture of upper and lower case. | |
350 | ||
351 | 3.3. Incremental Alternatives: Rule1 =/ Rule2 | |
352 | ||
353 | It is sometimes convenient to specify a list of alternatives in | |
354 | fragments. That is, an initial rule may match one or more | |
355 | alternatives, with later rule definitions adding to the set of | |
356 | alternatives. This is particularly useful for otherwise, independent | |
357 | specifications that derive from the same parent rule set, such as | |
358 | often occurs with parameter lists. ABNF permits this incremental | |
359 | definition through the construct: | |
360 | ||
361 | oldrule =/ additional-alternatives | |
362 | ||
363 | So that the rule set | |
364 | ||
365 | ruleset = alt1 / alt2 | |
366 | ||
367 | ruleset =/ alt3 | |
368 | ||
369 | ruleset =/ alt4 / alt5 | |
370 | ||
371 | is the same as specifying | |
372 | ||
373 | ruleset = alt1 / alt2 / alt3 / alt4 / alt5 | |
374 | ||
375 | 3.4. Value Range Alternatives: %c##-## | |
376 | ||
377 | A range of alternative numeric values can be specified compactly, | |
378 | using dash ("-") to indicate the range of alternative values. Hence: | |
379 | ||
380 | DIGIT = %x30-39 | |
381 | ||
382 | is equivalent to: | |
383 | ||
384 | DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / | |
385 | ||
386 | "7" / "8" / "9" | |
387 | ||
388 | Concatenated numeric values and numeric value ranges cannot be | |
389 | specified in the same string. A numeric value may use the dotted | |
390 | notation for concatenation or it may use the dash notation to specify | |
391 | ||
392 | ||
393 | ||
394 | Crocker & Overell Standards Track [Page 7] | |
395 | \f | |
396 | RFC 4234 ABNF October 2005 | |
397 | ||
398 | ||
399 | one value range. Hence, to specify one printable character between | |
400 | end of line sequences, the specification could be: | |
401 | ||
402 | char-line = %x0D.0A %x20-7E %x0D.0A | |
403 | ||
404 | 3.5. Sequence Group: (Rule1 Rule2) | |
405 | ||
406 | Elements enclosed in parentheses are treated as a single element, | |
407 | whose contents are STRICTLY ORDERED. Thus, | |
408 | ||
409 | elem (foo / bar) blat | |
410 | ||
411 | matches (elem foo blat) or (elem bar blat), and | |
412 | ||
413 | elem foo / bar blat | |
414 | ||
415 | matches (elem foo) or (bar blat). | |
416 | ||
417 | NOTE: | |
418 | ||
419 | It is strongly advised that grouping notation be used, rather than | |
420 | relying on the proper reading of "bare" alternations, when | |
421 | alternatives consist of multiple rule names or literals. | |
422 | ||
423 | Hence, it is recommended that the following form be used: | |
424 | ||
425 | (elem foo) / (bar blat) | |
426 | ||
427 | It will avoid misinterpretation by casual readers. | |
428 | ||
429 | The sequence group notation is also used within free text to set off | |
430 | an element sequence from the prose. | |
431 | ||
432 | 3.6. Variable Repetition: *Rule | |
433 | ||
434 | The operator "*" preceding an element indicates repetition. The full | |
435 | form is: | |
436 | ||
437 | <a>*<b>element | |
438 | ||
439 | where <a> and <b> are optional decimal values, indicating at least | |
440 | <a> and at most <b> occurrences of the element. | |
441 | ||
442 | Default values are 0 and infinity so that *<element> allows any | |
443 | number, including zero; 1*<element> requires at least one; | |
444 | 3*3<element> allows exactly 3 and 1*2<element> allows one or two. | |
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Crocker & Overell Standards Track [Page 8] | |
451 | \f | |
452 | RFC 4234 ABNF October 2005 | |
453 | ||
454 | ||
455 | 3.7. Specific Repetition: nRule | |
456 | ||
457 | A rule of the form: | |
458 | ||
459 | <n>element | |
460 | ||
461 | is equivalent to | |
462 | ||
463 | <n>*<n>element | |
464 | ||
465 | That is, exactly <n> occurrences of <element>. Thus, 2DIGIT is a 2- | |
466 | digit number, and 3ALPHA is a string of three alphabetic characters. | |
467 | ||
468 | 3.8. Optional Sequence: [RULE] | |
469 | ||
470 | Square brackets enclose an optional element sequence: | |
471 | ||
472 | [foo bar] | |
473 | ||
474 | is equivalent to | |
475 | ||
476 | *1(foo bar). | |
477 | ||
478 | 3.9. Comment: ; Comment | |
479 | ||
480 | A semi-colon starts a comment that continues to the end of line. | |
481 | This is a simple way of including useful notes in parallel with the | |
482 | specifications. | |
483 | ||
484 | 3.10. Operator Precedence | |
485 | ||
486 | The various mechanisms described above have the following precedence, | |
487 | from highest (binding tightest) at the top, to lowest (loosest) at | |
488 | the bottom: | |
489 | ||
490 | Strings, Names formation | |
491 | ||
492 | Comment | |
493 | ||
494 | Value range | |
495 | ||
496 | Repetition | |
497 | ||
498 | Grouping, Optional | |
499 | ||
500 | Concatenation | |
501 | ||
502 | Alternative | |
503 | ||
504 | ||
505 | ||
506 | Crocker & Overell Standards Track [Page 9] | |
507 | \f | |
508 | RFC 4234 ABNF October 2005 | |
509 | ||
510 | ||
511 | Use of the alternative operator, freely mixed with concatenations, | |
512 | can be confusing. | |
513 | ||
514 | Again, it is recommended that the grouping operator be used to | |
515 | make explicit concatenation groups. | |
516 | ||
517 | 4. ABNF DEFINITION OF ABNF | |
518 | ||
519 | NOTES: | |
520 | ||
521 | 1. This syntax requires a formatting of rules that is relatively | |
522 | strict. Hence, the version of a ruleset included in a | |
523 | specification might need preprocessing to ensure that it can be | |
524 | interpreted by an ABNF parser. | |
525 | ||
526 | 2. This syntax uses the rules provided in Appendix B (Core). | |
527 | ||
528 | rulelist = 1*( rule / (*c-wsp c-nl) ) | |
529 | ||
530 | rule = rulename defined-as elements c-nl | |
531 | ; continues if next line starts | |
532 | ; with white space | |
533 | ||
534 | rulename = ALPHA *(ALPHA / DIGIT / "-") | |
535 | ||
536 | defined-as = *c-wsp ("=" / "=/") *c-wsp | |
537 | ; basic rules definition and | |
538 | ; incremental alternatives | |
539 | ||
540 | elements = alternation *c-wsp | |
541 | ||
542 | c-wsp = WSP / (c-nl WSP) | |
543 | ||
544 | c-nl = comment / CRLF | |
545 | ; comment or newline | |
546 | ||
547 | comment = ";" *(WSP / VCHAR) CRLF | |
548 | ||
549 | alternation = concatenation | |
550 | *(*c-wsp "/" *c-wsp concatenation) | |
551 | ||
552 | concatenation = repetition *(1*c-wsp repetition) | |
553 | ||
554 | repetition = [repeat] element | |
555 | ||
556 | repeat = 1*DIGIT / (*DIGIT "*" *DIGIT) | |
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Crocker & Overell Standards Track [Page 10] | |
563 | \f | |
564 | RFC 4234 ABNF October 2005 | |
565 | ||
566 | ||
567 | element = rulename / group / option / | |
568 | char-val / num-val / prose-val | |
569 | ||
570 | group = "(" *c-wsp alternation *c-wsp ")" | |
571 | ||
572 | option = "[" *c-wsp alternation *c-wsp "]" | |
573 | ||
574 | char-val = DQUOTE *(%x20-21 / %x23-7E) DQUOTE | |
575 | ; quoted string of SP and VCHAR | |
576 | ; without DQUOTE | |
577 | ||
578 | num-val = "%" (bin-val / dec-val / hex-val) | |
579 | ||
580 | bin-val = "b" 1*BIT | |
581 | [ 1*("." 1*BIT) / ("-" 1*BIT) ] | |
582 | ; series of concatenated bit values | |
583 | ; or single ONEOF range | |
584 | ||
585 | dec-val = "d" 1*DIGIT | |
586 | [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ] | |
587 | ||
588 | hex-val = "x" 1*HEXDIG | |
589 | [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ] | |
590 | ||
591 | prose-val = "<" *(%x20-3D / %x3F-7E) ">" | |
592 | ; bracketed string of SP and VCHAR | |
593 | ; without angles | |
594 | ; prose description, to be used as | |
595 | ; last resort | |
596 | ||
597 | 5. SECURITY CONSIDERATIONS | |
598 | ||
599 | Security is truly believed to be irrelevant to this document. | |
600 | ||
601 | 6. References | |
602 | ||
603 | 6.1. Normative References | |
604 | ||
605 | [US-ASCII] American National Standards Institute, "Coded Character | |
606 | Set -- 7-bit American Standard Code for Information | |
607 | Interchange", ANSI X3.4, 1986. | |
608 | ||
609 | 6.2. Informative References | |
610 | ||
611 | [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
612 | Specifications: ABNF", RFC 2234, November 1997. | |
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | Crocker & Overell Standards Track [Page 11] | |
619 | \f | |
620 | RFC 4234 ABNF October 2005 | |
621 | ||
622 | ||
623 | [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, | |
624 | "Standard for the format of ARPA network text messages", | |
625 | RFC 733, November 1977. | |
626 | ||
627 | [RFC822] Crocker, D., "Standard for the format of ARPA Internet | |
628 | text messages", STD 11, RFC 822, August 1982. | |
629 | ||
630 | ||
631 | ||
632 | ||
633 | ||
634 | ||
635 | ||
636 | ||
637 | ||
638 | ||
639 | ||
640 | ||
641 | ||
642 | ||
643 | ||
644 | ||
645 | ||
646 | ||
647 | ||
648 | ||
649 | ||
650 | ||
651 | ||
652 | ||
653 | ||
654 | ||
655 | ||
656 | ||
657 | ||
658 | ||
659 | ||
660 | ||
661 | ||
662 | ||
663 | ||
664 | ||
665 | ||
666 | ||
667 | ||
668 | ||
669 | ||
670 | ||
671 | ||
672 | ||
673 | ||
674 | Crocker & Overell Standards Track [Page 12] | |
675 | \f | |
676 | RFC 4234 ABNF October 2005 | |
677 | ||
678 | ||
679 | Appendix A. ACKNOWLEDGEMENTS | |
680 | ||
681 | The syntax for ABNF was originally specified in RFC 733. Ken L. | |
682 | Harrenstien, of SRI International, was responsible for re-coding the | |
683 | BNF into an augmented BNF that makes the representation smaller and | |
684 | easier to understand. | |
685 | ||
686 | This recent project began as a simple effort to cull out the portion | |
687 | of RFC 822 that has been repeatedly cited by non-email specification | |
688 | writers, namely the description of augmented BNF. Rather than simply | |
689 | and blindly converting the existing text into a separate document, | |
690 | the working group chose to give careful consideration to the | |
691 | deficiencies, as well as benefits, of the existing specification and | |
692 | related specifications made available over the last 15 years, and | |
693 | therefore to pursue enhancement. This turned the project into | |
694 | something rather more ambitious than was first intended. | |
695 | Interestingly, the result is not massively different from that | |
696 | original, although decisions, such as removing the list notation, | |
697 | came as a surprise. | |
698 | ||
699 | This "separated" version of the specification was part of the DRUMS | |
700 | working group, with significant contributions from Jerome Abela, | |
701 | Harald Alvestrand, Robert Elz, Roger Fajman, Aviva Garrett, Tom | |
702 | Harsch, Dan Kohn, Bill McQuillan, Keith Moore, Chris Newman, Pete | |
703 | Resnick, and Henning Schulzrinne. | |
704 | ||
705 | Julian Reschke warrants a special thanks for converting the Draft | |
706 | Standard version to XML source form. | |
707 | ||
708 | Appendix B. APPENDIX - CORE ABNF OF ABNF | |
709 | ||
710 | This Appendix is provided as a convenient core for specific grammars. | |
711 | The definitions may be used as a core set of rules. | |
712 | ||
713 | B.1. Core Rules | |
714 | ||
715 | Certain basic rules are in uppercase, such as SP, HTAB, CRLF, DIGIT, | |
716 | ALPHA, etc. | |
717 | ||
718 | ALPHA = %x41-5A / %x61-7A ; A-Z / a-z | |
719 | ||
720 | BIT = "0" / "1" | |
721 | ||
722 | CHAR = %x01-7F | |
723 | ; any 7-bit US-ASCII character, | |
724 | ; excluding NUL | |
725 | ||
726 | ||
727 | ||
728 | ||
729 | ||
730 | Crocker & Overell Standards Track [Page 13] | |
731 | \f | |
732 | RFC 4234 ABNF October 2005 | |
733 | ||
734 | ||
735 | CR = %x0D | |
736 | ; carriage return | |
737 | ||
738 | CRLF = CR LF | |
739 | ; Internet standard newline | |
740 | ||
741 | CTL = %x00-1F / %x7F | |
742 | ; controls | |
743 | ||
744 | DIGIT = %x30-39 | |
745 | ; 0-9 | |
746 | ||
747 | DQUOTE = %x22 | |
748 | ; " (Double Quote) | |
749 | ||
750 | HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" | |
751 | ||
752 | HTAB = %x09 | |
753 | ; horizontal tab | |
754 | ||
755 | LF = %x0A | |
756 | ; linefeed | |
757 | ||
758 | LWSP = *(WSP / CRLF WSP) | |
759 | ; linear white space (past newline) | |
760 | ||
761 | OCTET = %x00-FF | |
762 | ; 8 bits of data | |
763 | ||
764 | SP = %x20 | |
765 | ||
766 | VCHAR = %x21-7E | |
767 | ; visible (printing) characters | |
768 | ||
769 | WSP = SP / HTAB | |
770 | ; white space | |
771 | ||
772 | B.2. Common Encoding | |
773 | ||
774 | Externally, data are represented as "network virtual ASCII" (namely, | |
775 | 7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to | |
776 | zero. A string of values is in "network byte order", in which the | |
777 | higher-valued bytes are represented on the left-hand side and are | |
778 | sent over the network first. | |
779 | ||
780 | ||
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | Crocker & Overell Standards Track [Page 14] | |
787 | \f | |
788 | RFC 4234 ABNF October 2005 | |
789 | ||
790 | ||
791 | Authors' Addresses | |
792 | ||
793 | Dave Crocker (editor) | |
794 | Brandenburg InternetWorking | |
795 | 675 Spruce Dr. | |
796 | Sunnyvale, CA 94086 | |
797 | US | |
798 | ||
799 | Phone: +1.408.246.8253 | |
800 | EMail: dcrocker@bbiw.net | |
801 | ||
802 | ||
803 | Paul Overell | |
804 | THUS plc. | |
805 | 1/2 Berkeley Square | |
806 | 99 Berkeley Street | |
807 | Glasgow | |
808 | G3 7HR | |
809 | UK | |
810 | ||
811 | EMail: paul.overell@thus.net | |
812 | ||
813 | ||
814 | ||
815 | ||
816 | ||
817 | ||
818 | ||
819 | ||
820 | ||
821 | ||
822 | ||
823 | ||
824 | ||
825 | ||
826 | ||
827 | ||
828 | ||
829 | ||
830 | ||
831 | ||
832 | ||
833 | ||
834 | ||
835 | ||
836 | ||
837 | ||
838 | ||
839 | ||
840 | ||
841 | ||
842 | Crocker & Overell Standards Track [Page 15] | |
843 | \f | |
844 | RFC 4234 ABNF October 2005 | |
845 | ||
846 | ||
847 | Full Copyright Statement | |
848 | ||
849 | Copyright (C) The Internet Society (2005). | |
850 | ||
851 | This document is subject to the rights, licenses and restrictions | |
852 | contained in BCP 78, and except as set forth therein, the authors | |
853 | retain all their rights. | |
854 | ||
855 | This document and the information contained herein are provided on an | |
856 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |
857 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |
858 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |
859 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
860 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
861 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
862 | ||
863 | Intellectual Property | |
864 | ||
865 | The IETF takes no position regarding the validity or scope of any | |
866 | Intellectual Property Rights or other rights that might be claimed to | |
867 | pertain to the implementation or use of the technology described in | |
868 | this document or the extent to which any license under such rights | |
869 | might or might not be available; nor does it represent that it has | |
870 | made any independent effort to identify any such rights. Information | |
871 | on the procedures with respect to rights in RFC documents can be | |
872 | found in BCP 78 and BCP 79. | |
873 | ||
874 | Copies of IPR disclosures made to the IETF Secretariat and any | |
875 | assurances of licenses to be made available, or the result of an | |
876 | attempt made to obtain a general license or permission for the use of | |
877 | such proprietary rights by implementers or users of this | |
878 | specification can be obtained from the IETF on-line IPR repository at | |
879 | http://www.ietf.org/ipr. | |
880 | ||
881 | The IETF invites any interested party to bring to its attention any | |
882 | copyrights, patents or patent applications, or other proprietary | |
883 | rights that may cover technology that may be required to implement | |
884 | this standard. Please address the information to the IETF at ietf- | |
885 | ipr@ietf.org. | |
886 | ||
887 | Acknowledgement | |
888 | ||
889 | Funding for the RFC Editor function is currently provided by the | |
890 | Internet Society. | |
891 | ||
892 | ||
893 | ||
894 | ||
895 | ||
896 | ||
897 | ||
898 | Crocker & Overell Standards Track [Page 16] | |
899 | \f |