[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 rfc2234                                        
Network Working Group                                     D. Crocker
Internet-Draft                              Internet Mail Consortium
Expiration <6/95>                                       8 March 1996



             Augmented BNF for Syntax Specifictions
                 <draft-ietf-drums-abnf-00.txt>


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 "<name>".
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:

                         <l>*<m>element

indicating at least <l> and at most <m> 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

"<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
exactly  <n>  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:

                         <l>#<m>element

indicating at least <l> and at most <m> 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

<dcrocker@imc.org>

Phone:    +1 408 246 8253
Fax:      +1 408 249 6205