[rfc-i] v3imp #8 Fragment tagging on sourcecode
dev+ietf at seantek.com
Sat Jan 24 08:59:43 PST 2015
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").
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.)
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.
More information about the rfc-interest