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

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Wed, 13 November 2013 23:51 UTC

Return-Path: <jhildebr@cisco.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 DF78921E80FA; Wed, 13 Nov 2013 15:51:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.201
X-Spam-Level:
X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8]
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 2WLfPY78NBGM; Wed, 13 Nov 2013 15:51:46 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4366121E8094; Wed, 13 Nov 2013 15:51:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=961; q=dns/txt; s=iport; t=1384386706; x=1385596306; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1iaQ0BIU+Wt4AjlnfmU/TmQCgMr+4Z3MUWY7OSiWcx8=; b=FPPXoTaJgqyFoE50Lq9lp2FBd34kNBWf0vbW49B1T4EKALeUyC6neqBD hi33yD9DN7uHd5lkDkMfgGRJPotU9agFHVrERXoDWVDyqJj37hdStWbva Z8q1/KlWr+uP2wbaeOB3Z7U5zOJT9MoJM4wcjzAAnweK68GgktAHnUWV3 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAEcPhFKtJV2a/2dsb2JhbABZgweBC78qgSUWdIIsOj8SAQg2QiUCBA4FiAHAKI9fB4QxA5Qug2KSC4MogWgGPA
X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="scan'208";a="284593254"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2013 23:51:45 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rADNpjeJ017564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 23:51:45 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 17:51:44 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: John Cowan <cowan@mercury.ccil.org>
Thread-Topic: [Json] JSON: remove gap between Ecma-404 and IETF draft
Thread-Index: AQHO37wfJCh2AJRFT02Gmc0EpJu9eJojjGwAgACdZQD//5yMgA==
Date: Wed, 13 Nov 2013 23:51:44 +0000
Message-ID: <CEA95C60.2CF3C%jhildebr@cisco.com>
In-Reply-To: <20131113224737.GI31823@mercury.ccil.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.21.124.251]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <88A13CDF1F6A284C9F3750B2CFFFFBD8@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 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: Wed, 13 Nov 2013 23:51:52 -0000

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.

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."

-- 
Joe Hildebrand