Re: [Json] Leading and trailing whitespace

Carsten Bormann <cabo@tzi.org> Tue, 11 June 2013 16:16 UTC

Return-Path: <cabo@tzi.org>
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 D06E621F8F9E for <json@ietfa.amsl.com>; Tue, 11 Jun 2013 09:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.147
X-Spam-Level:
X-Spam-Status: No, score=-106.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Ygr+WPsP-RFc for <json@ietfa.amsl.com>; Tue, 11 Jun 2013 09:16:47 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5B32D21F9634 for <json@ietf.org>; Tue, 11 Jun 2013 09:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5BGGfBN022471; Tue, 11 Jun 2013 18:16:41 +0200 (CEST)
Received: from [192.168.217.105] (p54893004.dip0.t-ipconnect.de [84.137.48.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1AA433608; Tue, 11 Jun 2013 18:16:41 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <51B73868-AA72-439E-B422-BF6A2B0E83ED@vpnc.org>
Date: Tue, 11 Jun 2013 18:16:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AF10493-9076-455E-97ED-C9F104A8D797@tzi.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> <CAK3OfOiBmzCdQtyUFoBkSFMFJijE7K8eR+9YUv7bhD2YaQBW2Q@mail.gmail.com> <B0660BD8-5D82-4D35-BD0E-DC2212198C7B@tzi.org> <51B73868-AA72-439E-B422-BF6A2B0E83ED@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1508)
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 16:16:52 -0000

On Jun 11, 2013, at 18:06, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

>> So we will have to add a production:
>> 
>> 	JSON-value = ws value ws
>> 
>> That didn't seem too hard.
> 
> Question: are you saying we should do that even if we don't allow all values at the top level, or only if we add them at the top level?

This production does not have any effect unless we use it.
The radical proposal is to replace the top-level JSON-text with it, or

JSON-text = ws value ws

My less radical, but somewhat questionable proposal is to use it as a second "top-level", i.e., keep 
JSON-text as is as the basis for application/json and the +json media types, and add application/json-value referencing this new production.

The less radical proposal is somewhat questionable because it is very likely that people will keep sending around JSON-value representations with a application/json media type even it is clarified that this one is JSON-text only.  On the other hand I haven't seen too many documented cases of that, so maybe it is not that much of a problem.  Clearly, some thinking would need to go into how +json would handle the desire for isolated atomic JSON values.  And, some phrases as in "send it to me in JSON" would need some recalibration, because it is no longer clear which variant is needed.  (Arguably, that hasn't really been clear for a while.)

Grüße, Carsten