Subject: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02

From: Dave CROCKER <[email-masked]>
Date: Fri, 10 Dec 2010 12:38:56 -0800

Document Reviewed:   draft-yevstifeyev-abnf-separated-lists-02
Reviewer:            Dave Crocker

Summary:

      This specification adds a built-in mechanism to ABNF [RFC5234], to provide 
a concise notation for list syntax, with the ability to specify the list separator.

      A list notation ( #(rule) ) that only permitted comma as the separator was 
introduced into the original ABNF in [RFC733].  The DRUMS working group removed 
it when moving the ABNF specification to its own document [RFC2234].

      I am probably misremembering, but I believe that the working group 
consensus was that a) it was not used enough to warrant its inclusion in the 
core, and b) it added noticeable complexity to an ABNF processing engine. In 
other words, it was too expensive.  However note that HTTP-related efforts 
re-introduced the construct.

      Discussion of this new proposal on the apps-discuss mailing list appears 
to indicate that consensus is still against standardizing a list construct or, 
at least, against adding it to the ABNF core.  However the existing "#" 
mechanism for HTTP is still popular with that effort.

      To be standardized, the mechanism needs to demonstrate significant 
support.  So far, that is lacking.  However should it emerge, it still seems 
unlikely to warrant inclusion in the ABNF core.  For one thing, discussion on 
the list suggests that there might need to be variants of this proposed 
mechanism, to cover different styles or templates for lists.

      Given continuance of the old "#" form, I wonder whether it might be worth 
assembling whatever ABNF enhancements are out in the wild into an Informational 
document, so that they stand on their own and are easily citable?  Should anyone 
have need of one or another of these, they can simply invoke it rather than 
having to (once again) specify it.

Detailed Comments:

> 1.  Introduction
...
> (*LWS element n*m(*LWS separator *LWS element))

I think the initial *LWS is not as common and that the typical form for the 
list, itself, is:

      element n*m(*LWS separator *LWS element)

This is worth noting simply to make the core definition simpler.  There's 
nothing 'wrong' with what is in the doc, but I can easily imagine cases in which 
the leading white space (or even ANY white space...) is not wanted.

Also:

> It is obvious that this construction is too simplified and bulky.

It is not obvious to /me/ that it is too simplified...

>    This document uses ABNF notation and core rules defined in RFC 5234
>    [RFC5234]. The construction in {} is used for expressing arithmetic
>    expressions. For instance, if a=2, b=3 and c={b-a}, c is 1. In this
>    case c=1*DIGIT.

"In this case..."??  In what case?  I don't see how the production rule was 
obtained.  I understand that a subtraction was performed before that, but where 
is the previous version of the rule?

> he ABNF notation for separated lists is <n>^(<a>)<m>element

The ABNF itself should be on a new line and indented, IMO.

FWIW, I'm not fond of this notation.  The parenthetical seems clunky, especially 
since it overloads the use of parens.  I also don't like
putting it in between the upper/lower bound.

Out of curiosity, why ^ rather than re-use #?

That said, I don't have a form that I think is wonderful.

I'll note that the original RFC733 ABNF was merely one of many differerent BNF 
variants that were developed in the mid-70s.  That this particular variant 
became popular is worth some curiosity.  My best guess is that it happened to 
hit a balance between complexity and power.  It was simple enough and useful enough.

I am very hard-pressed to look at the current proposal and feel that it 
maintains that balance, even though I personally really like the idea of a list 
notation and was sorry to see it removed by DRUMS.  And I think that having a 
list mechanism with the ability to specify the separator is quite reasonable.

> 2.1. Examples
>
>    The section contains a few examples of using the defined
>    construction.
>
>    1^(";")3element indicates the list of elements separated by
>    semicolons (";") and OPTIONAL linear-white-spaces which consists of
>    at least 1 and at most 3 elements.
>
>    1^(SP)element indicates the list of elements separated by spaces and
>    OPTIONAL linear-white-spaces which consists of any amount of elements
>    but not less than 1.
>
>    ^(",")3element indicates the list of elements separated by commas
>    (",") and OPTIONAL linear-white-spaces which consists of any amount

