incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Canonical JSON [Proposal for digital signatures of documents]
Date Mon, 09 Mar 2009 18:12:37 GMT
On Mon, Mar 9, 2009 at 10:22 AM, Jens Alfke <jens@mooseyard.com> wrote:
>
> On Mar 8, 2009, at 4:51 PM, Antony Blakey wrote:
>
>> OLPC has a start on canonical JSON:
>> http://wiki.laptop.org/go/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 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
http://jchris.mfdz.com

Mime
View raw message