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

Dave CROCKER <dhc@dcrocker.net> Sat, 11 December 2010 16:08 UTC

Return-Path: <dhc@dcrocker.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 C6A273A6D30 for <apps-discuss@core3.amsl.com>; Sat, 11 Dec 2010 08:08:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 zHhjED1rrpxv for <apps-discuss@core3.amsl.com>; Sat, 11 Dec 2010 08:08:43 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 99D313A6D2F for <apps-discuss@ietf.org>; Sat, 11 Dec 2010 08:08:43 -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 oBBGABMR030558 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 11 Dec 2010 08:10:16 -0800
Message-ID: <4D03A25E.9060709@dcrocker.net>
Date: Sat, 11 Dec 2010 08:10:06 -0800
From: Dave CROCKER <dhc@dcrocker.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: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
References: <4D028FE0.20906@bbiw.net>
In-Reply-To: <4D028FE0.20906@bbiw.net>
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]); Sat, 11 Dec 2010 08:10:17 -0800 (PST)
Cc: Mykyta Yevstifeyev <evnikita2@gmail.com>
Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Sat, 11 Dec 2010 16:08:43 -0000

Folks,

On 12/10/2010 12:38 PM, Dave CROCKER wrote:
> 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 #?


I see that the new version of the notation is:

>      <n>^(<a>)^<m>element

Having the same character used twice invites some parsing errors, though perhaps 
I'm being a purist on this point.  But having the separator be buried within the 
repetition boundaries numbers this way still causes me some discomfort.

At this point I am wondering whether it would not be cleaner to have the 
notation be:

      <n>*<m>[^(<a>)]element

In other words, augment the existing repetition construct with a clean separator 
construct.  The up-arrow only specifies a separator, it does not also specify 
repetition.

Hence:

       1*10^":"tag-val

would be 1 to 10 tag-vals separated by colons, and

       *^" "words

would be zero or more words separated by a space.


I'm still not in love with the up-arrow, but can see an argument for not 
overloading #, which runs the risk that a reader won't know which definition of 
# is in force.

Also the issue of allowing LWS or the like around the separator might best be 
expressed within the separator construct rather than be implied.  (On 
reflection, I have a vague memory that one of the other concerns about # was 
that whitespace was implied.)

Hence:

     1*3^(*LWSP "," *LWSP)

makes whitespace optional around the separator, whereas:

     1*3^("," LWSP)

requires exactly one whitespace character after each comma.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net