Re: [abnf-discuss] Target audience for ABNF

[Paul Kyzivat <[e-mail]>]

On 11/20/17 1:50 AM, Carsten Bormann wrote:
> 
>> On Nov 20, 2017, at 02:13, Paul Kyzivat <[e-mail]> wrote:
>>
>> Dave,
>>
>> On 11/19/17 7:54 PM, Dave Crocker wrote:
>>> On 11/19/2017 4:19 PM, Paul Kyzivat wrote:
>>>> On 11/19/17 4:08 PM, Carsten Bormann wrote:
>>>>>
>>>>>> On Nov 19, 2017, at 19:56, Dave Crocker <[e-mail]> wrote:
>>>>>>
>>>>>> Computers are not the target audience for computer languages.  Human readers are.
>>>>>
>>>>> +10k.
>>>>
>>>> I agree that the human audience is of major importance.
>>>> But mechanical verifiability of ABNF is also important.
>>> I of course do not mean that computers are irrelevant.  However 'verifiability' invokes formal methods and those typically aren't a concern for typical specification efforts.  Machine processing, yes. Mathematical proofs, no.
>>> I gather you are claiming otherwise.  I haven't noticed any history of formal verification for IETF-related specifications, so perhaps you have some pointers?
>>>> Ideally IdNits would verify ABNF in drafts as a matter of course. IIUC doing so has been included as a requirement for the new tooling. Given the current situation what IdNits can potentially do is very limited.
>>> IdNits hardly seems to qualify as 'verification'.  So I'm probably not understanding exactly what problem you are concerned about.  Details?
>>
>> I'm not talking about verifying/proving that the ABNF does what was "intended". I'm willing to grant (for purposes of IETF documents) that verifying the ABNF reflects the *intent* is done by the human review process.
> 
> Right, but tools like abnfgen can help enormously in this task — the reviewer generates a few matching instances and eyeballs whether they look like what was intended.  Validating a few manually generated instances against the ABNF is the other computer-assisted process in validation.
> 
>> I'm simply talking about verifying that the ABNF is entirely well formed, that all rulenames have definitions, and that there are no multiple definitions. (Multiple instances of the same rulename on the left of  an "=“.)
> 
> If the YANG people can do validation automatically upon submission, why can’t we?
> 
> (That would probably need the XML, with properly marked up [type=“abnf”] artwork elements.  But we could encourage submitting the XML for drafts that cite RFC 5234 normatively.)

Yes, and I gather that is what is being planned for the future. This 
will work ok if the ABNF is complete and self contained. But there are 
large numbers of important RFCs where it isn't, and in a practical sense 
can't be. For instance RFC6665 is an extension to RFC3261. It includes 
the following as a prelude to the ABNF it includes:

    The Augmented BNF [RFC5234] definitions for the various new and
    modified syntax elements follows.  The notation is as used in
    [RFC3261], and any elements not defined in this section are as
    defined in SIP and the documents to which it refers.

The end result of this is that if you attempt to verify the syntax in a 
standalone way all of the referenced rules are undefined.

(This RFC has the additional issue of using '=' to redefine a rule 
defined in RFC3261. This is historic - it is a revision of RFC3265 that 
was defined prior to the addition of '=/' to ABNF.

There are large number of RFCs that use techniques something like this. 
More modern ones use '=/' and sometimes do something like:

	foo = <defined in RFCxxxx>

That construct eliminates the undefined rules, but the verification then 
fails to check lots of other things.

Another issue is that there is ambiguity about the status of the Core 
Rules defined in RFC5234. Can anyone writing an ABNF grammar assume that 
the core rules are predefined for their use? Or must the grammar 
indicate specifically (how?) that it is implicitly including their 
definitions? If they are automatically present, then they are reserved 
rule names, and cannot be defined differently in any ABNF grammar.

These are impediments to thorough verification of ABNF syntax.

	Thanks,
	Paul