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

Stefan Drees <stefan@drees.name> Sun, 16 June 2013 10:43 UTC

Return-Path: <stefan@drees.name>
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 3B2D121F9E38 for <json@ietfa.amsl.com>; Sun, 16 Jun 2013 03:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 DjshNsDTns4w for <json@ietfa.amsl.com>; Sun, 16 Jun 2013 03:43:27 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 34EBC21F9E43 for <json@ietf.org>; Sun, 16 Jun 2013 03:43:26 -0700 (PDT)
Received: from newyork.local.box ([93.129.105.13]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0LwZ5z-1UGINV1x0R-018MxE; Sun, 16 Jun 2013 12:43:19 +0200
Message-ID: <51BD96C5.80709@drees.name>
Date: Sun, 16 Jun 2013 12:43:17 +0200
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Tony Hansen <tony@att.com>
References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org> <51BCF9C0.1080408@att.com>
In-Reply-To: <51BCF9C0.1080408@att.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:QW/CaBexQ9ZMZKBkRAizOiMoI4sheiVRggG1bKPNOc6LXIKDwyp qDZ7zkeAfKHW6uWDcDxLWaFQkvHKpRjXZyTsaAZzWXRlGIBWj7aKcgSJRT49VFePqLazgwy xbhwsBK681MMDqL5QScO3yItHHD1EVPPMdSWiMHc8mC8XCQC8HQP/j5unlbiegLKBUITnoY co3mxrN43uMTgerIW9RSw==
Cc: Norbert Lindenberg <ietf@lindenbergsoftware.com>, Paul Hoffman <paul.hoffman@vpnc.org>, 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
Reply-To: stefan@drees.name
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: Sun, 16 Jun 2013 10:43:32 -0000

On 2013-06-16 01:33 +02:00, Tony Hansen wrote:
> On 6/15/2013 11:27 AM, Paul Hoffman wrote:
>> On Jun 13, 2013, at 6:47 PM, Norbert Lindenberg <ietf@lindenbergsoftware.com> wrote:
>>
>>> In looking over older messages on this list, I found a message that made clear to me why we're having this endless discussion about Unicode surrogates - it's because we're not clear whether we're designing a wire format or a format that also for use at runtime:
>>> http://www.ietf.org/mail-archive/web/json/current/msg00355.html
>>>
>>> Some people are coming from the runtime point of view, especially ECMAScript, where it's accepted practice to use ill-formed UTF-16 or even non-text in strings. At least the ill-formed UTF-16 is legitimized by section 2.7 of the Unicode standard.
>>>
>>> Other people are coming from the wire protocol point of view, where clean formats are expected, in particular well-formed Unicode code unit sequences according to section 3.9 of the Unicode standard.
>>>
>>> So which one shall it be?
>> 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. 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.

Stefan Drees.