For me, these examples emphasize my concern about the appearance of the 
notation.  Perhaps one can get used to this notation and come to interpret it 
naturally.  However I tend to view a mass of graphics within BNF as pretty 
distracting and not at all intuitive.

While yes, this is more terse that the 'full' notation, I can't say I'm 
impressed with the result.

> 3.  Security Considerations
>
>    Security issues are not discussed by this document.

A notation that can create obscure effects might well introduce security holes. 
  That's an issue that is not specific to this document, but I wonder whether it 
isn't time to raise this point in the Considerations sectin?

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 11 Dec 2010 12:50:30 +0200

Hello all,

Some notes:

Firstly, this is a review of -02 version and many issues have been
corrected in -03 one.

Also, see below:

10.12.2010 22:38, Dave CROCKER wrote:
>      This specification adds a built-in mechanism to ABNF [RFC5234], 
> to provide a concise notation for list syntax, with the ability to 
> specify the list separator.
>
>      A list notation ( #(rule) ) that only permitted comma as the 
> separator was introduced into the original ABNF in [RFC733].  The 
> DRUMS working group removed it when moving the ABNF specification to 
> its own document [RFC2234].
>
>      I am probably misremembering, but I believe that the working 
> group consensus was that a) it was not used enough to warrant its 
> inclusion in the core, and b) it added noticeable complexity to an 
> ABNF processing engine. In other words, it was too expensive.  However 
> note that HTTP-related efforts re-introduced the construct.
>
>      Discussion of this new proposal on the apps-discuss mailing list 
> appears to indicate that consensus is still against standardizing a 
> list construct or, at least, against adding it to the ABNF core.  
> However the existing "#" mechanism for HTTP is still popular with that 
> effort.
>
>      To be standardized, the mechanism needs to demonstrate 
> significant support.  So far, that is lacking.  However should it 
> emerge, it still seems unlikely to warrant inclusion in the ABNF 
> core.  For one thing, discussion on the list suggests that there might 
> need to be variants of this proposed mechanism, to cover different 
> styles or templates for lists.
>
>      Given continuance of the old "#" form, I wonder whether it might 
> be worth assembling whatever ABNF enhancements are out in the wild 
> into an Informational document, so that they stand on their own and 
> are easily citable?  Should anyone have need of one or another of 
> these, they can simply invoke it rather than having to (once again) 
> specify it.
>
>
>
> Detailed Comments:
>
>> 1.  Introduction
> ...
> I think the initial *LWS is not as common and that the typical form 
> for the list, itself, is:
>
> This is worth noting simply to make the core definition simpler.  
> There's nothing 'wrong' with what is in the doc, but I can easily 
> imagine cases in which the leading white space (or even ANY white 
> space...) is not wanted.
>
> Also:
>
> "In this case..."??  In what case?  I don't see how the production 
> rule was obtained.  I understand that a subtraction was performed 
> before that, but where is the previous version of the rule?
>
If the construction {} is used.
> FWIW, I'm not fond of this notation.  The parenthetical seems clunky, 
> especially since it overloads the use of parens.  I also don't like
# is already used in RFC2616 so it is made not to create a conflict.
> I'll note that the original RFC733 ABNF was merely one of many 
> differerent BNF variants that were developed in the mid-70s.  That 
> this particular variant became popular is worth some curiosity.  My 
> best guess is that it happened to hit a balance between complexity and 
> power.  It was simple enough and useful enough.
>
> I am very hard-pressed to look at the current proposal and feel that 
> it maintains that balance, even though I personally really like the 
> idea of a list notation and was sorry to see it removed by DRUMS.  And 
> I think that having a list mechanism with the ability to specify the 
> separator is quite reasonable.
>
>
>> 2.1. Examples
>>
> For me, these examples emphasize my concern about the appearance of 
> the notation.  Perhaps one can get used to this notation and come to 
> interpret it naturally.  However I tend to view a mass of graphics 
> within BNF as pretty distracting and not at all intuitive.
>
> While yes, this is more terse that the 'full' notation, I can't say 
> I'm impressed with the result.
>
>
> A notation that can create obscure effects might well introduce 
> security holes.  That's an issue that is not specific to this 
> document, but I wonder whether it isn't time to raise this point in 
> the Considerations sectin?
How can a simple notation have any security consideration?
At the moment -03 version is available where many issues were corrected.
You can find it here:

  https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/

