Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-00.txt

[Tony Hansen <[e-mail]>]

On 12/6/2010 11:34 AM, Tony Hansen wrote:
> ...
I'm happy with the definitions of n, m and o that are given in -01.
>>> Note also: your introduction is incorrect. It talks about ABNF 
>>> having the # rule. However, it does not. The original 822 ABNF had 
>>> the # rule, but it was dropped when ABNF was extracted for the *234 
>>> series.
>> Maybe I meant the construction form RFC 2616.
>
> That's fine -- say so then.
>
> Note that the #rule in 2616 also uses a minimum of n and a maximum of 
> m -- it does not use a difference for the second number.
>
> If you're going to offer this as an update to RFC 5234, you may wish 
> to specify that the #rule be added in as well.

You may wish to add to the Introduction that RFCs 733, 822, 1945, 2068, 
2543, 2616 and 2831 all defined a limited version of this rule, 
specifically for a comma separator.

More comments from version -01:

I disagree with adding SP / HT to the production list for a:

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

Your example that uses this:

     1^(SP)element indicates the list of elements separated by spaces
     which consists of any amount of elements but not less than 1.

has serious issues as a protocol element. It allows for arbitrary 
amounts of SP or HT followed by a single SP followed by arbitary amounts 
of SP or HT. What any self-respecting protocol would really want is a 
list separated by at least one SP or HT, as in

     1*(1*LWS element)

This is more obvious and exact. I'd hate to write a parser for 1^(SP), 
or debug protocol problems with it. (Is there really at least one SP 
character between those elements?)

The example

     ^(-)element indicates the list of elements separated by hyphens ("-")

cannot use a bare "-" like that. It must be specified as

     ^("-")element

Hope this helps.

I think it would be useful to find ABNF constructs in existing protocols 
that provide for lists and give examples of how their ABNF would have 
been simplified if this new ABNF construct were available.

     Tony Hansen
     [e-mail]