Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case
Munjo Yu <munjo.yu@gmail.com> Fri, 03 April 2009 00:00 UTC
Return-Path: <munjo.yu@gmail.com>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3693A684C; Thu, 2 Apr 2009 17:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.981
X-Spam-Level:
X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599]
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 AI1pOQPj4O9T; Thu, 2 Apr 2009 17:00:51 -0700 (PDT)
Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 8AAAE3A67B1; Thu, 2 Apr 2009 17:00:51 -0700 (PDT)
Received: by qyk36 with SMTP id 36so1531351qyk.29 for <multiple recipients>; Thu, 02 Apr 2009 17:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K3BIFiZ3yHWcZBY5RX4flunI3nIsAzsxWWjsQq9dGnY=; b=oLttBrof2mQ/QfdjJR4xFGA80XlpcSMh9KcIipxeOpF1WHgryMyY+B9zuwFHNChiW+ Hp2WdWy1y/CRnoxPYr725mv03Mj9Ikqvn15t5vIWjTk35mxxR0wqq96atVTxvWsi33Lu 0K38vKw66xU+V6QfYAnBABzdVktSU0LzdD46Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fUmpl1yf3knVLnQksMXGfZCDvysBefwSooK9H3q+qW5OWGmL8bqxHSLVxTx4zlkNEy bh5ds4Jxsl55P8CodV28EZmJw6HAudF0i4YGCsFMNxtmfV22JSjmge+JCOwqFoSecJRE lVaHW6IlT1wrj0MFeXbwa2wt1Ii7QBEzjE/zI=
MIME-Version: 1.0
Received: by 10.229.84.5 with SMTP id h5mr335774qcl.25.1238716913214; Thu, 02 Apr 2009 17:01:53 -0700 (PDT)
In-Reply-To: <49D54E3A.4080702@cs.utk.edu>
References: <e4b033900904011817s1bcf676xc3f0efe175932029@mail.gmail.com> <858250208-1238635590-cardhu_decombobulator_blackberry.rim.net-207445933-@bxe1052.bisx.prod.on.blackberry> <49D4461E.2050709@cs.utk.edu> <49D54893.6010008@cisco.com> <49D54E3A.4080702@cs.utk.edu>
Date: Thu, 02 Apr 2009 19:01:53 -0500
Message-ID: <e4b033900904021701v48898504rfade903c7fad25e0@mail.gmail.com>
From: Munjo Yu <munjo.yu@gmail.com>
To: Keith Moore <moore@cs.utk.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: SIP@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>, apps-discuss@ietf.org
Subject: Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2009 00:00:52 -0000
Thanks for the historical insights. Yes, I found the following section from http://tools.ietf.org/html/draft-ietf-drums-abnf-02 3.5 Set Group: {Rule 1 Rule2} Elements enclosed in braces (squiggly brackets) are treated as a single, UNORDERED element. Its contents may occur in any order. Hence: {elem foo} bar would match (elem foo bar) and (foo elem bar). NOTE: Specifying alternatives is quite different from specifying set grouping. Alternatives indicate the matching of exactly one (sub-)rule out of the total grouping. The set mechanism indicates the matching of a string which contains all of the elements within the group; however the elements may occur in any order. And it was dropped from the following revisions. To understand the ambiguity Keith mentioned, I tried to find any discussion archives which led to the decision, but no luck so far. Anyone knows about such an archive somewhere? thanks, -Munjo On Thu, Apr 2, 2009 at 6:46 PM, Keith Moore <moore@cs.utk.edu> wrote: > Paul Kyzivat wrote: >> I agree with Keith about the inadvisability of rewriting the grammar. >> Save it for SIP/3.0. >> >> In any case, I think the issue isn't with ABNF per se, its with the >> way ABNF was used for SIP. ABNF isn't actually able to represent >> everything that was desired for sip, so some things were simply >> handled as exceptions in the text. >> >> Of course the "right" thing to do would have been to either give up on >> anything that couldn't legitimately be represented, or else switch to >> some other specification language that could express what was intended. > not clear. IMHO, trying to specify every aspect of detail of a protocol > syntax using a formal specification language can be misleading and cause > more interop failures, than a looser specification written in ABNF plus > some exceptions in the text. One reason for the additional failures > when using the precise formal specification is that you don't really > benefit from that specification unless you feed it to a program that > will automatically generate the recognizer. And if you do automatically > generate a recognizer from the formal specification, you often find that > it doesn't report errors in the way that you'd like, doesn't perform as > well as you want, etc. > > The trick is to design the protocol in such a way that a precise formal > syntax specification is not necessary. This implies having a certain > degree of simplicity and regularity in the protocol. >> >> But there is a big tradeoff there. At least many people are capable of >> reading ABNF, and a reasonable number of those can accurately >> understand what it means. A somewhat smaller, but still significant, >> number can write it correctly. Its important that the people involved >> in the standardization process, and that implement the standard, be >> able to understand it. A more powerful specification language, that >> fewer people could understand, might not be such a great choice. > exactly. > > Keith > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >
- [Sip] Proposal of Non-Sequential Group Notion in … Munjo Yu
- Re: [Sip] Proposal of Non-Sequential Group Notion… eburger
- Re: [Sip] Proposal of Non-Sequential Group Notion… Keith Moore
- Re: [Sip] Proposal of Non-Sequential Group Notion… Keith Moore
- Re: [Sip] Proposal of Non-Sequential Group Notion… Paul Kyzivat
- Re: [Sip] Proposal of Non-Sequential Group Notion… Munjo Yu
- Re: [Sip] Proposal of Non-Sequential Group Notion… Keith Moore
- Re: [Sip] Proposal of Non-Sequential Group Notion… John C Klensin
- Re: [Sip] Proposal of Non-Sequential Group Notion… Dale Worley
- Re: [Sip] Proposal of Non-Sequential Group Notion… Munjo Yu