Re: [Json] Complete section 3 proposal

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Tue, 18 June 2013 22:05 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 060BB21E80D1 for <json@ietfa.amsl.com>; Tue, 18 Jun 2013 15:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.663
X-Spam-Level:
X-Spam-Status: No, score=-10.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, 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 6AB-gjJ34ere for <json@ietfa.amsl.com>; Tue, 18 Jun 2013 15:05:30 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D92A921E80D6 for <json@ietf.org>; Tue, 18 Jun 2013 15:05:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1167; q=dns/txt; s=iport; t=1371593125; x=1372802725; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XvQei1pivcTFcsi+pS8nKsAbQ9H6Q4PfDdmqf8fILkU=; b=A4HsEt8voBSrEJkGGDxj5QhWTEhNNtg+6UITb03MZsmUrEnyT3ENQzHw Bk88UJynZ/djzw8hfaXVLUlihMrtKmJu6RYpoDXAZX+nmcMeff4TwGVwj GHKh0RCx7cM84uMSOsmoZPzZpctH+qfmlAQsIASFtg/LCrdjQ9PjoRnYo 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FADrYwFGtJV2c/2dsb2JhbABagwl6vxCBBBZ0giUBBDo/EgEIIhRCJQIEDgUIiAa7D48KMQeDAGEDqQSDD4Io
X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="224556606"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jun 2013 22:05:24 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5IM5OhF007172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 22:05:24 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 17:05:24 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Nico Williams <nico@cryptonector.com>
Thread-Topic: [Json] Complete section 3 proposal
Thread-Index: AQHObGQOe+q+3fshkkqz/+DniugiRZk8RoYA//+vxgA=
Date: Tue, 18 Jun 2013 22:05:23 +0000
Message-ID: <A723FC6ECC552A4D8C8249D9E07425A70FC591EA@xmb-rcd-x10.cisco.com>
In-Reply-To: <CAK3OfOgFqwxkoZtv2t9XR4t-DLYRoBJeATtGhOHZ2ZACACW4Gg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [64.101.72.72]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <78809B74E899194F80D3EC30186A1A4C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Complete section 3 proposal
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: Tue, 18 Jun 2013 22:05:36 -0000

On 6/18/13 2:52 PM, "Nico Williams" <nico@cryptonector.com> wrote:

>Note that if a JSON string in JSON data contains unescaped naked
>surrogates then the encoding of that data will not be valid UTF-8,
>UTF-16, nor, for that matter, CESU-8.  And some implementations
>probably produce CESU-8-encoded data.

I think the spirit of 4627 was that it literally be UTF-8, and that all of
those other odd encodings are already non-conformant.  We could always add
a note that says that there has been a history of encodings not being
quite adequately specified, so old software may produce octet streams that
this document doesn't describe.

>I'm not sure whether that's
>worth stating here or elsewhere, but the fact that there's
>not-quite-UTF-8 JSON out there means this SHALL is either
>interop-breaking or the matter must be mentioned nearby.

I agree it might be interop-breaking, but I don't think that's necessarily
the spec's fault.  People will write bad software, particularly when they
don't have test vectors easily at hand for them to probe what they
originally thought were edge cases.

>With this caveat, +1.

-- 
Joe Hildebrand