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

"Thomson, Martin" <> Thu, 16 December 2010 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AA2B3A6953 for <>; Thu, 16 Dec 2010 14:03:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.415
X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599, MANGLED_OFF=2.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4xF7nmK5vMj1 for <>; Thu, 16 Dec 2010 14:03:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ABDB03A691D for <>; Thu, 16 Dec 2010 14:03:26 -0800 (PST)
Received: from [] ([]:57699 "EHLO") by with ESMTP id S40293172Ab0LPWFL (ORCPT <rfc822;>); Thu, 16 Dec 2010 16:05:11 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 16 Dec 2010 16:05:11 -0600
Received: from ([fe80::9d82:a492:85e3:a293]) by ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 17 Dec 2010 06:05:08 +0800
From: "Thomson, Martin" <>
To: "" <>
Date: Fri, 17 Dec 2010 06:04:54 +0800
Thread-Topic: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on
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 22:03:28 -0000

+1 to the rest of this.  Other stuff below.

On 2010-12-17 at 04:40:30, Dave CROCKER wrote:
> 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.

+1.  I'm still open to being convinced though.  The HTTP-specific extensions to ABNF are a bit of an irritant, as are other such specification-specific extensions.  As it stands, the draft is not enough to convince me.

> { 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))

In fact, using more prescriptive prose and specific examples is probably better.  Explain in prose, then provide a few actual examples, with examples of the syntax that conforms to these grammars as well.  The style of RFC 5234 is a good guide; I don't like the fact that this draft strays so far from that.

The entire draft might be summarized so much more succinctly and clearly in this fashion:

3.11  Separated list: n*m#s rule

A hash following a repetition indicates a separator that appears between each of the multiple instances of the element.  Any variable or specific repetition can be followed by a separator.  The full form is:


Where <separator> is any valid element - including grouped elements - followed by optional whitespace.

A rule of the form:

   4*7#"," foo

is equivalent to:

   foo 3*6("," foo)

Similarly, a rule of the form:

   *#[*WSP ";" *WSP] foo

is equivalent to:

   [foo *([*WSP ";" *WSP] foo)]

4.1 ABNF Definition of ABNF
The <repeat> rule is extended from that in [RFC5234] from:

   repeat = 1*DIGIT / (*DIGIT "*" *DIGIT)


   repeat = 1*DIGIT / (*DIGIT "*" *DIGIT) [ "#" element *c-wsp ]


{ I missed the optional c-wsp in my previous comments - that's necessary to separate the two consecutive <rulename> constructs in a repetition.  For instance:

   example = 3*10#comma list-item

> 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.)

That was probably me.  You are correct.  Based on this, the grammar should be as above.

> >    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))

All this n_1, m_1 and f stuff is confusing and unnecessary.  It relies on what amounts to another modification to the grammar.  The definition of <f> still doesn't make sense.  u-(u-1) is 1, always.

> >    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.

Parentheses are not required here - if we assume that the separator grammar conforms to <element>.  They would be permitted, but the draft still does not describe the grammar for the separator.