tjson-spec

instead of 'Unicode'" outside the context of specific sections of the specification aren't particularly helpful. Furthermore, what does the author intend for escaped characters? Are they allowed? Presumably not, since that would provide for non-canonical representations. You are continuing to miss the point: TJSON intends to provide a foundation to use content-aware content hashing in lieu of a canonicalization scheme as an alternative solution which works across multiple encodings of the same data, sidesteps the exact problems you're talking about, and also allows arbitrary subsets of an object graph to be authenticated without requiring rehashing/resigning. Please see this closed issue on canonicalization ("won't do"): https://github.com/tjson/tjson-spec/issues/24 From what I can gather, TJSON is offering a degree of abstraction you have not yet fully gleaned. The core idea is: many serializations, one underlying data structure/object graph. TJSON is a mere serialization layer, and indeed many TJSON documents may refer to the same underlying data structure, but all will have the same "objecthash": https://github.com/benlaurie/objecthash

ally provide non-lossy transcoding to/from the similarly tagged types in CBOR in ways JSON itself cannot.

y understand what's going on here.

ttps://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#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 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.

3)? 4) "t: timestamp (Z-normalized)" What does that mean? There are literally dozens of timestamp formats. Does he mean full ISO 8601, restricted to UTC? 5) What is the point of TJSON anyway? When you deserialize, you still have to check that the data is of the type you expect. At best this saves a bit of parsing, since the deserializer can do that automatically. Various JSON schema languages already exist, which give you this richer typechecking. The only use case I can think of for this is exactly what the author mentions further down the article: canonicalization for content-aware hashing. But this only works if the only types you care about fall into the small handful he thought of. What about, say, IP addresses? Case-insensitive strings (such as e-mail addresses)? 6) If we're talking about canonicalization, TJSON does not say how to canonicalize decimal numbers. I suppose this stems from the author's mistaken belief that numbers in JSON are IEEE floats (they're not, regardless of what common broken parsers do). I hate to be so negative, but this really comes off as half-baked. EDIT: Looking at the spec [1] it seems to address some of these, but still indicates a strong confusion between data types (Unicode, rational numeric) and data representations (UTF-8, IEEE double). [1] https://github.com/tjson/tjson-spec/blob/master/draft-tjson-...