[apps-discuss] Fwd: Re: Fwd: I-D Action:draft-yevstifeyev-abnf-separated-lists-00.txt

Dave CROCKER <dcrocker@bbiw.net> Thu, 09 December 2010 23:09 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 A275328C155 for <apps-discuss@core3.amsl.com>; Thu, 9 Dec 2010 15:09:30 -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 oS2XGFuNOvVO for <apps-discuss@core3.amsl.com>; Thu, 9 Dec 2010 15:09:29 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 4F9A528C144 for <apps-discuss@ietf.org>; Thu, 9 Dec 2010 15:09:29 -0800 (PST)
Received: from [192.168.43.47] (m4a2436d0.tmodns.net [208.54.36.74]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oB9NApxZ026709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Thu, 9 Dec 2010 15:10:59 -0800
Message-ID: <4D0161EB.6020509@bbiw.net>
Date: Thu, 09 Dec 2010 18:10:35 -0500
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: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Content-Type: multipart/mixed; boundary="------------010009050700090207050305"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 09 Dec 2010 15:11:00 -0800 (PST)
Subject: [apps-discuss] Fwd: Re: Fwd: I-D Action:draft-yevstifeyev-abnf-separated-lists-00.txt
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: Thu, 09 Dec 2010 23:09:30 -0000

This is from my ABNF co-author. It took a couple of days to get his approval to 
forward it, so it refers to a previous version of the document.

I will yet be sending my own comments.  (It's been a busy week.)

d/

-------- Original Message --------
Subject: Re: Fwd: I-D Action:draft-yevstifeyev-abnf-separated-lists-00.txt
Date: Mon, 6 Dec 2010 21:12:19 +0000
From: Paul Overell <paul@bayleaf.org.uk>
To: Dave CROCKER <dcrocker@bbiw.net>



>1.  Introduction
>
>   ABNF provides a possibility to express lists of elements, separated
>   by commas (",") via the construction <a>#<b>element.

No, RFC5234 ABNF doesn't have the # construct.  The # notation is an
RFC822 construct.  AFAIR the consensus was to exclude it from ABNF as it
was too RFC822 specific and could trivially be handled as foo *(","
foo).

Note RFC822 also allowed a single comma to be replaced by any number of
commas.

>However
>   sometimes it is needed to express list of elements, separated by
>   other characters, such as semicolons, points etc. In this case the
>   following ABNF construction is used:
>
>   ([*LWS] element [n*([*LWS] separator [*LWS] element)])

LWS is not defined in RFC5234 (or RFC822), it should be WSP.  The []
around [*LWS] is redundant.

         element *(*WSP separator *WSP element)

>It is obvious that this construction is too bulky.

This is subjective, too bulky for what?

>   The ABNF for this construction is:
>
>   n^(a)m element = ( n([*LWS] element) [*o([*LWS] a [*LWS] element)])
>   n              = 1*DIGIT    ;minimum amount of elements
>   m              = 1*DIGIT    ;maximum amount of elements
>   o              = <m-n>      ;difference between <m> and <n>
>   a              = VCHAR      ;separator
>

1) The above is *not* ABNF for the proposed extension. It is an attempt
to define the semantics of the extension with an ABNF equivalent.  The
above is not legal ABNF.

2) I'm not even clear what the proposed syntax is.  Is a comma separated
list of foo given as

^,foo

or as

^(,)foo

?

The former is broken because the separator might be a digit which would
result in ambiguous syntax.  The latter could be made to work but it is
a bit obscure and overloads ().

3) The proposed syntax introduce an unquoted character as a terminal
symbol, whereas in all other constructs a terminal character has to be
quoted.

4) Unlike RFC822, ABNF deliberately avoids any implicit whitespace.  In
any ABNF specified language all whitespace must be explicit.  This
extension re-introduces implicit whitespace around the separator.  I
would strongly object to this extension on this ground alone.

5) Trying to decode the above ABNF semantics: the author seems to have
specified that

2^,4foo matches

foo foo, foo, foo

i.e. The first 2 foo are not separated by a comma.  If this extension is
supposed to follow RFC822 then he has misunderstood RFC822 # operator,
in which all elements are separated.

6) Why are separators restricted to VCHAR?  Why not num-value, or
another element?

I recommend that this extension is rejected.  Even if the design and
specification faults were addressed I don't see having a specific syntax
for lists gives sufficient (or any) advantage to warrant changing the
language.



Do I need to send my comments anywhere official?

Regards
-- 
Paul Overell


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net