Re: [Json] Leading and trailing whitespace

"Jim Schaad" <ietf@augustcellars.com> Tue, 11 June 2013 00:17 UTC

Return-Path: <ietf@augustcellars.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 51C5521F934B for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 17:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 vmLdKAcQ8E2A for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 17:17:26 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 74AEF21F9412 for <json@ietf.org>; Mon, 10 Jun 2013 17:17:26 -0700 (PDT)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 342D238EF2; Mon, 10 Jun 2013 17:17:16 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Paul Hoffman'" <paul.hoffman@vpnc.org>
References: <06c101ce6625$0f891bf0$2e9b53d0$@augustcellars.com> <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org>
In-Reply-To: <379266A1-82C1-4FF5-BD7C-EE657F1FD41F@vpnc.org>
Date: Mon, 10 Jun 2013 17:16:24 -0700
Message-ID: <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIjA7ejHysocqIyb9p/XvW1gI4I3gIdfG2fmHV8G1A=
Content-Language: en-us
Cc: 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 00:17:32 -0000

My intention here has nothing to do with canonicalization and everything to
do with what constitutes a valid string from a parsing perspective.

Consider for example the case of a text file which consists of a JSON text
string with a trailing CRLF in the file.  If trailing whitespace is allowed
then the entire text file is a legal JSON text string.  If the trailing
whitespace is not allowed then it is not a legal JSON text string.  I am
just trying to clarify which is true.

This makes a difference with the argument about moving all of the values to
the top level since then the string (ignore the quotes) "   true \r\n"
cannot be matched if you just want to say it is a Boolean literal (i.e. the
non-terminator true).  Instead you need to say that it can have whitespace
on either side of it.

I will agree that the original intention probably is just a question of
academic interest.  The real question I should have asked would be are
people taking advantage of the fact.

That is the question of what about normal whitespace.

I think there is a question about parsers that would accept the string

{"a":"b"}A

As I believe there are some that will (stop when you get to the end of the
object) and some that will not.

Jim


> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
> Sent: Monday, June 10, 2013 3:04 PM
> To: Jim Schaad
> Cc: json@ietf.org
> Subject: Re: [Json] Leading and trailing whitespace
> 
> <no hat>
> 
> On Jun 10, 2013, at 2:54 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
> 
> > The current specification allows for arbitrary whitespace to occur
> > before and after an array or object.  I would like to know if this is
> > what was intended to begin with or not.
> 
> Why is the "intention" important?
> 
> > There are two different things that could be done about this (one of
> > which would potentially be necessary if you allowed all values in a
JSON-
> text.
> 
> Why should something "be done about this"? I think you are leading into
> canonicalization, but that's not part of RFC 4627, so introducing it seems
like a
> pretty massive change.
> 
> Having said that, knowing your intention would be useful here.
> 
> --Paul Hoffman=