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

Mykyta Yevstifeyev <> Sat, 11 December 2010 10:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE9EB3A6C9A for <>; Sat, 11 Dec 2010 02:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GI4ebvFTxbYR for <>; Sat, 11 Dec 2010 02:48:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1D22E3A6D1E for <>; Sat, 11 Dec 2010 02:48:50 -0800 (PST)
Received: by bwz8 with SMTP id 8so5230004bwz.38 for <>; Sat, 11 Dec 2010 02:50:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=z0tFz535inG5qN9aHZynWmBQWtoqop6X9qYwkEEmVJg=; b=uyTpBEmxiXRpHIw5n+LkvskpeWQqxwFwWRB+imjY0z7rzLB29s1cKf30vNucvnMgMp AUSmk/TWyNXZb+s1QRVYT2kFKpzeGuwqNSMS8+zjTONBiK4ZWrhd1QQVNCZkvybnhUBJ pRXKYzhHk05grRm3QwMHfX5Tr3tzUux4iBmCs=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NTu2SwBCBQSZd3gMTrIrfSM2sMH2ZQm95T/9pF6JWUVWpJKmi+RfEibsK9kdp9tbBy eCKAzlteIEN0so1p+mpSCb10b/BdxyqZhND9AeL5yMR7TH5bWKBQdQ4Ioub46R+06/Fz JR/HCD3CGix/VVIsAl/VQSYk+3uxWKmtakI+E=
Received: by with SMTP id j7mr1703157bki.85.1292064621836; Sat, 11 Dec 2010 02:50:21 -0800 (PST)
Received: from [] ([]) by with ESMTPS id s16sm1995974bkk.12.2010. (version=SSLv3 cipher=RC4-MD5); Sat, 11 Dec 2010 02:50:20 -0800 (PST)
Message-ID: <>
Date: Sat, 11 Dec 2010 12:50:30 +0200
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Dave CROCKER <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Dec 2010 10:48:53 -0000

Hello all,

Some notes:

Firstly, this is a review of -02 version and many issues have been
corrected in -03 one.

Also, see below:

10.12.2010 22:38, Dave CROCKER wrote:
> 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?
If the construction {} is used.
>> 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 #?
# is already used in RFC2616 so it is made not to create a conflict.
> 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?
How can a simple notation have any security consideration?
At the moment -03 version is available where many issues were corrected.
You can find it here:

Could you please review and comment this.

Any suggestions are welcome.

All the best,
Mykyta Yevstifeyev