John,
Good of you to write. It has been a while since I received an email from
you.
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.
Well, who knows who constrains you to certain acts? :-)
I presume this is not what you intended, but you have just made
a powerful argument for:
Why make that presumption?
It is pretty much explicit in the draft.
(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.
Yes, this form of BNF was used.
I am not sure that it was instead of ABNF since it seems to pre-date the
completion of that work.
Who knows whether the reasons seemed appropriate at the time? And who cares?
We are where we are. A set of protocols use RBNF. The IESG insists that it
be documented.
Updating those protocols to use ABNF
is likely to be too costly and too prone to accidental errors,
Absolutely.
so this description is provided to improve understanding.
Right.
RBNF
is not recommended for new protocol specifications unless it is
necessary to preserve compatibility and reduce confusion
relative to existing ones.
I am neither recommending or not recommending its wider use.
I am recommending the positive of your statement. That is, that RBNF should
be used for new protocol specifications that extend or are compatible with
existing specifications that use RBNF.
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.
Given several people have asked what my intention is with regard to the use
of RBNF in new documents, I feel it is helpful to include specific
statements. Currently, I have:
RBNF as defined in this document is primarily applicable for the
protocols listed in the previous section. The specification may be
used to facilitate the interpretation of the pre-existing RFCs that
are referenced. It should also be used in the specification of
extensions to those protocols.
RBNF could also be used for the specification of new protocols. This
is most appropriate for the development of new protocols that are
closely related to those that already use RBNF. For example, PCEP is
closely related to RSVP-TE and when it was developed, the PCE working
gorup chose to use the same form of BNF as was already used in the
RSVP-TE specifications.
If a wholly new protocol is being developed and is not related to a
protocol that already uses RBNF, the working group should consider
carefully whether to use RBNF or to use a more formally specified and
broader form of BNF such as ABNF [RFC5234].
The use of RBNF to specify extensions to protocols that do not
already use RBNF (i.e., that use some other form of BNF) is not
recommended.
You feel I should be clearer?
(2) Publishing as Informational or direct-to-Historic.
How can it be Historic given that the protocols that use RBNF are not
Historic? I think that would be silly.
Should it be Informational? Well, if it only provided an explanation of
published RFCs, I'd be happy. But the flow is as follows:
- extensions to protocol documents will often be standards track
- extensions to existing protocols should use the same formal
language as the base documents
- if a specification uses a formal language, the definition of that
language is normative
- downrefs are discouraged
[SNIP]
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.
Hmmm. Looks like you are right about the date of 822. Unfortunate that the
RFC Editor index does not show 2234 obsoleting or updating 822.
Glad you agree that we should publish a description of RBNF.
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.
Well, there *will* be new uses.
It would be wrong IMHO for an extension to RSVP to vary from the BNF used in
RFC2205 whatever the history.
So, given that there will be new uses, we need to constrain those uses to do
the right thing.
2119 provides a way of laying it on thick enough that some people might pay
attention.
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 am perfectly willing to have someone disprove me by doing the work.
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".
Well, perhaps I meant that doing it is synonymous with doing it right. But
you are correct that introducing errors would be a pain.
You'll note that I did not provide a comprehensive list of RFCs that use
RBNF. I can see piles of them from where I am sitting.
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.
Just jumping in before the tirade :-)
It would have been possible to write a spec for RBNF as a variation from
ABNF. Doing so would require that I fully understood ABNF *and* that I was
certain to have caught all of the differences. Writing a spec for RBNF as it
stands was somewhat simpler (for me).
<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).
Which is largely why this document exists.
Protocol extension documents are being written, they use the same
metalanguage as the base specs. This should be documented and be a normative
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.
You have pointed to text in the Introduction.
Introductions are not normally formal, but provide background. The text is
not intended to make you understand the content, but to help you understand
the context.
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".
Then suggest a new and practical name.
I wanted to avoid "Routing Area BNF"
And I don't care what the BNF is called.
I would even be happy to call it "A metalanguage sometimes used"
</tirade>
Cheers,
Adrian
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf