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

[dev+ietf at seantek.com (Sean Leonard)]

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 
> reckless

The more I thought about this, the more I would like to propose that the 
RFC itself be unit of analysis (i.e., "module").

There are many examples of RFCs that normatively import definitions from 
other RFCs. For example, importing ALPHA, DIGIT, etc. from RFC 5234, or 
importing URI from RFC 3986, are common.

Here is a first stab (example) at an ABNF grammar for importing rules:

IMPORTS userinfo, URIunreserved = unreserved FROM [RFC3986]

The syntax is:

a line ending in CRLF, starting with "IMPORTS"

a comma-delimited list of rules named in the source

each rule can be renamed with "localRuleName = foreignRuleName"

the keyword "FROM"

the source identifier: currently the only acceptable format is 
[RFCXXXX]. (I recognize that people may want to use URIs, URNs, 
etc...please, let's keep it simple.)

The end.

An IMPORTS statement can be anywhere in the document; it is effective 
throughout the document. Convention suggests that it should be placed 
near the top. Repeated IMPORTS statements are harmless as long as they 
are not conflicting.

For RFCs after the numeric number of the RFC that this IMPORTS statement 
is defined in, a processor shall assume that all [RFC5234] Core Rules 
(Appendix B) are imported into the local context. I.e., importing ALPHA, 
DIGIT, BIT, LWSP, etc. do not have to be done explicitly.

Sean