Re: [Json] Leading and trailing whitespace

"Jim Schaad" <ietf@augustcellars.com> Tue, 11 June 2013 02:33 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 AD55021E80A0 for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 19:33:25 -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 IQ8CE5SO-otW for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 19:33:19 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C154021E805A for <json@ietf.org>; Mon, 10 Jun 2013 19:33:19 -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 smtp2.pacifier.net (Postfix) with ESMTPSA id 9E9C72C9F8; Mon, 10 Jun 2013 19:33:11 -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> <06e901ce6638$e8f27a90$bad76fb0$@augustcellars.com> <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org>
In-Reply-To: <51DE7E41-D682-4340-A234-7F7CFE513C10@vpnc.org>
Date: Mon, 10 Jun 2013 19:32:19 -0700
Message-ID: <070b01ce664b$e5e0ac10$b1a20430$@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/XvW1gI4I3gIdfG2fAXcnW3oCcTmHLZhWYFCA
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 02:33:25 -0000

> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
> Sent: Monday, June 10, 2013 7:02 PM
> To: Jim Schaad
> Cc: json@ietf.org
> Subject: Re: [Json] Leading and trailing whitespace
> 
> On Jun 10, 2013, at 5:16 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> > 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.
> 
> The "JSON text string" (called a "string" in RFC 4627) starts and ends
with a
> quotation mark:
>       string = quotation-mark *char quotation-mark There is no "ws"
anywhere
> there, but there sure are quotation marks.
> 

Ok - I used the wrong term - I need to get them clearer, I still am trying
to learn - Please read JSON text for JSON text string.  I was not using
string as a value in this location.

> > 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.
> 
> The current grammar does not allow whitespace around "true" for that
> boolean value.

Actually it does, but the whitespace comes from the container it is in.  The
current grammar does not allow true at the top level and if that does not
change then the above remains a moot point.  Note that the text was talking
about moving all values to the top level.

> 
> > 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 would be interested if anyone sees anything in the document that
> disagrees with the above.
> 
> > 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.
> 
> If that is meant to be a JSON text, I cannot imagine how that is valid,
but
> maybe I'm not creative enough.

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.

Jim

> 
> --Paul Hoffman=