[rfc-i] v3imp #8 Fragment tagging on sourcecode

dev+ietf at seantek.com (Sean Leonard) Fri, 30 January 2015 11:31 UTC

From: "dev+ietf at seantek.com"
Date: Fri, 30 Jan 2015 03:31:38 -0800
Subject: [rfc-i] v3imp #8 Fragment tagging on sourcecode
In-Reply-To: <20150128230227.GG3110@localhost>
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>
Message-ID: <54CB6B9A.1080801@seantek.com>

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