Re: [secdir] secdir review of draft-ietf-json-text-sequence-11

Nico Williams <nico@cryptonector.com> Wed, 17 December 2014 18:55 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B413A1A6FF9; Wed, 17 Dec 2014 10:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 22ZpWKTMavZt; Wed, 17 Dec 2014 10:55:30 -0800 (PST)
Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6081A1BBE; Wed, 17 Dec 2014 10:55:30 -0800 (PST)
Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id A0F1C76805C; Wed, 17 Dec 2014 10:55:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=IzuTY1544Pk/Ln DQHPRFYHEuuBk=; b=jHapU2vp3COnmD3Rfg+EsiySpk+yZZ+tp2PNFJQKPYy7jb pVItMYBHNeSpE3IYFL3HFTDQ73wZJQzpBlY9WAmhq2kAwt683X/UYeBOfczSE4QN ajs5yyqcAKDPoWCB5aSx5KM1wtggpgzsCQDbN0CIAIU3QbL01IYT+0B0DrU2s=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 3ED0E768057; Wed, 17 Dec 2014 10:55:29 -0800 (PST)
Date: Wed, 17 Dec 2014 12:55:28 -0600
From: Nico Williams <nico@cryptonector.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Message-ID: <20141217185523.GA3241@localhost>
References: <20141216000109.GP3241@localhost> <D0B587AB.2948E%carl@redhoundsoftware.com> <20141216163238.GT3241@localhost> <D0B5C964.2954A%carl@redhoundsoftware.com> <20141216174829.GZ3241@localhost> <D0B5DC2E.295DB%carl@redhoundsoftware.com> <20141216193707.GE3241@localhost> <D0B5F9D2.29691%carl@redhoundsoftware.com> <20141216213533.GI3241@localhost> <D0B64568.29705%carl@redhoundsoftware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D0B64568.29705%carl@redhoundsoftware.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/-V-HrQF3lxDQIiYkNT6MWZDnToc
Cc: draft-ietf-json-text-sequence@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Dec 2014 18:55:34 -0000

On Tue, Dec 16, 2014 at 09:13:55PM -0500, Carl Wallace wrote:
>                                          [...]. I still think the solution
> is to remove the delimiters added by the JSON text sequence encoder in the
> JSON text sequence decoder.  This seems cleaner to me.  It would probably
> require the encoder to reject inputs that have not been properly
> terminated or perhaps have a flag to auto-add <ws> to non-self-delimited
> top level values before adding the <LF> where such is safe to do.

Tolerating a missing LF seems like a fine thing to do if the top-level
value was nonetheless valid and delimited.

On the other hand it adds some ambiguity if some sequence parser
implementations can tolerate it and others can't.

For logging applications tolerating a missing LF seems like a desirable
thing to do, actually.  For non-logging applications not tolerating it
seems better.

Does requiring that the sequence parser strip the trailing LF
complicate the sequence parser ABNF?  I think the stripping of the
trailing LF simply can't be expressed in ABNF, only in prose.

I'll play with an implementation tonight and see what I think after I
re-write some code (jq, specifically).  It may well be that I like it
better your way.

Nico
--