Could you please review and comment this.

Any suggestions are welcome.

All the best,
Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Sat, 11 Dec 2010 12:10:32 +0100

On 10.12.2010 21:38, Dave CROCKER wrote:
> ...
> Given continuance of the old "#" form, I wonder whether it might be
> worth assembling whatever ABNF enhancements are out in the wild into an
> Informational document, so that they stand on their own and are easily
> citable? Should anyone have need of one or another of these, they can
> simply invoke it rather than having to (once again) specify it.
> ...

Indeed, that would be a good idea.

Some more thoughts:

- Please don't mess with RFC 5234 until those extensions are well 
understood and *in use*.

- Specifying is not sufficient; the few parsing and validation tools 
need to be extended. (*)

- I'm not sure why a new list production that is inspired by "#" can't 
have the same name.

Best regards, Julian

(*) In HTTPbis, we extended Bill Fenner's ABNF parser ("BAP") to accept 
the list production and re-serialize it in plain RFC 5234; this is what 
we're using to produce the 5234-style ABNF. See 
<http://trac.tools.ietf.org/wg/httpbis/trac/browser/abnfparser/bap>.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 11 Dec 2010 08:10:06 -0800

Folks,

I see that the new version of the notation is:

>      <n>^(<a>)^<m>element

Having the same character used twice invites some parsing errors, though perhaps 
I'm being a purist on this point.  But having the separator be buried within the 
repetition boundaries numbers this way still causes me some discomfort.

At this point I am wondering whether it would not be cleaner to have the 
notation be:

      <n>*<m>[^(<a>)]element

In other words, augment the existing repetition construct with a clean separator 
construct.  The up-arrow only specifies a separator, it does not also specify 
repetition.

Hence:

       1*10^":"tag-val

would be 1 to 10 tag-vals separated by colons, and

       *^" "words

would be zero or more words separated by a space.

I'm still not in love with the up-arrow, but can see an argument for not 
overloading #, which runs the risk that a reader won't know which definition of 
# is in force.

Also the issue of allowing LWS or the like around the separator might best be 
expressed within the separator construct rather than be implied.  (On 
reflection, I have a vague memory that one of the other concerns about # was 
that whitespace was implied.)

Hence:

     1*3^(*LWSP "," *LWSP)

makes whitespace optional around the separator, whereas:

     1*3^("," LWSP)

requires exactly one whitespace character after each comma.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 11 Dec 2010 08:16:42 -0800

> Firstly, this is a review of -02 version and many issues have been

However I raised a number of questions and concerns that do not appear to be 
resolved in the new version.

Since the number of comments in the review is not all that large, it would be 
helpful to see responses to each, even for those having the response "resolved 
in -03."  That will make it easy for readers to form their own opinions about 
the resolutions.

>> A notation that can create obscure effects might well introduce security
>> holes. That's an issue that is not specific to this document, but I wonder
>> whether it isn't time to raise this point in the Considerations sectin?

Whether it is simple is not the point.  The point is that a meta-syntax that 
makes syntax specifications less clear can make it legal to have data in forms 
that might not have been intended or desired.  This can, in turn, allow in types 
of data that are potentially dangerous.  This is often a problem with space, for 
example, which seeks to bypass filters.

d/
-- 

   Dave Crocker

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 13 Dec 2010 12:58:54 +0800

> At this point I am wondering whether it would not be cleaner to have

I was initially apprehensive of your proposed reuse of "*" for this construct.  However, on reflection, I like it.  This is a statement that says there are <n> to <m> elements, except that this is tweaked so that each repetition is separated by <a>.  The default value for <a> is the empty string.

Drop the parentheses.

I'm still concerned about how <a> is defined.  It seems that <element> is the right rule to use here; the -03 draft still uses ``*(VCHAR / SP / HT)'', which I think is wrong.

That gives a new, expanded definition for the <repeat> rule:

  repeat         =  (1*DIGIT / (*DIGIT "*" *DIGIT)) ["^" element]

