Proposal to use of ABNF in RFC977bis's formal syntax
Jonathan Grobe
grobe at netins.net
Thu Jul 11 14:47:58 PDT 1996
On Thu, 11 Jul 1996, Paul Overell wrote:
> I would like to propose that RFC977bis should use ABNF for its formal
> syntax. ABNF is currently being standardized, see draft-drums-abnf-
> 01.txt. This is the syntactic metalanguage that is used in RFC822 and
> in many other RFC's and drafts.
>
That draft doesn't exist. draft-ietf-drums-abnf-00.txt is the only one
I found:
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 at imc.org>
Phone: +1 408 246 8253
Fax: +1 408 249 6205
More information about the ietf-nntp
mailing list