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

Sean Leonard <dev+ietf@seantek.com> Wed, 28 January 2015 22:31 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C251A1A4F for <json@ietfa.amsl.com>; Wed, 28 Jan 2015 14:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJjS1RYEOfGx for <json@ietfa.amsl.com>; Wed, 28 Jan 2015 14:31:12 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D731E1A1A4E for <json@ietf.org>; Wed, 28 Jan 2015 14:31:11 -0800 (PST)
Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 66A1322E1F4; Wed, 28 Jan 2015 17:31:06 -0500 (EST)
Message-ID: <54C9632A.2040204@seantek.com>
Date: Wed, 28 Jan 2015 14:31:06 -0800
From: Sean Leonard <dev+ietf@seantek.com>
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 <nico@cryptonector.com>
References: <54C28E3F.4040901@alum.mit.edu> <E378C876-5217-4274-86B6-1DBFB653DE24@vpnc.org> <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>
In-Reply-To: <20150128173229.GC3110@localhost>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/5DuM4bLJsPckNCWdp4-CsSVMj9k>
Cc: rfc-interest@rfc-editor.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org
Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=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:
Abstract:

    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 
error.

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.

Sean