Mykyta: this is what the draft is still missing.  Rather than concentrating on the expanded form; use prose and example and instead concentrate on getting the syntax right.

> I'm still not in love with the up-arrow [...]

I too had a similar reaction, but it's only fair that Mykyta gets to choose, having had the initiative to write this down.  I really can't think of a reason other than the aesthetic one, which isn't really strong enough to ask for a change.

> Also the issue of allowing LWS or the like around the separator might
> best be expressed within the separator construct rather than be implied.  

Please, yes.  Let the user choose what separators are valid.  Optional whitespace might be commonplace in some grammars, but you should not assume that it's always desired.

--Martin

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Dec 2010 10:56:08 +0100

On 11.12.2010 17:10, Dave CROCKER wrote:
> In other words, augment the existing repetition construct with a clean
> separator construct. The up-arrow only specifies a separator, it does
> not also specify repetition.
>
> Hence:
>
> 1*10^":"tag-val
>

Looks better to me.

I believe it would be useful to have a look at existing specs that use 
list productions, and see how they could use this format.

That might discover missing pieces, or just things that are done 
differently across specs, which may make it harder to find a common syntax.

For instance, in HTTP we have:

"Wherever this construct is used, null elements are allowed, but do not 
contribute to the count of elements present. That is, "(element), , 
(element) " is permitted, but counts as only two elements. Therefore, 
where at least one element is required, at least one non-null element 
MUST be present. Default values are 0 and infinity so that "#element" 
allows any number, including zero; "1#element" requires at least one; 
and "1#2element" allows one or two." -- 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1>

I don't think the proposal addresses this use case, so it appears it 
would be unusable for expressing the HTTP ABNF.

Best regards, Julian

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Dec 2010 06:13:18 +0800

> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1>

For HTTP, the # rule can be handled with some tweaking...

  a = #b

->

  a = *LWS *^(*LWS "," *LWS)[b]

It means that this isn't as directly usable by HTTP, though establishing a convention would make this a little easier.

  a = *LWS *^COMMA[b]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Dec 2010 08:29:15 +0100

> It means that this isn't as directly usable by HTTP, though establishing a convention would make this a little easier.

Maybe I wasn't clear about the problem I see.

When in the HTTP grammar, we say

   1#2element

that matches the following header field values

   element

   element, element

   element, , element

So empty elements aren't counted.

I note that <http://tools.ietf.org/html/rfc822#section-2.7> has the same 
rule.

Is there a use case for this notation where empty list elements behave 
differently?

Best regards, Julian

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Dec 2010 03:52:50 +0800

> So empty elements aren't counted.

Oh, well that's actually even easier...

    1*2^(*LWS *("," *LWS))element

--Martin

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 16 Dec 2010 18:09:36 +0200

Hello all,

I've just uploaded the new version of 
draft-yevstifeyev-abnf-separated-lists - -02.
It has many issues corrected (see diffs). Among other, a new form is
presented - n*m#a(element), as was proposed, the definition has been updated
also. Could you please review *this* version?

All the best,
Mykyta Yevstifeyev

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 16 Dec 2010 09:40:30 -0800

Folks,

Note:  We still do not have statements of support for standardizing a mechanism, 
in spite of the continued activity on this thread.  So far, this is a fun 
exercise, but that's all.

Comments on the latest draft:

> Abstract
>
>    This document defines Augmented Backus-Naur Form (ABNF) notation for
>    representing lists separated by any specified character. It updates
>    RFC 5234.

The form of the mechanism permits the separator to be a string, not just a 
character.

> 1.  Introduction
>
>    ABNF does not provide the possibility to express the separated lists
>    of elements via specific construction. If it is needed (generally for
>    defining HTTP headers or human-readable forms), the following ABNF
>    construction is used:

    the following ABNF construction is used
    ->
    the following is an example of an ABNF construction that would be used

{ There are many different list forms; the one given here builds in certain 
assumptions that do not always apply.  /d }

>    It is obvious that this construction is too simplified and bulky.

Statements about human perception and assessment are almost always a mistake in 
a technical specification.  Don't make them.

It is enough to assert that a 'list' is a common pattern in ABNF specifications 
and it would make list specifications more convenient to have a construct that 
supports them.

