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

[Mykyta Yevstifeyev <[e-mail]>]

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:
>
> 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?
>
If the construction {} is used.
>
>> 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 #?
# is already used in RFC2616 so it is made not to create a conflict.
>
> 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?
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