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