X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Delivered-To: barryleiba.mailing.lists@gmail.com
Received: by 10.58.106.73 with SMTP id gs9csp648376veb;
        Tue, 8 Jul 2014 06:47:01 -0700 (PDT)
X-Received: by 10.68.130.6 with SMTP id oa6mr35293259pbb.102.1404827220417;
        Tue, 08 Jul 2014 06:47:00 -0700 (PDT)
Return-Path: <abnf-discuss-bounces@ietf.org>
Received: from mail.ietf.org (mail.ietf.org. [2001:1900:3001:11::2c])
        by mx.google.com with ESMTPS id hx2si43491018pbb.205.2014.07.08.06.46.59
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 08 Jul 2014 06:47:00 -0700 (PDT)
Received-SPF: pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) client-ip=2001:1900:3001:11::2c;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) smtp.mail=abnf-discuss-bounces@ietf.org;
       dkim=pass header.i=@ietf.org
Received: from ietfa.amsl.com (localhost [IPv6:::1])
	by ietfa.amsl.com (Postfix) with ESMTP id 609781B2853;
	Tue,  8 Jul 2014 06:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1404827219; bh=ouK6l/Oi8TilYgph2CsRqXj1DwNPTzxZp0Csz94XDyE=;
	h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc:
	 Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:
	 List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender;
	b=SM44H+7sfDongY8psjoFuCr/GnlBuucNT4FVqILtvhl1flstwINKj3LAv3DkKS8np
	 q2Z4v5UNLB3u0lp8+SpwG5nTRIIoma9lcVMUp90XAvGf6ul9+PCINbPCb5ZBJWEas0
	 eDHyRLuqSEg/vk989i1u3OvYnLFC4D4LiPgAj+cQ=
X-Original-To: abnf-discuss@ietfa.amsl.com
Delivered-To: abnf-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 060951B2838
 for <abnf-discuss@ietfa.amsl.com>; Tue,  8 Jul 2014 06:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id nhUZUH1xIFfE for <abnf-discuss@ietfa.amsl.com>;
 Tue,  8 Jul 2014 06:46:55 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net
 (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96])
 by ietfa.amsl.com (Postfix) with ESMTP id 24FE71B282B
 for <abnf-discuss@ietf.org>; Tue,  8 Jul 2014 06:46:55 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11])
 by qmta09.westchester.pa.mail.comcast.net with comcast
 id PnXH1o0060EZKEL59pmuBc; Tue, 08 Jul 2014 13:46:54 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164])
 by omta01.westchester.pa.mail.comcast.net with comcast
 id Ppmu1o0093ZTu2S3Mpmugn; Tue, 08 Jul 2014 13:46:54 +0000
Message-ID: <53BBF64E.5010605@alum.mit.edu>
Date: Tue, 08 Jul 2014 09:46:54 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
References: <53BAB55A.2090008@alum.mit.edu>
 <alpine.LSU.2.00.1407081157240.13901@hermes-1.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1407081157240.13901@hermes-1.csi.cam.ac.uk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
 s=q20140121; t=1404827214;
 bh=GqyLyHCf4an0A3IToMxip+pi4A5h/B05q8W9BY5XZpU=;
 h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject:
 Content-Type;
 b=MDLjQSI2EYm+nsQOS57ZBVQ5djqsl7jk8u+jTjkVdbAcATVCfo9MAocT5SJeVeigz
 oipioH3HOj1gtU0zmG7Lmpg6wWf9DjqT7SMjYtNhMx9sNQXGUu230c3ISeHkG32zuS
 1Ime2d5nudz8z/Ep8N1SynSC0BxK8BIr8U1PHaF0aiW79EKPtBG+tfnVnTehtyjPS8
 bp8/h4Av+MCfA/DAz87ivFUwH9GJfxXwe9SyR1FBr10EItbALfmwlU/busHBwJ0y53
 Nl1YJ18xQRxusmBgp4kNmTMmz9m2I8AeQ8kbIU9LHoXHb04pkSHJG8EYLKZwRW4WWI
 nQ+/qQ0VsWuyg==
Archived-At: http://mailarchive.ietf.org/arch/msg/abnf-discuss/tn1QcDA5I0aT8IVqIicftrYPpgs
Cc: "abnf-discuss@ietf.org" <abnf-discuss@ietf.org>
Subject: Re: [abnf-discuss] defining "compatible" extensions
X-BeenThere: abnf-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "General discussion about tools,
 activities and capabilities involving the ABNF meta-language"
 <abnf-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abnf-discuss>,
 <mailto:abnf-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abnf-discuss/>
List-Post: <mailto:abnf-discuss@ietf.org>
List-Help: <mailto:abnf-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abnf-discuss>,
 <mailto:abnf-discuss-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: abnf-discuss-bounces@ietf.org
Sender: "abnf-discuss" <abnf-discuss-bounces@ietf.org>

On 7/8/14 7:21 AM, Tony Finch wrote:
> Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>
>> The key thing is that an extension definition needs to satisfy *two* ABNF
>> rules.
>
> It is tempting perhaps to introduce a rule refinement operator that
> parallels /=, e.g.
>
>     attribute	 =	att-specific / att-generic
>     att-generic   =	(att-field ":" att-value) / att-field
>
>     att-specific	/=	new-att
>
>     new-att	 =	att-generic
>     new-att	&=	"new-att-name:" new-att-value

Interesting. I was thinking there should be a way to do this, but hadn't 
thought through exactly what it would look like.

There are still some details to work out. Suppose, after the above, I 
were to add:

	new-att =/ something-else

What would that mean? Which definition of new-att does it extend?

> The fun thing about this is that context-free grammars are not closed
> under intersection, so if you introduce a way of saying that a token
> must be parsable by two syntax rules then you are significantly increasing
> the power of your specification language :-) This has awkward consequences
> for tools that might work with the grammar.
>
> So I think the &= operator needs to have asymmetrical semantics: it should
> mean that the grammar following &= must be a subset of the existing
> grammar for the rule.

> That is, it is an error if a rule's refined grammar
> can match an input that is not matched by its generic grammar.

That is precisely the rule that we need for the extension to be backward 
compatible!

	Thanks,
	Paul

> (Note I
> have not properly checked if this restriction is sufficient to keep the
> grammar context-free.)
>
> Tony.
>

_______________________________________________
abnf-discuss mailing list
abnf-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/abnf-discuss