Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF

Ulysse Carion <ulysse@segment.com> Sun, 01 September 2019 22:19 UTC

Return-Path: <ulysse@segment.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDA61200C5 for <json@ietfa.amsl.com>; Sun, 1 Sep 2019 15:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com
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 F3RBNamE5mp4 for <json@ietfa.amsl.com>; Sun, 1 Sep 2019 15:19:51 -0700 (PDT)
Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770361200CD for <json@ietf.org>; Sun, 1 Sep 2019 15:19:51 -0700 (PDT)
Received: by mail-io1-xd42.google.com with SMTP id h144so10194776iof.7 for <json@ietf.org>; Sun, 01 Sep 2019 15:19:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AYZ11rpGeT4RHPq+AQyssOgA2rPOUyl2EXNcJmWtEGY=; b=BnhHO2t/2tz3z/nnv0Ll4+8BhbKkhJm1w0b+bU5zekdRBaE9G5znfHErOpGGfViJV3 YxI9xLJGJnlndKQOYO4uPGm5BHQHhUKPN0qBf1tgbP6oxzKtqe9uctEZXj0DqlAvTf// wN78NXAn2DR2CkyzVByNPalngT1F4SymELCNY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AYZ11rpGeT4RHPq+AQyssOgA2rPOUyl2EXNcJmWtEGY=; b=O9nsVf8eiQu8vZI6KFvS8AHNH1vm9Egukrpf/2b8A6oAlaFzndfZxMJTdvZ4LbmY0p A7b90BmeKuPQxM9lZmXXKUuDEKwk4MVr6YI5vZTBbgVho2OESCoozgsbK9QIGofU+IN7 FtsTuiQHlkrsjTdbiphMtvMO0xyFsAm5OVXXFplr2JYQeE0mS6h+T9aJuz7jJs/U00fZ DpWrFFjuNlO6yMxKN04uWK7wNKTYslV5IgbVpmV3aLuxeiXC9SCZGNP/Hi4PRgOvT/Cw mLY1YDzH2P5RINCQZvBfDmdSZGksOX3V+mNIBGRN4utR80HsG3N2TSxSkxcmLImFLTS1 3Nsw==
X-Gm-Message-State: APjAAAXN1kVwwRfyCQREaDGEkwacuQHdwLxXk+rUVoJXzGpwS9+qAxjt wVCMFZNnANi/3fcGe+TuFWLlrBHl9+Or0aoRSCS/EQ==
X-Google-Smtp-Source: APXvYqwnPV4SpQ22A+97mxQhtcTX6T0/TNwQ+moGpu5PytQsh3tutidOnrP+xCNUnX+I3o5EwKMMhW1ZHEFTjr9jqpw=
X-Received: by 2002:a6b:b4c7:: with SMTP id d190mr6149170iof.209.1567376390668; Sun, 01 Sep 2019 15:19:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAJK=1Rj6zW_MffKvsOiQh28KY5yDeoALGSYqve+vGj52s1Owag@mail.gmail.com> <SY2PR01MB2764EDAB3DD01417A95A26D5E5A20@SY2PR01MB2764.ausprd01.prod.outlook.com>
In-Reply-To: <SY2PR01MB2764EDAB3DD01417A95A26D5E5A20@SY2PR01MB2764.ausprd01.prod.outlook.com>
From: Ulysse Carion <ulysse@segment.com>
Date: Sun, 01 Sep 2019 15:19:39 -0700
Message-ID: <CAJK=1RhFnTqa+9b5M_WrPiEVg_+Prkv_+pazg8y1vACD7PXAkw@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Cc: JSON WG <json@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/mKp_yusFg_T-d3ykJSMQ8vfAzaA>
Subject: Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 01 Sep 2019 22:19:54 -0000

> JDDF offers "type":"uint8" but very common languages, such as Java, don't have an unsigned 8-bit type. So code generation might use a short (16-bit signed integer) to handle the [0, 255] range. That seems to put the code in a very similar situation to using a long when the JDDF says "int54". In both cases the native type can hold values that the schema doesn't allow, requiring extra parse/stringify functions if you really want to enforce the schema's rules.

This isn't quite right. Yes -- Java only has "byte", but by convention
you can store both signed and unsigned 8-bit numbers in these bytes.
Protobufs does this:

> [1] In Java, unsigned 32-bit and 64-bit integers are represented using their signed counterparts, with the top bit simply being stored in the sign bit.

Source: https://developers.google.com/protocol-buffers/docs/proto#scalar

Furthermore, the Java standard library has methods that explicitly let
you do the conversion of a Java byte-as-uint8 into a Java int or long:

https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsignedInt-byte-
https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsignedLong-byte-

If bytes-as-uint8 weren't conventional, then why does java.lang.Byte
have methods that enable such a style?

This is why, in my view, it's reasonable to say that uint8 has a clear
correspondence to Java's byte.

>> I didn't see any support for binary data

> Suggested extra types:
> * "type": "intString" -- an integer exchanged in decimal notation as a JSON string, with no decimal point or exponent. (maybe only offer "int64String" instead, if it is only 64-bit values that typically use this format)
> * "type": "uintB64u" -- a (non-negative) integer (potentially huge, as often used in cryptography) exchanged as a JSON string holding the base64url-encoding (without padding) of an unsigned big-endian representation of the integer. (may need a comment about gracefully accepting leading 0 bytes).
> * "type": "bytesB64" -- a byte array exchanged as a JSON string holding its base64-encoding
> * "type": "bytesB64u" -- a byte array exchanged as a JSON string holding its base64url-encoding (without padding)

I think I'm opposed to this suggestion. Adding support for arbitrary
binary data is going to be challenging. I think I prefer that we just
stick to {"type":"string"}, and then folks can write their own
extensions to JDDF to achieve their specific needs. After awhile, the
community may perhaps converge on common extensions, or patterns may
arise and we can update the JDDF spec.

Anything we add to the spec now would have to be supported by all
implementations. So I'd prefer we give out a minimal spec to the
world, and see where the real world takes it. If we try to solve all
problems right away, we may make it too hard for implementations to
crop up, ultimately solving no problems for anyone.

On Thu, Aug 29, 2019 at 12:42 AM Manger, James
<James.H.Manger@team.telstra.com> wrote:
>
> > https://tools.ietf.org/html/draft-ucarion-jddf-00
> > ...
> > I fear we may be at loggerheads on the question of {"type":"int53"}.
>
>
> JDDF offers "type":"uint8" but very common languages, such as Java, don't have an unsigned 8-bit type. So code generation might use a short (16-bit signed integer) to handle the [0, 255] range. That seems to put the code in a very similar situation to using a long when the JDDF says "int54". In both cases the native type can hold values that the schema doesn't allow, requiring extra parse/stringify functions if you really want to enforce the schema's rules.
>
> >> I didn't see any support for binary data
>
> Suggested extra types:
> * "type": "intString" -- an integer exchanged in decimal notation as a JSON string, with no decimal point or exponent. (maybe only offer "int64String" instead, if it is only 64-bit values that typically use this format)
> * "type": "uintB64u" -- a (non-negative) integer (potentially huge, as often used in cryptography) exchanged as a JSON string holding the base64url-encoding (without padding) of an unsigned big-endian representation of the integer. (may need a comment about gracefully accepting leading 0 bytes).
> * "type": "bytesB64" -- a byte array exchanged as a JSON string holding its base64-encoding
> * "type": "bytesB64u" -- a byte array exchanged as a JSON string holding its base64url-encoding (without padding)
>
> --
> James Manger