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: <50E73BCB.9010104@alum.mit.edu>
Date: Fri, 04 Jan 2013 15:30:03 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: abnf-discuss@ietf.org
References: <20130103171755.20983.75939.idtracker@ietfa.amsl.com>
	<50E5BF59.9000207@alum.mit.edu> <50E5D4C5.8010800@alum.mit.edu>
	<tk0GjBDTOy5QFAkk@paul.bayleaf.org.uk> <50E72801.3060906@gmail.com>
In-Reply-To: <50E72801.3060906@gmail.com>
Subject: Re: [abnf-discuss] A proposal for adding import and scopping to ABNF
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/4/13 2:05 PM, Dave Crocker wrote:
>
>
> On 1/4/2013 10:46 AM, Paul Overell wrote:
>> 4)
>>
>> Have you considered an import syntax to specify importing just a
>> specific rule or list of rules?  E.g. Importing from RFC5234 one might
>> just want some of the core rules from Appendix B, but not want the ABNF
>> Definition of ABNF in section 4.
>
>
> I've been wondering about the model of rule/set/ vs. individual rule
> importation.  Although it could become cumbersome for large sets, having
> a mechanism that merely calls for naming each imported rule separately
> is simplest.
>
> I believe that by far the pattern of importations is of rather short
> lists.  So the actual burden of the simplistic model would not typically
> be all that onerous.

I disagree.

An important use case is a draft that extends another draft. For 
instance consider RFC5839. It includes:

    7.3. Grammar

    This section defines the formal syntax for extensions described in
    this memo in Augmented BNF (ABNF) [RFC5234].  The rules defined here
    augment and reference the syntax defined in RFC 3261 [RFC3261] and
    RFC 3903 [RFC3903].

    Success            =/ "204"  ;  No Notification

          ; Success is defined in RFC 3261.

    message-header     =/ Suppress-If-Match

          ; message-header is defined in RFC 3261.

    Suppress-If-Match  =  "Suppress-If-Match" HCOLON ( entity-tag / "*" )

          ; entity-tag is defined in RFC 3903.

This needs the definitions of <Success>, <message-header>, and HCOLON 
from 3261, and <entity-tag> from 3903. Those in turn are dependent on 
various other things from those drafts and from 2234 (though 5234 would 
also work for those.)

It would be *very* painful, and ugly, to import every required rule one 
by one.

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