Subject: Re: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt

From: Bill McQuillan <[email-masked]>
Date: Mon, 6 Dec 2010 16:07:17 -0800

I found several problems with this draft.

In overview, the reason that we removed the #rule from ABNF was that it was
very difficult to specify for a general case. This draft has the same
problem.

The production given does not actually produce the desired results.

>   n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element))

If the usage is: 

    5^(",")10 "abc"
    
it would allow something like:

    abc abc abc abc abc abc , abc

not:

    abc, abc, abc, abc, abc, abc, abd

which was probably intended.

-----

The production:

>   a              = VCHAR / SP / HT / <any other separator>

does not seem to address the possibility of multi-character separators very
clearly. What if I want to define a list like:

    abc and def and ghi and jkl

can I use:

    ^(" and ")ident

-----

I also do not believe that *FWS belongs in such a general rule and should
rather be defined by the actual usage. E.g.:

    5^(*FWS "," *FWS)10 "abc"

-----

Typo: 2.1 Examples, fourth example should be: ^("-")element

-- 
Bill McQuillan <[email-masked]>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 7 Dec 2010 08:47:14 +0800

I wholly agree with Bill on this.

You want something a little more complicated than you have already specified:

  {n}^({a}){m}{e} => {e} {n-1}*{m ? m-n : ''}({a} {e}) ; where n > 0
                     {e} *{m ? m-1 : ''}({a} {e})      ; where n == 0 or n undefined

Note the n == 0 is a special case.  Note that this assumes that m > n.  There seems little point in this construction if m == 1, but this does handle that case.

Aside from those sorts of problems, the definition of 'a' is a little loose.  You should try to build on the RFC 5234 ABNF in your definitions.

The proposed rule has an ABNF definition something like (?): 

  hat-rule = 1*DIGIT "^(" a ")" 1*DIGIT
  a = VCHAR / SP / HT / <any other separator>

That's a lot of flexibility in the internal part.  Too much flexibility.  Using parentheses means that they need to be distinguished from the parentheses that might appear in the 'a' part. 

If you see this as a substitute for the "*" in a normal repetition rule, that makes it easier.  Given that it has length longer than 1 character, by providing a clear delineation of the start and end you can be more flexible on the content.  Either that or to restrict what follows the ^.

Preferably delineate better AND restrict content:

   repeat /= hat-rule
   hat-rule = *DIGIT "^" element "^" *DIGIT

This restricts the content without preventing the use of more complex content - you just have to use a rulename instead.

You can't use elements (note the 's') here because that sort of complexity is a real pain to specify.

That leaves examples:

 1^";"^3element ; 1 to 3 elements separated by ;
 1^SP^element   ; 1 or more elements separated by SP rule
 ^","^3element   ; 0 to 3 elements separated by ,
 ^%x20.20^element  ; any number of elements separated by a two space characters

You should try to answer the question in the draft: why use the '^' character instead of the '#' character?  I guess that this is an arbitrary choice more than anything else.

--Martin

On 2010-12-07 at 11:07:17, Bill McQuillan wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 7 Dec 2010 08:49:56 +0800

On 2010-12-07 at 11:47:15, Thomson, Martin wrote:
>                      {e} *{m ? m-1 : ''}({a} {e})      ; where n == 0

My mistake, forgot the brackets on the second:
                     [{e} *{m ? m-1 : ''}({a} {e})]      ; where n == 0