[rfc-i] v3imp #8 Fragment tagging on sourcecode
pkyzivat at alum.mit.edu
Tue Jan 27 12:53:43 PST 2015
On 1/25/15 3:57 AM, Julian Reschke wrote:
> On 2015-01-24 17:59, Sean Leonard wrote:
>> On 1/24/2015 8:21 AM, Sean Leonard wrote:
>>> First of all there is no such thing as "ABNF modules" yet--only ABNF
>>> grammar (combined with specification text). I recognize this
>>> conversation is trending to creating them.
>>> Providing different definitions of the same rule in the same RFC is
>> The more I thought about this, the more I would like to propose that the
>> RFC itself be unit of analysis (i.e., "module").
> I agree that it's good to formalize this somewhat, but I'm not convinced
> updating/extending RFC 5234 is a good idea.
> For instance, in the HTTP specs we use prose rules with a well-defined
> This might be enough for automated checkers to do the right thing.
I agree that we need to be careful not to extend ABNF too much, making
it more difficult. OTOH, the people who use ABNF are not, for the most
part, stupid. (Does ABNF need to be understandable to someone who
doesn't know at least one real programming language?)
The use of some symbols defined in another draft presents a particularly
To verify the using ABNF, you need to import at least the rule defining
the symbol in question. But that rule may well refer to other rules in
the referenced document. Should you:
- selectively import rules that are needed, one by one, until there
are no more undefined symbols?
- OR, simply import the full set of rules from the referenced document?
Either way, there may then be conflicts between rules defined in the new
document and those imported from the old document. The potential is
greater if you have imported all the ABNF from the referenced document.
And this of course depends a bit on whether the ABNF in the referenced
document was intended to be one "module" or not.
RFC5234 is itself an interesting case study. It includes:
- a set of "Core Rules" in Appendix B. This could be viewed as one
- a complete ABNF definition of ABNF. This could also be viewed as
a separate ABNF "module", but it informally indicates that it
depends (imports) the Core Rules.
- ABNF fragments interspersed with text, duplicating rules in
both of the above.
*Many* uses of ABNF reuse rules defined in the Core Rules. When doing
so, it would probably be fine to import the full set of Core Rules, but
it would probably be inappropriate to also import the rules defining the
ABNF of ABNF, and it certainly would be inappropriate to also import all
IMO it would make sense to introduce enough new syntax to ABNF to define
named modules, and to specify the import of specific named modules from
an external document.
More information about the rfc-interest