Re: [Json] I-JSON Tpic #2: Top-Level

Jacob Davies <jacob@well.com> Wed, 21 May 2014 15:13 UTC

Return-Path: <cromis@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB17B1A0364 for <json@ietfa.amsl.com>; Wed, 21 May 2014 08:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWSaunbh3bt8 for <json@ietfa.amsl.com>; Wed, 21 May 2014 08:13:17 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DD01A0691 for <json@ietf.org>; Wed, 21 May 2014 08:13:15 -0700 (PDT)
Received: by mail-ig0-f182.google.com with SMTP id uy17so2228800igb.9 for <json@ietf.org>; Wed, 21 May 2014 08:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=E3Fd4tZBb/BY6UjoKI+k2ttJ64rEysRstU6f4deDoCU=; b=o6+L2oko4b5YcDAPnwmy/RqqcsgaDN5yRRuOd5Nx6fAbuk+GKjQ/SypIKp52Nkr9k4 CXR1akTLLDPIDNTBHiizCTb7/yJmfZqutee5H0fkqR48Zc9DwhEiwAwwthQz9KIkqNeE QGn5v9cSlrAoQ7eWBjqKp4qu5D36M9tDEdr6dOLdeaGONflwsgH9HnwVIJhibH3gwOKo kvP6XHB2vrjtqf7rWtKWgzAAb0zlXri/Gz5VFiaYyZ7Bu7NeXISSa4EtCr+5Eh/n3qy6 2FFWxvTcq+gJTbGlrLnCsD1NCFEGjPOPBZsYU3/+djKc2e5nGl0KOVhQa+d2jmqMBtHO 0jbA==
X-Received: by 10.43.151.7 with SMTP id kq7mr3368839icc.78.1400685194708; Wed, 21 May 2014 08:13:14 -0700 (PDT)
MIME-Version: 1.0
Sender: cromis@gmail.com
Received: by 10.64.9.180 with HTTP; Wed, 21 May 2014 08:12:54 -0700 (PDT)
In-Reply-To: <537C64B3.1010502@it.aoyama.ac.jp>
References: <535EB119.4000908@cisco.com> <CAHBU6itycQmqzAuxWyrFZ_v=fHdenm2csyAqtUGGu+vteh6=yQ@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> <CAHBU6iuqosV91W6CJyow_eaKdCNm_VOairJysuLS8mrWV+HM9g@mail.gmail.com> <ABB2BA00-6A21-4710-A1F5-49D4FB469E8F@vpnc.org> <CAK3OfOig8y5KpYZ86KrMPxrJOYC_hLBew_nmyneHCC2mXX+tag@mail.gmail.com> <537BB89E.2040305@cisco.com> <3BF9B252-3CCD-4BC3-9F30-8634B483FAEE@tzi.org> <537C64B3.1010502@it.aoyama.ac.jp>
From: Jacob Davies <jacob@well.com>
Date: Wed, 21 May 2014 08:12:54 -0700
X-Google-Sender-Auth: fYa2XFm0zdOC11deXRkLUS8hGr0
Message-ID: <CAO1wJ5S=zrz3E+LUxHuYFi_Y56OUJumCKdUD7B2oMQm0kdb=Qg@mail.gmail.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/json/FHgxFzz6zxS5HWDWi8SyR44enDA
Cc: Carsten Bormann <cabo@tzi.org>, IETF JSON WG <json@ietf.org>
Subject: Re: [Json] I-JSON Tpic #2: Top-Level
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 21 May 2014 15:13:18 -0000

On Wed, May 21, 2014 at 1:32 AM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:
> I wanted to write that I didn't see that much of a need for single strings,
> numbers,... in any serious format for data interchange.

Some examples from the earlier discussion:

1. The retrieval of part of a resource by path. Requiring a JSON
object envelope is pointless and asymmetric.
2. Patching just part of a resource by path. Again, requiring an
object envelope is unnecessary.

The most common transport for JSON is HTTP, which already provides for
an out-of-band key-value space for extra data. It probably is the case
that JSON objects are the most suitable choice for the messages
exchanged in most protocols, but there are exceptions as described
above, and in any case I doubt anyone is really confused over whether
an object or a string is the most suitable message format.