>    This document specifies universal ABNF notation for lists, separated
>    by arbitrary specified characters.

    This document specifies universal ABNF notation
    ->
    This document specifies a concise ABNF notation

> 2.  Notation Description

    Notation Description ->  List Notation

{ This section is the formal definition of the construct; it's not just a 
"description".  /d }

>    This document augment the ABNF notation <n>*<m>element with OPTIONAL

    augment -> augments

    ABNF notation -> ABNF repetition notation

>    separator part, so that the construction for separated lists is:
>
>    <n>*<m>[#(<a>)]element

In reviewing the way Section 3 of RFC 5234 specifies things, I believe that the 
specification, here needs to be made without the square brackets and without the 
parentheses.  (I think someone earlier commented about the parens.)

In the place the construct is being specified, all of the pieces are required. 
The concept of being optional comes into play later.

So I think the specification of the construct needs to be:

    <n>*<m>#<a>element

>    where <a> is a separator. This construction indicates at least <n>

    a separator -> a separator string that is used in between element repetitions

>    and at most <m> elements separated by <a>.
>
>    The corresponding construction <n>element is also updated so that for
>    separated lists it stands as:
>
>    <n>[#(<a>)]element

    <n>#<a>element

>    indicating exactly <n> elements separated by <a>.
>
>    The ABNF for this construction is:
>
>    n*m#(a)(element) = (n_1*m_1(element 1*SP a) f(element))

    n*m#a element) = (n_1*m_1(element 1*SP a) f(element))

>    n#(a)(element)   = (n_1(element 1*SP a) element)

    n#a element   = (n_1(element 1*SP a) element)

>    1*3#(";")element indicates the list of elements separated by

Question to the audience:  are the parentheses needed here?  The quotation marks 
would seem to provide sufficient lexical uniqueness, but this is the sort of 
nuance I usually get wrong.

>    Security issues are not discussed by this document.

Improper or confusing specifications can introduce extensive security risks. 
The new construct provides a concise and clear means of specifying a common 
pattern that might otherwise permit data variations that could be used for 
hiding unwanted content, such as encoding a spam message that would bypass filters.

{ I didn't create this observation.  Mark Delaney didn't either, but during the 
DomainKeys development he was particularly adept at demonstrating this exploit. /d }

-- 

   Dave Crocker

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Dec 2010 22:56:36 +0100

On 16.12.2010 18:40, Dave CROCKER wrote:
> Question to the audience: are the parentheses needed here? The quotation
> marks would seem to provide sufficient lexical uniqueness, but this is
> the sort of nuance I usually get wrong.
> ...

Parentheses please.

Best regards, Julian

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 17 Dec 2010 06:04:54 +0800

+1 to the rest of this.  Other stuff below.

> exercise, but that's all.

+1.  I'm still open to being convinced though.  The HTTP-specific extensions to ABNF are a bit of an irritant, as are other such specification-specific extensions.  As it stands, the draft is not enough to convince me.

> >    (*LWS element n*m(*LWS separator *LWS element))

In fact, using more prescriptive prose and specific examples is probably better.  Explain in prose, then provide a few actual examples, with examples of the syntax that conforms to these grammars as well.  The style of RFC 5234 is a good guide; I don't like the fact that this draft strays so far from that.

The entire draft might be summarized so much more succinctly and clearly in this fashion:

--8<--
3.11  Separated list: n*m#s rule

A hash following a repetition indicates a separator that appears between each of the multiple instances of the element.  Any variable or specific repetition can be followed by a separator.  The full form is:

  <a>*<b>#<separator>element

Where <separator> is any valid element - including grouped elements - followed by optional whitespace.

A rule of the form:

   4*7#"," foo

is equivalent to:

   foo 3*6("," foo)

Similarly, a rule of the form:

   *#[*WSP ";" *WSP] foo

is equivalent to:

   [foo *([*WSP ";" *WSP] foo)]

4.1 ABNF Definition of ABNF
	
The <repeat> rule is extended from that in [RFC5234] from:

   repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)

to:

   repeat = 1*DIGIT / (*DIGIT "*" *DIGIT) [ "#" element *c-wsp ]

-->8--

{ I missed the optional c-wsp in my previous comments - that's necessary to separate the two consecutive <rulename> constructs in a repetition.  For instance:

   example = 3*10#comma list-item
}

> parentheses.  (I think someone earlier commented about the parens.)

That was probably me.  You are correct.  Based on this, the grammar should be as above.

>     n*m#a element) = (n_1*m_1(element 1*SP a) f(element))

All this n_1, m_1 and f stuff is confusing and unnecessary.  It relies on what amounts to another modification to the grammar.  The definition of <f> still doesn't make sense.  u-(u-1) is 1, always.

> nuance I usually get wrong.

Parentheses are not required here - if we assume that the separator grammar conforms to <element>.  They would be permitted, but the draft still does not describe the grammar for the separator.

--Martin

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 17 Dec 2010 14:48:22 -0800

>> the sort of nuance I usually get wrong.

In the form of the specifications in that part of the document, that means that 
the parentheses are terminals.  They are required to be used in the construct.

d/

-- 

   Dave Crocker

---

From: Paul Overell <[email-masked]>
Date: Sun, 19 Dec 2010 16:46:58 +0000

In message <[email-masked]>, Dave CROCKER
<[email-masked]> writes

Hi,

A few comments on <draft-yevstifeyev-abnf-separated-lists-04>

1)

