Re: [Json] What is a JSON-text? [REVISITED]

Mark Nottingham <mnot@mnot.net> Thu, 03 October 2013 22:58 UTC

Return-Path: <mnot@mnot.net>
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 888DC21F997D for <json@ietfa.amsl.com>; Thu, 3 Oct 2013 15:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.702
X-Spam-Level:
X-Spam-Status: No, score=-100.702 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_00=-2.599, FRT_ADOBE2=2.455, J_CHICKENPOX_24=0.6, 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 T4pMcBeNIa9z for <json@ietfa.amsl.com>; Thu, 3 Oct 2013 15:58:28 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2D64111E80FB for <json@ietf.org>; Thu, 3 Oct 2013 15:58:21 -0700 (PDT)
Received: from [192.168.1.64] (unknown [118.209.193.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C6C422E200; Thu, 3 Oct 2013 18:58:11 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D34820FD913@nambxv01a.corp.adobe.com>
Date: Fri, 04 Oct 2013 08:58:06 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <8426C572-0C47-4905-9BB9-8044087EC6CA@mnot.net>
References: <BF7E36B9C495A6468E8EC573603ED9411EF2B583@xmb-aln-x11.cisco.com> <CAHBU6iv7gT8nebFnz_mHQVZ3z8Kz+Pb8VRrSkMf44QRqWL8QjA@mail.gmail.com> <524DAEBF.1020509@drees.name> <CAK3OfOhRCCfNWHD-qSXOmswE7DL+QFefE_pvQO5g24NJ9q07hg@mail.gmail.com> <524DC3D5.4010806@drees.name> <C68CB012D9182D408CED7B884F441D4D34820FD913@nambxv01a.corp.adobe.com>
To: Larry Masinter <masinter@adobe.com>
X-Mailer: Apple Mail (2.1510)
Cc: Tim Bray <tbray@textuality.com>, Nico Williams <nico@cryptonector.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, "stefan@drees.name" <stefan@drees.name>, JSON WG <json@ietf.org>
Subject: Re: [Json] What is a JSON-text? [REVISITED]
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: Thu, 03 Oct 2013 22:58:39 -0000

What Larry said.

The RFC is very clearly defined to not allow this. The reasons for allowing other top-level values make total sense, but they're not JSON. One language that uses JSON allows more, but that's not JSON, else Crock would have written something different down.

Allowing more top-level values in text/json does *not* help interop; it hurts it.

OTOH doing it in another, separate media type (along with all of the other things we want to fix up) is perfectly workable; it improves interop for those who choose to use it.

Regards,

P.S. What we need to realise here is that just because we have the pen for bis, doesn't mean we can change the reality of deployed implementations, except with *very* gentle nudges over long periods of time. Or, put another way: <http://www.youtube.com/watch?v=409Pjtq7jzY>


On 04/10/2013, at 7:09 AM, Larry Masinter <masinter@adobe.com> wrote:

> I think you might make more headway if you think about the primary role of 4627 and 4627bis
> as registering Internet Media Types.  Consider, for example, having two media types
> 
> text/json and text/json+
> 
> the first of which is 4627 compatible, and the second (text/json+) allowing "non-container"
> top level.
> 
> Everything that is valid text/json would also be valid text/json+ with the same interpretation.
> 
> Or, you could keep the same internet media type and just declare it an extension,
> like image/gif changed for GIF89a. Or Postscript changed and still kept
> application/postscript. Yes, it's a change, no it fits within the convention of Internet
> Media Types to accept extensions that are lexically distinguishable.
> 
> 
> 
>> -----Original Message-----
>> From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of
>> Stefan Drees
>> Sent: Thursday, October 03, 2013 12:22 PM
>> To: Nico Williams
>> Cc: Matt Miller (mamille2); Tim Bray; JSON WG
>> Subject: Re: [Json] What is a JSON-text? [REVISITED]
>> 
>> On 2013-10-03 20:24 +02:00, Nico Williams wrote:
>>> On Thu, Oct 3, 2013 at 12:51 PM, Stefan Drees <stefan@drees.name> wrote:
>>>> Me also very strongly against "non-container" top-level entities.
>>>> 
>>>> Additional rationale:
>>>> - Add two bytes to wrap the serialized/transported value into array or
>>>>   say six bytes and use eg. {"d":my_top_level_value} should be cheap
>>>>   for the benefit of producing a JSON-text.
>>> 
>>> That's very lame; see below for rationale.
>>> 
>>>> Even if value is king, values like strings, numbers, true, false or null
>>>> just wrapped into "no clothes" make me wonder why one would serialize (or
>>>> forward) them as advertised JSON-text in the first place.
>>> 
>>> Because JSON isn't always used to transport values across networks
>>> (where it'd be silly to send scalar values with all the overheade of
>>> HTTP and TCP/IP, say).  JSON is often used for interop between local
>>> components, where the overhead that would make laughable the use of
>>> scalar values at the top-level just doesn't apply.  E.g., the Python
>>> bindings to libjq.  Indeed, here your suggestion that I call "lame"
>>> *adds* undesirable overhead.
>>> 
>>> "But JSON is an interchange format for networking" is not a good
>>> answer to that.  It's a good interchange format, full stop.  The train
>>> with JSON used for local interchange purposes left the station.  This
>>> is why parsers commonly have an option to accept scalar values at the
>>> top-level.
>> 
>> 
>>  ... and no one stops implementers nor users from parametrizing a
>> parser to adapt to special situations.
>> 
>> Say there is a document named pi.json that contains the text /3.14/ (but
>> without the slashes) that may be the (best effort) serialized
>> representation of the "number" pi or just the first four bytes, as the
>> file became truncated (or the local message content if you are so
>> inclined). As a JSON text wraped inside array or object, the situation
>> would be clear, in the above "unwrapped" case it is not anymore.
>> 
>> So I think, the above '[...]values like strings, numbers, true, false or
>> null just wrapped into "no clothes" make me wonder why one would
>> serialize (or forward) them as advertised JSON-text in the first place.'
>> remains as it stands, doesn't it?
>> 
>> Whatever un-"lame" and un-"laughable" ;-) "train has left the station",
>> I guess that without making "wrapping" mandatory for JSON-text, one
>> might consider JSON-izing every binary protocol on earth into such an
>> unwrapped JSON+* channel (by combining the unlimited "number" feature of
>> the JSON rfc and "interpreting" some representation bilaterally
>> negotiated as the underlying bit pattern for the stored/transmitted
>> binary protocol message).
>> 
>> The set of relations, where one uses JSON as a means to communicate
>> between otherwise unrelated components, that are on one hand so closely
>> coupled, that no wrapping is needed, but on the other hand so far apart,
>> that they cannot accept non JSON-text (as it stands now) looks similar
>> to the empty set to me, but I am sure, people will let me soon know of
>> exotic situations ... :-)
>> 
>> ["Stefan"]
>> 
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham   http://www.mnot.net/