Re: [abnf-discuss] constrained-01

We use ABNF to define naming conventions for devices, URIs, etc. within our managed system. For example, the system may require a device's identify (as defined by its own naming convention) to be a host name. Its identity may also need to be displayed on a second device that has naming conventions of its own. Clearly if we can define each naming convention (including that for a host name) unambiguously in ABNF we can provide guidance to the system manager as to whether any entered name is valid across all applicable naming conventions. This would apply to all objects that need to be identified within the system and for all protocols, etc. we need to support. If there is ambiguity in the ABNF within the relevant RFCs, etc. then we have to remove that ambiguity to the extent we need to provide support. If there is no ambiguity, full support is available "out of the box".

Hope that helps,

Jonathan

> -----Original Message-----
> From: Sean Leonard [mailto:dev+ietf@seantek.com]
> Sent: 15 November 2016 04:51
> To: Jonathan Hansford <jonathan@hansfords.net>
> Cc: Doug Royer <douglasroyer@gmail.com>; abnf-discuss@ietf.org
> Subject: Re: [abnf-discuss] constrained-01 - advantage?
> 
> 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
> >