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

Sean Leonard <> Wed, 28 January 2015 22:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4C251A1A4F for <>; Wed, 28 Jan 2015 14:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NJjS1RYEOfGx for <>; Wed, 28 Jan 2015 14:31:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D731E1A1A4E for <>; Wed, 28 Jan 2015 14:31:11 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 66A1322E1F4; Wed, 28 Jan 2015 17:31:06 -0500 (EST)
Message-ID: <>
Date: Wed, 28 Jan 2015 14:31:06 -0800
From: Sean Leonard <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nico Williams <>
References: <> <> <> <> <> <> <> <> <> <> <20150128173229.GC3110@localhost>
In-Reply-To: <20150128173229.GC3110@localhost>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Jan 2015 22:31:14 -0000

On 1/28/2015 9:32 AM, Nico Williams wrote:
> On Tue, Jan 27, 2015 at 09:16:37PM -0800, Sean Leonard wrote:
>> Overall I still stand by my proposition that the RFC is the module
>> for ABNF purposes. Honestly it just makes things a lot simpler. To
>> the extent that you need to split things inside the RFC, you can
>> refer to specific sections. Specific comments below.
> Well, draft-ietf-json-text-sequence-13 will break this proposition.

Hello--I took a look at draft-ietf-json-text-sequence-13.

There are two typos:

    ASCII Record Separator (0x1E), and each ending with an ASCII Line
    Feed character (0x1A).

should be 0x0A.

Section 2.2

    Note that on some systems it's possible to input RS by typing
    'ctrl-^'; on some system or applications the correct sequence may be
    'ctrl-v crtl-^'.  This is helpful when constructing a sequence

should be ctrl-^.

An editorial point: why define LF in this I-D when it's already defined 
in RFC 5234 Appendix B? Just sayin'.

> It's on the RFC-Editor queue.  We could "fix" the "problem" in AUTH48,
> but I've no intention to.

Well you might want to look at the problems above...

> I doubt it's the first RFC that will break your assumption.
It's not an RFC yet. :-)

First of all, I don't see a "problem" because there are no "modules" in 
draft-ietf-json-text-sequence, or any other Internet-Draft. It's all a 
bunch of plain text. I am not trying to be flippant; it's simply the way 
it is. I-Ds are just large reams of plain text punctuated with FF codes. 
That is why extracting data out of RFCs is convoluted and fraught with 

I am not stating an assumption so much as I am stating a workable 
proposition that makes sense for authoring future RFCs in a structured 
format, i.e., a format where ABNF is clearly distinguished from 
specification text or other things.

I too dealt with this exact problem in draft-josefsson-pkix-textual-10 
(also in the RFC-Editor queue, btw). In that soon-to-be-RFC, I renamed 
the rules to:
textualmsg              ; what most extant parsers and generators will 
work with
stricttextualmsg     ; what compliant generators SHOULD emit
laxtextualmsg         ; the most relaxed input that parsers MAY accept

Thus, consider renaming the rules to distinguish between inputs and 
outputs, such as {JSON-sequence-in} and {JSON-sequence-out}. It is 
clearer and more accurate. I note that the "meat" parts are named 
differently: {possible-JSON} vs. {JSON-text}, presumably to indicate the 
difference in strictness between generators and parsers.

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.

> Not that it matters.  Suppose all RFCs with ABNF only had a *single*
> ABNF module, so that each module could be said to be named rfc1234.abnf.
> Now what?  You'd still be missing the machine-readable imports.

Uh I already laid this out...I no longer ascribe to the premise of "ABNF 
modules". It's just a bunch of ABNF text.

You know, other symbolic systems such as ASN.1 have modules...and ASN.1 
is seen as way too complicated. I doubt that anyone is going to 
"compile" the ABNF in draft-ietf-json-text-sequence-13 anyway--they are 
just going to hunt for RS bytes, which is the whole point.

> We could say that every module exports every rule by default, so we
> could get away with not having exports.  But imports are absolutely
> necessary in order to validate ABNF modules that import rules from
> others.

Unless you don't have ABNF modules...

> We already have a mess on our hands.  ABNF needs a module system.  An
> ad-hoc module system won't do.

No modules = no messes. I would say that all the crazy importing and 
exporting in ASN.1 modules (an in particular, the fact that the 
definitions have changed over time, witness PKCS #7 1.0 -> PKCS #7 1.5 
-> CMS '99 -> CMS '02 -> CMS '04 -> CMS '09) is much messier. 
Significant tool support is required, which is one significant reason 
why people hate on ASN.1 and are trying to do things with JSON instead.