>   It is obvious that this construction is too simplified and bulky.

This is a subjective statement and does not belong in a formal
specification.  It does not make the case for this proposal.  I do not
understand what is "too simplified" in the above.

Here is an ABNF example from RFC5322

>   mailbox-list    =   (mailbox *("," mailbox)) / obs-mbox-list

Here is the same with the proposed notation

   mailbox-list    =   1*#(",")mailbox / obs-mbox-list

Is it clearer?  It it easier to understand?  The proposed syntax may
(slightly) reduce bulk, but by putting the "," before the mailbox I
think it also reduces clarity.

The original # list notation from RFC822 was dropped from RFC2234,
AFAIR, because it was deemed to be too specialized and so easily
replaced with the other constructs.

2)

>   n               = *DIGIT        ;the minimum amount of elements
>   m               = *DIGIT        ;the maximum amount of elements
>   n_1             = {n-1}
>   n_1             =/ *DIGIT
>   m_1             = {m-1}
>   m_1             =/ *DIGIT
>   u               = <the number of used elements>
>   f               = {u-(u-1)}
>   f               =/ 1*DIGIT      ;will be 0 if no elements are used
>                                   ;and 1 if at least one is used

The above is *NOT* the ABNF of the proposed construct.  Instead it tries
to define the semantics in term of ABNF extended with {}, but I find it
confusing and overly complex.  Nor it is syntactically correct ABNF
(illegal rulenames, <a> undefined).

Instead, the formal syntax for the proposal should extend the existing
RFC5234 syntax for a repetition using the =/ operator.  The semantics
should be specified in prose.

Something like:

        repetition     =/  [repeat] list-spec element
        list-spec      = "#" separator
        separator      = group

>>
>> Parentheses please.
>
>
>In the form of the specifications in that part of the document, that
>means that the parentheses are terminals.  They are required to be used
>in the construct.
>
>d/
>

Note that using <group> for the separator ensures the use of
parentheses.

3) One of the design decisions we made for ABNF in RFC2234, still
preserved in RFC5234 para 3.1 is:

>   NOTE:
>
>      This specification for ABNF does not provide for implicit
>      specification of linear white space.
>
>   Any grammar that wishes to permit linear white space around
>   delimiters or string segments must specify it explicitly.

This proposal seems to break this design decision by re-introducing
implicit linear white space.

>   n*m#(a)(element) = (n_1*m_1(element 1*SP a) f(element))

The above seems to require at least one space before the separator.
Whereas the examples talks of "OPTIONAL spaces".

In summary, if this proposal is to be adopted then I think the following
need to be addressed:

1) The case needs to be made for adding the proposed construct.  ABNF
can already define lists, is a more succinct specialized syntax really
necessary?

2) The formal syntax should be given as an extension to that given in
RFC5234.  The semantics should be expressed in prose.

3) The RFC5234 design decision to have no implicit white space should be
respected.

Regards
-- 
Paul Overell