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

Dave CROCKER <> Thu, 16 December 2010 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EF153A695D for <>; Thu, 16 Dec 2010 09:38:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.953
X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hqw2Bodm+gWB for <>; Thu, 16 Dec 2010 09:38:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2821C3A6928 for <>; Thu, 16 Dec 2010 09:38:57 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id oBGHeZnD032439 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 16 Dec 2010 09:40:41 -0800
Message-ID: <>
Date: Thu, 16 Dec 2010 09:40:30 -0800
From: Dave CROCKER <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
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 ( []); Thu, 16 Dec 2010 09:40:41 -0800 (PST)
Cc: "" <>, Paul Overell <>
Subject: Re: [apps-discuss] 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: Thu, 16 Dec 2010 17:38:58 -0000


Note:  We still do not have statements of support for standardizing a mechanism, 
in spite of the continued activity on this thread.  So far, this is a fun 
exercise, but that's all.

Comments on the latest draft:

> Abstract
>    This document defines Augmented Backus-Naur Form (ABNF) notation for
>    representing lists separated by any specified character. It updates
>    RFC 5234.

The form of the mechanism permits the separator to be a string, not just a 

> 1.  Introduction
>    ABNF does not provide the possibility to express the separated lists
>    of elements via specific construction. If it is needed (generally for
>    defining HTTP headers or human-readable forms), the following ABNF
>    construction is used:

    the following ABNF construction is used
    the following is an example of an ABNF construction that would be used

{ There are many different list forms; the one given here builds in certain 
assumptions that do not always apply.  /d }

>    (*LWS element n*m(*LWS separator *LWS element))
>    It is obvious that this construction is too simplified and bulky.

Statements about human perception and assessment are almost always a mistake in 
a technical specification.  Don't make them.

It is enough to assert that a 'list' is a common pattern in ABNF specifications 
and it would make list specifications more convenient to have a construct that 
supports them.

>    This document specifies universal ABNF notation for lists, separated
>    by arbitrary specified characters.

    This document specifies universal ABNF notation
    This document specifies a concise ABNF notation

> 2.  Notation Description

    Notation Description ->  List Notation

{ This section is the formal definition of the construct; it's not just a 
"description".  /d }

>    This document augment the ABNF notation <n>*<m>element with OPTIONAL

    augment -> augments

    ABNF notation -> ABNF repetition notation

>    separator part, so that the construction for separated lists is:
>    <n>*<m>[#(<a>)]element

In reviewing the way Section 3 of RFC 5234 specifies things, I believe that the 
specification, here needs to be made without the square brackets and without the 
parentheses.  (I think someone earlier commented about the parens.)

In the place the construct is being specified, all of the pieces are required. 
The concept of being optional comes into play later.

So I think the specification of the construct needs to be:


>    where <a> is a separator. This construction indicates at least <n>

    a separator -> a separator string that is used in between element repetitions

>    and at most <m> elements separated by <a>.
>    The corresponding construction <n>element is also updated so that for
>    separated lists it stands as:
>    <n>[#(<a>)]element


>    indicating exactly <n> elements separated by <a>.
>    The ABNF for this construction is:
>    n*m#(a)(element) = (n_1*m_1(element 1*SP a) f(element))

    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#a element   = (n_1(element 1*SP a) element)

>    1*3#(";")element indicates the list of elements separated by

Question to the audience:  are the parentheses needed here?  The quotation marks 
would seem to provide sufficient lexical uniqueness, but this is the sort of 
nuance I usually get wrong.

> 3.  Security Considerations
>    Security issues are not discussed by this document.

Improper or confusing specifications can introduce extensive security risks. 
The new construct provides a concise and clear means of specifying a common 
pattern that might otherwise permit data variations that could be used for 
hiding unwanted content, such as encoding a spam message that would bypass filters.

{ I didn't create this observation.  Mark Delaney didn't either, but during the 
DomainKeys development he was particularly adept at demonstrating this exploit. /d }


   Dave Crocker
   Brandenburg InternetWorking