Date: Sun, 27 Oct 1996 14:20:13 -0400
From: John C Klensin <klensin@mail1.reston.mci.net>
Subject: Re: draft-ietf-drums-abnf-01.txt
To: drums@cs.utk.edu
Message-id: <3.0b36.16.19961027141914.3ad7fea6@mail1.reston.mci.net>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"

I think I'm about to make myself very unpopular...

At least just as a strawman, I'd like to suggest that the last few weeks of
discussion identify most of the participants as well-meaning amateur 
metalanguage designers -- good amateurs, but with the emphasis on 
"amateur".   I've personally never been very happy with ABNF, but I've 
recognized that my problems partially  arose as the result of having hung 
around real metalanguage experts, the compiler-compiler efforts of the 70s, 
and a few formal and semi-formal programming language standardization 
efforts.  

I've mostly kept my mouth shut because ABNF seemed to meet the 
needs of the Internet community and everyone else seemed to be happy 
about it.   Having learned in those other contexts that metalanguages and
metalinguistics turn into religious issues fairly early on, I figured I'd
just try to 
ignore the problem or go off and fight other fights instead.

As long as we are going to accept and use the ABNF of 822, with only trivial 
clarifications (if that), then I still believe in that original position --
people (if not
parser generators) have managed to work successfully with the thing, it is
widely accepted and popular, and there are strong and obvious arguments
against
changing something that has mostly worked for us for more than a decade.

But the discussions have moved out of that domain and into the domain where
we are trying to invent a new metalanguage, perhaps ABNF++, with new 
metasyntax rules and perhaps new implied productions for old rules.  That 
seems to me to be a bad idea for three reasons:

    -- we augment whatever confusion exists about ABNF as [mostly] defined in 
       822 by giving people the opportunity to become confused about whether 
       the old or the new version is in use.

   -- we are fussing with details without reaching agreement about what we are
      trying to accomplish and optimize and how important various goals
are.  That
      is never a good way to do design.

   -- we aren't demonstrably good at this (the second point may be a symptom
      of that observation).

So, I'd like to ask participants in the WG to step back a little bit and
ask themselves
two questions:

 (i) Do we really need to revise and upgrade this puppy, as distinct from
just clarifying 
it?  To put that differently, is ABNF, as distinct from its existing
specification, broken and broken sufficiently to justify
potentially-significant fixes?

 (ii) If we need a new metalanguage, are there candidates out there that
are widely-deployed and/or widely-understood, for which automated parser 
converters exist and have been debugged, and maybe even that are supported by
existing tutorials, textbooks, etc.?   As we review those, are there
candidates that move a little further into definition of semantics (rather
than just crude syntax) that  would be worth examining?   I.e., if ABNF is
broken, can we replace it with something sensible, without having to go
into the metalanguage invention business or are we determined to build our
own wheel?

Guess I better go find my flame-proof suit.

      john