Re: [Json] Leading and trailing whitespace

Nico Williams <nico@cryptonector.com> Tue, 11 June 2013 03:42 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C9111E80D5 for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 20:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuvmc4n+0DNR for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 20:42:24 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2E11E80CC for <json@ietf.org>; Mon, 10 Jun 2013 20:42:24 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 9D110674059 for <json@ietf.org>; Mon, 10 Jun 2013 20:42:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8fhHvgavCvFz7jw4g9Xw z50A+J4=; b=gRB6j8ufnHvhLpuWMovgMOYLJaXmG2JnKug0gsrNJHMyS//LfYSg DqbIqwqmmsTku4y6Cs0LXiGvR/P+t7R/8o7hX/j9d0APCXiskyrJE/gRVS5+G8rp mDjAeBe0BwVnmTjUvhu4rCJi5g4bSMs8DqZ+jF20GPWLk5p1LsHKiSk=
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 4E733674057 for <json@ietf.org>; Mon, 10 Jun 2013 20:42:23 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hq4so1483730wib.14 for <json@ietf.org>; Mon, 10 Jun 2013 20:42:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=51uoy5VQ6omAc4HKsTb5xYXPoTBqPVFEYvkwmowXUkI=; b=fNAk8olijZhDFaExFnt4QTK/B58jeMPYSte3rcFDbGe+iVuEStPdYQD8iLbPtfxy9s UGzbD1VSPqg0Ik35TqKcO9AB+4tQuWhV1VkbsZCDAkPXL1zAGEOiNYPjkImXscs8JHxp nxDfYZUyud2KfbfAqjaiUx2dmd2unP3CzH5p1BSuFtQhgLig360RZSfOh4oD9GiT6Dqx nG4LXAYbYYkiTKOZ4PKxG581U+MwFaw6nOO2ELUuDeNP/olw6q3Nu6W5Ef6QdTmV2Sgu Z/DKlKuCRtpt+VKKNEy/FxhY0vqILSOkRCi08tD18SEEv0KvM+KYBFByTPdJkFGKDswX vvUw==
MIME-Version: 1.0
X-Received: by 10.194.8.163 with SMTP id s3mr7231744wja.41.1370922142008; Mon, 10 Jun 2013 20:42:22 -0700 (PDT)
Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 20:42:21 -0700 (PDT)
In-Reply-To: <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org>
References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org> <070b01ce664b$e5e0ac10$b1a20430$@augustcellars.com> <6E03D281-D6BA-424D-A30A-3DA18E61A051@vpnc.org>
Date: Mon, 10 Jun 2013 22:42:21 -0500
Message-ID: <CAK3OfOiBmzCdQtyUFoBkSFMFJijE7K8eR+9YUv7bhD2YaQBW2Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=UTF-8
Cc: Jim Schaad <ietf@augustcellars.com>, json@ietf.org
Subject: Re: [Json] Leading and trailing whitespace
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 11 Jun 2013 03:42:29 -0000

On Mon, Jun 10, 2013 at 9:53 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On Jun 10, 2013, at 7:32 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
>
> You might be asking "if we allow other JSON items at the top level, will we also allow optional whitespace before and after". But that's a supposition, not a question about what is in the document now.

Sure, but since we're full-out having the any value type at the
top-level discussion (and it looks like we'll at least have to have
informational text acknowledging that ECMAScript will allow them) this
becomes relevant.

Do implementations that allow any value type at the top-level allow
leading and/or trailing whitespace?

*Should* they?

IMO the intuitive answer to the last should be "yes", that arbitrary
amounts of whitespace can surround any value regardless of where it
appears.  But my intuition could be wrong.

> You have changed the subject of the question, then. You were asking about the top level, without a container. I claim my answer is correct for the question you asked.

Well, that's what happens when people have discussions...  :)

> None of the objects other than arrays and objects have optional whitespace. None.

Indeed.  But that might need to change with the top-level value type
discussion.  Or if not "need", we might want it to anyways.

>> Yes -but what I am saying is that there are (probably) parsers which stop
>> before the string has been fully consumed.  Thus they would accept the
>> string as valid.
>
> There are (probably) parsers that do all sorts of stupid, non-conformant things. Why is that relevant here?

Actually, that seems very relevant for the Security Considerations
section.  What should parsers do with any content left over after
parsing the end of a top-level value?

Trailing whitespace would allow parsers to delimit top-level numeric
values when end-of-message might be hard to distinguish from a TCP
RST.

Trailing content might allow smuggling of data past a JSON parser,
where it could do damage (e.g., get past deep packet inspectors).

Perhaps the simplest thing to do would be to allow just one space to
trail top-level values.

Nico
--