IETF Logo Mail Archive

Re: [Json] Allow any JSON value at the top level

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 11 June 2013 02:05 UTC

Return-Path: <paul.hoffman@vpnc.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 1FD9C21F9942 for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 19:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.436
X-Spam-Level:
X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, 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 Orbupepb7JeH for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 19:05:54 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 54FF521F972C for <json@ietf.org>; Mon, 10 Jun 2013 19:05:54 -0700 (PDT)
Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5B25p5V061298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Jun 2013 19:05:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAK3OfOjLQv9eGA6TB62JuFRZLMQsDsdKMHJkWmb7zZgLYdY9Pg@mail.gmail.com>
Date: Mon, 10 Jun 2013 19:05:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <29C7B970-C97D-47E2-9C91-272B2C18E3D1@vpnc.org>
References: <A723FC6ECC552A4D8C8249D9E07425A70FC33B5B@xmb-rcd-x10.cisco.com> <51b23e6d.6196420a.0b15.4245SMTPIN_ADDED_BROKEN@mx.google.com> <CAChr6SwrveU=fesF8VidDYWzeYMu2c1+=38+__BqHArxTiW5mg@mail.gmail.com> <51b4dbbe.64da440a.1fc2.6dd2SMTPIN_ADDED_BROKEN@mx.google.com> <CAChr6Sx_obmG+=sY100ySBLmevN0VJ_0Z9TjYGxcXKOx+UtnJA@mail.gmail.com> <51b4ec44.ea05420a.7c73.ffffa487SMTPIN_ADDED_BROKEN@mx.google.com> <CAChr6SxiZ2Yz6SiozQZpuYoGKSzWnUux6PukyWDkcvKsVyyRbQ@mail.gmail.com> <51b507b1.c686e00a.3a7e.ffffa0adSMTPIN_ADDED_BROKEN@mx.google.com> <CAO1wJ5R2H27qh-DWG5B8CzutkTFWxn-h+Qi1jiet23axxmvLyA@mail.gmail.com> <20130610201746.GC1057@mercury.ccil.org> <CAO1wJ5Q9mhspheU3h4NRx9x5LOz9yOgJBXhwPWBOVw-w71ncTQ@mail.gmail.com> <3CE20E15-8F9E-4727-BBE7-FBB06F7CAC24@jorgechamorro.com> <CAGrxA24T8m9oHmuVE8n+YG6ATr3sTTByet7Te8VyAmypD11p6w@mail.gmail.com> <B14769F1-5C71-4F1D-8E20-513271876620@vpnc.org> <CAK3OfOjLQv9eGA6TB62JuFRZLMQsDsdKMHJkWmb7zZgLYdY9Pg@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1508)
Cc: json@ietf.org
Subject: Re: [Json] Allow any JSON value at the top level
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:05:58 -0000

On Jun 10, 2013, at 5:30 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Mon, Jun 10, 2013 at 6:56 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> <no hat>
>> 
>> Although I earlier supported the idea of any JSON value at the top level, a bunch of recent posts show that this is probably a significant revision to the RFC because it would take a lot of extra requirements as well. I now support leaving the requirement in the -bis document as it is now.
>> 
>> If we want to add a new MIME type for "any JSON item", that is clearly a significant addition to the RFC. It can wait until the WG recharters.
> 
> I see no reason [yet... the way these threads have been going...] why
> we couldn't recommend that parsers be able to parse any top-level
> value, with the only interesting note being that end-of-message
> termination of numeric top-level values must not be accidentally
> confused with premature EOF.  Also, we could just allow any
> non-numeric top-level value.  With a similar recommendation for
> encoders.

Why add any recommendation for parsers for that case? The current doc already has:

   A JSON parser MAY accept non-JSON forms or extensions.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email