Received-SPF: pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 2001:1890:126c::1:1e as permitted sender) client-ip=2001:1890:126c::1:1e;
Message-ID: <50E45B21.20509@gmail.com>
Date: Wed, 02 Jan 2013 08:06:57 -0800
From: Dave Crocker <dcrocker@gmail.com>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
References: <50DCD850.3020106@alum.mit.edu>
	<alpine.LSU.2.00.1301021022570.15409@hermes-1.csi.cam.ac.uk>
	<50E45623.9060607@gmail.com>
	<alpine.LSU.2.00.1301021552190.15409@hermes-1.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1301021552190.15409@hermes-1.csi.cam.ac.uk>
Cc: abnf-discuss@ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [abnf-discuss] Some thoughts about how to make ABNF more
 convenient to use
Precedence: list
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: abnf-discuss-bounces@ietf.org
Errors-To: abnf-discuss-bounces@ietf.org


On 1/2/2013 7:57 AM, Tony Finch wrote:
> Dave Crocker <dcrocker@gmail.com> wrote:
>>
>> It would need to be able to distinguish among potentially independent sets of
>> rules, within a spec. We don't currently have a way to indicate that.
>
> Has there ever been any need for it?

Well, ummm, RFC822 had several parsers, such as for addresses versus 
dates versus free-form like Subject.  Applications often need this, I 
believe.  For that matter, any environment that creates distinct 
processing contexts can easily lead to this.  While a single syntax is 
obviously simpler, I think it's pretty common to wind up creating more 
than one "sub-" syntax, for example.


 > You can solve the problem using an
> informal namespace hack, e.g. named beginning A- are in set A and Z- are
> in set Z. Each independent parser is defined by its starting rule name.

Sure.  The question is whether there is a desire to have automated 
processing that is aware of the distinction.  My own feeling is that it 
would be a useful enhancement to the rigor of using abnf.


>> Also, I like the idea of having a formal construct to 'import' rulesets.  I
>> think this needs a way of labeling the set and declaring its being imported.
>
> At the moment specs tend to just (informally) import all the rules from
> RFC NNNN.

I take the current proposal as noting exactly that existing practice and 
suggesting that it be formalized to permit automated processing.  In 
terms of having a foundation for making an enhancement suggestion, that 
seems pretty strong to me.

What I don't know is whether there will be the community will to pursue 
it -- will we see enough operational benefit?


d/
-- 
  Dave Crocker
  bbiw.net
_______________________________________________
abnf-discuss mailing list
abnf-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/abnf-discuss