Re: [Json] JSON: remove gap between Ecma-404 and IETF draft

Allen Wirfs-Brock <allen@wirfs-brock.com> Thu, 14 November 2013 02:35 UTC

Return-Path: <allen@wirfs-brock.com>
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 1BE5121E812D; Wed, 13 Nov 2013 18:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_45=0.6]
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 a0XXOYx2HxkW; Wed, 13 Nov 2013 18:35:18 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id F39DC21E811C; Wed, 13 Nov 2013 18:35:17 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.22]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vgmm3-000Lab-3q; Thu, 14 Nov 2013 02:35:15 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19HjyrCL5dDEOvVnuQBcuUDCOeOOKXxJrA=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <CEA95C60.2CF3C%jhildebr@cisco.com>
Date: Wed, 13 Nov 2013 18:35:06 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E62DA50-F941-4A0E-A7B3-966A0DDE4C7A@wirfs-brock.com>
References: <CEA95C60.2CF3C%jhildebr@cisco.com>
To: Joe Hildebrand <jhildebr@cisco.com>
X-Mailer: Apple Mail (2.1085)
Cc: John Cowan <cowan@mercury.ccil.org>, IETF Discussion <ietf@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>, Anne van Kesteren <annevk@annevk.nl>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft
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, 14 Nov 2013 02:35:24 -0000

On Nov 13, 2013, at 3:51 PM, Joe Hildebrand (jhildebr) wrote:

> On 11/13/13 3:47 PM, "John Cowan" <cowan@mercury.ccil.org> wrote:
> 
>> It's not clear that 404 disallows it, since 404 is defined in terms of
>> characters, and a BOM is not a character but an out-of-band signal.

However, for example, a conforming implementation of the ECMAScript JSON.parse function would reject any string passed to it that starts with a U+FFEF code point because the unquoted occurrence of that code point does not conform to the ECMA-252, 5th Edition or Ecma-404 JSON grammar.

In order to be successfully processed, that code point would have to be stripped from the string prior to calling JSON.parse.

Allen

> 
> Agree.  However, that signal would be a part of the 4627bis octet stream,
> so a little interop guidance would likely be useful.  Something like:
> 
> "Some producers of JSON produce JSON-text that starts with a redundant
> U+FEFF (ZERO WIDTH NO-BREAK SPACE, previously known as BYTE ORDER MARK)
> with the ostensible purpose of signaling the encoding of the text to
> follow.  Since JSON has other mechanisms to determine encoding, this is
> not required.  Receiving applications MAY safely ignore this initial
> character without generating an error.  Implementations that do not send
> U+FEFF are interoperable in the sense that all software implementations
> which receive the un-prefixed text will not generate parse errors."
> 

Isn't it an interooperbility issue that many receiving applications do not ignore it.

Allen