--On Thursday, February 05, 2009 5:14 PM +0000 Adrian Farrel
<adrian@xxxxxxxxxxxx> wrote:
> 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 have been trying for several years to narrow the number of
things I try to worry about in the IETF so as to concentrate
efforts on those for which I have time. My own choice, clearly.
>> 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.
I was trying to suggest that, despite the draft's, and Last
Call, presumably of Proposed Standard, it might be more
appropriate to publish this as Informational, defining "RBNF"
for the context of a list of specific specifications and their
derivatives. That doesn't require standards-track unless we do
want to recommend it.
>> (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 know.
> 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?
ABNF has been around, and actively used in the IETF, for a very
long time. During most of that time, specifications that used
it simply references 822, which contains a plausible definition.
The only thing that changed with the publication of RFC 2234 in
1997 were that the specification expanded a bit and got a little
better defined and the appropriate reference changed from 822 to
2234/4234/5234/STD68. I think it is worth caring about because
it sets a context for this different form: unlike protocol
standards, there is little reason for the IETF to support or
permit multiple metalanguage standards unless one can be clearly
shown to be superior for a particular situation. You have not
made the assertion that none of those specs could have been
written with ABNF instead without loss of quality, only that
changing them over at this point would be more trouble than it
is worth (a conclusion with which I agree).
>...
>> 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.
And I am suggesting that, if this is going to be a
standards-track document, such a recommendation is a
requirement. That is a special case of the requests from others
for an applicability statement.
> 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.
If you would be comfortable inserting "only" in that sentence,
we would be in agreement, both about what is needed and what
should be said.
> 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?
While I believe that a stronger statement would be both more
appropriate and simpler to write, I could live with the above.
>> (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.
I think Informational would be more appropriate for that and
other reasons. On the other hand, "silly" has not been a bar to
IETF decisions in recent years :-(
> 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
And that takes us down the usual path, e.g., questions about how
one tests interoperability of a metalanguage specification?
Perhaps we should be testing meta-interoperability, but I don't
know what that is.
>
> 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.
Mutter. It really doesn't because the metalanguage defined in
822 is correct for 822, presumably correct for documents and
reference 822 for the metalanguage, and slightly different from
the metalanguage specified by 2234/ 5234. But maybe the
relationship is such that it should be identified as "updates"
because we have no better mechanism.
> Glad you agree that we should publish a description of RBNF.
I think having these things floating around undocumented is a
big mistake. Indeed, I believe that the specs that use what you
are called RBNF should never have been published without a clear
definition. If is a bit too late to fix that now.
>> 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 way to get people to pay attention is for the IESG to make
firm decisions about requirements and publicize them. If they
do that, then it doesn't make any difference what category this
document is published in, only that it be published. If they
are not willing to do that, then I'm skeptical about the
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.
Sorry. I completely agree that it would be a lot of work (and I
have enough experience with such conversions to be able to
judge). I am also convinced, based on the same experience, that
the odds of an error-free conversation are too low to be
tolerable. I was merely pointing out that you had not
_explained_ the reason for not converting, merely asserted that
it would be a lot of work. I was not disputing the assertion.
>...
> 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).
And maybe we need to be pragmatic about this and say "some spec
for RBNF is clearly better than no spec for RBNF and this is all
that resources are going to permit". I can live with that if
we are explicit about it.
>> <tirade>
>...
>> 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.
As I tried to say above, we are in complete agreement on that
subject.
>...
>> 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"
I'm not good at names and would prefer to leave this to others.
But I don't think we should call it "reduced" relative to
something that is smaller than it is. And I think we would be
better off with a title that is as specific to function as
possible.
best,
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf