[rfc-i] v3imp #8 Fragment tagging on sourcecode

pkyzivat at alum.mit.edu (Paul Kyzivat) Fri, 23 January 2015 21:50 UTC

From: "pkyzivat at alum.mit.edu"
Date: Fri, 23 Jan 2015 16:50:22 -0500
Subject: [rfc-i] v3imp #8 Fragment tagging on sourcecode
In-Reply-To: <54C2A4AF.6040108@seantek.com>
References: <54C20F92.4090400@seantek.com> <54C232FC.1000604@gmx.de> <54C275BC.1040905@alum.mit.edu> <20150123175511.GI2350@localhost> <54C28E3F.4040901@alum.mit.edu> <20150123181608.GJ2350@localhost> <54C294FC.5000204@alum.mit.edu> <20150123190759.GK2350@localhost> <54C2A4AF.6040108@seantek.com>
Message-ID: <54C2C21E.1040402@alum.mit.edu>

On 1/23/15 2:44 PM, Sean Leonard wrote:

> 3) ABNF is comprised of simple declarative statements -- each statement
> is self-contained (except to the extent that it references other
> production names). Unlike ASN.1 or C/C++, for example, there are no
> imports, preprocessor directives, function prototypes, class
> definitions, or macros.

Unfortunately it isn't that simple. Often a draft has an extension to an 
RFC. The draft identifies the RFC being extended, and then the ABNF is 
incremental to that. (Often using "=/".)

Verifying that ABNF requires extracting the ABNF from the document being 
extended, and merging that with the ABNF from the extension draft.

Having done this several times, I can say that it is a pain in the ass 
and error prone.

Properly dealing with this requires a couple of things:
- a reliable extraction mechanism, such as we are discussing here
- some extensions to ABNF (at least an include mechanism)

We can't deal with the extensions here, but reliable extraction is 
something we can address. Then ABNF extensions can be dealt with.

	Thanks,
	Paul