[rfc-i] ABNF Core Rule extensions

pkyzivat at alum.mit.edu (Paul Kyzivat) Fri, 30 January 2015 16:58 UTC

From: "pkyzivat at alum.mit.edu"
Date: Fri, 30 Jan 2015 11:58:23 -0500
Subject: [rfc-i] ABNF Core Rule extensions
In-Reply-To: <54CB6B9A.1080801@seantek.com>
References: <54C29891.6040101@alum.mit.edu> <54C3576A.9030206@greenbytes.de> <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> <20150128230227.GG3110@localhost> <54CB6B9A.1080801@seantek.com>
Message-ID: <54CBB82F.2050007@alum.mit.edu>

Changing the subject because the discussion no longer has anything to do 
with fragment tagging.

First, it's questionable whether extending the ABNF Core Rules is in 
scope for rfc-interest. If we are talking about extending RFC5234 then 
abnf-interest would be a better place.

OTOH, it might make sense to decouple the Core Rules from RFC5234 into 
their own RFC. In that case it *might* make sense to do it here.

Decoupling them (and then updating RFC5234 to remove them and instead 
reference the separate draft) would eliminate one obvious case where 
there are two distinct ABNF modules in the same draft.

	Thanks,
	Paul

On 1/30/15 6:31 AM, Sean Leonard wrote:
> On 1/28/2015 3:02 PM, Nico Williams wrote:
>>> As a broader useful point (not directed specifically to
>>> draft-ietf-json-text-sequence-13), I think it would be nice if
>>> future RFC ABNF can assume that the symbols in RFC 20 for %x00-20 /
>>> %x7F are rules that can be used as-is. Hence NUL = %x00, SUB = %x1A,
>>> DEL = %x7F, etc.
>> I agree.  These should be added to RFC5234 (i.e., we should publish an
>> update RFC listing them).
>
> I would be willing to write up/work on a concise RFC (Internet-Draft)
> that does this, prior to IETF 92. I would not mind adding a few
> additional rules to the Core Rules if there is near-unanimous support
> for such rules. (Hard to think of any in particular, except maybe some
> generic UTF8 character rules. Last I checked, ABNF is still
> octet-oriented and US-ASCII focused.)
>
> While I would not say "precondition", it is reasonable to require that
> RFCs after the publication of such an RFC follow it, much like RFCs past
> 5234 use RFC 5234 as the basis.
>
> Sean
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>