RE: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt
Mykyta Yevstifeyev <evnikita2@gmail.com> Fri, 10 December 2010 14:28 UTC
Return-Path: <evnikita2@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2DC28C0EE; Fri, 10 Dec 2010 06:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.983
X-Spam-Level:
X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 eNjsCHMMoht1; Fri, 10 Dec 2010 06:28:07 -0800 (PST)
Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 0373428C0E6; Fri, 10 Dec 2010 06:28:06 -0800 (PST)
Received: by bwz8 with SMTP id 8so4259180bwz.38 for <multiple recipients>; Fri, 10 Dec 2010 06:29:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=jIdN4rs7RR2VU1+DVEl51BRtF8SLEG2YDUIxO2IBkCs=; b=E+qApaC9BatbS8xN3SLrKVtBFUDfrKsGZhzW4rVyT9K6R1F+lslFhDZwlfleOBk14c NxA9miSzuW7anQ6NeNIy+BY3acKc0QrbCkffGI1aapVexPD6aOlgKYppzwwh3QZD5NSp D0kBsgw8uSLKDBHCPy69mX0NCmtTbRpdyXVsc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=hrPE5kDVkNRG10i8alAAum7N2Lsm856j7MRXsKOItcdkJ38IGa9a7kOue2TgmFaTn9 EqIvIW1gSWTRqBXcz1x7j4Gkomlxri59Hiwy2p3IK9EXXplYBa4w1Qzpn25e1EnucZo6 dkRYD0yFBZCs4ZDUMj92YRvQ2O4HLWI/UJIe8=
Received: by 10.204.113.65 with SMTP id z1mr785285bkp.86.1291991376945; Fri, 10 Dec 2010 06:29:36 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id q15sm1571910bkk.13.2010.12.10.06.29.35 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Dec 2010 06:29:36 -0800 (PST)
Message-ID: <4D023959.3070604@gmail.com>
Date: Fri, 10 Dec 2010 16:29:45 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>, apps-discuss@ietf.org
Subject: RE: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 10 Dec 2010 08:44:01 -0800
Cc: Bill McQuillan <McQuilWP@pobox.com>, Martin.Thomson@andrew.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Dec 2010 14:28:08 -0000
Hello all, I have get known that there is a discussion of my draft on this list (IETF-discuss). So some notes on what have been already posted: > > I wholly agree with Bill on this. > > You want something a little more complicated than you have already > specified: > > {n}^({a}){m}{e} => {e} {n-1}*{m ? m-n : ''}({a} {e}) ; where n > 0 > {e} *{m ? m-1 : ''}({a} {e}) ; where n == 0 or n undefined This is not what is mentioned in my draft. Especially in the case when n=0. > > Note the n == 0 is a special case. Note that this assumes that m > n. > There seems little point in this construction if m == 1, but this does > handle that case. If m=1, there is no need to use the defined construction. It is 1<element> and nothing else. > > Aside from those sorts of problems, the definition of 'a' is a little > loose. You should try to build on the RFC 5234 ABNF in your definitions. > > The proposed rule has an ABNF definition something like (?): > > hat-rule = 1*DIGIT "^(" a ")" 1*DIGIT > a = VCHAR / SP / HT / <any other separator> > > That's a lot of flexibility in the internal part. Too much > flexibility. Using parentheses means that they need to be > distinguished from the parentheses that might appear in the 'a' part. > > If you see this as a substitute for the "*" in a normal repetition > rule, that makes it easier. Given that it has length longer than 1 > character, by providing a clear delineation of the start and end you > can be more flexible on the content. Either that or to restrict what > follows the ^. > > Preferably delineate better AND restrict content: > > repeat /= hat-rule > hat-rule = *DIGIT "^" element "^" *DIGIT OK. It will be taken into consideration. > > This restricts the content without preventing the use of more complex > content - you just have to use a rulename instead. > > You can't use elements (note the 's') here because that sort of > complexity is a real pain to specify. What do you mean? > > That leaves examples: > > 1^";"^3element ; 1 to 3 elements separated by ; > 1^SP^element ; 1 or more elements separated by SP rule > ^","^3element ; 0 to 3 elements separated by , > ^%x20.20^element ; any number of elements separated by a two space > characters Will be corrected. > > You should try to answer the question in the draft: why use the '^' > character instead of the '#' character? I guess that this is an > arbitrary choice more than anything else. # is already used in RFC2616 and ^ is used in order to to make the conflict between these documents. > > --Martin > > On 2010-12-07 at 11:07:17, Bill McQuillan wrote: > > I found several problems with this draft. > > > > In overview, the reason that we removed the #rule from ABNF was that it > > was > > very difficult to specify for a general case. This draft has the same > > problem. > > > > The production given does not actually produce the desired results. > > > > > n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element)) > > > > If the usage is: > > > > 5^(",")10 "abc" > > > > it would allow something like: > > > > abc abc abc abc abc abc , abc > > > > not: > > > > abc, abc, abc, abc, abc, abc, abd > > > > which was probably intended. > > > > ----- > > > > The production: > > > > > a = VCHAR / SP / HT / <any other separator> > > > > does not seem to address the possibility of multi-character separators > > very > > clearly. What if I want to define a list like: > > > > abc and def and ghi and jkl > > > > can I use: > > > > ^(" and ")ident > > > > ----- > > > > I also do not believe that *FWS belongs in such a general rule and > > should > > rather be defined by the actual usage. E.g.: > > > > 5^(*FWS "," *FWS)10 "abc" > > > > ----- > > > > Typo: 2.1 Examples, fourth example should be: ^("-")element > > > > -- > > Bill McQuillan <McQuilWP@pobox.com> > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > Bill, All your propositions have been taken into consideration. These comments concern -01 draft. As for FWS, it is *element so it can be used and can not be used. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf I really believe that the construction I have used is acceptable for all cases. Now I am working on -03 version of the draft so I'll get known when it will become available. All the best, Mykyta Yevstifeyev
- Re: I-D Action:draft-yevstifeyev-abnf-separated-l… Bill McQuillan
- RE: I-D Action:draft-yevstifeyev-abnf-separated-l… Thomson, Martin
- RE: I-D Action:draft-yevstifeyev-abnf-separated-l… Thomson, Martin
- RE: I-D Action:draft-yevstifeyev-abnf-separated-l… Mykyta Yevstifeyev