Adrian,
Having spent several years working with formal and semi-formal
definitions of programming language and being fairly unsatisfied
with IETF trends in the area, I had hoped to avoid looking at
this spec. No such luck, obviously.
I presume this is not what you intended, but you have just made
a powerful argument for:
(1) Adding a clear statement to this that says, approximately,
"this is intended to document a BNF variant that was used in
some protocols instead of ABNF, for reasons that seemed
appropriate at the time. Updating those protocols to use ABNF
is likely to be too costly and too prone to accidental errors,
so this description is provided to improve understanding. RBNF
is not recommended for new protocol specifications unless it is
necessary to preserve compatibility and reduce confusion
relative to existing ones.
Without debating "coyness" or the lack thereof, I see no reason
to avoid being clear about this... and going well beyond an
applicability statement for a Proposed Standard while doing so.
(2) Publishing as Informational or direct-to-Historic.
See below.
--On Thursday, February 05, 2009 12:44 PM +0000 Adrian Farrel
<adrian(_at_)olddog(_dot_)co(_dot_)uk> wrote:
...
It is also clear to me that RBNF is not recommended for
protocols that already use some other form of BNF.
As far as I am concerned, the use of RBNF for the development
of any other new protocol is a choice for the working group
concerned and out of scope for me. However, I have included
text that leans toward using ABNF.
...
C) In a similar vein, to me, and perhaps to many in the IETF,
it is RFC5234 or
its precursors that represent the 'standard' meta-syntactic
language. Some
comparison of the functionality would be helpful, as an
informative Appendix.
Is this a proper subset, if not, then where?
This was considered and rejected as the I-D was being written.
5234 might be the default/standard form of BNF in the IETF
*now* but we are dealing in protocols that pre-date 5234.
Indeed they pre-date (just) ABNF right back to 2234.
With the understanding that I am not a big fan of ABNF and never
have been, it dates from RFC 822. None of these specifications
predate that. On the other hand, however wise or unwise the
decision to use something else might have been at the time, it
is long since done. Debating its wisdom now appears to me to be
a waste of time and getting this description published (in some
category) seems wise to me.
However, if you are documenting existing practice for
understanding and compatibility, rather than encouraging use of
this form, the use of strongly normative RFC 2119 language
directed to new uses seem inappropriate.
The Introduction explains why 5234 cannot be used in this case
because of the cost of updating existing RFCs.
While I am very sympathetic to this position and the explanation
made there (actually, all it says is "would require a lot of
work" which strikes me as more of an assertion than an
explanation),
I note that, when RFC 821 was updated to form 2821, the formal
syntax for describing commands was changed from BNF to ABNF. It
is possible and the cost equation is somewhat subjective.
However, errors were made in the transition that made it into
2821 despite considerable checking. The likelihood of
introducing errors is, to me, a much stronger argument for not
making changes than "lot of work".
The question becomes how to work with the sentence:
Unfortunately these specifications are not based on any
specific
formal definition of BNF and differ slightly from the
definitions
provided in other places.
My view was that it is necessary to provide a specification of
RBNF for the uses identified. Such a definition should be
stand-alone and does not require any comparison with any other
form of BNF. Such a comparison would be a lot of work for (I
believe) zero gain.
So, I don't propose to make any changes for this.
I partially disagree if you are trying for Proposed Standard. I
get much more relaxed if you are aiming for Informational, as
suggested above. See below.
<tirade>
Having multiple syntactic metalanguages floating around in the
same community is bad news. That is especially true if
documents that use those metalanguages are not painfully clear
about what they are using. If a reader looks at the
metalanguage in one document and believes that he is seeing one
that is specified differently from what is actually there, we
have at least the equivalent of a specification ambiguity.
"Painfully clear" is not going to occur here, since there is no
way to modify the existing RFCs to include normative references
to this spec.
While this horse has left the barn, I believe it is
irresponsible for the IETF to publish a document that uses a
metalanguage without a precise definition of that metalanguage
(either inline or by reference).
If one cannot eliminate the use of multiple forms, the advantage
of doing a comparison becomes clear: it is an important warning
to the user as to what to watch out for. Since this doesn't
look like ABNF (which uses different operator syntax and uses
pointed brackets only when needed for clarity) it is likely that
the appropriate comparison should be to either to the original
BNF or to ISO EBNF but that doesn't eliminate the desirability
of documenting the major differences. In that context, "similar
to a subset of Extended BNF" impresses me as the worst sort of
hand waving. I guess it isn't actually an (unspecified) subset
and I don't know what "similar" means. The whole purpose of
using formal metalanguage is to provide rigorous precision and
clarity; "similar to a subset" denies that entire concept.
Finally, the name of this thing is misleading at best. BNF is
_very_ minimal and this is, in no sense, "reduced" BNF. Perhaps
it is "reduced extended BNF", "reduced variant near-subset
extended BNF", or "slightly extended BNF", but "reduced BNF it
is not".
</tirade>
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf