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@xxxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf