On Wed, May 27, 2015 at 4:24 PM, Joe Hildebrand <hildjj(_at_)cursive(_dot_)net>
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, as
CBOR has additional capabilities, and the efficiencies we need in the
constrained node network environment are indeed made possible by those
additional capabilities [1].
I note that you still haven't answered my challenge on data encoding
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:
https://tools.ietf.org/html/draft-hallambaker-udf-00
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.