3 ms·

1) Numeric precision of integers is (under)specified in RFC 7159 section 6: https://tools.ietf.org/html/rfc7159#section-6 https://tools.ietf.org/html/rfc7159#s

by bascule 10y ago

1) Numeric precision of integers is (under)specified in RFC 7159 section 6: https://tools.ietf.org/html/rfc7159#section-6 https://tools.ietf.org/html/rfc7159#section-6 Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. There is no contract that JSON integers give you full 64-bit precision. TJSON has such a contract, and tests for support for full-precision 64-bit integers (and expected failure in the boundary cases) is specified in the canonical test cases/examples file: https://github.com/tjson/tjson-spec/blob/master/draft-tjson-examples.txt#L210 https://github.com/tjson/tjson-spec/blob/master/draft-tjson-... 2) Please see https://github.com/tjson/tjson-spec/issues/27 https://github.com/tjson/tjson-spec/issues/27 3) Yes, these specific ranges are covered in the spec: https://www.tjson.org/spec/#rfc.section.3.3 https://www.tjson.org/spec/#rfc.section.3.3 4) Z-normalized RFC3339. See: https://www.tjson.org/spec/#rfc.section.3.4 https://www.tjson.org/spec/#rfc.section.3.4 5) TJSON provides a repertoire of types which approximates what's available in the scalar types of a format like Protobufs: https://developers.google.com/protocol-buffers/docs/proto3#scalar https://developers.google.com/protocol-buffers/docs/proto3#s... What about, say, IP addresses Simple solution for that case: IP addresses have canonical representations as strings, so use their string representations. Or, if you prefer, represent them as a TJSON object. 6) objecthash provides an alternative to canonicalization: we can use a "content-aware" hash algorithm to produce a digest of the content rather than trying to arrange the content into a canonical form. See: https://github.com/tjson/tjson-spec/issues/24 https://github.com/tjson/tjson-spec/issues/24 I hate to be so negative, but this really comes off as half-baked. As far as I can tell, you didn't read the spec. All of your perceived ambiguities are addressed.

colanderman 10y ago
1) That paragraph is discussing interoperability, not the semantics of JSON. JSON "integers" have no such concept as "precision". They are just a sequence of digits. Just like most environments have no problem with very large strings, many environments also have no problem with very large numbers. Dictating "numbers can only be this big" is quite a step backward. 5) Ignoring for a second that IP addresses (particularly IPv6) don't have a universally-accepted canonical format, that's a great solution. But it's one that applies equally to every other data type, even those TJSON special-cases. TJSON is picking a handful of "privileged" types that won't be enough for everyone, so we'll just hit the same problem again.
- bascule 10y ago
  1) TJSON imposes precision requirements on parsers which JSON lacks. It gives you guarantees where JSON doesn't. JSON may or may not lose precision when you go outside the RFC 7159 range [-(2^53)+1, (2^53)-1]. This is a potential silent failure that mangles data and is unacceptable in a security context, and one present in popular language environments such as JavaScript and Go. 5) The set of scalar types provided by TJSON is not too far off from that provided by protos. As I explained in my previous response, if you want to go beyond those, use a non-scalar type: https://developers.google.com/protocol-buffers/docs/proto3#scalar https://developers.google.com/protocol-buffers/docs/proto3#s... This is par for the course for most typed languages and serialization formats. You don't magically define new scalar types de novo: you build them as sum/product types from scalars and other non-scalars. TJSON's objects are self-describing product types.

by bascule 10y ago

colanderman 10y ago

1) That paragraph is discussing interoperability, not the semantics of JSON. JSON "integers" have no such concept as "precision". They are just a sequence of digits. Just like most environments have no problem with very large strings, many environments also have no problem with very large numbers. Dictating "numbers can only be this big" is quite a step backward. 5) Ignoring for a second that IP addresses (particularly IPv6) don't have a universally-accepted canonical format, that's a great solution. But it's one that applies equally to every other data type, even those TJSON special-cases. TJSON is picking a handful of "privileged" types that won't be enough for everyone, so we'll just hit the same problem again.

bascule 10y ago
1) TJSON imposes precision requirements on parsers which JSON lacks. It gives you guarantees where JSON doesn't. JSON may or may not lose precision when you go outside the RFC 7159 range [-(2^53)+1, (2^53)-1]. This is a potential silent failure that mangles data and is unacceptable in a security context, and one present in popular language environments such as JavaScript and Go. 5) The set of scalar types provided by TJSON is not too far off from that provided by protos. As I explained in my previous response, if you want to go beyond those, use a non-scalar type: https://developers.google.com/protocol-buffers/docs/proto3#scalar https://developers.google.com/protocol-buffers/docs/proto3#s... This is par for the course for most typed languages and serialization formats. You don't magically define new scalar types de novo: you build them as sum/product types from scalars and other non-scalars. TJSON's objects are self-describing product types.