On Wed, May 27, 2015 at 6:56 AM, Carsten Bormann <cabo@xxxxxxx> wrote:
On 23 May 2015 at 04:16:00, Nico Williams (nico@xxxxxxxxxxxxxxxx) wrote:I should clarify that my objection is to a working group IF a JOSE->CBOR
mapping is trivial enough,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.
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.
What your constrained node example needs is a better encoding for JSON, not the introduction of yet another encoding for a random data model.
So the main work of the WG will simply be about how exactly to use those capabilities. (It all looks trivial on a napkin, but a few bikesheds still have to be painted.) Any other hypothetical approach that adds binary capabilities to the JSON data model will need to do this kind of work, bold statements to the contrary notwithstanding.
My encoding is generated entirely mechanically. Switching from a text encoding to binary means simply choosing a different encoding method. Using compressed tags is slightly more complicated in that a dictionary has to be compiled, but that is at worst a registration effort.
I repeat that no Working Group effort is required or desired for applying the encoding to JOSE, ACME or any current or future JSON spec.