<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 17, 2014 at 4:03 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">If you're interested in this sort of thing, you should have a look at JSON Web Encryption:<div>
<br></div><div><a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-21" target="_blank">http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-21</a><br>

</div><div><br></div><div>...although I can't say I'm really a fan. It seems ugly to me.</div></div></blockquote><div><br></div><div>That is in part what motivated the initial work. The problem with the JOSE encryption work is that if you have nested encryption/signature sections you suffer a cumulative 33% inflation per pass. </div>
</div><div><br></div><div>So what I started with was 'I just want to be able to do normal JSON framing but be able to write out a binary chunk efficiently as a length encoded blob'.</div><div><br></div><div><br></div>
<div>One consequence of my approach is that it is very easy to switch between the text and binary encodings. Which means that you can use the text version in the documentation knowing that it is semantically equivalent to the binary. And you can have tools that interpret the binary and dump out text.</div>
<div><br></div><div>On Mon, Feb 17, 2014 at 4:46 PM, Theodore Ts'o <span dir="ltr"><<a href="mailto:tytso@mit.edu" target="_blank">tytso@mit.edu</a>></span> wrote:<br></div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:16px">>Have you looked at RFC 7049?  Paul Hoffman pointed me to it off-list,</span><br style="font-family:arial,sans-serif;font-size:16px">
<span style="font-family:arial,sans-serif;font-size:16px">>like your I-D, it's closely aligned to the JSON model.  There is also</span><br style="font-family:arial,sans-serif;font-size:16px"><span style="font-family:arial,sans-serif;font-size:16px">>an Apache 2.0 licensed implementation available:</span><br>
</div><div><br></div><div>Yes, it is not a good piece of work. Unfortunately Paul was far more interested in ramming it through the process than listening to anyone's requirements other than his own. Each time a requirement was raised, his response was 'this is a private matter, none of your business, go write your own'. Which is why I appealed the standards track designation.</div>
<div><br></div><div><br></div><div>CBOR is not closely aligned with JSON, it is a new data model which means that it is rather less interesting than BJSON which does at least have millions of MongoDB users and is much closer to the JSON model.</div>
<div><br></div><div>The problem here is that a new encoding only has value if it has a chance of becoming ubiquitous which means meeting all the requirements that are regularly raised for encodings. So going off into a private 'members only' club to write the spec removed the main potential benefit. As did moving it through the process so fast that there was no time to get buy in from the people who might adopt it in significant platforms as the default.</div>
<div><br></div><div>So instead of one definitive binary encoding we have another binary encoding to add to the five that existed and were in use before the work started and one that is not even based on the JSON data model.</div>
<div><br></div><div><br></div><div>For a new encoding to become a natural extension to JSON it has to be easy for someone to take their existing JSON encoder/decoder and adapt it to support the new encoding types. And it has to be backwards compatible.</div>
<div><br></div><div>CBOR requires a whole new encoder which is a very different model.</div><div><br></div><div>I did manage to convince them that it had to be possible to write data out in chunks but they punted on the hard problems by making it extensible. One of the main lessons of JSON is that a data encoding should not be extensible or have versions. </div>
<div><br></div><div>JSON-B is not an extension to JSON, it is a new encoding that is a superset of JSON - a different thing entirely. What this means is that when doing content negotiation, the features are all or nothing. Either a decoder understands the encoding or it does not. Having optional extensions that might or might not be understood is a recipe for disaster.</div>
<div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>