Re: [Json] Scope: Wire format or runtime format?

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 17 June 2013 01:59 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 CAD4C21F8B07 for <json@ietfa.amsl.com>; Sun, 16 Jun 2013 18:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.59
X-Spam-Level:
X-Spam-Status: No, score=-101.59 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 xRUuCA1Xb1T4 for <json@ietfa.amsl.com>; Sun, 16 Jun 2013 18:59:45 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1879121F9C01 for <json@ietf.org>; Sun, 16 Jun 2013 18:59:44 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5H1xVO0017543; Mon, 17 Jun 2013 10:59:31 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 174d_9a4f_8ce4247c_d6f1_11e2_825f_001e6722eec2; Mon, 17 Jun 2013 10:59:30 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1E1A8C0234; Mon, 17 Jun 2013 10:58:13 +0900 (JST)
Message-ID: <51BE6D79.5010909@it.aoyama.ac.jp>
Date: Mon, 17 Jun 2013 10:59:21 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Markus Lanthaler <markus.lanthaler@gmx.net>
References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> <51BCF9C0.1080408@att.com> <51BD96C5.80709@drees.name> <00b001ce6a80$9a821ea0$cf865be0$@lanthaler@gmx.net>
In-Reply-To: <00b001ce6a80$9a821ea0$cf865be0$@lanthaler@gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: json@ietf.org
Subject: Re: [Json] Scope: Wire format or runtime format?
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: Mon, 17 Jun 2013 01:59:51 -0000

On 2013/06/16 19:59, Markus Lanthaler wrote:
> On Sunday, June 16, 2013 12:43 PM, Stefan Drees wrote:
>> On 2013-06-16 01:33 +02:00, Tony Hansen wrote:
>>> On 6/15/2013 11:27 AM, Paul Hoffman wrote:
>>>> Why not both? RFC 4627 deals with both; why should the update change
>>>> to restrict that?
>>>
>>> I'm with Paul -- it needs to continue to do both.
>>>
>>> IMO, there's 1) the character-based definition of the JSON format, the
>>> one defined by the ABNF, and 2) an expression of that for over-the-wire
>>> use as an application/json entity. The bulk of this document should be
>>> focused on #1, and I think #2 can then be a fairly small section.
>>
>> I second that POV.

+1.

But as far as I understand, these two were not the two that Norbert was 
talking about in the mail that started this thread. (More on that in a 
separate mail.)

>> Until we started suggesting new titles for our
>> well-beloved RFC 4627, we all focused mostly on #1 and took #2 for
>> granted as necessary for hand-over "conventions".
>>
>> Please keep these two aspects together in one document, and ... just let
>> us **not** shoot too far over the approx. 2000 words RFC 4627 needed.
>> Most discussions - until now - convinced me that we will not be able to
>> really add that much to it, so many additional words will be considered
>> unreasonable and diluting.
>>
>> An additional document even worse, seems like complete overhead to me.
>
> +1

+1, at least as long as we haven't tried seriously with one document.

Regards,   Martin.