Re: [jose] Fwd: New Version Notification for draft-rundgren-predictable-serialization-for-json-00.txt

"Manger, James" <James.H.Manger@team.telstra.com> Mon, 09 November 2015 00:12 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B701B5214 for <jose@ietfa.amsl.com>; Sun, 8 Nov 2015 16:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InH9NQoUGvju for <jose@ietfa.amsl.com>; Sun, 8 Nov 2015 16:12:21 -0800 (PST)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id B43601B5210 for <jose@ietf.org>; Sun, 8 Nov 2015 16:12:19 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.20,264,1444654800"; d="scan'208";a="42558638"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 09 Nov 2015 11:12:16 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,7979"; a="40315069"
Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbni.tcif.telstra.com.au with ESMTP; 09 Nov 2015 11:12:16 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Mon, 9 Nov 2015 11:12:16 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, "jose@ietf.org" <jose@ietf.org>
Date: Mon, 09 Nov 2015 11:12:14 +1100
Thread-Topic: [jose] Fwd: New Version Notification for draft-rundgren-predictable-serialization-for-json-00.txt
Thread-Index: AdEXDHXNMKd2us+uQjCAgqQXSzYU9QAY20hw
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BB1997461@WSMSG3153V.srv.dir.telstra.com>
References: <20151104111119.27070.27389.idtracker@ietfa.amsl.com> <563A14E7.5050901@gmail.com>
In-Reply-To: <563A14E7.5050901@gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/wE3fv8Vegwcjh3lfOE8vb_4hYFg>
Subject: Re: [jose] Fwd: New Version Notification for draft-rundgren-predictable-serialization-for-json-00.txt
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2015 00:12:23 -0000

Comments on draft-rundgren-predictable-serialization-for-json:

1. It is useful to have a canonical form of JSON defined, even if most applications should avoid relying on a canonical form where possible.

2. Signing JSON is a primary use-case for a canonical form, but should be specified separately. Defining the "signature" member in section 3 is too incomplete (which key, which algorithm etc) so it should be omitted.
[I wonder if an easy way to define how to embed a signature in the JSON value being signed would be to define, say, a "jws" member that holds "protected", "header", and "signature" members. Those member are as per JWS [RFC7515], except "protected" is not base64-encoded as its canonical form is used. The payload is the canonical form once "jws" is removed.]

3. The sample in the introduction should show a few more features: some string escapes, and changing whitespace. How about:
  {
    "device": "Pump 1\/2 \u0022Red\u0022",
    "value": 0.000000000000000001
  }
and
  { "value":1e-18, "device":"Pump 1/2 \"Red\"" }

4. Don't require "empty properties" to be rejected. It's not clear if an empty property is one with a null value, or "" as its name; both of which are valid JSON that should be accepted.

5. You don't need to say the "'\/' escape sequence MUST be honoured on input" as this is no different from all the other valid escape sequences that also need to be honoured by a JSON parser (unless you are implying \/ needs to be preserved when creating the canonical form). Suggested text:
  2.2.2 String Normalization
  The canonical form of a JSON string uses escape sequences as follows:
  * \" \\ \b \f \n \r and \t MUST be used to represent their respective characters
  * \u00xx (where xx are lowercase hex digits) MUST be used to represent the other 27 control characters in the range U+0000 to U+001F 
  * All other characters MUST NOT be escaped
  Note: the canonical form does not use the \/ escape sequence, nor does it escape the line and paragraph separator characters U+2028 and U+2029.

6. Preserving the form of numbers is too unnatural for most uses of JSON (where JSON is parsed into primitive types such as a 64-bit IEEE float). We can and should specify a canonical form for decimals in general (exponent iff value outside [1e-6, 1e21), no leading or trailing zeros, "e" for exponent, + or - on exponent); plus a canonical form for translating from binary floating point formats (use shortest then closest significand that parses to the float). Plus advice about rounding floats to lower precision (eg 14 digits) to improve chances of interop.

7. For interop with ECMAScript JSON.parse/stringify you don't have to forbid integer-like member names, eg "1". It is sufficient to require they occur first and in numeric order.

8. Offering specific code in 3.3 to minimise interop issues from ECMAScript's leniency is nice, but shouldn't be "REQUIRED". Need to clarify that this sort of code should only be used when initially creating JSON (eg signing), not when re-creating JSON after parsing it (eg verifying).

9. It is curious that the special value the code uses for rounding to zero (< 2.22507385850721E-308) isn't the smallest non-subnormal 64-bit float, but the 4th smallest.


--
James Manger




-----Original Message-----
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren
Sent: Thursday, 5 November 2015 1:24 AM
To: jose@ietf.org
Subject: [jose] Fwd: New Version Notification for draft-rundgren-predictable-serialization-for-json-00.txt

A new version of I-D, draft-rundgren-predictable-serialization-for-json-00.txt
has been successfully submitted by Anders Rundgren and posted to the IETF repository.

Name:		draft-rundgren-predictable-serialization-for-json
Revision:	00
Title:		Predictable Serialization for JSON Tools
Document date:	2015-11-04
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-rundgren-predictable-serialization-for-json-00.txt
Status:         https://datatracker.ietf.org/doc/draft-rundgren-predictable-serialization-for-json/
Htmlized:       https://tools.ietf.org/html/draft-rundgren-predictable-serialization-for-json-00


Abstract:
    This specification outlines an optional characteristic of JSON tools
    like parsers, serving two entirely different purposes: 1) Making
    information-rich JSON messages more human-readable by honoring the
    originator's conventions.  2) Facilitating simple "Signed JSON"
    schemes without necessarily needing specific signature text-
    processing software.  Finally, there is a section containing
    recommendations for interoperability with systems based on EcmaScript
    V6 (AKA JavaScript).


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose