Re: [abnf-discuss] constrained-01

Can you elaborate on your request or concern? Is this about ABNF rule names, or something else?

Thanks!

Sean

> On Nov 14, 2016, at 5:45 PM, Jonathan Hansford <jonathan@hansfords.net> wrote:
> 
> Re the formality of ABNF, we use it to help enforce naming conventions for system management (which, with multiple naming conventions from various vendors and standards impacting on a single name, is why this is of interest). The less ambiguity the better, otherwise we will have to develop our own "ABNF" to more formally capture what is presented in RFCs.
> 
> Jonathan
> 
>> -----Original Message-----
>> From: abnf-discuss [mailto:abnf-discuss-bounces@ietf.org] On Behalf Of
>> Sean Leonard
>> Sent: 14 November 2016 04:46
>> To: Doug Royer <douglasroyer@gmail.com>
>> Cc: abnf-discuss@ietf.org
>> Subject: Re: [abnf-discuss] constrained-01 - advantage?
>> 
>> 
>>> On Nov 14, 2016, at 12:26 PM, Doug Royer <douglasroyer@gmail.com>
>> wrote:
>>> 
>>> On 11/13/2016 04:21 PM, Sean Leonard wrote:
>>> 
>>>>> …
>>>> 
>>>> Well:
>>>> 
>>>>> resent-field    = "Resent-" field-name ":" unstructured CRLF
>>>> 
>>>> 
>>>> Is simpler than:
>>>> 
>>>>> resent-field  = resent-unstructured / resent-date / resent-from / resent-
>> sender / ...
>>>> 
>>>> 
>>>> First of all, it looks simpler, because it is.
>>>> 
>>>> Second of all, <resent-date>, <resent-from>, <resent-sender> etc. are all
>> “subsumed” in <resent-unstructured>, leading to an intentionally ambiguous
>> grammar. The problem with the existing way of writing things out, is that the
>> former are all superfluous when the latter is present. Another way to write it
>> tends to be:
>>>> 
>>>> field = date / from / sender / … / extension-field
>>>> 
>>>> extension-field = field-name ":" unstructured CRLF
>>>> 
>>>> Well it makes perfect sense when you read it, of course,
>>>> but when a computer / parser parses productions, every <date> is
>>>> going to match with <extension-field> as well. The point being
>>>> <extension-field> is not really doing what you think it’s doing in ABNF:
>>>> it’s really <any-and-every-field>.
>>>> ...
>>>> There is nothing “wrong” with creating an ambiguous grammar,
>>>> but it can lead to subtle parsing errors if you are not careful.
>>>> Usually ambiguous grammars are undesirable because you want your
>>>> code to go down one, and only one, path. An automated ABNF validator
>>>> should be able to detect ambiguous grammars and inform you about
>> that.
>>> 
>>> If your talking about replacing ABNF with new syntax. then I would agree.
>> To a person reading the ABNF, they mean the same thing.
>>> At no point is one path more important than another.
>>> 
>>> Unless you deprecate the old method, its not going to help.
>>> Because people will use which ever makes sense to them.
>> 
>> I suppose that deprecating the old method would be something on the table
>> to discuss. I believe it is desirable to avoid ambiguous grammars. At the same
>> time, a sufficiently sophisticated tool could be written to identify these sorts
>> of cases (of intentionally ambiguous grammars for parameterized names and
>> values).
>> 
>>> Is the goal of this draft to make all future ABNF in RFC's parsable by a
>> computer program? To mandate it?  I did not understand that after reading
>> the draft.
>>> 
>>> If this keeps going, it will be a new ASN.1
>> 
>> We don’t want that. But the idea of “Table Constraints” is an ASN.1 term. (It
>> is also a SQL concept, because, surprise, it’s about constraining data to tables
>> of values.)
>> 
>> One thing is that none of the drafts that are being proposed change the
>> context-free nature of ABNF.
>> 
>> I would say that a goal is that ABNF in RFCs should be easy to validate, and
>> this would include by means of computer programs. This increases document
>> quality. I recognize that there is a spectrum of views around here about how
>> “formal” ABNF ought to be.
>> 
>> Regards,
>> 
>> Sean
>> 
>> _______________________________________________
>> abnf-discuss mailing list
>> abnf-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/abnf-discuss
> 