bap
bap copied to clipboard
ietf-tools
Support for RFC2616-style ABNFs
(this may be an enhancement request)
For the purpose of migrating the BNF rules in RCF2616, I have added minimal
support for the list (#) rule defined in
http://tools.ietf.org/html/rfc2616#section-2.1.
Note that this is probably incomplete because it has only been tested with
the rules from RFC2616 itself, in particular it only supports "#" and "1#".
I am attaching the diffs in case somebody feels like turning this into a
full-blown BAP feature.
Original issue reported on code.google.com by [email protected] on 20 Nov 2007 at 1:02
Attachments:
fix: also properly handle list rule for case like
n#m ( nore stuff )
Original comment by [email protected] on 21 May 2008 at 4:31
Attachments:
@resche After looking at this code a bit, I think I would rather optionally replace the list with the equivalent tokens in the in-memory version, rather than change it on output. i.e., have a phase that replaces the one object* representing a list with the appropriate group and concatentation tokens, and then let the optimizer have its chance at reducing it, instead of having to have different cases for lists in T_RULE and T_GROUP. In addition, if we are in a mode where we are permitting the # syntax, then we can simply skip this modification and actually output the #.
WFM; the patch reflects what I could do back then given my limited knowledge of lex/yacc.
(Maybe this is the wrong place for this comment, but nevertheless...)
I find this "feature" to be a disturbing hack. The problem is that it elevates "," to exulted status. Why is "," so special? Often lists use other separators. (Ones that are commonly seen are ";" and " ", but also sometimes "|" and "/".) So why would we special-case "," in ABNF?
It would be different if the operator could be parameterized with the desired separator. But ABNF doesn't have trinary operators.
As a result I consider this a waste of a precious "nice" operator symbol that could be used for some more general-purpose feature.
I agree that a concise representation for lists would be nice to have. Perhaps it could be accomplished by incorporating some sort of macro or function mechanism into abnf.
Paul,
I imagine using "-o RFC7230", defaulting to off, to enable this support. Since it's defined in a standards-track document, https://tools.ietf.org/html/rfc7230#section-7 , I don't think that there's an argument to be had about the syntax. Since it defaults to off, I don't think it affects the "normal" case.
Bill - OK, if it is considered a "deviant" branch then I don't have any problem with it.
It won't present any issues until some hypothetical time in the future when somebody wants to use "#" for some other extension. Then I guess there might be some objection on the basis that it would be incompatible with past practice.