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

[nico at cryptonector.com (Nico Williams)]

On Tue, Jan 27, 2015 at 03:53:43PM -0500, Paul Kyzivat wrote:
> I agree that we need to be careful not to extend ABNF too much,

I'm not sure what "extend too much" could mean here.

Consider draft-ietf-json-text-sequence-13.  It gives two definitions of
the same rule, for two distinct contexts.  A module system here would be
perfect.

> 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?)

But we pretend that ABNF should be extractable and readable by machines,
and then be validated by machines too.  There will be cases where one
RFC's ABNF imports another's and so on, and in those cases a machine
cannot extract and validate the ABNF unless the importing document
quotes the imported rules verbatim (which would be bad, I'm sure you'd
agree).

What possible harm could result from adding a module system for ABNFs?!

Sure, we'd then have a pile of RFCs that define ABNF rules without
defining modules, but most could be said to define a single module
named rfc1234.abnf.  A few might need an update (IF we care to) to
specify a multiple modules instead of one, and many might need updates
(some day) to specify what modules' rules are imported, and what rules
are exported.  This isn't a harm, and it's not work we must do as a
result of adding a module system, just work we would have done has we
had a module system from the get-go, and work we'll want to do as we
have other reasons to update these older RFCs.

Nico
--