<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 5:57 PM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</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"><span class="">On 27/02/2015 16:08 pm, Ladar Levison 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">
Hi,<br></blockquote></span><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"><span class="">
1. While I’ve identified the majority of the functionality associated<br>
with the access protocol (DMAP), my attempts to document the specifics<br></span>
keep getting sidelined by a single question: */should DMAP be a line<span class=""><br>
based protocol, like IMAP (and POP, and SMTP), or should it be designed<br></span>
as a JSON-RPC protocol, like the Magma camelface, or JMAP?/* See:<br>
<br>
<a href="https://github.com/lavabit/magma.classic/raw/master/docs/magma.web.api.pdf" target="_blank">https://github.com/lavabit/<u></u>magma.classic/raw/master/docs/<u></u>magma.web.api.pdf</a><br>
</blockquote>
<br>
<br>
For my money, binary.  Line-based or JSON are good if you are working with lots of random implementations of low quality, but for security work, it is easier to work in binary.  Be precise about sodding everything.<br></blockquote><div><br></div><div>+1</div><div><br></div><div>BUT!</div><div><br></div><div>Pretty much the whole Web Services world is going to JSON because it is a simple data model that is widely supported. Unlike XML there is pretty much only one way to serialize a data stream on the wire rather than fifty.</div><div><br></div><div>Which is why some of us suggested that we would like a binary encoding for the JSON data model so that an encoder could emit either and a decoder could read either.</div><div><br></div><div>I wrote this up as:</div><div><br></div><div><a href="https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/">https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/</a><br></div><div><br></div><div>JSON only uses 7 bit ASCII code points for control data. That leaves 128+ data points for tagging binary data types which is more than enough.</div><div><br></div><div>All that is really essential to encode crypto data nicely is an option to encode text strings and data blobs as length-data items. JSON-B adds those plus binary integers and floats. There is also a compression option to allow the text headers to be dispensed with and a data variant with more floating point types.</div><div><br></div><div><br></div><div>For security reasons, only atoms are encoded in length-data format. Lists are delimited by an end list control. This produces much more reliable coding and avoids read past end of buffer errors.</div><div><br></div><div>In particular, a decoder can verify the syntactic correctness of each token in the stream in a single pass using only the data previously read. Checking correctness of an ASN.1 file is a real horrorshow because an inner length encoding can be inconsistent with either an outer or an inner one.</div><div><br></div><div><br></div><div>PHB</div></div></div></div>