incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: Canonical JSON [Proposal for digital signatures of documents]
Date Mon, 09 Mar 2009 18:45:45 GMT

On Mar 9, 2009, at 2:12 PM, Chris Anderson wrote:

> On Mon, Mar 9, 2009 at 10:22 AM, Jens Alfke <>  
> wrote:
>> On Mar 8, 2009, at 4:51 PM, Antony Blakey wrote:
>>> OLPC has a start on canonical JSON:
>> Thanks for the link! I'd done a bit of searching for prior-art, but  
>> hadn't
>> run across that.
>> It's pretty close to my description. It looks good, except that
>> • They say that arbitrary byte sequences are allowed in strings.  
>> This is
>> really problematic (it makes it impossible to reliably convert JSON  
>> to an
>> in-memory JavaScript string object!) and contradicts the JSON spec,  
>> whose
>> third paragraph says that "a string is a  sequence of zero or more  
>> Unicode
>> characters".
>> • As I did, they say keys should be sorted in "lexicographic  
>> order". Like
>> me, they probably meant "code-point order".
>> The ban on floating-point numbers is sensible. I'd draw the line at  
>> banning
>> integers, though, as that tends to really complicate round-trip
>> transformations with in-memory objects. (Every int field has to be  
>> shadowed
>> as a string.)
> Quoting myself from the old thread - is a printf style formatter a
> reasonable compromise for floats?

The problem is floating point/text is a really difficult problem. I've  
butchered FP text conversion in Lotus Notes myself, it's way more  
complicated and subtle then I ever though it could be. While there are  
standardized algorithms, the reality is they are so many languages and  
libraries that have slight variations it's really hard to know when  
you got it right. You may have written a ton of tests and everything  
passes, but did you try it with "0.13421143112e-12" Because the bias  
tables in algorithm X is slightly different from algorithm Y, and none  
of your tests detect it. Yada yada.

If the numbers were sent as the raw hexidemical bits in the double,  
then there is no problem to fidelity. However, you can't look at that  
as a human and tell what the FP value is, and no json parser will  
understand it either. I understand why they punted and said "none  


>> The requirement not to use JSON numbers might be too stringent. The
>> other option is to have the signature state which form of number it's
>> working with. Basically this would be a function from the number to a
>> string.
>> Eg: all numbers in this signature were converted to strings using the
>> printf format "%4.2f" or somesuch.
>> This would allow signers to specify the precision that must be
>> maintained for them to consider the document representative of what
>> they chose to sign. So you might end up signing a document that would
>> be valid if transport lost some precision, but invalid if it lost too
>> much precision.
>> As long it rounds to "3.33" I'm good. If the JSON makes it all the  
>> way
>> to the other end, and still contains 3.3333333333 that may be better,
>> but it doesn't effect the signature.
> -- 
> Chris Anderson

View raw message