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

Dave CROCKER <dcrocker@bbiw.net> Fri, 10 December 2010 20:37 UTC

Return-Path: <dcrocker@bbiw.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8585228C13A for <apps-discuss@core3.amsl.com>; Fri, 10 Dec 2010 12:37:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUoGNjic7Lgm for <apps-discuss@core3.amsl.com>; Fri, 10 Dec 2010 12:37:36 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 7979928C11D for <apps-discuss@ietf.org>; Fri, 10 Dec 2010 12:37:34 -0800 (PST)
Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBAKd0ol017630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2010 12:39:05 -0800
Message-ID: <4D028FE0.20906@bbiw.net>
Date: Fri, 10 Dec 2010 12:38:56 -0800
From: Dave CROCKER <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 10 Dec 2010 12:39:06 -0800 (PST)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Dec 2010 20:37:38 -0000

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?


> 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 #?

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?



-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net