From: John Cowan
...
For example, I'm
unhappy about an apparent sentiment that would put ABNF on a lower
footing that the English text. I think I'm like most implementors and
perhaps unlike non-engineers in reversing that precedence. Whenever
I read an RFC, I rely first and foremost on the ABNF. I use the English
only for hints, and follow the ABNF instead of the English whenever
there is a conflict.
Then you would be incapable of implementing any programming language compiler,
or an XML parser, for the specs for these things include literally hundreds
of constraints that are specified only in technical English and not in the
BNF. As far as the BNF is concerned, this is good sound C:
main(argv, argc) {
float Argv;
int* Argc;
print(32);
}
In contexts other than UNIX applications with modern compilers,
that fragment is perfectly sound, if not something I'd write. An
example context is before typing of formal args and in what ANSI/ISO
9899-1990 calls a "freestanding environment" where main() is not
special. I've suppressed most of the memories, but I seem to recall
that what Microsoft calls threaded WIN32 applications are such
things, or were before the POSIX additions.
Besides, I didn't say that one should ignore the English, but that
implementors give precedence to the ABNF. When you are writing an RFC
that you hope will be implemented, you MUST remember that programmers
are lazy. We transliterate the ABNF to build the parser and so implement
the syntax and read the English to figure out and so build the semantics.
As I said, if you must have contradictions between your ABNF and your
English, you must accept the fact that most technical people will
assume your ABNF is right and your English is wrong. That fact seemed
to me to conflict with statements in this thread, and that suggests a
problem in your working group and your RFC.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf