Network Working Group D. Crocker Internet-Draft Internet Mail Consortium Expiration <6/95> 8 March 1996 Augmented BNF for Syntax Specifictions STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). TABLE OF CONTENTS 1. INTRODUCTION Internet technical specifications often need to define a format syntax and are free to employ whatever notation their authors deem useful. Over the years, a modified of Backus-Naur Form (BNF), called Augmented BNF, has been popular. It balances compactness with reasonable representation power. In the early days of the Arpanet, each specification contained its own provision for ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. The differences between standard BNF and ABNF involve naming rules and indicating repetition and "local" alternatives. The current document adds value-ranges. 2. RULE NAMING Angle brackets ("<", ">") are not used, in general. The name of a rule is simply the name itself, rather than "". Quotation-marks enclose literal text (which may be upper and/or lower case). Certain basic rules are in uppercase, such as SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in rule definitions, and in the rest of this document, whenever their presence will facilitate discerning the use of rule names. 3. RULE1 / RULE2: ALTERNATIVES Elements separated by slash ("/") are alternatives. Therefore "foo / bar" will accept foo or bar. 4. (RULE1 RULE2): LOCAL ALTERNATIVES Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo / bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem". 5. *RULE: REPETITION The character "*" preceding an element indicates repetition. The full form is: *element indicating at least and at most occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two. 6. [RULE]: OPTIONAL Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)". 7. NRULE: SPECIFIC REPETITION "(element)" is equivalent to "*(element)"; that is, exactly occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. 8. #RULE: LISTS A construct "#" is defined, similar to "*", as follows: #element indicating at least and at most elements, each separated by one or more commas (","). This makes the usual form of lists very easy; a rule such as '(element *("," element))' can be shown as "1#element". Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element),,(element)" is permitted, but counts as only two elements. Therefore, where at least one ele ment is required, at least one non-null element must be present. Default values are 0 and infinity so that "#(element)" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two. 9. ; COMMENTS A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications. 10. VALUE RANGES Elements separated by double periods ("..") specify a range of values. Therefore "foo..bar" represents the range of data values from foo to bar, inclusively. 11. ACKNOWLEDGEMENTS The syntax for ABNF was originally specified in RFC #733, Ken L. Harrenstien, of SRI International, was responsible for re- coding the BNF into an augmented BNF that makes the representation smaller and easier to understand. 12. CONTACT David H. Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 USA Phone: +1 408 246 8253 Fax: +1 408 249 6205