Re: [abnf-discuss] Target audience for ABNF

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 20 November 2017 18:04 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: abnf-discuss@ietfa.amsl.com
Delivered-To: abnf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13FD12E048 for <abnf-discuss@ietfa.amsl.com>; Mon, 20 Nov 2017 10:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvnogMwK1_BX for <abnf-discuss@ietfa.amsl.com>; Mon, 20 Nov 2017 10:04:41 -0800 (PST)
Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id DBC5E12E039 for <abnf-discuss@ietf.org>; Mon, 20 Nov 2017 10:04:40 -0800 (PST)
X-AuditID: 12074414-0d3ff70000006ddf-89-5a131937b78e
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 3B.76.28127.739131A5; Mon, 20 Nov 2017 13:04:39 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vAKI4bwl032297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Nov 2017 13:04:38 -0500
To: Carsten Bormann <cabo@tzi.org>
Cc: Dave Crocker <dcrocker@gmail.com>, abnf-discuss@ietf.org
References: <97E6D6C0-7010-46D6-8641-670F10A2504C@seantek.com> <3fbd228d-c6cf-be73-c7f2-f6b15979b852@gmail.com> <477FA5E8-FBAA-47D4-98A6-79DBAE4498C7@tzi.org> <7db503ef-3db4-9a72-6d14-001831742600@gmail.com> <62B9A765-E6EE-4C20-9A4E-58ADA9FDE975@seantek.com> <c10a79f2-5e42-fc00-ed5a-4459064b5af4@gmail.com> <6BF6E482-7EAD-4564-B273-44ADC13E7375@tzi.org> <b979026d-cb07-ad36-58ab-1ba82c0e8263@alum.mit.edu> <f370948e-b738-06fd-7d39-82bf068499f4@gmail.com> <c6e9c6df-0b35-a4df-57ef-8c04e9637acf@alum.mit.edu> <4D0B3FB6-988B-4772-B0AB-C6FA22D7E102@tzi.org> <b44a3940-9317-07e8-ba4e-2e6e0d92f800@alum.mit.edu> <87E95822-E99C-4C86-A699-6B2FBFC8A6E7@tzi.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <6b5dae66-93ec-0260-9350-c96add3e1e52@alum.mit.edu>
Date: Mon, 20 Nov 2017 13:04:37 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <87E95822-E99C-4C86-A699-6B2FBFC8A6E7@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUixO6iqGsuKRxl0P1MwuLpoR9sFkem3GW1 6Py9g9GB2WPnrLvsHkuW/GTymLYoM4A5issmJTUnsyy1SN8ugStj6WmDgo8CFZ+ezGJvYNzC 28XIwSEhYCLxYbFzFyMXh5DADiaJQxuPsUE4D5kkJnRcYe1i5OQQBiqa0HOUEcQWEVCSuHBx DRuIzSxgI7Ho/01miIalrBIPzx8CS7AJaEnMOfSfBcTmFbCXaJi7EizOIqAqsXF9H9hQUYE0 iTszHjJB1AhKnJz5BKyeU8Ba4vWMg0wQC8wk5m1+yAxhi0vcejIfKi4v0bx1NvMERoFZSNpn IWmZhaRlFpKWBYwsqxjlEnNKc3VzEzNzilOTdYuTE/PyUot0LfRyM0v0UlNKNzFCQlpkB+OR k3KHGAU4GJV4eD/wCEUJsSaWFVfmHmKU5GBSEuVd9RsoxJeUn1KZkVicEV9UmpNafIhRgoNZ SYRXLQoox5uSWFmVWpQPk5LmYFES5/22WN1PSCA9sSQ1OzW1ILUIJivDwaEkwZsgIRwlJFiU mp5akZaZU4KQZuLgBBnOAzQ8BaSGt7ggMbc4Mx0if4rRmKOn58YfJo5nM183MAux5OXnpUqJ 8wqDlAqAlGaU5sFNg6WlV4ziQM8J80qCVPEAUxrcvFdAq5iAVrlc4AdZVZKIkJJqYLR1956w /soLp327GJYo3a6LkZ5xeILOx2Z9xTXTH2bdE3VasL9xXuI+ftu7og+Ej1TMYPRLrtadKe2Q Ef2zW6pJaNWTRMnLsROvfPzQdijbq3Hjx9O1m8oFnD5MkMx22HzsSYZxpkwDc0XCdJWWrdES HWornt8znMFaO3v+1RdzcnaXlFwJWq7EUpyRaKjFXFScCAAonxK6JgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/abnf-discuss/EpWK7MrYlzQYqAoF_av9i-b_VKM>
Subject: Re: [abnf-discuss] Target audience for ABNF
X-BeenThere: abnf-discuss@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "General discussion about tools, activities and capabilities involving the ABNF meta-language" <abnf-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abnf-discuss>, <mailto:abnf-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/abnf-discuss/>
List-Post: <mailto:abnf-discuss@ietf.org>
List-Help: <mailto:abnf-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abnf-discuss>, <mailto:abnf-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 18:04:44 -0000

On 11/20/17 12:45 PM, Carsten Bormann wrote:
> Hi Paul,
> 
> I think these are good observations for a future FDT (ABNFplus :-) or CDDL 2.0).
> 
>> 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.
> 
> Of course, YANG solves this by defining an import/export interface.
> ABNF could grow a convention that makes something like
> 
>> 	foo = <defined in RFCxxxx>
> 
> actually well-defined.
> (We have discussed this for CDDL and didn’t want to include this in this round.)
> 
>> 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.
> 
> Right.  In CDDL, we have a defined “prelude” that is added to all specifications, effectively becoming a set of reserved names.  ABNF could use the above convention with RFC 5234 as the source, or grow a wholesale “import RFC5234” style statement.
> 
> Grüße, Carsten

Indeed it is possible to address these issues with some extensions to 
ABNF. But there is resistance to making extensions to ABNF for fear of 
making it too complex or "formal" for users.

What I'm trying to do here is make the case that there are some issues 
that need solutions. If we can get agreement on those then we can 
discuss how to do so without confusing users.

	Thanks,
	Paul