Re: [Json] "best practices" Vs. Profile for i-json

Phillip Hallam-Baker <ietf@hallambaker.com> Sat, 02 August 2014 14:58 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE121A0AF3 for <json@ietfa.amsl.com>; Sat, 2 Aug 2014 07:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQbktsq0f4I0 for <json@ietfa.amsl.com>; Sat, 2 Aug 2014 07:58:26 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69471A0AF1 for <json@ietf.org>; Sat, 2 Aug 2014 07:58:25 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id e16so4161534lan.11 for <json@ietf.org>; Sat, 02 Aug 2014 07:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ljhG5mxCTYPkVsh0cQWIYtdSvtC16amfixxHFA9GLSU=; b=KDEGXWgjxD4vwr7mEFZ0tjFBf00hSimJcZ0L3s9+gU7cDsEi5qV6l0awV6pgllu2N8 iQQGwSkk4ZgJCYvmQWZoYqgBb2Q+IhiA8qKy9FhpsNMvNmjxVfSLS+t37QWSC1BjJKLN krhZMpd/H+ZRQRfNy9lhigB16sVVJOjTdlrRZM/HZo11jvlgHrjR0ptwkFZi/8yN/2P2 hX6YxUlbk9E/f3CNH/3cpgh6KAUesiYY4j/Bef7e474qCceaVuYUQ8BOu5aa7BTRzhYk LjTFJObhtB+6av09fVmMyShMv90/gyRM/qAkiSIaM5mUpTOBrilEIxNjkdlE/Ga6RoMd Osuw==
MIME-Version: 1.0
X-Received: by 10.112.161.72 with SMTP id xq8mr12195860lbb.18.1406991503994; Sat, 02 Aug 2014 07:58:23 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.122.50 with HTTP; Sat, 2 Aug 2014 07:58:23 -0700 (PDT)
In-Reply-To: <20140802061129.GB13625@mercury.ccil.org>
References: <2d53157574f749e0b1399b9e39564ecd@BL2PR02MB307.namprd02.prod.outlook.com> <CAMm+LwhXmtYzs4wO-znptyQvrU9ci3LQvNREgyiSu7mJsOTXsA@mail.gmail.com> <20140802061129.GB13625@mercury.ccil.org>
Date: Sat, 02 Aug 2014 10:58:23 -0400
X-Google-Sender-Auth: lSTXZGVDieMaduhcNOgDuxWCxqo
Message-ID: <CAMm+LwgirNk0uDpHT8xMa66wbnOeggiJ=bOcK8HDpAMiJjuXNA@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
To: John Cowan <cowan@mercury.ccil.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/json/HheqpinjRxPxrUlVeTqJ5LtX3N0
Cc: IETF JSON WG <json@ietf.org>, Larry Masinter <masinter@adobe.com>
Subject: Re: [Json] "best practices" Vs. Profile for i-json
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Aug 2014 14:58:27 -0000

On Sat, Aug 2, 2014 at 2:11 AM, John Cowan <cowan@mercury.ccil.org> wrote:
> Phillip Hallam-Baker scripsit:
>
>> Not happening unless we move to a binary encoding or a binary exponent
>> encoding. To round trip the floating point between binary and decimal
>> exponents is ridiculously non-trivial.
>
> I don't say it's trivial, but it *is* a solved problem, if by "round
> trip" you mean "guarantee that what one implementation writes, another
> implementation reads as the same float."  The current C and C++
> standards require round-trippability in this sense.

Its not a problem that can be solved in an IETF spec by referencing
another spec.

At the very minimum, code is required. But if it is going to be any
use in practice we would need to validate each implementation which is
hard and there will be many non-compliant implementations around and
no way to know which is which.

IF this is a requirement then extending the spec to include a direct
representation of binary exponent floating point is the only way to be
sure it can be relied on.