Support for RFC2616-style ABNFs

[GoogleCodeExporter]

(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 julian.r...@googlemail.com on 20 Nov 2007 at 1:02

Attachments:

• diffs-for-abnf2616.txt

[GoogleCodeExporter]

fix: also properly handle list rule for case like

  n#m ( nore stuff )

Original comment by julian.r...@googlemail.com on 21 May 2008 at 4:31

Attachments:

• diffs

[fenner]

@reschke fyi

[fenner]

@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 #.

[reschke]

WFM; the patch reflects what I could do back then given my limited knowledge of lex/yacc.

[pkyzivat]

(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.

[fenner]

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.

[pkyzivat]

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.