Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02
Dave CROCKER <dhc@dcrocker.net> Thu, 16 December 2010 17:38 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 4EF153A695D for <apps-discuss@core3.amsl.com>; Thu, 16 Dec 2010 09:38:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.953
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqw2Bodm+gWB for <apps-discuss@core3.amsl.com>; Thu, 16 Dec 2010 09:38:57 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 2821C3A6928 for <apps-discuss@ietf.org>; Thu, 16 Dec 2010 09:38:57 -0800 (PST)
Received: from [192.168.1.15] (adsl-67-124-149-131.dsl.pltn13.pacbell.net [67.124.149.131]) (authenticated bits=0) by sbh17.songbird.com (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: <4D0A4F0E.7090604@dcrocker.net>
Date: Thu, 16 Dec 2010 09:40:30 -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.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> <4D071CCB.5040509@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> <4D0A39C0.2070308@gmail.com>
In-Reply-To: <4D0A39C0.2070308@gmail.com>
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]); Thu, 16 Dec 2010 09:40:41 -0800 (PST)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, Paul Overell <paul@bayleaf.org.uk>
Subject: Re: [apps-discuss] 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: Thu, 16 Dec 2010 17:38:58 -0000
Folks, 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 character. > 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: <n>*<m>#<a>element > 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 <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 bbiw.net
- [apps-discuss] Review of: draft-yevstifeyev-abnf-… Dave CROCKER
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Mykyta Yevstifeyev
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Julian Reschke
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Dave CROCKER
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Dave CROCKER
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Thomson, Martin
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Julian Reschke
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Thomson, Martin
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Julian Reschke
- Re: [apps-discuss] Review of: draft-yevstifeyev-a… Thomson, Martin
- Re: [apps-discuss] draft-yevstifeyev-abnf-separat… Mykyta Yevstifeyev
- Re: [apps-discuss] draft-yevstifeyev-abnf-separat… Dave CROCKER
- Re: [apps-discuss] draft-yevstifeyev-abnf-separat… Julian Reschke
- Re: [apps-discuss] draft-yevstifeyev-abnf-separat… Thomson, Martin
- Re: [apps-discuss] draft-yevstifeyev-abnf-separat… Dave CROCKER
- Re: [apps-discuss] draft-yevstifeyev-abnf-separat… Paul Overell