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:[email protected]] On Behalf Of Anders Rundgren
Sent: Thursday, 5 November 2015 1:24 AM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
