Anders,
JSON strings are perfectly unambiguous, they are simply not unique (like many
text formats that have escapes).
I am glad you want to pick a unique (canonical) form, but if your choice
involves not escaping newlines, for instance, then please show some courtesy to
the rest of the community by not calling it JSON — because it simply will not
interoperate with many other JSON-compliant systems.
For instance, try the console (press F12) of the popular Chrome browser:
> JSON.parse("\"hello\\nworld\"");
"hello
world"
> JSON.parse("\"hello\nworld\"");
SyntaxError: Unexpected token
A laptop.org form might also only escape \ and ", but it also accepts arbitrary
bytes that are not valid UTF-8. Perhaps that is useful in their circumstance,
but it will not interoperate with general JSON systems so should not be called
JSON.
JCS looked interesting, but if it doesn't bother to meet the easy bar of
complying to the JSON string format then my interest vanishes.
--
James Manger
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Anders Rundgren
> Sent: Saturday, 7 September 2013 8:37 PM
> To: [email protected]
> Subject: [jose] On-line Demo/Test of JSON Clear Text Signatures
>
> https://mobilepki.org/jcs/home
>
> Enjoy!
>
> Canonicalization
>
> Precondition: Valid JSON data as described on http://www.json.org has
> been received.
>
> Restriction: The only permitted (and required) escape sequences are \\
> and \" because JSON supplied as a part of a web-page must anyway be
> escaped according to web-rules, while JSON supplied through HTTP etc.
> only needs to be parsable.
>
> Another reason for this somewhat radical step is that the JSON world
> appears to be severely divided on escapes sequences in general:
> http://stackoverflow.com/questions/6011012/making-json-not-escape-
> forward-slashes.
>
> The canonicalization steps are as follows:
> - Whitespace is removed which in practical terms means removal of all
> characters outside of quoted strings having a value <= ASCII space
> - Properties are sorted in lexical UNICODE order using their unescaped
> form. Zero-length properties are not allowed
> - The JSON object associated with the Signature is recreated using the
> actual textual data. Rationale: Numbers are ambiguously defined in
> JSON which means that encoding and decoding most likely will differ
> among JSON implementations. There is another, more subtle issue as
> well. If a sender for example assigns a large number such as
> 0.99999999999999999999 to a JSON property there is a possibility that a
> receiver due to limitations in arithmetic precision rather interprets
> it as 1.0. To cope with these potential problems, a compliant parser
> must preserve the original textual representation internally in order
> to perform proper canonicalization
>
> Anders
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Anders
Rundgren
Sent: Saturday, 7 September 2013 9:30 PM
To: [email protected]
Subject: [jose] Yet another Canonical JSON
http://wiki.laptop.org/go/Canonical_JSON
It was nice to see that this scheme also outlaws all escapes but \\ and \".
It looks like a trend :-)
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
