[apps-discuss] Some notes on ABNF notation for separated lists

Mykyta Yevstifeyev <evnikita2@gmail.com> Mon, 13 December 2010 11:53 UTC

Return-Path: <evnikita2@gmail.com>
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 64FD93A6E91 for <apps-discuss@core3.amsl.com>; Mon, 13 Dec 2010 03:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.236
X-Spam-Level:
X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 eYEiOnv51kqP for <apps-discuss@core3.amsl.com>; Mon, 13 Dec 2010 03:53:15 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 002B33A6E8F for <apps-discuss@ietf.org>; Mon, 13 Dec 2010 03:53:14 -0800 (PST)
Received: by gwb20 with SMTP id 20so5635209gwb.15 for <apps-discuss@ietf.org>; Mon, 13 Dec 2010 03:54:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=8yeuFSN+vzXuSK0uFcUyB2/Bxo+ylhUT4ZDZhnyb9yY=; b=dk3fTWga1Xmj/hJDczyRUvTOfxXXxPGcvtXAvO4bYxjl3fl8actJy+5lxHWfMGXB9W GyTAeFUocufii04gR52DfzofRYEa7gA5HodPLKsX8xTo2OcYkM0bQbIBeF1AcXxbnna9 CK201awQNTA60DJ8mT0CirlmvkYCGoxd0wFho=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Fjp15ithx6LYq1KrEI51GNYujWjh9gpnNZv10fYmHfwizhdSYJWXjzc8tMh/0cyKlJ 8QSTar8LYkWZX0c8631FdxXpMpZWJm2vQnR2HCYr6KloYMrM4z5j5Z1FPXrGpD4IRh8L 8jiVhQC7OAfUlIaN8QT/rprRoTVHU8BoHImEY=
MIME-Version: 1.0
Received: by 10.150.158.15 with SMTP id g15mr6232540ybe.57.1292241292345; Mon, 13 Dec 2010 03:54:52 -0800 (PST)
Received: by 10.150.52.19 with HTTP; Mon, 13 Dec 2010 03:54:52 -0800 (PST)
Date: Mon, 13 Dec 2010 13:54:52 +0200
Message-ID: <AANLkTimYKuC+vGiak6VKi3hLxAR_QP9izcewixJ6Ku4Y@mail.gmail.com>
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
To: apps-discuss@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Cc: dcrocker@bbiw.net
Subject: [apps-discuss] Some notes on ABNF notation for separated lists
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: Mon, 13 Dec 2010 11:53:16 -0000

Hello all,

I have carefully reviewed all the messges which concern my ABNF
notation for separated lists. So some omments and thoughts:

Firstly, there have been a discusion about the form of notation.
Several variants have been proposed, the latest is
<n>*<m>[^<a>]element and I think it is quite acceptable. Moreover, the
corresponding form <n>^<a>element has been proposed. I think that will
be OK too. These proposals will be taken into consideration while
preparing the new version of the draft.

Secondly, there have been a discussion on to put or not to put the LWS
in the notation ABNF description. Maybe it is OK to remove it from the
definition but allow the user to put it manually in the <a> part.

Thirdly, it is a topic to discuss about the definition of separator.
However I don't think the form 1*VCHAR is bad or not acceptable for
this occasion. It is obvious that separator can be only visible chars.
But I think it would be useful to put the restriction on maximum
amount of chars in separator - maybe 56 is enough. what do you think
about this?

Lastly, the problem seems to be in security Consideration section. The
only issue mentioned while discussing was that spaces may occure in
the defined rule while we do not need them and this will cause the
problem. However as I'll correct the rule it will not create any
problems. However any suggestions for Sec. Cons. section are welcome
as well as other ones.

So I'll try to take all the comments into considerations. I'll let you
know when the new version of the draft will be available.

Best regards,
Mykyta Yevstifeyev