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

[Paul Overell <[e-mail]>]

In message <[e-mail]>, Dave CROCKER
<[e-mail]> writes

Hi,

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

1)

>   (*LWS element n*m(*LWS separator *LWS element))
>
>   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)

>   The ABNF for this construction is:
>
>   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               = *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