On Wed, May 27, 2015 at 4:24 PM, Joe Hildebrand <hildjj@xxxxxxxxxxx> wrote:
On 27 May 2015, at 13:53, Phillip Hallam-Baker wrote:
The CBOR data model is a superset of the JSON data model, so a trivial
translation of JOSE to CBOR is indeed trivial.
It is a rather complex superset.
It takes less code to parse than JSON, however, which is ironic. For those that haven't thought about the problem, consider this bit of valid JSON:
{ "one": 1e400, "on\u0065": "\udead" }
1e400 is bigger than most implementations can deal with. Are "one" and "on\u0065" the same thing? (yes) If so, what do you do about the duplicate key? (implementation-defined, non-interoperable) What do you do about the half surrogate pair \udead, since JSON is defined as an odd subset of UTF-16 that allows invalid 16-bit code units? (usually: generate an invalid codepoint and hope for the best)
These are not a problem in protocols since we almost never use floating point numbers. We do use decimals but those are rare as well.
Doing such a trivial mapping would be completely misguided, though, asI note that you still haven't answered my challenge on data encoding
CBOR has additional capabilities, and the efficiencies we need in the
constrained node network environment are indeed made possible by those
additional capabilities [1].
efficiency. My JSON-C encoding shows what can be achieved using the JSON
data model with only the addition of a binary blob data type. I posted the
encoding for the JOSE signing example shortly after Dallas.
I've just gone back and looked at draft-hallambaker-jsonbcd-02 again. I agree with you that JSON-[BCD] do a better job at segregating functionality that might be needed by different applications than CBOR does, at the expense of some implementation complexity and complexity on the part of the protocol designer picking which level to use.
The aim would be to leave these to deployment.
I disagree that there is a difference in the degree to which JSON-C differs from JSON than CBOR does. If you compare Table 1 and Table 2 of your doc to Section 2.1 of RFC 7049, for example, there's a lot of similarity.
Yes, there is a lot of similarity and had certain individuals been willing to consider external input we could have come up with one specification very easily.
The key difference is that JSON-C is doing string segment compression and a single dictionary can be used for any code point. There is no context sensitivity. That greatly reduces the complexity of writing encoder/decoders at a modest cost in space efficiency.
The ASN.1 OID references in your Section 5 would need to be both motivated better and better described before they would be interoperably implemented.
The reason I let that draft expire is I have been working on this one that eliminates the need for the ASN.1 there:
Basically it is a spec that generalizes OpenPGP fingerprints to allow other content to be digested in the same fashion without ambiguity.
If you wanted to do the work to turn this doc into one or more specifications that were ready to publish as RFCs, with more complete explanations and examples, then wanted to define a JOSE mapping into that set of specifications, I would fight for your right to do so (although probably wouldn't provide much technical help beyond reviewing for completeness).
Thanks.
However, I don't see any likely possibility that we could talk existing JSON implementations (such as those in browsers) into implementing these formats natively, so we're looking at completely new code for both parsing and generation. At that point, retaining any kind of compatibility with JSON doesn't provide a win, and retains all of JSONs interoperability issues.
Since the specs are supersets a JSON-D decoder will decode JSON, JSON-B or JSON-C. A JSON-C decoder, JSON-B and JSON and so on.
The advantage comes when you have nested structures. Say you have a JSON document and you want to include in another structure. You can copy across the bytes verbatim without worrying if they are JSON or JSON-B.