Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 74.125.44.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=LYFmqdfkxxro2lAe9tQbn5MjxLLLrMXp92V2cA9rcSuK+GD+uFHVlAtdN/TPzObcb/
         nieA+SGyRCj5NwOg3mjCZ90nmNF8xF/cDzGfXmI/OrKrO8br5c6oCfIcrbSGoc7YlSKI
         6GDIWYeugGD9si/9cpJ6BNMIm2VwIxxFkjFUQ=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <C69AD3E6-FB72-4906-86F4-59E643397824@mooseyard.com>
References: <283A6EDD-6701-4A6A-88AE-8B97E6D11D9E@mooseyard.com>
	 <B9C0BDBB-27A5-45C8-9CBF-A3506EB3FB13@gmail.com>
	 <C69AD3E6-FB72-4906-86F4-59E643397824@mooseyard.com>
Date: Mon, 9 Mar 2009 11:12:37 -0700
Message-ID: <e282921e0903091112i622dc80ax39ee1fa5f6ed18f2@mail.gmail.com>
Subject: Re: Canonical JSON [Proposal for digital signatures of documents]
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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
>
> =95 They say that arbitrary byte sequences are allowed in strings. This i=
s
> 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 =A0sequence of zero or more Unic=
ode
> characters".
>
> =95 As I did, they say keys should be sorted in "lexicographic order". Li=
ke
> me, they probably meant "code-point order".
>
> The ban on floating-point numbers is sensible. I'd draw the line at banni=
ng
> integers, though, as that tends to really complicate round-trip
> transformations with in-memory objects. (Every int field has to be shadow=
ed
> 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.


--=20
Chris Anderson
http://jchris.mfdz.com