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

[Mykyta Yevstifeyev <[e-mail]>]

Hi all,

Some answers:

06.12.2010 16:45, Tony Hansen wrote:
> On 12/6/2010 2:36 AM, Mykyta Yevstifeyev wrote:
>> 2010/12/6, Tony Hansen<[e-mail]>:
>>>      n              = 0*DIGIT    ;minimum amount of elements
>>>      m              = 0*DIGIT    ;maximum amount of elements
>> Will be taken into consideration.
>> Or, maybe, just *DIGIT .
>
> *DIGIT is fine
Will be corrected in the next version of the draft.
>
>>> Your draft is inconsistent. In one place, you use "m" and another place
>>> you use "o".
>>>
>>> I don't see why you use "o" at all -- I recommend you just use "m".
>> o = m-n as m is maximum and n we have already used as it is mimimum.
>> So we can use only he differebce between them.
>
> We *can*, but that doesn't mean we *should*.
>
> Other ABNF constructs use "m" and "n" directly -- they do *not* use 
> the difference.
>
> I think using the difference for this case is just asking for trouble 
> and will introduce subtle errors in future protocols that use this 
> construct.
>
> Consider the normal 5234 ABNF rule <a>*<b>element. <a> is the minimum 
> and <b> is the maximum. It is *not* <a>*<b-a>element.
>
> The 822 ABNF rule <a>#<b>element, which your rule is updating, also 
> used the same minimum and maximum values -- it did *not* use the 
> difference.
However we MUST use *n* elements and MAY use all more *(m-n)*. If we say 
that we use the we MAY use more *m*, it is possible that we use *(m+n)* 
togetger, but we MUST use at most *m* while
*m+n is not m*
>
> 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.
>
>>> It would be useful to have examples of where this production would have
>>> been useful, such as some RFCs or I-Ds that have been written using the
>>> "old way" and how they would be better written using the "new way".
>> At the moment there are no acceptable examples - however I think the
>> construction will be useful in future.
>
> Two points: Examples of future use would still be useful.
>
> And not having examples of places where this would have been useful in 
> the past is going to make it a very hard sell.
>
> There was a reason the #rule was dropped from the *234 series of RFCs 
> -- it wasn't found to be useful enough to keep for a general purpose 
> ABNF rule.
>
>     Tony Hansen
>     [e-mail]
>

06.12.2010 17:01, Barry Leiba wrote:
> On Mon, Dec 6, 2010 at 4:23 AM, Mykyta Yevstifeyev<[e-mail]>  wrote:
>> I am writing to reuqest the review of my draft folowing the advice of
>> Russ Housley
> ...
>> You are able to find it here:
>>
>> https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/?include_text=1
> It's short; I'll give it a review for form here.  I'll leave it to
> Dave to discuss why such list constructs aren't in 5234.
>
> Starting with a nit: How did you create this draft?  The abstract is
> in the "wrong" place (I initially thought it was missing), so it seems
> you're not using the latest tools.
>
> The abstract is too brief.  How about this?:
>
> OLD
>     This document specifies Augmented Backus-Naur Form (ABNF) notation
>     for separated lists. It updates RFC 5234.
>
> NEW
>     This document defines Augmented Backus-Naur Form (ABNF) notation
>     for representing lists separated by any specified character. It
> updates RFC 5234.
>
Will be taken into consideration.
> Introduction:
>     ABNF provides a possibility to express lists of elements, separated
>     by commas (",") via the construction<a>#<b>element.
>
> Where is that documented?  It's not in RFC 5234.
See above - in RFC2616 (however it is not a specification of ABNF).
>
> Section 2:
> The ABNF isn't right.  You don't show that<n>  and<m>  are optional,
> and you define them as having at least one digit each... and then you
> say that either or both can be omitted in some cases.
>
> Also, "<m-n>" as an arithmetic difference isn't meaningful in ABNF.
> Perhaps the text that's there is sufficient to make it clear, but I
> think it won't pass automated processing.  I'm not sure what the best
> way to handle that is.
>
See above.
> A section with a few examples would be helpful.
Will be added.
> Barry
>
Mykyta Yevstifeyev