From nobody Sun Sep 1 15:19:55 2019 Return-Path: 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 ; 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 ; 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 ; Sun, 1 Sep 2019 15:19:51 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id h144so10194776iof.7 for ; 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: In-Reply-To: From: Ulysse Carion Date: Sun, 1 Sep 2019 15:19:39 -0700 Message-ID: To: "Manger, James" Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 bo= th cases the native type can hold values that the schema doesn't allow, req= uiring extra parse/stringify functions if you really want to enforce the sc= hema'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 th= eir signed counterparts, with the top bit simply being stored in the sign b= it. 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#toUnsignedLon= g-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 JS= ON string, with no decimal point or exponent. (maybe only offer "int64Strin= g" instead, if it is only 64-bit values that typically use this format) > * "type": "uintB64u" -- a (non-negative) integer (potentially huge, as of= ten 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 i= ts 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 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 bo= th cases the native type can hold values that the schema doesn't allow, req= uiring extra parse/stringify functions if you really want to enforce the sc= hema's rules. > > >> I didn't see any support for binary data > > Suggested extra types: > * "type": "intString" -- an integer exchanged in decimal notation as a JS= ON string, with no decimal point or exponent. (maybe only offer "int64Strin= g" instead, if it is only 64-bit values that typically use this format) > * "type": "uintB64u" -- a (non-negative) integer (potentially huge, as of= ten 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 i= ts base64-encoding > * "type": "bytesB64u" -- a byte array exchanged as a JSON string holding = its base64url-encoding (without padding) > > -- > James Manger From nobody Sun Sep 1 15:28:12 2019 Return-Path: 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 D8CE71200DF for ; Sun, 1 Sep 2019 15:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 rUKY2RU7j3w3 for ; Sun, 1 Sep 2019 15:28:09 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 460C712008F for ; Sun, 1 Sep 2019 15:28:09 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id j4so25502561iog.11 for ; Sun, 01 Sep 2019 15:28:09 -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; bh=Fry7kUhQbI7BRkrdlLCTrn4FfGTbdzAdFftFvn9UrYE=; b=bVkQP8ztvu9B2vCV89EFwlCnKf5O3SHCdwZToZJ4q66uRb2zW+vLN1EnlsELwk08rn OznE7MF0BDNWKpiCWwZcwHoQtu4vhpICmNp9eKmpDDqkXDqUTs6ifD7Nf2Aw2PBkM+kV eV8N53Ktc6IRouhb220KEPeCqqzf6hIK+BiAo= 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; bh=Fry7kUhQbI7BRkrdlLCTrn4FfGTbdzAdFftFvn9UrYE=; b=dzFLWrRwetwU3HCoUEKyQfsuSDSZZ4O94nKRGRHP6x1sw09Fp91YtdFn1EgRdSOYRg q8EX8RBn/gPMGuzNdLTbRFNnzWflFgJ2UluIXh8t8BQSja6NiPKOUUcqZj7bcZpASryf 69LwVV+P5+JRsnDyXFPZ8+b6BLvRSFNZca6bOah7wSCj7ZYbRZMppagn1lyaF2Jte8jV PX2rO6HDaTDYltsJe+kVUBF7x3jtu/Iu+KM54pxzw//pMWjBl/TC0PGj7WPjFumTezKm geFpbrYyPXZlWTPEHcg8eqVjG/3ZC7sgs9A4bV1forMk0VAaCWP5vcv9EEHkC+UnXU+/ gKgA== X-Gm-Message-State: APjAAAWdF6CZzSIQE/NKYsLbljtrK3PkyoqNEweZbGnkLGyNhl7Docua W6oApvmmVVXz/hTHq24xX/SPDBS+WUQx3EZl2VY9z9rUAhQ= X-Google-Smtp-Source: APXvYqxEz8JLuDs7wXqC1Kr6k39OLNvhyB+BochtnFSh3F4YTx4CI1SZWwizbWuZ/C7aCQT9hXvf9CGla3KbfDzwWcM= X-Received: by 2002:a02:c652:: with SMTP id k18mr21712063jan.44.1567376888395; Sun, 01 Sep 2019 15:28:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Sun, 1 Sep 2019 15:27:57 -0700 Message-ID: To: John Cowan Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 22:28:11 -0000 Fixed-length strings and arrays both sound like things one could implement with extensions, no? Tuples are a very sensible suggestion. But I wonder if we can live without them? I very much want to keep JDDF as small as possible. From nobody Sun Sep 1 15:42:08 2019 Return-Path: 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 5904812008F for ; Sun, 1 Sep 2019 15:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=ccil-org.20150623.gappssmtp.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 obK0hdDNKVyn for ; Sun, 1 Sep 2019 15:42:04 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 5096F120074 for ; Sun, 1 Sep 2019 15:42:04 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id c10so666767wmc.0 for ; Sun, 01 Sep 2019 15:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Wu2F9EY8oSzLFNzYj86IQUK4cD0jXmHL3GTJPYykg4=; b=EaMeq9BF8Wj/0i6c9SK5hU+6NLXAP28OOqwe5r7ruJnpwDfg5BFoyJg4txDETO06y5 Z38TrAPhgTSKlheMVmfBPg5chpE1jQpYKWVTgShN6vdzOU81VlmHrS/fs3X8Gs36+W2R JcptZtYjfxcTlU1VcUN+HZNVwqaGEAnCaXowPSK3WGcafDK2tx/y8BqH731d3uqQpquA tbk+9oJKYf1rf3YNTjRHvvayfcdZE2NUQ6mpgMZ5v68hojIOzHq9bKOFCyhQilTvct4g J/EarZN3d6ysGl0ijKa441PBVaFwVtRPsYPRFhJb5dRSvFSv7EMESRL0DBtVUapgO7hj Cs4Q== 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; bh=3Wu2F9EY8oSzLFNzYj86IQUK4cD0jXmHL3GTJPYykg4=; b=Y0zOdhY6v0e1N9AbEZ9LvxdSEAO6H2aB1Xv14qiSgqMr0aawcKOmBReFXRhM8+FtrM l+/gptaT3BaJN01TBI/cSSoLiwgyiTiyobpRLvZ4MOHcoXKeoYHlTsTLUQZ6ObTZBFv0 Ah+yddmDlpPcRbxqrf8YWcmxrOH6wQIIwGZSwhWZKq2XiLeM048P9E7BwJKZTT/shQZf xkktnN40ylL+L38w0JIjWWuY51Gs4Dhxe+6zm4fQIXXiblC7nOj3mvYR4hLQX8owoTO+ TOgqOZWXsiRz0P2GBQDnPdETemnNIsC+r9okV/4N/jTLyoXYGef1JHpTqSZACY9vXUuc r9KQ== X-Gm-Message-State: APjAAAUG6rvrJY2SIBHMpwWKJZguhyR1urEqP+O4midCAi5MX2cTyBGC LZelvC2oXVfNhGdRr5qCrofsl+zt1qN6epBhyZlilQ== X-Google-Smtp-Source: APXvYqwp8t1uC/l+eWFy92ecE3OEWobToXodane1SIR+D2xtCzWG62tsrmu3sbKcvYF1HuAfAkdwkL6onDCau1jqqHI= X-Received: by 2002:a1c:9889:: with SMTP id a131mr11231817wme.38.1567377722842; Sun, 01 Sep 2019 15:42:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Cowan Date: Sun, 1 Sep 2019 18:41:50 -0400 Message-ID: To: Ulysse Carion Cc: JSON WG Content-Type: multipart/alternative; boundary="00000000000066396b05918590b9" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 22:42:06 -0000 --00000000000066396b05918590b9 Content-Type: text/plain; charset="UTF-8" Section 2.3 says that extensions can't be validation-related, so a length limitation would most certainly be a matter of validation. On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion wrote: > Fixed-length strings and arrays both sound like things one could > implement with extensions, no? > > Tuples are a very sensible suggestion. But I wonder if we can live > without them? I very much want to keep JDDF as small as possible. > --00000000000066396b05918590b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 2.3 says that extensions can't be validation-r= elated, so a length limitation would most certainly be a matter of validati= on.

On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion <ulysse@segment.com> wrote:
Fixed-length strings and arrays both sound= like things one could
implement with extensions, no?

Tuples are a very sensible suggestion. But I wonder if we can live
without them? I very much want to keep JDDF as small as possible.
--00000000000066396b05918590b9-- From nobody Sun Sep 1 16:03:46 2019 Return-Path: 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 0664A1200C5 for ; Sun, 1 Sep 2019 16:03:45 -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 m4Lkv2cO1CvE for ; Sun, 1 Sep 2019 16:03:43 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 E2502120074 for ; Sun, 1 Sep 2019 16:03:42 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id b136so1517655iof.3 for ; Sun, 01 Sep 2019 16:03:42 -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; bh=N3KIwb++/xHyYCdwdiMHRHT+XRbKiWy3Kb0azerPD0o=; b=fYLk5hWnqvJNB2ADlVQbbiZJeEaXuQf3t+T1Ti8sEK5BwvLzOIexZSW0SrjGYMjQok 5Cp6Jxg3ftOHZnL6wfUNpPDOtvXvcIS3Kcc4LJAcH3ciIism5Yo3UshQjaelr++ij5id OSeV3IdgRbhzLpxn1N4hCISqmbCDhmG2jLQek= 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; bh=N3KIwb++/xHyYCdwdiMHRHT+XRbKiWy3Kb0azerPD0o=; b=VHvCWTCdeGvSsQDcwZdzuOBQRjJwfu697Doyb8ODxgVLjIW7NFujUYZt85zyAHdDOD kALsgXCL0H3J9mv5cEwlB+jGRWwi1fAfVcPdNSCmPLlcJM56+3PNf9pnoVEQX895CetU I4AwTBi0B5ESmAZzZq4pK3Zch5x2FgfOhEN3JcpwFAUh6cgcpkdxjh3yMOSIoXzaMMpM 6szDQeKTYcpUZojgEdzu1SqyYXpt3Iuplluj6499c8Y7BjmPRn9PoEL7QIyHFZo9dQvj KWD6JCsCtmcneHZVvXhMXLZFMxktSKU5h7YzSuPUHVkkX5Q35haqYbrCpq3+Sd6x7EDp Ao1A== X-Gm-Message-State: APjAAAUVE/AKLt7e1SfERXsGoXiOlN4yqKLRRi5N8QEExRV7jxZlxc0x NYb+9iYNaaJkJeyWPjfae8QKtW+8VeMeRdUp/64Uzw== X-Google-Smtp-Source: APXvYqzxmAfK+NNebUw1otl7WOtZyLaBr3LgvffAEiyAxMcFqJgZCmmXFAhv9yHcvmfKw86DDiZmfoa5SO/Fl+nysCU= X-Received: by 2002:a02:65cd:: with SMTP id u196mr1440254jab.3.1567379022049; Sun, 01 Sep 2019 16:03:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Sun, 1 Sep 2019 16:03:31 -0700 Message-ID: To: John Cowan Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 23:03:45 -0000 Sure -- but you could use the length validation as a hint to code generators, and a warning to data producers that the application will, post JDDF-level validation, do additional length checks. I'm not sure the need for length validation is strong enough to merit its inclusion in this version of the spec. On Sun, Sep 1, 2019 at 3:42 PM John Cowan wrote: > > Section 2.3 says that extensions can't be validation-related, so a length limitation would most certainly be a matter of validation. > > On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion wrote: >> >> Fixed-length strings and arrays both sound like things one could >> implement with extensions, no? >> >> Tuples are a very sensible suggestion. But I wonder if we can live >> without them? I very much want to keep JDDF as small as possible. From nobody Sun Sep 1 16:14:46 2019 Return-Path: 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 53F611200C5 for ; Sun, 1 Sep 2019 16:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=ccil-org.20150623.gappssmtp.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 z5CoEIRAOwsJ for ; Sun, 1 Sep 2019 16:14:43 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 D21AF120074 for ; Sun, 1 Sep 2019 16:14:42 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id p13so12755620wmh.1 for ; Sun, 01 Sep 2019 16:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=598G2BABrSf6ZLQlwLt4lZS4gVA/5/bhjHJvvQbWHz0=; b=BCnIn6vyDyKDOzXhHxjXsAosRZAEnz/Pl70WF6d2JgYiDjtUE5hZ478y9xaSYFzOUa rjcdv2Mgx3Ek+N5JKH4FBFViNzOb64kXJEta2Y+RaYtLFnKTFAjuX3nJdqpyVDagJPRg gF7tbQMX1NVqcPn4xTVimGvwhIQ3kP9wchOd5k/7vDCDkw14a7OS4VlRkhYhilNefbx8 SLBphx1dhQh9VQJy7nL4f8GACt8y8xD6l+44zjKKfN7YGe5XeKapG9m43H74+eqBRo0g CbBG08j87DRwUHZs6UitsXrJuCL/PSLqwNiyMCtXExPm8bgUs4qBIL3l/c9QUeBgYvhE FNjg== 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; bh=598G2BABrSf6ZLQlwLt4lZS4gVA/5/bhjHJvvQbWHz0=; b=TbykJbI0k6JnG4B9XSthJfrdgw6VQQOXMghHFwG2L3k1RWMRUc9PacMM4weN9jfVmS mGjA4ul4cKzZ2S9B/jLOw254NRSeRNzAQfkZA8Ca7UnJviTDE62pDpS7Yk2XEeSacwLh XkdfvVBIRy+QL/4bFlnaecndDecpnSRSVEpFYD5gwN0Ofg5nyH2h2CELxaWW3/JTE6PY yDr6DDiVFYtQU7n9OLZbhjuF7y3QfTFEywUC1MRLAuQEIeHCBhyf9zO7ZPLLXQ4xH+hD nZG1AlxO0NaGkGkzMtEtaBLt5R67DfSX1egY+uBgyccSusceX6jlmOsNFFF4E5fQP34i lMsA== X-Gm-Message-State: APjAAAVon4fTw/2jtbeSEct9f6+T59EvK7nv7R571/fhEkUo2wol6PPf Dcjnq32jICWMl50igaAnzOyByqFty35oJhegiRceAPlqspI= X-Google-Smtp-Source: APXvYqwvVHnjZiPoCxHtpClQb8OLQvm2YfkLxul8of6A0gx4TO5/3j1dlfnRT7K5+IQAd4Qo+WdN8qeRbnV0ev0uHsg= X-Received: by 2002:a1c:96c6:: with SMTP id y189mr24642871wmd.160.1567379681343; Sun, 01 Sep 2019 16:14:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Cowan Date: Sun, 1 Sep 2019 19:14:28 -0400 Message-ID: To: Ulysse Carion Cc: JSON WG Content-Type: multipart/alternative; boundary="000000000000229bab05918605bd" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 23:14:45 -0000 --000000000000229bab05918605bd Content-Type: text/plain; charset="UTF-8" The argument for it is precisely in situations where static allocation is required along with static typing. If you know the (maximum) length, you can safely allocate a fixed amount of memory for your internal representation, which you cannot do otherwise. Languages with static types and garbage collection (allowing dynamic allocation) are just one particular kind of languages, and I think you need to accommodate all widely used kinds of languages. I wouldn't object to skipping bounded arrays and strings in favor of just fixed-length ones. See < http://www.catb.org/esr/microjson/>, a JSON-subset parser written in C that imposes exactly this restriction so that it can run safely on embedded systems with only small amounts of RAM. On Sun, Sep 1, 2019 at 7:03 PM Ulysse Carion wrote: > Sure -- but you could use the length validation as a hint to code > generators, and a warning to data producers that the application will, > post JDDF-level validation, do additional length checks. > > I'm not sure the need for length validation is strong enough to merit > its inclusion in this version of the spec. > > On Sun, Sep 1, 2019 at 3:42 PM John Cowan wrote: > > > > Section 2.3 says that extensions can't be validation-related, so a > length limitation would most certainly be a matter of validation. > > > > On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion wrote: > >> > >> Fixed-length strings and arrays both sound like things one could > >> implement with extensions, no? > >> > >> Tuples are a very sensible suggestion. But I wonder if we can live > >> without them? I very much want to keep JDDF as small as possible. > --000000000000229bab05918605bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The argument for it is precisely in situations where stati= c allocation is required along with static typing.=C2=A0 If you know the (m= aximum) length, you can safely allocate a fixed amount of memory for your i= nternal representation, which you cannot do otherwise.=C2=A0 =C2=A0Language= s with static types and garbage collection (allowing dynamic allocation) ar= e just one particular kind of languages, and I think you need to accommodat= e all widely used kinds of languages.=C2=A0 I wouldn't object to skippi= ng bounded arrays and strings in favor of just fixed-length ones.

<= /div>
See < http://www.catb.org/esr/micr= ojson/>, a JSON-subset parser written in C that imposes exactly this= restriction so that it can run safely on embedded systems with only small = amounts of RAM.=C2=A0


On Sun, Sep 1, 2019 at 7:03 P= M Ulysse Carion <ulysse@segment.com> wrote:
Sure -- but you could use the length validation as a hin= t to code
generators, and a warning to data producers that the application will,
post JDDF-level validation, do additional length checks.

I'm not sure the need for length validation is strong enough to merit its inclusion in this version of the spec.

On Sun, Sep 1, 2019 at 3:42 PM John Cowan <cowan@ccil.org> wrote:
>
> Section 2.3 says that extensions can't be validation-related, so a= length limitation would most certainly be a matter of validation.
>
> On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion <ulysse@segment.com> wrote:
>>
>> Fixed-length strings and arrays both sound like things one could >> implement with extensions, no?
>>
>> Tuples are a very sensible suggestion. But I wonder if we can live=
>> without them? I very much want to keep JDDF as small as possible.<= br>
--000000000000229bab05918605bd-- From nobody Sun Sep 1 16:24:39 2019 Return-Path: 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 45EF01200BA for ; Sun, 1 Sep 2019 16:24:38 -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 ZMwj6Oi1nRXx for ; Sun, 1 Sep 2019 16:24:35 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 D55F5120074 for ; Sun, 1 Sep 2019 16:24:35 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id r4so10466584iop.4 for ; Sun, 01 Sep 2019 16:24:35 -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=0be5OsPz6HRQK44CDE2qvZkfnp/zSf6C8XZihCbs3jQ=; b=lq6tOJsqIgYHryzTS3cetHilnXlEwV7xnog3uaGBorx9zUI6YzHQUyaprWej80OB+Y H7izokYY76oNcwPTJhdnKiGEgSvdkvHWlPSA1dHCmUdSlHJAeYUiMZKJrevkoBwexoqs 2qhzDUTcFZyYFAqOHOuo1q69/Q6bxF8qfwfBY= 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=0be5OsPz6HRQK44CDE2qvZkfnp/zSf6C8XZihCbs3jQ=; b=tm9IMU/463Beb3ZoIa9RPfxaOw9ebt8DXAa4LR2G2yi9u4kc51pPA4IdUtNGbHEHD1 hgJX92FX9rcjmsTIDnh4S46pMSKxwMhsE3Gh1DEPOOVQODZD1uQ69pRDh0giLbNbDdvO YYBazlY8Y8l0MDJPzWLi0jxi1XaiBHn2PGw5stPyaeWNqbkjC4KYJzo//2oLfFBMTZ74 aVYQGz2M5uGFruyqUjI4TOzYgPTF0KXwofEliDJ5qsKoHyddhAdANHYFs4sgfBfMsyoG WueVfC68oJniWh+PLIOKyKq9nVmAPW9i8TK40r2tvFZoHwFtzl6zLOERz21UOYmNgWZq gIuQ== X-Gm-Message-State: APjAAAX6x9YkUkQZpTLl2Kk39lsmni51gG2JLcRkk1mSTpsG3ddIG4aD Q5qWG4bEx+6sV4ohAEtOKIk8uahs9TlQD6FpEyBgPg== X-Google-Smtp-Source: APXvYqy7SDV/5FX7rqxqq9injBH2gcOAfd1d/3MBl2J8Rebizlz8gkZZsTv7OLXSqeXs00zJG+KCiSGXFfALpjdzwRw= X-Received: by 2002:a6b:7503:: with SMTP id l3mr3048295ioh.244.1567380275032; Sun, 01 Sep 2019 16:24:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Sun, 1 Sep 2019 16:24:24 -0700 Message-ID: To: John Cowan Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 23:24:38 -0000 How is such a thing supposed to work portably? What is the "length" of a JSON string, and does this have any correspondence to the memory representation of that string, post-parsing? On Sun, Sep 1, 2019 at 4:14 PM John Cowan wrote: > > The argument for it is precisely in situations where static allocation is= required along with static typing. If you know the (maximum) length, you = can safely allocate a fixed amount of memory for your internal representati= on, which you cannot do otherwise. Languages with static types and garbag= e collection (allowing dynamic allocation) are just one particular kind of = languages, and I think you need to accommodate all widely used kinds of lan= guages. I wouldn't object to skipping bounded arrays and strings in favor = of just fixed-length ones. > > See < http://www.catb.org/esr/microjson/>, a JSON-subset parser written i= n C that imposes exactly this restriction so that it can run safely on embe= dded systems with only small amounts of RAM. > > > On Sun, Sep 1, 2019 at 7:03 PM Ulysse Carion wrote: >> >> Sure -- but you could use the length validation as a hint to code >> generators, and a warning to data producers that the application will, >> post JDDF-level validation, do additional length checks. >> >> I'm not sure the need for length validation is strong enough to merit >> its inclusion in this version of the spec. >> >> On Sun, Sep 1, 2019 at 3:42 PM John Cowan wrote: >> > >> > Section 2.3 says that extensions can't be validation-related, so a len= gth limitation would most certainly be a matter of validation. >> > >> > On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion wrot= e: >> >> >> >> Fixed-length strings and arrays both sound like things one could >> >> implement with extensions, no? >> >> >> >> Tuples are a very sensible suggestion. But I wonder if we can live >> >> without them? I very much want to keep JDDF as small as possible. From nobody Sun Sep 1 16:38:52 2019 Return-Path: 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 7A650120074 for ; Sun, 1 Sep 2019 16:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=ccil-org.20150623.gappssmtp.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 coJrW01nKInC for ; Sun, 1 Sep 2019 16:38:47 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 B5A051200BA for ; Sun, 1 Sep 2019 16:38:46 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id c3so12138740wrd.7 for ; Sun, 01 Sep 2019 16:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JAvvJBFF3Zteu/G64IsMi4+GfUWLWXeYFoYB2ihzU0g=; b=Ntp8A9k529aECE2VhnIgNa1W0gpu6dldirp4+HbAz2yAsci0H8Vmt2ATUg+r/HLD8w QXb5W8Pnq1Ccuf2iotFADB6HYtCkejQLMo/pODxWCfHytjurh1ag30Yqli0xg2keyJ9K UziNq4Fy8/ZBrdepIRJRLN2EQstI+VvSN8/MYqFdCEiHUhoX3LO6AziWER15S/h9sYwq hUa5XfSnWRbjerhYBKnqtLyjd5S4cucSN6BiQ9/CfQxJpKRVN0WMMV1E6dI/uusUA952 dqXgCfyDWQdWTLeXFlOWk5Ak4twNpSBGAis9+0b9QJUpGe9mlRsBK5DK/df1zTIrHc1X /bzA== 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; bh=JAvvJBFF3Zteu/G64IsMi4+GfUWLWXeYFoYB2ihzU0g=; b=hWOwzgn/8aB271XTo5LOU5WiW/oTLzRSRvd8vh4hj8oq4kwmUtbSLIuv0iZG1Wq+0Q SAwc/zO8KTK4T4cwKp1dvAkR9zZ+O+OJLKEjB439/pH6l2YDvwLu6h0gxP0l03IlSnfg tX2ELRzbdE/c/yM9GiRMywiBtBUwAV5Rw2uNn7iUE2PPa4hmOdKa7chOcPJ/dtw/H2SP mlAF/H2oSpDguj/MJlaEM5QTmnUR79QedSDEMY+FEXWLCzmptd+mDu9t/X/dcjVFfzzh buVnrab4/3mzM3uZvCV7k/ErGJpYMUN5dSQt3nXCwnAZwswobUOUP3Y1i/lM10f68Kiv R8Yg== X-Gm-Message-State: APjAAAVEJ7KvlaipSxg7aMw+UtgSWi81xz3V3pcHvgTAkPNoOJ/IO9qa KaCcqGAYuAzWAPpakP0QiO0576nYTVG6lgS+GTEcDcbI X-Google-Smtp-Source: APXvYqwGBwy5UYuSdV47Y9+ItiVkeRGDTkW/SeyfZjFeI8ECfpdxGIL3uVdD2YaHQmUPbuEaG29KztEcSedBEv1bm+0= X-Received: by 2002:a5d:678d:: with SMTP id v13mr24218130wru.133.1567381125231; Sun, 01 Sep 2019 16:38:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Cowan Date: Sun, 1 Sep 2019 19:38:33 -0400 Message-ID: To: Ulysse Carion Cc: JSON WG Content-Type: multipart/alternative; boundary="000000000000328d180591865b52" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 23:38:50 -0000 --000000000000328d180591865b52 Content-Type: text/plain; charset="UTF-8" I agree that that is somewhat arbitrary, but I'd say the length of a string is its length in bytes in UTF-8 encoding, given that UTF-8 is the standard encoding of JSON. On Sun, Sep 1, 2019 at 7:24 PM Ulysse Carion wrote: > How is such a thing supposed to work portably? What is the "length" of > a JSON string, and does this have any correspondence to the memory > representation of that string, post-parsing? > > On Sun, Sep 1, 2019 at 4:14 PM John Cowan wrote: > > > > The argument for it is precisely in situations where static allocation > is required along with static typing. If you know the (maximum) length, > you can safely allocate a fixed amount of memory for your internal > representation, which you cannot do otherwise. Languages with static > types and garbage collection (allowing dynamic allocation) are just one > particular kind of languages, and I think you need to accommodate all > widely used kinds of languages. I wouldn't object to skipping bounded > arrays and strings in favor of just fixed-length ones. > > > > See < http://www.catb.org/esr/microjson/>, a JSON-subset parser written > in C that imposes exactly this restriction so that it can run safely on > embedded systems with only small amounts of RAM. > > > > > > On Sun, Sep 1, 2019 at 7:03 PM Ulysse Carion wrote: > >> > >> Sure -- but you could use the length validation as a hint to code > >> generators, and a warning to data producers that the application will, > >> post JDDF-level validation, do additional length checks. > >> > >> I'm not sure the need for length validation is strong enough to merit > >> its inclusion in this version of the spec. > >> > >> On Sun, Sep 1, 2019 at 3:42 PM John Cowan wrote: > >> > > >> > Section 2.3 says that extensions can't be validation-related, so a > length limitation would most certainly be a matter of validation. > >> > > >> > On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion > wrote: > >> >> > >> >> Fixed-length strings and arrays both sound like things one could > >> >> implement with extensions, no? > >> >> > >> >> Tuples are a very sensible suggestion. But I wonder if we can live > >> >> without them? I very much want to keep JDDF as small as possible. > --000000000000328d180591865b52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that that is somewhat arbitrary, but I'd say t= he length of a string is its length in bytes in UTF-8 encoding, given that = UTF-8 is the standard encoding of JSON.

On Sun, Sep 1, 2019 at 7:24 PM Ulyss= e Carion <ulysse@segment.com&g= t; wrote:
How is= such a thing supposed to work portably? What is the "length" of<= br> a JSON string, and does this have any correspondence to the memory
representation of that string, post-parsing?

On Sun, Sep 1, 2019 at 4:14 PM John Cowan <cowan@ccil.org> wrote:
>
> The argument for it is precisely in situations where static allocation= is required along with static typing.=C2=A0 If you know the (maximum) leng= th, you can safely allocate a fixed amount of memory for your internal repr= esentation, which you cannot do otherwise.=C2=A0 =C2=A0Languages with stati= c types and garbage collection (allowing dynamic allocation) are just one p= articular kind of languages, and I think you need to accommodate all widely= used kinds of languages.=C2=A0 I wouldn't object to skipping bounded a= rrays and strings in favor of just fixed-length ones.
>
> See < http://www.catb.org/esr/microjson/>, a JSON-s= ubset parser written in C that imposes exactly this restriction so that it = can run safely on embedded systems with only small amounts of RAM.
>
>
> On Sun, Sep 1, 2019 at 7:03 PM Ulysse Carion <ulysse@segment.com> wrote:
>>
>> Sure -- but you could use the length validation as a hint to code<= br> >> generators, and a warning to data producers that the application w= ill,
>> post JDDF-level validation, do additional length checks.
>>
>> I'm not sure the need for length validation is strong enough t= o merit
>> its inclusion in this version of the spec.
>>
>> On Sun, Sep 1, 2019 at 3:42 PM John Cowan <cowan@ccil.org> wrote:
>> >
>> > Section 2.3 says that extensions can't be validation-rela= ted, so a length limitation would most certainly be a matter of validation.=
>> >
>> > On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion <ulysse@segment.com> wrot= e:
>> >>
>> >> Fixed-length strings and arrays both sound like things on= e could
>> >> implement with extensions, no?
>> >>
>> >> Tuples are a very sensible suggestion. But I wonder if we= can live
>> >> without them? I very much want to keep JDDF as small as p= ossible.
--000000000000328d180591865b52-- From nobody Sun Sep 1 16:47:53 2019 Return-Path: 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 26F14120122 for ; Sun, 1 Sep 2019 16:47:47 -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 QC0K2gbJnK69 for ; Sun, 1 Sep 2019 16:47:44 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 B20AE1200F1 for ; Sun, 1 Sep 2019 16:47:44 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id j5so25712813ioj.8 for ; Sun, 01 Sep 2019 16:47:44 -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=zH90GMfWydU+oqQewkU5RT5Gkyq+cdFFDRH3Na8kIw4=; b=dbjcHeP+ih9cwul5FB0cPDLoh2pR3KQrYTngQXYVzLjIiwA+DGcNfFo+qxAJnfFSTv NkBxNOd3ifZL7tgaZhIQdHUC+OBVD/fQBvw6Win/2cs0G8CisyP/M1p3+/cc+XOQLl5H gXnwd8YIMKHKfzzu/1nkahU13cX4dpHD2+8gk= 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=zH90GMfWydU+oqQewkU5RT5Gkyq+cdFFDRH3Na8kIw4=; b=Bvm4fgsnsT8So7zDDuk4w3BQjmExILEzts3p+zqlHa8ANQSTiN9wU6OLJZal7c4eeT L3khMKeQlM5hrYFeolWgGl8mOG7rXhDnSF6Kx97rXim2Miompp9+wwBiDdtptsIZjnQh nbm7RhdixXK8j3qWoZr6pWFu9QRe2+ti8qmqFIZ21X1ReDVApRNbEvUKyEgMZgX2/DQz E4af4pOIvOdvwtStu9MGymHO4zIsYAWR7OcV91aR15g8h8agYPsoBwRk6UlN9/cf4owy pdLDcsDRGjF4rZpgeNITtcQMUDxozyfH8xjDHcYLxMirnMy1RnaIxLvkITaO1sYbX7pi a27A== X-Gm-Message-State: APjAAAXO0bUgnZXCtJfZKGz8mCZDyT0n16o1XVRZvwl+84tzRRgnk+0w VHUr4bFTjtxYAdjUsEhjTwn+UISYZonWQN4wiTCtig== X-Google-Smtp-Source: APXvYqzv8tyjYG4LbY1gLrcMzkc0Q3/44xOhoNWTideZ5uBl83ChegDruHyqQS1pNF8ZI0FqIJMlgH7Xjh4hTHFK9to= X-Received: by 2002:a5d:888a:: with SMTP id d10mr32011929ioo.201.1567381663935; Sun, 01 Sep 2019 16:47:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Sun, 1 Sep 2019 16:47:32 -0700 Message-ID: To: John Cowan Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 23:47:52 -0000 This seems like another example of a call I'd rather not have to make, nor insert into the core spec. Again -- nothing stops folks who have specific limitations to add specific extensions. And just because something isn't validated in JDDF itself doesn't mean it can't be validated at all. On Sun, Sep 1, 2019 at 4:38 PM John Cowan wrote: > > I agree that that is somewhat arbitrary, but I'd say the length of a stri= ng is its length in bytes in UTF-8 encoding, given that UTF-8 is the standa= rd encoding of JSON. > > On Sun, Sep 1, 2019 at 7:24 PM Ulysse Carion wrote: >> >> How is such a thing supposed to work portably? What is the "length" of >> a JSON string, and does this have any correspondence to the memory >> representation of that string, post-parsing? >> >> On Sun, Sep 1, 2019 at 4:14 PM John Cowan wrote: >> > >> > The argument for it is precisely in situations where static allocation= is required along with static typing. If you know the (maximum) length, y= ou can safely allocate a fixed amount of memory for your internal represent= ation, which you cannot do otherwise. Languages with static types and gar= bage collection (allowing dynamic allocation) are just one particular kind = of languages, and I think you need to accommodate all widely used kinds of = languages. I wouldn't object to skipping bounded arrays and strings in fav= or of just fixed-length ones. >> > >> > See < http://www.catb.org/esr/microjson/>, a JSON-subset parser writte= n in C that imposes exactly this restriction so that it can run safely on e= mbedded systems with only small amounts of RAM. >> > >> > >> > On Sun, Sep 1, 2019 at 7:03 PM Ulysse Carion wrot= e: >> >> >> >> Sure -- but you could use the length validation as a hint to code >> >> generators, and a warning to data producers that the application will= , >> >> post JDDF-level validation, do additional length checks. >> >> >> >> I'm not sure the need for length validation is strong enough to merit >> >> its inclusion in this version of the spec. >> >> >> >> On Sun, Sep 1, 2019 at 3:42 PM John Cowan wrote: >> >> > >> >> > Section 2.3 says that extensions can't be validation-related, so a = length limitation would most certainly be a matter of validation. >> >> > >> >> > On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion w= rote: >> >> >> >> >> >> Fixed-length strings and arrays both sound like things one could >> >> >> implement with extensions, no? >> >> >> >> >> >> Tuples are a very sensible suggestion. But I wonder if we can live >> >> >> without them? I very much want to keep JDDF as small as possible. From nobody Sun Sep 1 18:46:01 2019 Return-Path: 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 7EB8E1200F6 for ; Sun, 1 Sep 2019 18:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.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 pWTXJAf0r2ST for ; Sun, 1 Sep 2019 18:45:56 -0700 (PDT) Received: from ipxdno.tcif.telstra.com.au (ipxdno.tcif.telstra.com.au [203.35.82.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B907F12003F for ; Sun, 1 Sep 2019 18:45:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,457,1559484000"; d="scan'208";a="152552757" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipodni.tcif.telstra.com.au with ESMTP; 02 Sep 2019 11:45:50 +1000 Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbni.tcif.telstra.com.au with ESMTP; 02 Sep 2019 11:45:50 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by WSMSG3705.srv.dir.telstra.com (172.49.40.203) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 2 Sep 2019 11:43:49 +1000 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 2 Sep 2019 11:43:47 +1000 Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.229.126) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 2 Sep 2019 11:43:47 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jvDK+w25P7cObWTQj6ly5Wmq0qXwj8fCqhDLtxVlot8DrODkHChH1YetjFdQGRJ00GOyW9ktt85fWWPPPE3yqCjlFyz8PHV08p7pRlp0iTw8VddU3vQw0EmdN5XoxdMhPX75ZVv2zEqJpNeXD+7j5yoGtpoFB/YBBwueEyoQkAe6/Vt8k+r9UNIJvQsSSo2HtNDRiisx0aHxCQ1DGD4z3PbllzHxet5s44qKxzpgtx9YqZcImFrc1iVard0ImihLewwNShRIuW+RaNhQR+pos4rjSGQO5F1VcuNZrbT7QHPEkzlaFzJayWSUVIXVRVBWo5rkyGvrGdINrZR75zn8PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=42drhMml6HW5/y3AiotSTVWNX7cgJi7CZcLLxX+Q+sI=; b=B3Ndj+Usz43nOI6AcD8ilV/yjdECiuwMZH5D2VmiPuezCnvq5Ge7pjjeLmp2Cg6/77U37FDT3wADKk4k2NSZFLt/7XSn/c/nI21Uj2oONY7e6WFaEvRpilMvROOmmoZCP5ZDG/70Ai/ELcArwFl2NVS5VZoMv4h3Z38qUNqBHlYSkoeVDOOm1ZAUttt9thwkFIiLFG4wI6xsAJNdwdJ8seTne+KDxjaH2cdU+DatFfw4ppQ4jOzIdTNIrOW+QmYZsil0KeyKFmudFHZ674ExOOZU2DKYn+ZCzliSNS7vBB5vs7yNNFKMeT4Dnj9xX8dTcmn2vOa/ZsvydpJz5bbupQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=42drhMml6HW5/y3AiotSTVWNX7cgJi7CZcLLxX+Q+sI=; b=MQ6a91um7MnFddpPCYq9yhqi6EPtKv/CInpBqXV6yBPbSVN/xm/YyrKHZLmrC90YTTai2y6AqcOkMZX9MxKC6p8peHPWDk+KUq14nV5vloaxEEqnRUYnpMfiM8Ix8uf207fpnM4yx5vvxZsi84bgzIHy7UGwkYsN1Q2g6d/APvc= Received: from ME2PR01MB2753.ausprd01.prod.outlook.com (52.134.205.148) by ME2PR01MB4066.ausprd01.prod.outlook.com (52.134.222.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.20; Mon, 2 Sep 2019 01:43:46 +0000 Received: from ME2PR01MB2753.ausprd01.prod.outlook.com ([fe80::49ef:3e0b:cfc9:e613]) by ME2PR01MB2753.ausprd01.prod.outlook.com ([fe80::49ef:3e0b:cfc9:e613%7]) with mapi id 15.20.2220.021; Mon, 2 Sep 2019 01:43:46 +0000 From: "Manger, James" To: Ulysse Carion CC: JSON WG Thread-Topic: [Json] JSL: Clarifying purpose, and renaming it to JDDF Thread-Index: AQHVXdry9oK6lPp0d0O1tpBiqjOWTKcRrocAgAW8c4CAACijUA== Date: Mon, 2 Sep 2019 01:43:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.9.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f319b16-ddc5-4526-ed1c-08d72f46ff00 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:ME2PR01MB4066; x-ms-traffictypediagnostic: ME2PR01MB4066: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01480965DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(189003)(478600001)(6916009)(86362001)(14454004)(11346002)(71190400001)(486006)(33656002)(446003)(74316002)(6436002)(102836004)(229853002)(305945005)(256004)(476003)(7696005)(7736002)(76176011)(71200400001)(2906002)(9686003)(55016002)(6506007)(6306002)(14444005)(66066001)(316002)(53936002)(66446008)(8676002)(6246003)(64756008)(66556008)(66476007)(81166006)(81156014)(3846002)(66946007)(4326008)(8936002)(26005)(76116006)(99286004)(25786009)(186003)(5660300002)(52536014)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:ME2PR01MB4066; H:ME2PR01MB2753.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TLnp6yf2amAA3siOyW3rfWfKx3LENzAPkO2A8b2+km5WVu5gi2PXAg7/LNepVVtIrlMZkmAw4oVdma5b1oZf3B2cXFruMYhdMEXGLzXf0NldPPGmp/cQG535hdsaQqSEO0geWcQOVVodeDL+7Sp7nxJbBDoDbiKT6uHC59gaTyaXhy0t9j3BnAnT2lldkExlr/MDHrhagpL2GNb+zAJimd8M0z4srh3QuFaZQLfijyl9E8HRUE+rTKyckybZMY0/dRe4cHarHgqQF2ZJYF8E1Vq/Pw3Ahb552PQrO69l1eiGSnSDDfm5r66EqA9iOx24gTZGgBTPxM4DuZBTdgwWC4n1FeNsZ+PTJ9SHiTG89D8s7D4WC7iFQU3ZwvZq4kaUY3z6gemsMBmyxOBjNq83acuMjLVyHTvFJHi/OK1nb5c= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8f319b16-ddc5-4526-ed1c-08d72f46ff00 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 01:43:46.7502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nskmPEoXzGX8jDjqbgrfDDL9ZptPTtaA4dn88ecHMh1utjsexOvaL2DKWHIeDlvw/vp80bAhHkwxs+zV8OjrVwht53AlzzyWVWz3YDQKLbE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB4066 X-OriginatorOrg: team.telstra.com Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 01:46:00 -0000 Pj4gSkRERiBvZmZlcnMgInR5cGUiOiJ1aW50OCIgYnV0IHZlcnkgY29tbW9uIGxhbmd1YWdlcywg c3VjaCBhcyBKYXZhLCBkb24ndCBoYXZlIGFuIHVuc2lnbmVkIDgtYml0IHR5cGUuIFNvIGNvZGUg Z2VuZXJhdGlvbiBtaWdodCB1c2UgYSBzaG9ydCAoMTYtYml0IHNpZ25lZCBpbnRlZ2VyKSB0byBo YW5kbGUgdGhlIFswLCAyNTVdIHJhbmdlLiBUaGF0IHNlZW1zIHRvIHB1dCB0aGUgY29kZSBpbiBh IHZlcnkgc2ltaWxhciBzaXR1YXRpb24gdG8gdXNpbmcgYSBsb25nIHdoZW4gdGhlIEpEREYgc2F5 cyAiaW50NTQiLiBJbiBib3RoIGNhc2VzIHRoZSBuYXRpdmUgdHlwZSBjYW4gaG9sZCB2YWx1ZXMg dGhhdCB0aGUgc2NoZW1hIGRvZXNuJ3QgYWxsb3csIHJlcXVpcmluZyBleHRyYSBwYXJzZS9zdHJp bmdpZnkgZnVuY3Rpb25zIGlmIHlvdSByZWFsbHkgd2FudCB0byBlbmZvcmNlIHRoZSBzY2hlbWEn cyBydWxlcy4NCg0KPlRoaXMgaXNuJ3QgcXVpdGUgcmlnaHQuIFllcyAtLSBKYXZhIG9ubHkgaGFz ICJieXRlIiwgYnV0IGJ5IGNvbnZlbnRpb24geW91IGNhbiBzdG9yZSBib3RoIHNpZ25lZCBhbmQg dW5zaWduZWQgOC1iaXQgbnVtYmVycyBpbiB0aGVzZSBieXRlcy4NCj5Qcm90b2J1ZnMgZG9lcyB0 aGlzOg0KDQpUaGF0IGlzIGNlcnRhaW5seSAxIHJlYXNvbmFibGUgY2hvaWNlIGZvciBhIGNvZGUg Z2VuZXJhdG9yLg0KDQo+RnVydGhlcm1vcmUsIHRoZSBKYXZhIHN0YW5kYXJkIGxpYnJhcnkgaGFz IG1ldGhvZHMgdGhhdCBleHBsaWNpdGx5IGxldCB5b3UgZG8gdGhlIGNvbnZlcnNpb24gb2YgYSBK YXZhIGJ5dGUtYXMtdWludDggaW50byBhIEphdmEgaW50IG9yIGxvbmc6DQo+DQo+aHR0cHM6Ly9k b2NzLm9yYWNsZS5jb20vamF2YXNlLzgvZG9jcy9hcGkvamF2YS9sYW5nL0J5dGUuaHRtbCN0b1Vu c2lnbmVkSW50LWJ5dGUtDQo+aHR0cHM6Ly9kb2NzLm9yYWNsZS5jb20vamF2YXNlLzgvZG9jcy9h cGkvamF2YS9sYW5nL0J5dGUuaHRtbCN0b1Vuc2lnbmVkTG9uZy1ieXRlLQ0KPg0KPklmIGJ5dGVz LWFzLXVpbnQ4IHdlcmVuJ3QgY29udmVudGlvbmFsLCB0aGVuIHdoeSBkb2VzIGphdmEubGFuZy5C eXRlIGhhdmUgbWV0aG9kcyB0aGF0IGVuYWJsZSBzdWNoIGEgc3R5bGU/DQoNCkRpZCB5b3Ugbm90 aWNlIHRoZSAiU2luY2UgMS44IiBhbm5vdGF0aW9uIG9uIHRob3NlIG1ldGhvZHM/IFRoaXMgc3Vw cG9ydCBmb3IgYnl0ZS1hcy11aW50OCB3YXMgb25seSBhZGRlZCBpbiBKYXZhIDguDQpBbmQgZXZl biB0aGVzZSBhZGRpdGlvbnMgZG9uJ3QgbWFrZSBKYXZhJ3Mgc3RhbmRhcmQgc29ydGluZyBvciBw cmludGluZyB3b3JrIGZvciB1aW50OC4gR2VuZXJhdGVkIGNvZGUgY2Fubm90IG1lcmVseSB1c2lu ZyBieXRlIGZvciB1aW50ODsgaXQgYWxzbyBuZWVkcyB0byBhZGQgY29kZSBzbyBhIGJ5dGUtYXMt dWludDggaXMgc2VyaWFsaXplZCBkaWZmZXJlbnRseSB0byBhIG5vcm1hbCBieXRlLWFzLWludDgu DQoNClNob3J0LWFzLXVpbnQ4IGhhcyBkaWZmZXJlbnQgcHJvcGVydGllczogc29ydGluZyAmIHNl cmlhbGl6aW5nIHdvcmtzIGFzICJub3JtYWwiLCBidXQgaXQgdGFrZXMgdHdpY2UgYXMgbXVjaCBt ZW1vcnkuDQoNCklmIEkgc2F3IHVpbnQ4IGluIEpEREYsIEknZCBhbG1vc3QgY2VydGFpbmx5IHdh bnQgY29udHJvbCBvdmVyIHdoZXRoZXIgaXQgYmVjYW1lIGEgYnl0ZSBvciBzaG9ydCBpbiBteSBK YXZhIGNvZGUsIGRlcGVuZGluZyBvbiB0aGUgc2l0dWF0aW9uLg0KDQoNCj4+ICogInR5cGUiOiAi aW50U3RyaW5nIiAuLi4NCj4+ICogInR5cGUiOiAidWludEI2NHUiIC4uLg0KPj4gKiAidHlwZSI6 ICJieXRlc0I2NCIgLi4uDQo+PiAqICJ0eXBlIjogImJ5dGVzQjY0dSIgLi4uDQoNCj4gSSB0aGlu ayBJJ20gb3Bwb3NlZCB0byB0aGlzIHN1Z2dlc3Rpb24uIEFkZGluZyBzdXBwb3J0IGZvciBhcmJp dHJhcnkgYmluYXJ5IGRhdGEgaXMgZ29pbmcgdG8gYmUgY2hhbGxlbmdpbmcuIEkgdGhpbmsgSSBw cmVmZXIgdGhhdCB3ZSBqdXN0IHN0aWNrIHRvIHsidHlwZSI6InN0cmluZyJ9LCBhbmQgdGhlbiBm b2xrcyBjYW4gd3JpdGUgdGhlaXIgb3duIGV4dGVuc2lvbnMgdG8gSkRERiB0byBhY2hpZXZlIHRo ZWlyIHNwZWNpZmljIG5lZWRzLiBBZnRlciBhd2hpbGUsIHRoZSBjb21tdW5pdHkgbWF5IHBlcmhh cHMgY29udmVyZ2Ugb24gY29tbW9uIGV4dGVuc2lvbnMsIG9yIHBhdHRlcm5zIG1heSBhcmlzZSBh bmQgd2UgY2FuIHVwZGF0ZSB0aGUgSkRERiBzcGVjLg0KPg0KPkFueXRoaW5nIHdlIGFkZCB0byB0 aGUgc3BlYyBub3cgd291bGQgaGF2ZSB0byBiZSBzdXBwb3J0ZWQgYnkgYWxsIGltcGxlbWVudGF0 aW9ucy4gU28gSSdkIHByZWZlciB3ZSBnaXZlIG91dCBhIG1pbmltYWwgc3BlYyB0byB0aGUgd29y bGQsIGFuZCBzZWUgd2hlcmUgdGhlIHJlYWwgd29ybGQgdGFrZXMgaXQuIElmIHdlIHRyeSB0byBz b2x2ZSBhbGwgcHJvYmxlbXMgcmlnaHQgYXdheSwgd2UgbWF5IG1ha2UgaXQgdG9vIGhhcmQgZm9y IGltcGxlbWVudGF0aW9ucyB0byBjcm9wIHVwLCB1bHRpbWF0ZWx5IHNvbHZpbmcgbm8gcHJvYmxl bXMgZm9yIGFueW9uZS4NCg0KQnV0IGlmIHRoZSBzcGVjIGlzIHRvbyBtaW5pbWFsIGl0IGlzbid0 IHdvcnRod2hpbGUuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From nobody Mon Sep 2 12:48:31 2019 Return-Path: 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 7C71A12008D for ; Mon, 2 Sep 2019 12:48:29 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BLPRzN3CJf7b for ; Mon, 2 Sep 2019 12:48:27 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 23A3212004E for ; Mon, 2 Sep 2019 12:48:27 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id y19so15070666wrd.3 for ; Mon, 02 Sep 2019 12:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2vkErUpe2oSLcYz6LjP82eR7ZWPqZekfN/VMGhDEbBI=; b=jpe8JjvST9yg9Kd0rYe5kEqlnku6o0ayvik5lCWWQoRsKrrJvWSf65LKwErOM0hOnC CCcIlR1+S5HnJMEBXmOfvwbgDZ8M/r7QoRAB8MCG1rc+d+/x7DJtBe1QOqQW3UGfG/VZ h35kR/5whS9owbt8fMpKlrAlsYBrEVUukxTH600TkxLKzgOEo7aM63G9R1uUs0/CbFna sgjXIpl17VNkXXfnrmWol94HxF0EKsvq0vQn1c1QG/RFbSHEQ0ExJ0bTRjZbfsWYOJf5 MGGiK/0bfqUL0Ej8Pkb1FgorJsQR20+kqR6jWrwSuQN4k79efDu7PRSkw9Q+SjNLjAZH Bm5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2vkErUpe2oSLcYz6LjP82eR7ZWPqZekfN/VMGhDEbBI=; b=fafy8DLg1snPPv5aRnXcDvaMVQGA6Fyzm8caZFxWqo4JOQRStxWEWjLdW2JS+p6X7U 9BORnuaUkjBri0qOb8GTIIXI08shsBGV7j6yTeSi4oLbqslWjbHk4APb2BDa4I8LOJJg vFQLOlY3JWm5ZoUX8RLLT0rokg07AsgRj0ypnFaDdevP3ncXXiPfPm0Kkvvd8jRdpYIk yc4XSvgCJcCKZKQLAbpXm9mag9fvI5rocIhsECyTKDWCU9iUulXwv37PzZYL4oY+kd+1 JKEQJrU5qeHbmJ8n8EpE+602qalSWd/863RIvsXBT4LaASqnqaC6jGXj2LMjfwhjW4bR Puzw== X-Gm-Message-State: APjAAAVcy2svG5Szcx9EFD1rAd3fyGUNfSlLRZgJ5Z0QL3L+Xnp641MZ ayz5fdB/EAgte/jL6SP8xI9EZTKO X-Google-Smtp-Source: APXvYqz0P/mIYqc87ACgQ9aFEAh5QzqE6fGdIhDkUZA3X/73GtHhYKTLvYjStnacJUUVXZljfYJ0qA== X-Received: by 2002:adf:f20f:: with SMTP id p15mr2391580wro.17.1567453705316; Mon, 02 Sep 2019 12:48:25 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id t203sm16974993wmf.42.2019.09.02.12.48.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Sep 2019 12:48:24 -0700 (PDT) To: Tim Bray , John Levine Cc: "json@ietf.org" References: From: Anders Rundgren Message-ID: <042f281f-0d8e-7ebf-f1bc-592790025786@gmail.com> Date: Mon, 2 Sep 2019 21:48:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 19:48:30 -0000 Thanx John and Tim, your input was much appreciated! Anders On 2019-08-31 20:21, Tim Bray wrote: > It's incorrect to say that nobody complains about UTF-16, I do so all the time. But it doesn’t do any good. > > I don't see any problem with using UTF-16 this way. > > On Sat, Aug 31, 2019 at 8:39 AM Anders Rundgren > wrote: > > Hi JSON experts, > Pardon the subject line, I'm by no means an UTF-16 aficionado. > > That UTF-16 has been deprecated by the industry at large for EXTERNAL representation of textual data is completely understandable. > > However, an I-D dealing with canonical JSON serialization is currently in the IETF ISE queue got criticism for using UTF-16 encoding INTERNALLY for sorting properties/keys. > I don't see why since the only purpose of the sorting is creating a defined order.   That sorting on UTF-8 or UTF-32 would give another result is true but for the stated purpose that is of no importance. > > In addition, JSON itself also depends on UTF-16 encoding for \uhhhh constants and AFAIK nobody have complained about that. > Example: A smiley Emoji has the Unicode value U+1F600 but would in a JSON escape sequence be represented as \ud83d\ude00 > > The reason for preferring UTF-16 in this particular case is simply because JavaScript, Windows and Java use UTF-16 as internal representation.  That's obviously a slight platform bias but the my Go and Python implementations show that the UTF-16 requirement in practice is a no-issue. > > According to the Unicode standard UTF-16 belongs to the set of supported fully interchangeable encodings. > > WDYT? > > thanx, > Anders > https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06 > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Mon Sep 2 14:00:14 2019 Return-Path: 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 C9A8412022E for ; Mon, 2 Sep 2019 14:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 UKXlrNlifdFS for ; Mon, 2 Sep 2019 14:00:02 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F091201CE for ; Mon, 2 Sep 2019 14:00:02 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MjC43Z1tz100j; Mon, 2 Sep 2019 23:00:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 2 Sep 2019 22:59:59 +0200 Cc: "json@ietf.org" X-Mao-Original-Outgoing-Id: 589150796.295164-2a91f7718b3e95a4fe8dbc552df1a78b Content-Transfer-Encoding: quoted-printable Message-Id: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> References: To: Anders Rundgren X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 21:00:12 -0000 Hi Anders, > On Aug 31, 2019, at 17:39, Anders Rundgren = wrote: >=20 > I-D dealing with canonical JSON serialization is currently in the IETF = ISE queue I don=E2=80=99t really care much about this draft, as I have pointed = out. (Mainly not because deterministic encoding is wrong, but because the = reasons you want to define a =E2=80=9Cstandard=E2=80=9D for it are = wrong. But that has been said already in different messages.) So please do go ahead and taint your scheme further with UTF-16 legacy = stuff. For those people who missed the early history of ISO 10646 (aka = Unicode): Unicode was supposed to be the 16-bit character set to end all 8-bit = character sets. We were all supposed to move to UCS-2 (a 2-byte, 16-bit representation = where the standards bodies couldn=E2=80=99t even decide the endianness, = so we actually have two of those). One important language designed in the early-to-mid-1990s got stuck with = this: Java. As did Windows. Pioneers get shot full of arrows. =20 The .NET system designed for Windows as a competitor to the JVM (Java = Virtual Machine), as well as JavaScript (which is not Java but usurped = the name), also inherited 16-bit characters. Then it dawned people that 16 bits were not enough, and after a short = excursion to a 31-bit system, UTF-16 was invented as a hack to accept = more than 63488 [sic] codepoints, with the built-in problem that the = =E2=80=9Castral=E2=80=9D codepoints (beyond 2**16) were infrequent = enough that people built endless amounts of bugs into software that used = it. =20 The 16-bit legacy embedded into Java and its contemporaries could not be = stamped out since. The main reason is that while UTF-16 is a hack that = hurts, it does not hurt enough to sustain deployment of a fix (remember = that even Python is still struggling this very year with getting its = Unicode fixes deployed). JSON of course inherited the 16-bit legacy from JavaScript in its string = escape scheme, but otherwise did come out pretty much unharmed and = managed to focus on UTF-8, like everything else relevant to interchange. Defining a deterministic encoding scheme (=E2=80=9Ccanonicalization=E2=80=9D= ) for JSON in 2019 that needs a detour through UTF-16-land looks like a = cruel joke. If you only ever care about Java and its contemporaries, it = may actually seem practical to you. Given that most map keys will be = ASCII anyway, people will certainly find shortcuts (also known as = sleeping interoperability problems) around the issue. A protocol = designer would not touch this with a 16-foot pole. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 2 14:17:56 2019 Return-Path: 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 6FEEE1200B4 for ; Mon, 2 Sep 2019 14:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 9st8g4lC-D0Y for ; Mon, 2 Sep 2019 14:17:53 -0700 (PDT) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF92712004A for ; Mon, 2 Sep 2019 14:17:53 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E0E206A30A4; Mon, 2 Sep 2019 21:17:52 +0000 (UTC) Received: from pdx1-sub0-mail-a35.g.dreamhost.com (100-96-86-133.trex.outbound.svc.cluster.local [100.96.86.133]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E13F66A2A5E; Mon, 2 Sep 2019 21:17:51 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a35.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Mon, 02 Sep 2019 21:17:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Fumbling-Army: 5f40987931343282_1567459072306_1677195476 X-MC-Loop-Signature: 1567459072306:2243112277 X-MC-Ingress-Time: 1567459072306 Received: from pdx1-sub0-mail-a35.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTP id 2DB427F249; Mon, 2 Sep 2019 14:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=ZurHkOx599jvFZuuvagJM+ALQ/I=; b=Dy/rRy3Ingr f2klMm3nMyM3aYVWOzG4/Gf27G7l9WOGP7WTq7sPPyyTAuSveiJIuMaGbbwgUdCq nE2VkVWilZN1BzkTsBMqaQGfzbSUSjuq1YVEyShymBUHOzy414KtC26FS/uTfkgE AZTi6ucBVUZHHJNmYkqbWFb0iWluIlz4= Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTPSA id E63547F5E0; Mon, 2 Sep 2019 14:17:47 -0700 (PDT) Date: Mon, 2 Sep 2019 16:17:45 -0500 X-DH-BACKEND: pdx1-sub0-mail-a35 From: Nico Williams To: Carsten Bormann Cc: Anders Rundgren , "json@ietf.org" Message-ID: <20190902211744.GA7920@localhost> References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudejtddgudeitdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 21:17:55 -0000 On Mon, Sep 02, 2019 at 10:59:59PM +0200, Carsten Bormann wrote: > Defining a deterministic encoding scheme (=E2=80=9Ccanonicalization=E2=80= =9D) for JSON > in 2019 that needs a detour through UTF-16-land looks like a cruel > joke. [...] Is that what this is about?! Oh no. Every JSON implementor needs to deal with UTF-8, but not every JSON implementor needs to deal with UTF-16. Speaking as a maintainer and developer of one popular JSON implementation that only supports UTF-8, I'm loather to have to add support for transliterating to UTF-16 code for canonicalization purposes. I understand that for many implementors the use of UTF-16 for this would be far, _far_ more convenient than UTF-8, and that were I one of them, I'd probably be on the other side. For this reason I think it would be fair for either camp to end up on the rough side of consensus, and if it be my side so be it. But first we should find what the consensus is. Has there been a consensus call on this? Whatever we do here will make some unhappy. Like endianness, we can have some notion of purity (network byte order) and yet often prefer that which is most widely implemented in hardware (little endian byte order). In Internet standards we _tend_ to prefer purity. > [...]. If you only ever care about Java and its contemporaries, it may > actually seem practical to you. Given that most map keys will be > ASCII anyway, people will certainly find shortcuts (also known as > sleeping interoperability problems) around the issue. A protocol > designer would not touch this with a 16-foot pole. +1 Nico --=20 From nobody Mon Sep 2 14:20:29 2019 Return-Path: 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 E2CC51201AA for ; Mon, 2 Sep 2019 14:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 S8r5nfSZPpaI for ; Mon, 2 Sep 2019 14:20:12 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D0112020A for ; Mon, 2 Sep 2019 14:20:12 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MjfL3bCdzyyw; Mon, 2 Sep 2019 23:20:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190902211744.GA7920@localhost> Date: Mon, 2 Sep 2019 23:20:10 +0200 Cc: "json@ietf.org" , Anders Rundgren X-Mao-Original-Outgoing-Id: 589152008.5743639-e3bac0de17e3f45e45cf446bce809a54 Content-Transfer-Encoding: quoted-printable Message-Id: <2619B2B5-C241-4CBA-854F-8A30CD4A8DF8@tzi.org> References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 21:20:27 -0000 On Sep 2, 2019, at 23:17, Nico Williams wrote: >=20 > But first we should find what the consensus is. Has there been a > consensus call on this? This is not a consensus document. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 2 14:34:58 2019 Return-Path: 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 1B76F120096 for ; Mon, 2 Sep 2019 14:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 CaRQB0WuoY0q for ; Mon, 2 Sep 2019 14:34:54 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B6812004A for ; Mon, 2 Sep 2019 14:34:54 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MjzK0wjPz10jQ; Mon, 2 Sep 2019 23:34:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190902211744.GA7920@localhost> Date: Mon, 2 Sep 2019 23:34:52 +0200 Cc: "json@ietf.org" , Anders Rundgren X-Mao-Original-Outgoing-Id: 589152891.030826-af91668f3d5809e8733f30fca7f49eec Content-Transfer-Encoding: quoted-printable Message-Id: <40386571-301A-47BD-937D-55666566CFB5@tzi.org> References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 21:34:56 -0000 On Sep 2, 2019, at 23:17, Nico Williams wrote: >=20 > I'm loather to have to add > support for transliterating to UTF-16 code for canonicalization > purposes. It=E2=80=99s not that bad. If you have the code point cp, you can translate this to a comparison = value by doing (cp < 0x10000 ? cp << 16 : (cp << 10) + 0xD4000000) (Untested code alert. =20 This does not give you valid UTF-16, but something that will compare the = same.=20 I think.) A similar transform can be applied to UTF-8 with a little state machine, = but I=E2=80=99m too tired to code this up right now. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 2 14:40:58 2019 Return-Path: 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 E80691200B4 for ; Mon, 2 Sep 2019 14:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 3bsxtcr13Y_Y for ; Mon, 2 Sep 2019 14:40:55 -0700 (PDT) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E3312004A for ; Mon, 2 Sep 2019 14:40:55 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 586EB502CC5; Mon, 2 Sep 2019 21:40:54 +0000 (UTC) Received: from pdx1-sub0-mail-a35.g.dreamhost.com (100-96-11-62.trex.outbound.svc.cluster.local [100.96.11.62]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 91C56502C28; Mon, 2 Sep 2019 21:40:53 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a35.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Mon, 02 Sep 2019 21:40:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Bored-Company: 68180aa345d8deb3_1567460454063_3882119213 X-MC-Loop-Signature: 1567460454062:2125450951 X-MC-Ingress-Time: 1567460454062 Received: from pdx1-sub0-mail-a35.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTP id 13A6C7F5E2; Mon, 2 Sep 2019 14:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=1SMZxUpi8P3RHifoM5mJEaF2fQc=; b=LFKXGOHUdh/ fkUlvjef8TnFx0y+ctC19t5xvAlLSKCvfHHWDT4AUjMHy3l0kHCBE7PR4TGyXLsB pWlspKibeVzU6G+/oIihwy/aTfjNPjvSmazxYl9Y0ng/FTInuQyO04Fitz7n5lf1 qDgw1k1lgoVga8M7tqWG+hB9sx1TaWP8= Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTPSA id CB5BB7F249; Mon, 2 Sep 2019 14:40:50 -0700 (PDT) Date: Mon, 2 Sep 2019 16:40:48 -0500 X-DH-BACKEND: pdx1-sub0-mail-a35 From: Nico Williams To: Carsten Bormann Cc: "json@ietf.org" , Anders Rundgren Message-ID: <20190902214047.GB7920@localhost> References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <40386571-301A-47BD-937D-55666566CFB5@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudejuddgtdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppeekrddvrddutdehrddujeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpeekrddvrddutdehrddujedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 21:40:57 -0000 On Mon, Sep 02, 2019 at 11:34:52PM +0200, Carsten Bormann wrote: > On Sep 2, 2019, at 23:17, Nico Williams wrote: > > I'm loather to have to add > > support for transliterating to UTF-16 code for canonicalization > > purposes. >=20 > It=E2=80=99s not that bad. >=20 > If you have the code point cp, you can translate this to a comparison v= alue by doing Yes, I'm aware. It's not that bad. It's not that bad for the other camp either (since they must already have UTF-{8, 16} transliteration. Neither choice here is the end of the world for anyone. Nico --=20 From nobody Mon Sep 2 14:49:00 2019 Return-Path: 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 4C27E12004A for ; Mon, 2 Sep 2019 14:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 Q5vUUleu8n4d for ; Mon, 2 Sep 2019 14:48:56 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9380C120044 for ; Mon, 2 Sep 2019 14:48:56 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MkHW079jzylG; Mon, 2 Sep 2019 23:48:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190902214047.GB7920@localhost> Date: Mon, 2 Sep 2019 23:48:54 +0200 Cc: "json@ietf.org" , Anders Rundgren X-Mao-Original-Outgoing-Id: 589153732.851678-50ad4c48f67923e3e8e501bc35c33241 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 21:48:58 -0000 On Sep 2, 2019, at 23:40, Nico Williams wrote: >=20 > Yes, I'm aware. It's not that bad. It's not that bad for the other > camp either (since they must already have UTF-{8, 16} transliteration. It=E2=80=99s trivial for the UTF-16 side because JSON needs conversion = to UTF-8 already. Only if you then want to carry around the JSON as UTF-16 inside your = program (which appears to be something that some Java people like) the = whole thing becomes ugly. =20 > Neither choice here is the end of the world for anyone. No, because we don=E2=80=99t care :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 2 16:13:55 2019 Return-Path: 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 84BE01200A4 for ; Mon, 2 Sep 2019 16:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 dnoroW4o83y5 for ; Mon, 2 Sep 2019 16:13:53 -0700 (PDT) Received: from azure.elm.relay.mailchannels.net (azure.elm.relay.mailchannels.net [23.83.212.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D6012007C for ; Mon, 2 Sep 2019 16:13:52 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 08F5B500F7C; Mon, 2 Sep 2019 23:13:52 +0000 (UTC) Received: from pdx1-sub0-mail-a24.g.dreamhost.com (100-96-168-83.trex.outbound.svc.cluster.local [100.96.168.83]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 24CB8501330; Mon, 2 Sep 2019 23:13:51 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a24.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Mon, 02 Sep 2019 23:13:51 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Arch-Illegal: 61f354fe2c2d2268_1567466031552_1470261916 X-MC-Loop-Signature: 1567466031552:919563922 X-MC-Ingress-Time: 1567466031551 Received: from pdx1-sub0-mail-a24.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTP id C45B783FE1; Mon, 2 Sep 2019 16:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LWmiHn/kHCSZjg u4BbJ7WRgCJ7o=; b=nIaaTgM0fTqwxup+uPAU8TjMg0t6h1G/NEDiMgUZPqVDoe 38Nv70PSOwck2BK4eJMLSkjuQhAmCd2/oar80hrBKh0/c/RUhiR0lO/0EAMweOu9 ONgzx8yq8rITyEhLjsG+OoCXiCz8xq3N/7DHVfn9o2TMHSfNX1muTb/S0RxR0= Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTPSA id EBE4983FDF; Mon, 2 Sep 2019 16:13:43 -0700 (PDT) Date: Mon, 2 Sep 2019 18:09:38 -0500 X-DH-BACKEND: pdx1-sub0-mail-a24 From: Nico Williams To: Joe Hildebrand Cc: Carsten Bormann , Anders Rundgren , "json@ietf.org" Message-ID: <20190902230937.GC7920@localhost> References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudejuddgudelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 23:13:55 -0000 On Mon, Sep 02, 2019 at 03:56:09PM -0600, Joe Hildebrand wrote: > I agree with Carsten. The use of utf-16 here is just one more reason to > think this is a bad idea. Well, yes, there's that too. We all know that canonicalization should just not be necessary. In practice, to not need canonicalization requires additional functionality somewhere. For example, the Heimdal ASN.1 compiler will (for types where it's requested) include a _save field in the emitted structures that has a copy of the sub-string of the octet string being decoded that corresponds to that structure. E.g., you can request that the TBSCertificate structure include a _save field whose value will be the original encoding of a tbsCertificate field of a Certificate. This makes it trivial to validate the signature in a Certificate. I'm starting to think that JSON parsers are going to need a similar feature... Nico -- From nobody Mon Sep 2 16:30:40 2019 Return-Path: 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 478F9120164 for ; Mon, 2 Sep 2019 16:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wj2yoWUqanwO for ; Mon, 2 Sep 2019 16:30:25 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 2DCEA12018D for ; Mon, 2 Sep 2019 16:30:25 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id x4so31743234iog.13 for ; Mon, 02 Sep 2019 16:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wL8FrBxVtTT0/jkRFpQ9lmRWXRXQ5WhHw7ulePuAILM=; b=YPBjNufS6hLynBo31nYJfqFtdn04UEAxoz684rO/HDPpJgOAq46yg2PiEQAZZaGCj5 RUflwcpKD3BP7qv2MJHG17bNnGAgOTGUJQtDSVnRzodkiZom1b5G5gsDEr72IxEOoD+o BMipHvGmHZpMmq5pBhXXYF24Asl7aJANWIbDdrVQ9RHH9/pwzpBqu2bontIFCdRg03SH 2K7gdskSEvRsPuS+TwgztjI8SnwD8uYdAVUhgI7FPyJow++5uvKR8YnSI0Swpnm4vLr8 H/IFOtkqE+XNxNKHIZx1bId+d8w0hYM9363i2mT99LvH68FvFpzwswJLi81jDnT7KZzP zAVg== 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; bh=wL8FrBxVtTT0/jkRFpQ9lmRWXRXQ5WhHw7ulePuAILM=; b=a7rCwa5MGkdPBsjq4NstzSKO9YCU4OXoWw18FQAiadIWErq5qNYmsMn9yDuvBniStU W5uignZkozfocpfOgkkGDp3tUTnepSI5Ikho0kPT/fFaxrik4MzXXg7QecVi4xSlxfX+ u4+cTsfQXJs/vRvD3rxo8Rwt0i1YAIle/0dhhEQG4Zh98d7Xa6VYdnKYv5s+olBF7/nY lOgKIx2gng+7jg7dBH2g2MZfql1ISGYWJyszSIOelS8yWPPFQx++uIDth98x44V0zkCF 6bqLdM6SM/8D0r/KKTGgQ77yPuwCNu4mWOEe6ASgRdOztlcCtF+RDHVqHPjoJK+G9o81 w5+g== X-Gm-Message-State: APjAAAVom4FCUayjXce2bYD/ozFuq4YFsCeHTouwDcQcPxn4uJTDRnV7 /+U2qfQD2teJSk7KUCOFms1LVRSAb4NpGZGQdQQ= X-Google-Smtp-Source: APXvYqx5AbKm2M5se6Sl7KR9ys0n9L3To1Y8IZqi7EOcYiLllVLvU48t8d12ciZK5ZV/eFx/jcM9m3wDyVJajts3wm4= X-Received: by 2002:a5d:8457:: with SMTP id w23mr25751598ior.189.1567467024260; Mon, 02 Sep 2019 16:30:24 -0700 (PDT) MIME-Version: 1.0 References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> In-Reply-To: From: Rob Sayre Date: Mon, 2 Sep 2019 16:30:10 -0700 Message-ID: To: Carsten Bormann Cc: Nico Williams , Anders Rundgren , "json@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002da3a305919a5b35" Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 23:30:39 -0000 --0000000000002da3a305919a5b35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 2, 2019 at 2:49 PM Carsten Bormann wrote: > On Sep 2, 2019, at 23:40, Nico Williams wrote: > > > > Yes, I'm aware. It's not that bad. It's not that bad for the other > > camp either (since they must already have UTF-{8, 16} transliteration. > > It=E2=80=99s trivial for the UTF-16 side because JSON needs conversion to= UTF-8 > already. > Only if you then want to carry around the JSON as UTF-16 inside your > program (which appears to be something that some Java people like) the > whole thing becomes ugly. > Doesn't this argument miss the escaping syntax that JSON requires? 'To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a 12-character sequence, encoding the UTF-16 surrogate pair. So, for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E".' , section 7. thanks, Rob --0000000000002da3a305919a5b35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 2, 2019 at 2:49 PM Carste= n Bormann <cabo@tzi.org> wrote:
On Sep 2, 2019, a= t 23:40, Nico Williams <nico@cryptonector.com> wrote:
>
> Yes, I'm aware.=C2=A0 It's not that bad.=C2=A0 It's not th= at bad for the other
> camp either (since they must already have UTF-{8, 16} transliteration.=

It=E2=80=99s trivial for the UTF-16 side because JSON needs conversion to U= TF-8 already.
Only if you then want to carry around the JSON as UTF-16 inside your progra= m (which appears to be something that some Java people like) the whole thin= g becomes ugly.

Doesn't this argume= nt miss the escaping syntax that JSON requires?

&#= 39;To escape an extended character that is not in the Basic Multilingual Pl= ane, the character is represented as a 12-character sequence, encoding the = UTF-16 surrogate pair.=C2=A0 So, for example, a string containing only the = G clef character (U+1D11E) may be represented as "\uD834\uDD1E".&= #39;


thanks,
Rob


--0000000000002da3a305919a5b35-- From nobody Mon Sep 2 19:02:25 2019 Return-Path: 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 7DD351200C4 for ; Mon, 2 Sep 2019 19:02:24 -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 XXDTzYU554SK for ; Mon, 2 Sep 2019 19:02:22 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 1AB33120074 for ; Mon, 2 Sep 2019 19:02:22 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id u185so28567562iod.10 for ; Mon, 02 Sep 2019 19:02:22 -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=lwWfb3iq0U2nLSZFGCYQrmGtQMBMPvIFYe88bPSfEp0=; b=VtIM0d5rs1dfoz/knByDfLDE3G8Jej5tWlVFqCl+uz6lI6SKUCsf+vozOnDzxTb0EI QOvMSj7U8+UCgKC4jyMb10pHkR2lyHn6cWN7n4NKYuMrUw36antk7IRPZwCXQihlC4QE ZGpk6fl7MMyPaC9vuZ0Afon/kbCIf3mpawB34= 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=lwWfb3iq0U2nLSZFGCYQrmGtQMBMPvIFYe88bPSfEp0=; b=cmm6+Du6rXjPkdi/0v/lbhbVt0a8A+Z+9qhWNMqauP+hKTDeQlAcOMF8N68ckPh/nM 0D1IkKHj8KXfB4YsnHZDNMieiVGwnrE4i+t1KBV3mCtrBfAB9mjPVUx2omaBVyd/xh2M 7KE+DAe8XKVQALSSjqpvRsbU3I7xl1FY2/QW4wU05HdwvbDnQqeyWzIn31Bv9OK7Fr1Y QEVpH9zg2DK2+uRFPEkW9P35HYPro3vzP84pfmvnz9zqY9PdUL4/h+ODhSJZcFmy4zgS KdvmSMUDsEYi/lB2tv9+F8xQiUbE9GkqGQejVYerEp3//ed46TYucSI1um2WaNxge1am UmPw== X-Gm-Message-State: APjAAAXnqbHSquMnIcKvwEmECXWHM2EM2Nv2ghls6NpLnQ5ZH1CeMwd7 o4WTcurNc91VbaKVwHr/KEYLqs0QymfdR7qmrIzQig== X-Google-Smtp-Source: APXvYqy6ktTGlx62MIQ8D2ir4ysXQb8L8Tf4dSGNor5btLzNNmLyVRNoSi0sMseLILzQkDcOrngdu6j02fB7GJKFZ8k= X-Received: by 2002:a6b:7718:: with SMTP id n24mr10003821iom.114.1567476141322; Mon, 02 Sep 2019 19:02:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Mon, 2 Sep 2019 19:02:09 -0700 Message-ID: To: "Manger, James" Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 02:02:25 -0000 > And even these additions don't make Java's standard sorting or printing w= ork for uint8. Generated code cannot merely using byte for uint8; it also n= eeds to add code so a byte-as-uint8 is serialized differently to a normal b= yte-as-int8. It's true that the standard sorting and printing stuff doesn't work as-is. It's untrue that one cannot merely use byte for uint8, or int for uint32. gRPC does this. It's quite common to use []byte in a context where the byte is known, beyond the type system, to represent unsigned numbers. Serializing an int back to JSON is a stronger point. But code generation can deal with this by overriding the relevant fromJSON/toJSON or equivalent. Both gson and Jackson have such functionality. This is unpleasant, but handled entirely by the code generator. But from the user's perspective they have a POJO they can immediately use, and which behaves correctly with respect to SerDe. That's what matters most for a code generating tool, in my view. Having to write special serialization logic happens already for the discriminator form, and for many languages the timestamp data type. But the important thing is that the codegen'd code can contain this nastiness, and automate away having to write such code. > If I saw uint8 in JDDF, I'd almost certainly want control over whether it= became a byte or short in my Java code, depending on the situation. This is a very sensible position. Sounds like jddf-codegen ought to support such an option, and equivalents for uint16 and uint32. > But if the spec is too minimal it isn't worthwhile. Yes, but as it is I don't think the spec meets this "too minimal" threshold= . On Sun, Sep 1, 2019 at 6:45 PM Manger, James wrote: > > >> JDDF offers "type":"uint8" but very common languages, such as Java, do= n't have an unsigned 8-bit type. So code generation might use a short (16-b= it 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 y= ou can store both signed and unsigned 8-bit numbers in these bytes. > >Protobufs does this: > > That is certainly 1 reasonable choice for a code generator. > > >Furthermore, the Java standard library has methods that explicitly let y= ou 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#toUnsigned= Int-byte- > >https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsigned= Long-byte- > > > >If bytes-as-uint8 weren't conventional, then why does java.lang.Byte hav= e methods that enable such a style? > > Did you notice the "Since 1.8" annotation on those methods? This support = for byte-as-uint8 was only added in Java 8. > And even these additions don't make Java's standard sorting or printing w= ork for uint8. Generated code cannot merely using byte for uint8; it also n= eeds to add code so a byte-as-uint8 is serialized differently to a normal b= yte-as-int8. > > Short-as-uint8 has different properties: sorting & serializing works as "= normal", but it takes twice as much memory. > > If I saw uint8 in JDDF, I'd almost certainly want control over whether it= became a byte or short in my Java code, depending on the situation. > > > >> * "type": "intString" ... > >> * "type": "uintB64u" ... > >> * "type": "bytesB64" ... > >> * "type": "bytesB64u" ... > > > I think I'm opposed to this suggestion. Adding support for arbitrary bi= nary data is going to be challenging. I think I prefer that we just stick t= o {"type":"string"}, and then folks can write their own extensions to JDDF = to achieve their specific needs. After awhile, the community may perhaps co= nverge on common extensions, or patterns may arise and we can update the JD= DF spec. > > > >Anything we add to the spec now would have to be supported by all implem= entations. So I'd prefer we give out a minimal spec to the world, and see w= here the real world takes it. If we try to solve all problems right away, w= e may make it too hard for implementations to crop up, ultimately solving n= o problems for anyone. > > But if the spec is too minimal it isn't worthwhile. > > -- > James Manger From nobody Mon Sep 2 21:09:25 2019 Return-Path: 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 E89001200E6 for ; Mon, 2 Sep 2019 21:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 1jGmyk2M_WHl for ; Mon, 2 Sep 2019 21:09:20 -0700 (PDT) Received: from brown.elm.relay.mailchannels.net (brown.elm.relay.mailchannels.net [23.83.212.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0716E12001E for ; Mon, 2 Sep 2019 21:09:19 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id F153114365F; Tue, 3 Sep 2019 04:09:18 +0000 (UTC) Received: from pdx1-sub0-mail-a6.g.dreamhost.com (100-96-45-15.trex.outbound.svc.cluster.local [100.96.45.15]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 89D1E14309E; Tue, 3 Sep 2019 04:09:03 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a6.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Tue, 03 Sep 2019 04:09:18 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Spot-Bitter: 679887a000926be6_1567483758757_4220975229 X-MC-Loop-Signature: 1567483758757:2573228922 X-MC-Ingress-Time: 1567483758757 Received: from pdx1-sub0-mail-a6.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTP id AF88F82D52; Mon, 2 Sep 2019 21:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=broPgOjQJPhCma Ku6sVy+wCCO3Y=; b=RMTwZRK8nqaYOreyucVkG6W3jDBtyq4P0Q5Lj1A0tUgaJ5 CiomFha0HkhfZLJl+7ti4W3NgC8gUs4MRCPPLsd5jlSHZVBOR47+7DbBZDID+juj b60gze1Qmh5xHXtxKxIfsllf4R75+RBTQiiHNa/p3RdjYceeqZsY0h+4fsGjU= Received: from localhost (944d5466.cst.lightpath.net [148.77.84.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 122C382D57; Mon, 2 Sep 2019 21:08:58 -0700 (PDT) Date: Mon, 2 Sep 2019 23:08:56 -0500 X-DH-BACKEND: pdx1-sub0-mail-a6 From: Nico Williams To: Rob Sayre Cc: Carsten Bormann , Anders Rundgren , "json@ietf.org" Message-ID: <20190903040855.GE7920@localhost> References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudejuddgjeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepudegkedrjeejrdekgedruddtvdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedugeekrdejjedrkeegrddutddvpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 04:09:23 -0000 On Mon, Sep 02, 2019 at 04:30:10PM -0700, Rob Sayre wrote: > Doesn't this argument miss the escaping syntax that JSON requires? > > 'To escape an extended character that is not in the Basic Multilingual > Plane, the character is represented as a 12-character sequence, encoding > the UTF-16 surrogate pair. So, for example, a string containing only the G > clef character (U+1D11E) may be represented as "\uD834\uDD1E".' Ah, good point. Objection withdrawn. From nobody Mon Sep 2 22:17:34 2019 Return-Path: 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 4BA53120105 for ; Mon, 2 Sep 2019 22:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 oBg8vpXYq89t for ; Mon, 2 Sep 2019 22:17:31 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 6545B1200DF for ; Mon, 2 Sep 2019 22:17:31 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id b16so15882382wrq.9 for ; Mon, 02 Sep 2019 22:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qw5AuIGNXlCLpPrEnUbrE4oPeRIuuvfWZ+/x6EX4M+w=; b=BIqIg7/RYipTduh5/iak2NyGiUcpStutVT9wj8KsnxtMJRcEoZ8hVobGyXQMhSvO2N HOuJ5a/7hEPmgyX4/xeChwdKz92OK6VMBCiXDBPOi/OcqTfQ3en//ZDRjen/w2a9blce pTvU+F5por87ba/n673aV6ActlfR4d/2aP+tQG7MMOpgqu3wzuHl55NEN8PbS58SPGb8 RECmd9yRMuzDFgzaVfXzEJRickry+vdtxcEa4EFH2GmEW70O3NDYQ3soe01p+NDBYBzM 18SbEEd53gsdR0zAwT0KTogH0gTjCPlORESzsrr680gD75b/6ax4tH3DtnH1Hs13V4i1 K2eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qw5AuIGNXlCLpPrEnUbrE4oPeRIuuvfWZ+/x6EX4M+w=; b=nTgE9Jh/L1PYXfzBROH7F7em7Q4uqcenXdoKdIXe9emq7lxIAJLly3+MTjsEU/4Ry3 zzeSraz0Pu1ix4gjmKN8rGYvvA/PQOMyK12D2rOssVtMiFCWYeyUTKBLvcXVGm0Wdo+D A2uY7vzYxdxh6wTnocPrVGxeu23PD643u7oaSAXT6Cl/zq6wYIl9gKqku0lL0GOJKGXJ KteFaNH3D7k87jZzBknfUgl1zDEyGGi5FpnoicpmeihJc0Rgb3wpzRfBkbxOBoHSNJ+D V921apxMtwONcpuNPHC6/Nk0b+CWFbZppXlSgTiqXZIu6PNNNKj23Crae8iw8ZB72V9m e+Cg== X-Gm-Message-State: APjAAAW3kRY6U39gbsMc+6eU7wMcAMz10R5wiqwo3FrpkKBzsTyjPji2 rnqkSAQq/SRGOtHHRbaeWDA= X-Google-Smtp-Source: APXvYqyDtAwha0JStpXdkmsYrhcElqwwS0L0M9Q9kY+r+kFWaBr+8nhejVTqa45anhQ1VB8nSdGmIQ== X-Received: by 2002:adf:f5c5:: with SMTP id k5mr37468364wrp.42.1567487849734; Mon, 02 Sep 2019 22:17:29 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id z189sm8669380wmc.25.2019.09.02.22.17.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Sep 2019 22:17:28 -0700 (PDT) To: Nico Williams , Carsten Bormann Cc: "json@ietf.org" References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> From: Anders Rundgren Message-ID: Date: Tue, 3 Sep 2019 07:17:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190902214047.GB7920@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 05:17:33 -0000 { "mildIrony": "Thanx Nico and Carsten for your \"encouraging\" input", "applicableEmojis": "\ud83d\udca9\ud83d\ude01" } More seriously, you are wasting your precious cycles on already solved and quite simple problems: https://chromium.googlesource.com/android_tools/+/78ccfd5f7e4880597fd90c61453a3be0e7aee5f0/sdk/sources/android-21/java/lang/Character.java#2058 The slight platform "bias" doesn't actually matter, it is the result that counts. Personally, I found it more worthwhile looking into the [previously] unsolved problem: canonical serialization of 64-bit doubles. This was clearly out of my league but I got some excellent help on the way. The JCS number test suite passes without a glitch for Java, JavaScript, C#, Python and Go: https://github.com/cyberphone/json-canonicalization/tree/master/testdata#es6-numbers This scheme also have a clear platform bias. In fact, the entire JCS specification (modulo sorting) is 100% compatible with ES6's JSON.stringify(). Anyway, if you think that JCS is controversial, that's nothing compared to what it is targeted for: https://lists.w3.org/Archives/Public/public-payments-wg/2019Sep/0000.html The 5-level signature depth required made the [previously] mandatory B64U wrapping schemes look really stupid. thanx, Anders https://mobilepki.org/jws-jcs/home From nobody Mon Sep 2 22:32:54 2019 Return-Path: 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 B8EAB1201AA for ; Mon, 2 Sep 2019 22:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 RDkvmGKA30Ba for ; Mon, 2 Sep 2019 22:32:51 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6444A120020 for ; Mon, 2 Sep 2019 22:32:51 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MwZb2ldMz1007; Tue, 3 Sep 2019 07:32:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 3 Sep 2019 07:32:28 +0200 Cc: Nico Williams , Anders Rundgren , "json@ietf.org" X-Mao-Original-Outgoing-Id: 589181547.353497-29672c584ea53c3a1cf218b727074da2 Content-Transfer-Encoding: quoted-printable Message-Id: <3BD0DBAF-21DA-46D0-9BEB-0141FDBCCDF0@tzi.org> References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> To: Rob Sayre X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 05:32:54 -0000 On Sep 3, 2019, at 01:30, Rob Sayre wrote: >=20 >=20 >=20 > On Mon, Sep 2, 2019 at 2:49 PM Carsten Bormann wrote: > On Sep 2, 2019, at 23:40, Nico Williams wrote: > >=20 > > Yes, I'm aware. It's not that bad. It's not that bad for the other > > camp either (since they must already have UTF-{8, 16} = transliteration. >=20 > It=E2=80=99s trivial for the UTF-16 side because JSON needs conversion = to UTF-8 already. > Only if you then want to carry around the JSON as UTF-16 inside your = program (which appears to be something that some Java people like) the = whole thing becomes ugly. >=20 > Doesn=E2=80=99t this argument miss the escaping syntax that JSON = requires? A (sanely designed) canonical encoding won=E2=80=99t ever use that, so = you don=E2=80=99t have to implement it even at the decoder. > 'To escape an extended character that is not in the Basic Multilingual = Plane, the character is represented as a 12-character sequence, encoding = the UTF-16 surrogate pair. So, for example, a string containing only = the G clef character (U+1D11E) may be represented as =E2=80=9C\uD834\uDD1E= ".' Yes, but you never escape these. The only ones that you do escape are = the one you MUST: =E2=80=A6 the characters that MUST be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). [p. 8] So, even if your string source is non-UTF-8, all escaping can be done = *after* UTF-8 conversion, looking at the ASCII characters (high bit of = the byte unset) only. (For those listening in and not understanding what the disagreement = could possibly be here: It is a common misunderstanding of the cited paragraph at the start of = page 9 of RFC 8259 that this mandates escaping astral code points. No, = it just says how you do it if you want to. But you don=E2=80=99t want = to.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 2 22:42:25 2019 Return-Path: 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 4A4601201E0 for ; Mon, 2 Sep 2019 22:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 bxtCV14DpfcI for ; Mon, 2 Sep 2019 22:42:21 -0700 (PDT) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 A1C9C1201B7 for ; Mon, 2 Sep 2019 22:42:21 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id m11so1197408ioo.0 for ; Mon, 02 Sep 2019 22:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DrYcx9yaY3NjQkWd8TTSXs8p0SdBjxR/i1Yuz3PYIYs=; b=nCGoebKjEd3rSgaBg2/3qqAqodKc0/WxyCuKamEONa5V3nD5L8Rq4Wro8aTnBeVPdw /RJXRUuUEpfyb/Fviqe47CHkn3/28K8wlHA1W/LVv+PnsGZnNLu55it6nWeMfN2ejVqY n5AJIWPoPQTZGuQvdxgb4wNFuoERZK5f4tD0QOyWV/WEaSGzfnp8VuDShyJIuHwWAEWQ oVxV7cVE+GzA04Iaeyu8CcU0YUs05l09OW80xtUhJKkRtTaeWWyD5dJQmh2MP6+ShtM3 u7cTxhkY/EGtnIYQHCDQ2wTJE1NPE+P3jdI9GAGDrkDTCzqNdNbxa3BrnVIaMUoq5JvS eOrg== 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; bh=DrYcx9yaY3NjQkWd8TTSXs8p0SdBjxR/i1Yuz3PYIYs=; b=e9jjoAnAxeFfXYoAz19Uc64IXS9NnL2fhKDRAE7NTHmIMOWr/AdoI4q0IxGvp4ycyr WseSTEz7yD2JMGDLZwl0+4uICTu7VJfBr4gTNgfYveGeE4AETpNjsxJsisNsByfo2yXB jxwmjRaZM9IQIyXmvEo153krb1XPlcCMLZxIXiQ/ye2VM+E1hHevYQomSWQZvJl6sZkt TTJu5NAUqubmBXHGnja4RATY3FwOkUIikirUQWOv2UcLF7/kJ7/8lsZxWRiAx/c/ltgc nZ2aWflqdQOx0g6j4NiMxzk2Nr6MX1MrsvoKX7K4fQ8rnlRN4/HV0QvbJ3LB7Nqq7rkR 6qrg== X-Gm-Message-State: APjAAAXrXMn/noB29vcG5xVYSF0ie5wGNBsMtJsj9YumCvrJrEF3W8GS RG/BmpJsdCVsdY9mqd4IB9b1gqCVDC5mmbDYZvY= X-Google-Smtp-Source: APXvYqwf242bBiyPrgxpEVrt4FAMqrdwxM6cXK3HAnvPX9E+tIkKwuw2+4P2WjX9ZY5vZTKnnEgDvknVe7WcEsdyM6A= X-Received: by 2002:a5e:9b12:: with SMTP id j18mr22072885iok.54.1567489340839; Mon, 02 Sep 2019 22:42:20 -0700 (PDT) MIME-Version: 1.0 References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> <3BD0DBAF-21DA-46D0-9BEB-0141FDBCCDF0@tzi.org> In-Reply-To: <3BD0DBAF-21DA-46D0-9BEB-0141FDBCCDF0@tzi.org> From: Rob Sayre Date: Mon, 2 Sep 2019 22:42:06 -0700 Message-ID: To: Carsten Bormann Cc: Nico Williams , "json@ietf.org" , Anders Rundgren Content-Type: multipart/alternative; boundary="000000000000599a6505919f8d1d" Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 05:42:23 -0000 --000000000000599a6505919f8d1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 2, 2019 at 10:32 PM Carsten Bormann wrote: > > (For those listening in and not understanding what the disagreement could > possibly be here: > It is a common misunderstanding of the cited paragraph at the start of > page 9 of RFC 8259 that this mandates escaping astral code points. No, i= t > just says how you do it if you want to. But you don=E2=80=99t want to.) > I don't think it mandates escaping those astral code points. It says "may". That means encoders and decoders must deal with that UTF-16 representation in order to interoperate. I agree that it's not necessary in an end-to-end UTF-8 pipeline. thanks, Rob --000000000000599a6505919f8d1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 2, 2019 at 10:32 PM Carst= en Bormann <cabo@tzi.org> wrote:<= /div>

(For those listening in and not understanding what the disagreement could p= ossibly be here:
It is a common misunderstanding of the cited paragraph at the start of page= 9 of RFC 8259 that this mandates escaping astral code points.=C2=A0 No, it= just says how you do it if you want to.=C2=A0 But you don=E2=80=99t want t= o.)

I don't think it mandates escap= ing those astral code points. It says "may". That means encoders = and decoders must deal with that UTF-16 representation in order to interope= rate. I agree that it's not necessary in an end-to-end UTF-8 pipeline.<= /div>

thanks,
Rob

--000000000000599a6505919f8d1d-- From nobody Mon Sep 2 22:46:11 2019 Return-Path: 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 55E9312010F for ; Mon, 2 Sep 2019 22:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 MYi0CaYm25fU for ; Mon, 2 Sep 2019 22:46:07 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 7D9DD1200FB for ; Mon, 2 Sep 2019 22:46:07 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id t16so15970407wra.6 for ; Mon, 02 Sep 2019 22:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MrKQTfrTu3IozDgsRFdvkaZZ11DdrutumWbkTRVXaLc=; b=Yevzox2LZO3G8VLB5CjjnPQgS2aF0lBVMlSYhbGu7zfHan4vfsHMhIXDKjgakH033L z/O2A/JfJVwMfsv6E/J9SmgxsgDeFhWpmlSMBti5yFSPJklMbZl8BvxGvjPhqOGF/XDl jPkGa9PKdUp3Mu1YDHd2Sx+91SFc+l2ewn2IMRCFS2MQd6dv5AIq+mw+ewmgIdbVrp/7 XPpSV3dRagTFwqnJhb2jOF8I+meDFg4168/xgwmaltzij+0/av+VKFeM3v3r3+cHCmKh +ybwaLT6AzJGk12JlaBe6krg2zK8banQW6StE/J+iszzMmb0EcYENcXM4nZTaTxcPGX/ TxOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MrKQTfrTu3IozDgsRFdvkaZZ11DdrutumWbkTRVXaLc=; b=WTsx7tYrXCo3SX+FfCfwsLbI/pwKo9mdwXHlFnMxu1z2VEpPRRF+YC/0+tuOS73LrK MoGgiiP1QYuycvRfPpfApyaaX7WkN9hV51X9L1kP88vJ/WI8l07kuIYA3iQ2bH2tYJyO DC3CVt14Byoa9qr+IQBLZF0+O3dyvWUE6XRx/SAp7lWfK08crM7KbeU2nmaXhRE+t4Et vw0C7pdnkaqXRMJqwfCu9RV20pRkhGlfW4psXei6ThiJrBLyA8rAbx6u7lq2KMbRHo19 h0cyamqPzGjby2hcXLPRh0p8Qgw7BU3WBXN+9inAA1z3W1LWLuM246rmbevl0mKfqFRm gnNg== X-Gm-Message-State: APjAAAW5s23XKmemICQU4blWjpgSTnzXTfhIVpni7WZ8udOTXNFsjNNS 6XqKP8A8RusSzCZV3bu4zZWXwYaL X-Google-Smtp-Source: APXvYqw+zt1KIqBm4RM/6oqZmo1S5qOp3v2CYA8gjr5GbMALBFeS3pTNuNMxQl3pIiJxNnXRRLq8FQ== X-Received: by 2002:a5d:6ac8:: with SMTP id u8mr4299021wrw.104.1567489565375; Mon, 02 Sep 2019 22:46:05 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id q14sm36144042wrc.77.2019.09.02.22.46.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Sep 2019 22:46:04 -0700 (PDT) From: Anders Rundgren To: "json@ietf.org" References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> Message-ID: <2086bfc5-aa63-80ed-1a11-c0f770d1480d@gmail.com> Date: Tue, 3 Sep 2019 07:46:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 05:46:10 -0000 The (IMO) only real problem with JCS is in Appendix E: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06#appendix-E Why is that? Because you typically expect tools and libraries to do all the gory stuff. In this particular case a part of the canonicalization process may spill over to the application. There are easy workarounds but workarounds is always a source of problems. IF JCS gets firm adoption this problem could be more or less nullified but that's another story. thanx, Anders From nobody Mon Sep 2 23:01:05 2019 Return-Path: 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 79E8A12003F for ; Mon, 2 Sep 2019 23:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8HPvGbQsBagb for ; Mon, 2 Sep 2019 23:01:02 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825761200FB for ; Mon, 2 Sep 2019 23:01:02 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46MxC63l6Szyrc; Tue, 3 Sep 2019 08:00:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <2086bfc5-aa63-80ed-1a11-c0f770d1480d@gmail.com> Date: Tue, 3 Sep 2019 08:00:39 +0200 Cc: "json@ietf.org" X-Mao-Original-Outgoing-Id: 589183237.978719-d144438870e0cbd8e49fc8292e81830f Content-Transfer-Encoding: quoted-printable Message-Id: References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> <2086bfc5-aa63-80ed-1a11-c0f770d1480d@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 06:01:05 -0000 Any deterministic encoding scheme always has an application layer = canonicalization issue. It=E2=80=99s just slightly worse for (I-)JSON because its generic data = model has so few common data types, so more work is at the application = layer, mapping to those data types. Gr=C3=BC=C3=9Fe, Carsten > On Sep 3, 2019, at 07:46, Anders Rundgren = wrote: >=20 > The (IMO) only real problem with JCS is in Appendix E: > = https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06= #appendix-E >=20 > Why is that? Because you typically expect tools and libraries to do = all the gory stuff. >=20 > In this particular case a part of the canonicalization process may = spill over to the application. > There are easy workarounds but workarounds is always a source of = problems. >=20 > IF JCS gets firm adoption this problem could be more or less nullified = but that's another story. >=20 > thanx, > Anders >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From nobody Tue Sep 3 22:18:47 2019 Return-Path: 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 5FBF8120090 for ; Tue, 3 Sep 2019 22:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 IehD8u1olUwY for ; Tue, 3 Sep 2019 22:18:44 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 83FBC12001E for ; Tue, 3 Sep 2019 22:18:44 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id q19so1744115wmc.3 for ; Tue, 03 Sep 2019 22:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dUhwrdHSUIe1rOkeGzwysjcBh6I0hXhAffQSTpNY8c0=; b=aUESmOHJ8JEP8GhnWcCzbm36Lkw0HhN0+qYJ5on/wz7QNodEEbzrInUM7pRfFo7vHe Clx1+Z49qITzwXysqn4xWh9T+y7v3INLRx7LWJCUdafquNXhpEOWYnOo2H7RF4lkX/te SQ0tezv8R3P+CbhJhEmlj4G4J02+0juSar3rXz6yITLt7rUoQdh13GWBJm1Zq35zIaYo nuO2QuJKbkWGdAXnmZInPK46kXS70mwyCqMcqlIlvvEzn0jUY3eRJr7jn8rTsAsUT7xo HfVxTMUnRg0hrT2l+aWEDcsPGLbAJ/JjByShKAFkTJIaHkyakb06U5guoWr/SXNmKKLB 2s6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dUhwrdHSUIe1rOkeGzwysjcBh6I0hXhAffQSTpNY8c0=; b=DLR6z5gAaQ2GjRKRUQncPBTx1PbDOuHTAuGR94wz/kjrq/YlCHcAX1Eq0bvg9oCWdg lslNfxqBLqPNW5munEwADhNLVmWhDaGEqr7pWZlRaGe8cfrHBTxTeLkBwrcdblwKItVd xh3uRp+/ctEqml3LJkx38hQZo4ggqtXWqxX7h2UB0B2Ic6I6fF1A1ue7D735Sqdgat0r CSUw7xRJinyNWuBGd++XbZFCfE2P9gABKpacRpbRKCsJikYXi5oAXQK1szps089lIiir Z1wXUEgk/JJJJb6e03bTqj1maScacxt/dQRQAFng+5Er/+rB6zhMkwi20ITmGUXGubI/ 4XhQ== X-Gm-Message-State: APjAAAUJ6IvBqd6Nuwps5bshHrtpdoHQ00nU7Bc8fzGkouvOEEeFodNF 4hQvmuFNZIrkj+h/+kJHIIff40QH X-Google-Smtp-Source: APXvYqyK/dAZ+oej9EpQ/wppc/FY9KKwEcSbKUuim+nfS7LelAIsDJCJ5QnCkrgO/Ng7PLMw6EAZgg== X-Received: by 2002:a1c:4b16:: with SMTP id y22mr2624770wma.55.1567574322673; Tue, 03 Sep 2019 22:18:42 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id e30sm30789256wra.48.2019.09.03.22.18.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Sep 2019 22:18:41 -0700 (PDT) From: Anders Rundgren To: Carsten Bormann Cc: "json@ietf.org" References: <00231270-86DF-4AD2-949E-25B04D518577@tzi.org> <20190902211744.GA7920@localhost> <40386571-301A-47BD-937D-55666566CFB5@tzi.org> <20190902214047.GB7920@localhost> <2086bfc5-aa63-80ed-1a11-c0f770d1480d@gmail.com> Message-ID: Date: Wed, 4 Sep 2019 07:18:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] In "praise" of UTF-16 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 05:18:47 -0000 On 2019-09-03 08:00, Carsten Bormann wrote: > Any deterministic encoding scheme always has an application layer canonicalization issue. > It’s just slightly worse for (I-)JSON because its generic data model has so few common data types, so more work is at the application layer, mapping to those data types. A schema based system could manage this in a for the application developer transparent way at the expense of an additional backing string variable for each emulated data type. Anders > > Grüße, Carsten > > >> On Sep 3, 2019, at 07:46, Anders Rundgren wrote: >> >> The (IMO) only real problem with JCS is in Appendix E: >> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06#appendix-E >> >> Why is that? Because you typically expect tools and libraries to do all the gory stuff. >> >> In this particular case a part of the canonicalization process may spill over to the application. >> There are easy workarounds but workarounds is always a source of problems. >> >> IF JCS gets firm adoption this problem could be more or less nullified but that's another story. >> >> thanx, >> Anders >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Sep 5 07:20:12 2019 Return-Path: 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 371331200CD for ; Thu, 5 Sep 2019 07:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IFmb0MzF2z_5 for ; Thu, 5 Sep 2019 07:20:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4FD120026 for ; Thu, 5 Sep 2019 07:20:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4217CB8181D; Thu, 5 Sep 2019 07:19:46 -0700 (PDT) To: tbray@textuality.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, linuxwolf+ietf@outer-planes.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: lucab@lucabruno.net, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190905141946.4217CB8181D@rfc-editor.org> Date: Thu, 5 Sep 2019 07:19:46 -0700 (PDT) Archived-At: Subject: [Json] [Technical Errata Reported] RFC8259 (5853) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 14:20:10 -0000 The following errata report has been submitted for RFC8259, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5853 -------------------------------------- Type: Technical Reported by: Luca BRUNO Section: 11 Original Text ------------- Note: No "charset" parameter is defined for this registration. Adding one really has no effect on compliant recipients. Corrected Text -------------- Note: No "charset" parameter is defined for this registration. JSON text is encoded as described in RFC 8259, Section 8.1. Notes ----- Last sentence of last note of section 11 should be amended, as it introduces confusion by going against other explicit statements, like the followings: * RFC8259 sect. 8.1 defines that inner encoding is UTF-8 * RFC8259 sect. 11 defines no formal (optional/required) parameters for this registered type * RFC6838 sect. 4.2.1 defines the common usage of a "charset" parameter as a "required" one (which isn't the case here) * RFC6838 sect. 4.2.1 defines that "charset" should not be used if the inner payload already transports charset information (e.g. mandatory UTF-8, which is the case here) * RFC6838 sect. 4.2.1 defines a "charset" parameter only for subtypes of the "text/*" hierarchy (which isn't the case here) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8259 (draft-ietf-jsonbis-rfc7159bis-04) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : December 2017 Author(s) : T. Bray, Ed. Category : INTERNET STANDARD Source : Javascript Object Notation Update Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Sep 16 21:51:03 2019 Return-Path: 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 64B8C1200F6 for ; Mon, 16 Sep 2019 21:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PBNYZ8d6is6i for ; Mon, 16 Sep 2019 21:50:59 -0700 (PDT) Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD43D1200E9 for ; Mon, 16 Sep 2019 21:50:59 -0700 (PDT) Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa5.dc.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id x8H4ov8e002813 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 17 Sep 2019 04:50:58 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 21:50:56 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1473.005; Mon, 16 Sep 2019 21:50:55 -0700 From: Amanda Baber To: "json@ietf.org" CC: "rt-comment@icann.org" Thread-Topic: [IANA #1147224] WebSocket Subprotocol Name registration Thread-Index: AQHVbRN9vlgn5DsYSUOWNkPy53iuQA== Date: Tue, 17 Sep 2019 04:50:55 +0000 Message-ID: <7888644A-1F38-413E-81F8-B43A58BE3972@iana.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3651515455_592718712" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-17_02:, , signatures=0 Archived-At: Subject: [Json] [IANA #1147224] WebSocket Subprotocol Name registration X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 04:51:02 -0000 --B_3651515455_592718712 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi all, IANA has received a request to register "json" in the WebSocket Subprotocol Name registry at https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name Barry Leiba and Alexey Melnikov suggested asking this mailing list for opinions on this request. This is all of the information that was provided: === Type of Assignment: WebSocket Subprotocol ID: `json`, Common Name: `JavaScript Object Notation` Description: A lightweight messaging protocol for structured data using simple data types. Defined in http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf === We currently have only the requester's name as an entry for the registry's "Reference" field. We're also asking the CBOR mailing list to comment on a request to register "cbor." thanks, Amanda --B_3651515455_592718712 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5wYJKoZIhvcNAQcCoIIR2DCCEdQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D7AwggWfMIIEh6ADAgECAhAPR6TMNbkogI6cWmnmfXLwMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjEwMDQw MDAwMDBaFw0xOTEwMDQxMjAwMDBaMIG/MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEhMB8GA1UEAxMYQW1hbmRhIEJh YmVyIElBTkEgNE9jdDE2MSQwIgYJKoZIhvcNAQkBFhVhbWFuZGEuYmFiZXJAaWFuYS5vcmcw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCiMPnAAHvWgd/PZQPOTHtU/SMq/rPI 9IVtpiNZkiHJyt5p47FPtd6QJLl5D+/bZrAk5+IXWC9DOZrip45nWO0FskD9aU+rwP07CD1D gYrY3odTULA1AfpDkDF5uztRGZSUk2VSFIfVVc5ozdltJykUJmFHn0Xe5SMSzcHzcPnnOo2m otV94ZQSq9yjuPqQ9qqysZ95y/Vd3aUoNIG8Y88wU7G5x9xMhOjCPefaw5OB6eJ83Ie68vxm 6Jg8nDytljgZBAfVC4XIOmao4qIJQj5Q86Nyp+3RNCvi3gTQYsPXJqPAQQyZpDQgR8euT0WM X3yxW5KctnXFb5ZzGaCMANghAgMBAAGjggHuMIIB6jAfBgNVHSMEGDAWgBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAdBgNVHQ4EFgQUlEcWyxsaDGdGq2VJ8hy8azNmmggwDAYDVR0TAQH/BAIw ADAgBgNVHREEGTAXgRVhbWFuZGEuYmFiZXJAaWFuYS5vcmcwDgYDVR0PAQH/BAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIw KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGA MH4wPaA7oDmGN2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS1nMi5jcmwwPaA7oDmGN2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNI QTJBc3N1cmVkSURDQS1nMi5jcmwweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2lj ZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEB ALRQmTJgZ7NF8TnyFMZKMkZp8zH9/mjR6OPRDhDhP0ECv2R+OHOeB3SgpSAy31li1JMWruOm CWu3m8jFGL+IErXhcMaUtUeZPO0rdkcJSjl88LH/3TQ+HAx9jVWzoaIIRJxzpsHI7Zt4F/04 /kb95x5zrV6UKNY/0Vll6JymF+XUFiFEofHH0o1jwHh6oSWsmUcioFQi0umscjOB4tfFK5eR 6gXieS6Te6W4ekLJ2jZd+hrSS2o+iDxwJWpmexGYYC0VsR1NaaH5X1oMf1eNoe2S2U50/Ge9 XWWOZQhR0pVV+FMJjbVzbsH6H1+6u7EXD5iJtpWOThB6wEkLzXmMYTswggZOMIIFNqADAgEC AhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMT G0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODExMDUx MjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHf DtQVG093pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xC fiWwIxnGRTjXPUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/ Xv9Q8/AXEf+9xYn1vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04 PBPmHn9mnNVN2Uba9s9Sp307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvz snM8wbCSnhh9vat9xX0IoSzCn3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAw DgYDVR0PAQH/BAQDAgGGMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29j c3AuZGlnaWNlcnQuY29tMIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2Vy dC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5k aWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGmMIIBogYKYIZIAYb9bAACBDCCAZIw KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwggFkBggrBgEFBQcC AjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYA aQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMA ZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4A ZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUA bgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4A ZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5 MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO 1Iknuf0dh3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vl AqKEEtkV9gpEV8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7 zZOr8GrLT1gPuXtdGwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVA jmbtgti7KF/tTGHtBlgoGVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7 xkLb7L6rm2FMBpLjjt8hKlBXBMBgojXVJJ5mNwlJz9X4ZbPg4m7CMIIDtzCCAp+gAwIBAgIQ DOfg5RfYRv6P5WD8G/AwOTANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtE aWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMDYxMTEwMDAwMDAwWhcNMzExMTEwMDAw MDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0Ew ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtDhXO5EOAXLGH87dg+XESpa7cJpSI qvTO9SA5KFhgDPiA2qkVlTJhPLWxKISKityfCgyDF3qPkKyK53lTXDGEKvYPmDI2dsze3Tyo ou9q+yHyUmHfnyDXH+Kx2f4YZNISW1/5WBg1vEfNoTb5a3/UsDg+wRvDjDPZ2C8Y/igPs6eD 1sNuRMBhNZYW/lmci3Zt1/GiSw0r/wty2p5g0I6QNcZ4VYcgoc/lbQrISXwxmDNsIumH0DJa oroTghHtORedmTpyoeb6pNnVFzF1roV9Iq4/AUaG9ih5yLHa5FcXxH4cDrC0kqZWs72yl+2q p/C3xag/lRbQ/6GW6whfGHdPAgMBAAGjYzBhMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBRF66Kv9JLLgjEtUYunpyGd823IDzAfBgNVHSMEGDAWgBRF66Kv 9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAog683+Lt8ONyc3pklL/3cmbY MuRCdWKuh+vy1dneVrOfzM4UKLkNl2BcEkxY5NM9g0lFWJc1aRqoR+pWxnmrEthngYTffwk8 lOa4JiwgvT2zKIn3X/8i4peEH+ll74fg38FnSbNd67IJKusm7Xi+fT8r87cmNW1fiQG2SVuf AQWbqz0lwcy2f8Lxb4bG+mRo64EtlOtCt/qMHt1i8b5QZ7dsvfPxH2sMNgcWfzd8qVttevES RmCD1ycEvkvOl77DZypoEd+A5wwzZr8TDRRu838fYxAe+o0bJW1sj6W3YQGx0qMmoRBxna3i w/nDmVG3KwcIzi7mULKn+gpFL6Lw8jGCAf8wggH7AgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAPR6TMNbkogI6cWmnmfXLwMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUxVp5xLgvAMlXE6R5lS7Tq4N4MbkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwOTE3MDQ1MDU1WjANBgkqhkiG 9w0BAQEFAASCAQBPpT3fLkIt7wG68YAQbQ3du8PAemcJ4fRp0HBDvQ2qXwnXAKX94dAjp4V/ N1kXBZmrW1ePkXv4mxQe1vF1Zg0Af+EHqB7bY0KMeKOUY+CTqhqM7VcVerJMQaBQP2pjxpCR SbkWxogl2aRpypWWDZjO/9qEErXwRKERknwD6wNPBfGnfnyGBBaLmrE3Dh0qeOuWUJX0GNoP XbXC+I1PHJKTLqObeRCl17lftHummJPvfVsByVbfj1TdXxAICKcn7y7oA85iywHtvmHJPIQ7 BgLsVcUw7/cf3rYIF9GR9OQToALrpOmQKP+yomRQuSPtQFm8HWpNpw78CyLs/Eh22Qvm --B_3651515455_592718712-- From nobody Mon Sep 16 22:02:25 2019 Return-Path: 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 5F7761200FB for ; Mon, 16 Sep 2019 22:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmx.net 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 3qDeRg-9Uevr for ; Mon, 16 Sep 2019 22:02:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 C8BD01200E9 for ; Mon, 16 Sep 2019 22:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568696499; bh=it7PTMf8VDAuc3QKN1a26u+ucs7B9vyc0M0ULyhyiu0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=BKv6dsYwHHjy4yV2Gfc13/5xJX0JPIbqEc55/KRYUUKh4zHUAYS28qmp+H0lvwYpg rxybcwTnTn+ielTH4E0WEbYhtdA5Km9wRx4jZIPdjwyAQzpUKFejVM7HVcRQKqgExA p5f+FvwmH/mI6cwq1WaqEkT/83vPJf8KEapnszUY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([217.251.134.22]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPIvU-1iEVSl2v0y-004UiW; Tue, 17 Sep 2019 07:01:39 +0200 To: Amanda Baber , "json@ietf.org" Cc: "rt-comment@icann.org" References: <7888644A-1F38-413E-81F8-B43A58BE3972@iana.org> From: Julian Reschke Message-ID: <69996e23-6d23-8ed2-482a-de79ff348b66@gmx.de> Date: Tue, 17 Sep 2019 07:01:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <7888644A-1F38-413E-81F8-B43A58BE3972@iana.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:z15QSkXGW1bWh0RkNOqdcN4EcNL1L/OeTYvUTfBcs+Yddl1nvSC +cbBQSbjHElIkA3FRmlfgnExPxL0OCOKZi1q10ChXiusvvMyH0SSJlH8FoX1mWsBK6j+6gT JAQTv1XjVe2tUpDg0iV2yEtHyEV70LdNyt+P6QS9lGXd83VOshnwswE0jOuJkrNfxvhvmvC xvrDX4XCt7dWZYlSiV8DA== X-UI-Out-Filterresults: notjunk:1;V03:K0:KH/P8DUxQhY=:+PicbIvS9E6ltHxbnt9s0o aQb6CD168xXAxtM1szzI4ZWcrdp/ZL0VbhWA10monMggxvyFvloyZ64Yf9mxsKC3tQURqJ5Ec /ybeV0ewFBKJ7NO50iquNqjvES99WZtMKsleQfxrF+9K19UhD2HhXsZhT+SVR+QqX8HmSgUNv 6u+bZWDaouuuArtzI5agR/et4+fMgYAsWqnu7BpCgvDznzALCp/9ipeuA2tjTye9XbMUL2dmx 2YYoILlyQqHEO8ue/2hczRMyoM0DC6W7bskRBB6FjM248fCWGSX86ed0/I8KhRAE/GHM2wyWx YT/87mNfqbEXOyOcV84+Lq7ttm/TfKAQvoYvWInXxGzDemu3/I8hBIZEjzm0XQiq69LeKQCML JDzMviNkHCzXSFl1Ra5vGooig+JDMqOOAOIhswVZyQgJX7S0ADfhhZFv9sAKv6Ybxjhk5uQ7p FjO/AFyFlZqAArBFhblh0ymlUeCUYuyAgPQpG22TG72AMr6rwcOpJ+Hd8eLE6+j/teIpsch17 YxJLoEuTw2nz/x1Pjrnoi+wMqFlWEDCvhfk8Tc5QzBJVPmnAvI2vWIxSb/QUbvpW+Hw0pfxP3 lavzmpo9Gqz0i8Nq3kj69dYd92m/jnaqTUJQ8Ns3D2KlMeenvf8DAKjEhWlJfkitqerIu9ayN CxmXWA2NVlUVoaUuD2FOnNjd6x0E72k0VHyFCvLFLOTyy/O1InrzgUN8xZ4hkNzpG9+0R0hbz 3QBNpvgR3kROdEL5KlUnjommDPDJ6zw9i0ZpC15qwEitbo5Tevx1tg3wqoUWHa4P80xXTbOaq oCUtnxaC4Fgtywuk9qLPbdOZsLCydqizKkBfs6v1Sv2XH7IQEKQlI5/S0eCZo8/hrDxfSHRHS cYlSDXZQdyIQpmaLBm4gypXP2U31uqQx3rt75c/UDkgZ/5fdUTpbGk5wWdZGfM3xaRvBPst8o ka3ODJn8wTphoR8OVMVQvBQ8LIvTptmY01PxHCHQ4cejn6NvXjwznpFoR2cvkS9bljfqApo/e pehLialBdfQ72zZ5GeAeakHBneEaoRoyrVmIZXNShXa5hMxbEgVeR+Wudz9/uZ8kf7CwDFsWW 3m6M8AdAgrCz84cZJ9eABSJmuHqOB4aMIwU2oGnq6X7R6XTXP/hqCUCzHYKL6qBYgDkCt4oAn XW1WGQOMDAXrawywRnUSa8kIf7UEtWNVmlPMOoKmkt0Hv8dbM1j9QLg0Pdpj9p38E8AAM5Z+c WG4Scqu6lolgjQSikMNWQg875A3QSpAk6cUYiItiEVBQncNWXYPxj1coXcqM= Archived-At: Subject: Re: [Json] [IANA #1147224] WebSocket Subprotocol Name registration X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 05:02:23 -0000 On 17.09.2019 06:50, Amanda Baber wrote: > Hi all, > > IANA has received a request to register "json" in the WebSocket Subproto= col Name registry at > > https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-nam= e > > Barry Leiba and Alexey Melnikov suggested asking this mailing list for o= pinions on this request. > > This is all of the information that was provided: > > =3D=3D=3D > > Type of Assignment: > WebSocket Subprotocol ID: `json`, Common Name: `JavaScript Object Notati= on` > > Description: > A lightweight messaging protocol for structured data using simple data t= ypes. Defined in http://www.ecma-international.org/publications/files/ECMA= -ST/ECMA-404.pdf > > =3D=3D=3D > > We currently have only the requester's name as an entry for the registry= 's "Reference" field. > > We're also asking the CBOR mailing list to comment on a request to regis= ter "cbor." That looks insufficient to me. The definition of a payload format isn't a protocol definition, as required by : > Subprotocol Definition > A reference to the document in which the subprotocol being used > with the WebSocket Protocol is defined. Best regards, Julian From nobody Wed Sep 18 16:19:24 2019 Return-Path: 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 1D72F12011A for ; Wed, 18 Sep 2019 16:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 WsJwa8S2dYDC for ; Wed, 18 Sep 2019 16:19:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DC4120103 for ; Wed, 18 Sep 2019 16:19:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C64A1B8123E; Wed, 18 Sep 2019 16:19:08 -0700 (PDT) To: nico@cryptonector.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, mamille2@cisco.com, paul.hoffman@vpnc.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190918231908.C64A1B8123E@rfc-editor.org> Date: Wed, 18 Sep 2019 16:19:08 -0700 (PDT) Archived-At: Subject: [Json] [Editorial Errata Reported] RFC7464 (5860) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 23:19:23 -0000 The following errata report has been submitted for RFC7464, "JavaScript Object Notation (JSON) Text Sequences". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5860 -------------------------------------- Type: Editorial Reported by: Benjamin Kaduk Section: 2.2 Original Text ------------- Note that on some systems it"s possible to input RS by typing Corrected Text -------------- Note that on some systems it's possible to input RS by typing Notes ----- The contraction "it's" needs a single apostrophe, not a double-quote mark. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7464 (draft-ietf-json-text-sequence-13) -------------------------------------- Title : JavaScript Object Notation (JSON) Text Sequences Publication Date : February 2015 Author(s) : N. Williams Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Mon Sep 23 09:27:17 2019 Return-Path: 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 C377E120875; Mon, 23 Sep 2019 09:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vGr9AHjji61E; Mon, 23 Sep 2019 09:27:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613F912085E; Mon, 23 Sep 2019 09:27:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 77B58B81699; Mon, 23 Sep 2019 09:26:54 -0700 (PDT) To: kaduk@mit.edu, nico@cryptonector.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aamelnikov@fastmail.fm, iesg@ietf.org, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190923162654.77B58B81699@rfc-editor.org> Date: Mon, 23 Sep 2019 09:26:54 -0700 (PDT) Archived-At: Subject: [Json] [Errata Verified] RFC7464 (5860) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 16:27:16 -0000 The following errata report has been verified for RFC7464, "JavaScript Object Notation (JSON) Text Sequences". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5860 -------------------------------------- Status: Verified Type: Editorial Reported by: Benjamin Kaduk Date Reported: 2019-09-18 Verified by: Alexey Melnikov (IESG) Section: 2.2 Original Text ------------- Note that on some systems it"s possible to input RS by typing Corrected Text -------------- Note that on some systems it's possible to input RS by typing Notes ----- The contraction "it's" needs a single apostrophe, not a double-quote mark. -------------------------------------- RFC7464 (draft-ietf-json-text-sequence-13) -------------------------------------- Title : JavaScript Object Notation (JSON) Text Sequences Publication Date : February 2015 Author(s) : N. Williams Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Sep 25 16:30:39 2019 Return-Path: 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 0E4F11201E0 for ; Wed, 25 Sep 2019 16:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0KwQ62zp5Dtl for ; Wed, 25 Sep 2019 16:30:35 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2927F1201C6 for ; Wed, 25 Sep 2019 16:30:35 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 03466E0B8A for ; Wed, 25 Sep 2019 23:30:35 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 0147520374; Wed, 25 Sep 2019 23:30:35 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-prot-param-comment@iana.org In-Reply-To: References: <7888644A-1F38-413E-81F8-B43A58BE3972@iana.org> <69996e23-6d23-8ed2-482a-de79ff348b66@gmx.de> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1147224 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: json@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 25 Sep 2019 23:30:34 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Json] [IANA #1147224] Request for Assignment (websocket) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 23:30:37 -0000 Hi Julian, all, We received a suggestion from the ADs that we specifically ask about the utility of websocket subprotocol IDs for JSON (and CBOR, the subject of the other request we received). Are there issues there? thanks, Amanda Baber Lead IANA Services Specialist On Tue Sep 17 05:02:33 2019, julian.reschke@gmx.de wrote: > On 17.09.2019 06:50, Amanda Baber wrote: > > Hi all, > > > > IANA has received a request to register "json" in the WebSocket > > Subprotocol Name registry at > > > > https://www.iana.org/assignments/websocket/websocket.xml#subprotocol- > > name > > > > Barry Leiba and Alexey Melnikov suggested asking this mailing list > > for opinions on this request. > > > > This is all of the information that was provided: > > > > === > > > > Type of Assignment: > > WebSocket Subprotocol ID: `json`, Common Name: `JavaScript Object > > Notation` > > > > Description: > > A lightweight messaging protocol for structured data using simple > > data types. Defined in http://www.ecma- > > international.org/publications/files/ECMA-ST/ECMA-404.pdf > > > > === > > > > We currently have only the requester's name as an entry for the > > registry's "Reference" field. > > > > We're also asking the CBOR mailing list to comment on a request to > > register "cbor." > > That looks insufficient to me. The definition of a payload format > isn't > a protocol definition, as required by > : > > > Subprotocol Definition > > A reference to the document in which the subprotocol being used > > with the WebSocket Protocol is defined. > > Best regards, Julian From nobody Wed Sep 25 16:59:38 2019 Return-Path: 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 08D09120251 for ; Wed, 25 Sep 2019 16:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 OO7aELtOUG7Q for ; Wed, 25 Sep 2019 16:59:34 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 787A3120227 for ; Wed, 25 Sep 2019 16:59:34 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id z6so419430otb.2 for ; Wed, 25 Sep 2019 16:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YwmLVdFK3lOcC8LtHEhD7OoTN4CBwPMp3RrV/YryOeg=; b=mRLmlC3/dvWdnbTh+OSmVXV/kT6RT/D1opReSLmDsYhiWwinXCoitGZMF32B0ktm2l lIg5k910qTMJURY29a9/Lx8xfq2gjBUi+s4wLqGhgZJiUvSH1ZPRo4o4gcz95nG6IeaB EOD3cNPbjO75Q54MXqaQQWNYmdHAiaOOIdNRSXz2ezI6Kbs+ZmjGNjXZ14K2LaD+13Lr FibcKIiWXl1UgcItFI+Twcyva9Q6gDPUUyo46CH62f9ZpEELtM9l9yjhFhrEFtgEHe1D Mg2CzIJ35J+IOVzsLth4IQvxoiPVAf6cy1s6HCp8asuUubK9RDzMKq1hzRp6XXQqZK/0 EsEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YwmLVdFK3lOcC8LtHEhD7OoTN4CBwPMp3RrV/YryOeg=; b=K7RL3+sRsjUmu790tCAH9VraMgCWfzgAcpW8+8PbOyKtX7v3EZmAmgB5xuR/CuGpPM WYT4yvjRUG9e3Ymm/zaF3gIN9cX8FZbQPRmVKKMJPrd/eS3R6oTq6iXNFcQClemMDB7o XAJKa/I2apFdcWVmy+DzicvEA8kkJ23/xVolz/WnuY9g+62PMEpOjSc80iHr3HvCGTpC J4Tz4sI9BRi7feOG9tzx0ZEEzSRMn09ltMl4AfFTeL/7k+e/7qCQJJ0+IWh8ZCMMXMES bFTgd0ywdLqJBw41LoHb5rnpIi64rAMwbF2rKxnZvOw0TxXtghIHCuRW8auiDuw07ZOL 0Gdg== X-Gm-Message-State: APjAAAW+znB4xfKDWPTmzMkc30iBlmM/DsEycTZQxXmJ8pQqq+ND3BBY NLCxbteVGOxDbKQoiKpBSobOLsodKDGLxQ== X-Google-Smtp-Source: APXvYqxrRh7bXjuG7nXNbIoImn74ib2uXGTmQdiaMSUSxhP9qccQzGPTNnCZn+PrE6tG1OvXkgxxjw== X-Received: by 2002:a9d:664:: with SMTP id 91mr556204otn.189.1569455973360; Wed, 25 Sep 2019 16:59:33 -0700 (PDT) Received: from mmiller-44677.local ([207.126.127.114]) by smtp.gmail.com with ESMTPSA id a69sm187077oib.14.2019.09.25.16.59.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Sep 2019 16:59:32 -0700 (PDT) Sender: Matthew Miller To: iana-prot-param-comment@iana.org Cc: json@ietf.org References: <7888644A-1F38-413E-81F8-B43A58BE3972@iana.org> <69996e23-6d23-8ed2-482a-de79ff348b66@gmx.de> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBPQQTAQoAJwUCWKsJ1AIbAwUJC8ckMQULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRDs 9HJOEJ4Fu1iBCADAcW06d/7GTlBjTlYuMGgjzDBoWeQ9/zxgMnSrgNb6yO7wHzE65CeFs6OI 6LQ4A34CNM3hhcWDIzlqrV25fVyy7qCh6bCNMs1pOT63+Od4kcjHtUnGGTONT5fXSGY7mCtl XJFjb3TwyLUZXQCifhCIaUdF/4SVoGk96W9ssbDKN+5xq7B7gyVkwB0WM67zxt/kC6TPcXXL 5m7jsNRpRmFQqOlIF+HrQAcSr1lKRWgetb1VHfXCgcmDaTKn1QC7s0Ml+27dc0SoIkBI8cnv inJ4oFYWrvnTlOvv+v8AFXZnPrxZ/JYvnVD/y5PX7v08Z8RFXm1AmVxIWjXPI6TySkGvuQEN BFJoAooBCADA/ruHwYlQ7pdjJY6twkZcMmedkQNL6r5tNBeQkwVrvitUjHTKKipjxB2kEkUZ oxPgMI1h7/enDrVlMMMqq6RIJ86H+yx13zNIZNBlJfmVHgHj7TT8spa6A/qIccdiIRNsFVvl vFxpH8sTjVbHfPYexbdOR5kHpZWTzYxNyVLXMK5jen0B4K+vjbgFJAvsoLfzLZ5Bz3kb6dpu xUNzqhDyhk5/UPaCIFvZWBtiRKmkqPwEq8G2aMJq5Z4Sr8CRkpoMB25rxCPS8R+ByiHxpq+U 8mKuqPVg1LJzcA7hHmms8aBN6lxSlbyKnzEg8AWgld+6+xlJXu5U/fqDAClTj5mfABEBAAGJ ATwEGAEKACYCGwwWIQQx11iN7JBpDWvMmODs9HJOEJ4FuwUCWm+kiwUJC8tagQAKCRDs9HJO EJ4Fu40cB/9xyEnuQegivmL6OBVG5HvUAaXGUxtWiWdLm3NrduL0h7rctF060xQTekNRCjbl xZ1w/unPDBEEIMPYbF8i7IwJZoRLTG1B1MjI04AUU60G0IU6uw0ST6IsC7oYGvhDNJApbVBb j9u9x+kzaktCftl3qdpSKgRh9McIyZgevuFBdo80RDtX8niktUA3xsfJWBD1yJA33UNSzqOe 54wFRbsM2+4erREPMD659h2lACPCXjPW/6ucnv0/cdPF8V2JNMCT0yPJVCSUfFLTrtyYtiRI 6S52cI4eEOZIXCQp30TA4E27O2mMLOYzlKA5P5T+Icf4gz8e/puNUKIBDlY6KF7p Message-ID: <3530055a-b7db-1a16-24bd-060b31144136@outer-planes.net> Date: Wed, 25 Sep 2019 17:59:31 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] [IANA #1147224] Request for Assignment (websocket) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 23:59:37 -0000 In my opinion, a generic "json" WebSocket subprotocol does not make sense. JSON is too generic a content format for a client and server to adequately understand what the WebSocket session would be used for. If there were a specification that made it clearer what the intent is, my opinion might change. - m&m Matthew A. Miller On 19/09/25 17:30, Amanda Baber via RT wrote: > Hi Julian, all, > > We received a suggestion from the ADs that we specifically ask about the utility of websocket subprotocol IDs for JSON (and CBOR, the subject of the other request we received). Are there issues there? > > thanks, > > Amanda Baber > Lead IANA Services Specialist > > On Tue Sep 17 05:02:33 2019, julian.reschke@gmx.de wrote: >> On 17.09.2019 06:50, Amanda Baber wrote: >>> Hi all, >>> >>> IANA has received a request to register "json" in the WebSocket >>> Subprotocol Name registry at >>> >>> https://www.iana.org/assignments/websocket/websocket.xml#subprotocol- >>> name >>> >>> Barry Leiba and Alexey Melnikov suggested asking this mailing list >>> for opinions on this request. >>> >>> This is all of the information that was provided: >>> >>> === >>> >>> Type of Assignment: >>> WebSocket Subprotocol ID: `json`, Common Name: `JavaScript Object >>> Notation` >>> >>> Description: >>> A lightweight messaging protocol for structured data using simple >>> data types. Defined in http://www.ecma- >>> international.org/publications/files/ECMA-ST/ECMA-404.pdf >>> >>> === >>> >>> We currently have only the requester's name as an entry for the >>> registry's "Reference" field. >>> >>> We're also asking the CBOR mailing list to comment on a request to >>> register "cbor." >> >> That looks insufficient to me. The definition of a payload format >> isn't >> a protocol definition, as required by >> : >> >>> Subprotocol Definition >>> A reference to the document in which the subprotocol being used >>> with the WebSocket Protocol is defined. >> >> Best regards, Julian > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Wed Sep 25 17:07:07 2019 Return-Path: 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 E65E412001A for ; Wed, 25 Sep 2019 17:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=GD+bIx1F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KsmmrKaj 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 selFgN1sj8Jd for ; Wed, 25 Sep 2019 17:07:00 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC4B12004D for ; Wed, 25 Sep 2019 17:06:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 2BA5F615; Wed, 25 Sep 2019 20:06:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 25 Sep 2019 20:06:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=y 2ikPudxnW+WYBua/+tE1YZemHoWeKblLa8j/vIWV/c=; b=GD+bIx1FGxr2I4cd4 fMviVAyLpUkueafwcZInkKls1TRUxHSyGSrh6CBcX30lLWq1Q/0v3w31k2F09Kn8 IbjRvjsv1JcIyF/pKXpNALrhs806APTwUXIGoygZ5zyCgRtTn8C2Dzpgl1XwJEl2 lKzq8Hrx6k3KiJo5Nrg0Evzi6eU+hOPSsvznMYe1pL8u00hZqU8DXdrraFGH/nps VWdRDS9NJgIQoPOYAmwA1q/PfYszPkaysYLILbwmHAZoOMuUXyssHbBvhw72WNJT krif8cL3XH+IFJWvA/8w7VicxXa1yjTVuu4IWtS52umGFi/AlJ1oNKq93qoLYy9X DstDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=y2ikPudxnW+WYBua/+tE1YZemHoWeKblLa8j/vIWV /c=; b=KsmmrKaj70P6cphgJA2l0Cat5v4j2LcdJXcYYKdh4pjVCXPx0JhdwoFYl M0o0cuIu1WinbEReXUG38gaOnSJ6tW7epGaj+4Bii45oHIojcObmswQRAzBb7fO0 +V0IQGxTFy8n2fYEs5g/Ux8Y761h5w+dy/fXLtqPyMMAR1BJciRSJnBMZB3MZW4P 6HHlGJBbQGqW4I6v5l25c9r4BkOMGiQ7G15qJ1HqIAMe83dBJ42ra+arhEhNrknZ fDxdMPTrScen0xLZ/EmT9qj5/BJ7QIOonZXlI7TzaMMI9jOrZKrW/5KQqyZ9HH5Z SsVrwJnux/ji9O8xa42e8mDzSg52A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrfeefgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhepvggtmhgrqdhinhhtvghrnhgrthhiohhnrghlrd horhhgpdhivghtfhdrohhrghdpmhhnohhtrdhnvghtpdhirghnrgdrohhrghenucfkphep uddrudegfedrheelrdejnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnoh htrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [IPv6:2001:8004:1200:70bc:c9af:ecc3:4600:bc56] (unknown [1.143.59.7]) by mail.messagingengine.com (Postfix) with ESMTPA id 9EE318005C; Wed, 25 Sep 2019 20:06:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: <3530055a-b7db-1a16-24bd-060b31144136@outer-planes.net> Date: Thu, 26 Sep 2019 10:06:49 +1000 Cc: iana-prot-param-comment@iana.org, json@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0AFF8A0C-DB07-406B-B87D-28C8FA756819@mnot.net> References: <7888644A-1F38-413E-81F8-B43A58BE3972@iana.org> <69996e23-6d23-8ed2-482a-de79ff348b66@gmx.de> <3530055a-b7db-1a16-24bd-060b31144136@outer-planes.net> To: "Matthew A. Miller" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Json] [IANA #1147224] Request for Assignment (websocket) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 00:07:05 -0000 +1 > On 26 Sep 2019, at 9:59 am, Matthew A. Miller = wrote: >=20 > In my opinion, a generic "json" WebSocket subprotocol does not make > sense. JSON is too generic a content format for a client and server = to > adequately understand what the WebSocket session would be used for. >=20 > If there were a specification that made it clearer what the intent is, > my opinion might change. >=20 >=20 > - m&m >=20 > Matthew A. Miller > On 19/09/25 17:30, Amanda Baber via RT wrote: >> Hi Julian, all, >>=20 >> We received a suggestion from the ADs that we specifically ask about = the utility of websocket subprotocol IDs for JSON (and CBOR, the subject = of the other request we received). Are there issues there?=20 >>=20 >> thanks, >>=20 >> Amanda Baber >> Lead IANA Services Specialist >>=20 >> On Tue Sep 17 05:02:33 2019, julian.reschke@gmx.de wrote: >>> On 17.09.2019 06:50, Amanda Baber wrote: >>>> Hi all, >>>>=20 >>>> IANA has received a request to register "json" in the WebSocket >>>> Subprotocol Name registry at >>>>=20 >>>> = https://www.iana.org/assignments/websocket/websocket.xml#subprotocol- >>>> name >>>>=20 >>>> Barry Leiba and Alexey Melnikov suggested asking this mailing list >>>> for opinions on this request. >>>>=20 >>>> This is all of the information that was provided: >>>>=20 >>>> =3D=3D=3D >>>>=20 >>>> Type of Assignment: >>>> WebSocket Subprotocol ID: `json`, Common Name: `JavaScript Object >>>> Notation` >>>>=20 >>>> Description: >>>> A lightweight messaging protocol for structured data using simple >>>> data types. Defined in http://www.ecma- >>>> international.org/publications/files/ECMA-ST/ECMA-404.pdf >>>>=20 >>>> =3D=3D=3D >>>>=20 >>>> We currently have only the requester's name as an entry for the >>>> registry's "Reference" field. >>>>=20 >>>> We're also asking the CBOR mailing list to comment on a request to >>>> register "cbor." >>>=20 >>> That looks insufficient to me. The definition of a payload format >>> isn't >>> a protocol definition, as required by >>> : >>>=20 >>>> Subprotocol Definition >>>> A reference to the document in which the subprotocol being used >>>> with the WebSocket Protocol is defined. >>>=20 >>> Best regards, Julian >>=20 >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >>=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham https://www.mnot.net/ From nobody Wed Sep 25 22:05:33 2019 Return-Path: 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 029A01200DE for ; Wed, 25 Sep 2019 22:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=itaoyama.onmicrosoft.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 PIw5uflI6kXg for ; Wed, 25 Sep 2019 22:05:27 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410099.outbound.protection.outlook.com [40.107.141.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA951200BA for ; Wed, 25 Sep 2019 22:05:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B/5vh4KZfD+jOH62eMO2MERKUKeHYAyCNUi7QhEKTvsOb6DvdZzpbjMPCjb7isyOYSp+oH2GFISZPEyivOmLMlWAzphRkFvkc2leOirJle15gbT5s5HTAzWyrTvDc69smNpdhoc6qAr4a+CWbgVFUMfioo0jiNqFaLQxjsNZkli+C5hds1jsC0DpXpUv6R8W2oTIa8ddrKTpZw4pErzpYWF4zuNi148tzOlJQV+8QCo9+51p3EMw2jL6+Qf6SeHLu4Mk1Cc242+/iXJP9fwKFQc00w0rxQLwOOskEDusw8nlK1BWyrJCsCL+3S1kWTyPN5fkZDNQ9MpUw+3FCPKZ5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X3kZBW3AvM2qdb1pB9TJpbExjWgFQNNAL1gSV/aYjOA=; b=Zld4uomgtRTqzpn2RpUxTmxPvwS/6xlIChR3LDzNNfTpKisk7XXY6l9WeC7kizRkX+aI7x2xrqwYCO8kJ6l5uBCt6uDE57Ai9aDLctT5U3gwqosY9P6/CN7NrPxxXiSdu/TdvKToiQSnlEXRxBkHQ5kqtm8RzNWXufxRh6nzy1QrRTceVlbRt88f8LjATPTMB8GkEK7abZuaTsZOO4UnVoUzXw60FkaUsoaticdvxEaHbDhKIwXFZK8x/JH+3KOW/302V6nMhslxYaTrx8mP1M0uFs3evosmhsZAILQYryow5bQTXDHaBVoYXUQvZ77VARS/yFDa8wm+aDk3kljZ0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X3kZBW3AvM2qdb1pB9TJpbExjWgFQNNAL1gSV/aYjOA=; b=EcZA25fiMb8jRJq1zK/RJP2LH8/M14T73HjL99k6IEGEAH7VOlReI8crj55ymo7SDY+TP1oWvYna0WC3QBii52Qm7Z5qpBnIv19I1J7Og39seWA9wNefZWNjLC31IS4k8CMXp0mM3WSBzd1g9ebXON6UuEG1zYNxRC65JFBvPaw= Received: from TYAPR01MB4397.jpnprd01.prod.outlook.com (20.179.186.213) by TYAPR01MB5166.jpnprd01.prod.outlook.com (20.179.173.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.25; Thu, 26 Sep 2019 05:05:24 +0000 Received: from TYAPR01MB4397.jpnprd01.prod.outlook.com ([fe80::990:689e:3836:c512]) by TYAPR01MB4397.jpnprd01.prod.outlook.com ([fe80::990:689e:3836:c512%5]) with mapi id 15.20.2284.023; Thu, 26 Sep 2019 05:05:24 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Mark Nottingham , "Matthew A. Miller" CC: "iana-prot-param-comment@iana.org" , "json@ietf.org" Thread-Topic: [Json] [IANA #1147224] Request for Assignment (websocket) Thread-Index: AQHVc/lDZShKjZXFUUygPoaY3peU9Kc9EpiAgAACCoCAAFNqAA== Date: Thu, 26 Sep 2019 05:05:24 +0000 Message-ID: <4c8ca62c-8e6a-7e21-c7b8-1d41d0d71085@it.aoyama.ac.jp> References: <7888644A-1F38-413E-81F8-B43A58BE3972@iana.org> <69996e23-6d23-8ed2-482a-de79ff348b66@gmx.de> <3530055a-b7db-1a16-24bd-060b31144136@outer-planes.net> <0AFF8A0C-DB07-406B-B87D-28C8FA756819@mnot.net> In-Reply-To: <0AFF8A0C-DB07-406B-B87D-28C8FA756819@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TYAPR03CA0016.apcprd03.prod.outlook.com (2603:1096:404:14::28) To TYAPR01MB4397.jpnprd01.prod.outlook.com (2603:1096:404:12d::21) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f59ae9d-5cd1-4c0f-be17-08d7423f2372 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7025125)(7027125)(7023125)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:TYAPR01MB5166; x-ms-traffictypediagnostic: TYAPR01MB5166: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0172F0EF77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400004)(376002)(366004)(396003)(346002)(136003)(189003)(199004)(5660300002)(8676002)(486006)(476003)(85202003)(256004)(14444005)(85182001)(6512007)(102836004)(26005)(508600001)(186003)(7736002)(25786009)(6506007)(6436002)(99286004)(446003)(11346002)(54906003)(14454004)(786003)(6486002)(6116002)(64756008)(3846002)(66476007)(2616005)(76176011)(31696002)(305945005)(52116002)(66446008)(110136005)(66066001)(316002)(53546011)(31686004)(386003)(81156014)(81166006)(8936002)(66946007)(4326008)(6246003)(66556008)(2906002)(71200400001)(86362001)(229853002)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB5166; H:TYAPR01MB4397.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YUCJtXruA+/40deFDUFYd61ISwndtqAXLJWEinWUXe7ceFfKfRQ9vRoQFS/bUBuFVJm/himHOjpke9BZDRrtx4kZaKJ8D1k0La93PtJUvcPQ5RFHxra04gkiZW0WzPv7qzUZ1hzSQFBxKSUy86Tl1uYIlZAUq9CiwHJwdawiWHycc9N/qBm9+42JbOgX0irguBAIQn6iMnesFfOX4bjUdSrhdB/61TUbUSlhuryTAEyAbTpEC0EckzMplI0VMeKYEaWaN4SMdumIdWw2d0TfwEyib8QfW3cgeL0Pqcyf1HH/d6pZvbYtv6moZe2OxW4kPwm6n3hrro3zVdrC+ZZnXyK2TnCyHtbsnJrreUr/EK6EZD/q+WutiifReEgfH2t3amFqkMCJPQzc0irtFAavqtDZXjzWQpg/V510OHy6jRQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 3f59ae9d-5cd1-4c0f-be17-08d7423f2372 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 05:05:24.2558 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xYkInsVM+36nJFi5AITxL1yvFdi+XVXZ1HN26HaCX7dKGKwwVWGrazwMNL+fdWq+1QipcspN2Dh9SzDf3H8SHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB5166 Archived-At: Subject: Re: [Json] [IANA #1147224] Request for Assignment (websocket) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 05:05:30 -0000 T24gMjAxOS8wOS8yNiAwOTowNiwgTWFyayBOb3R0aW5naGFtIHdyb3RlOg0KPiArMQ0KPiANCj4+ IE9uIDI2IFNlcCAyMDE5LCBhdCA5OjU5IGFtLCBNYXR0aGV3IEEuIE1pbGxlciA8bGludXh3b2xm K2lldGZAb3V0ZXItcGxhbmVzLm5ldD4gd3JvdGU6DQo+Pg0KPj4gSW4gbXkgb3BpbmlvbiwgYSBn ZW5lcmljICJqc29uIiBXZWJTb2NrZXQgc3VicHJvdG9jb2wgZG9lcyBub3QgbWFrZQ0KPj4gc2Vu c2UuDQoNCkZ1bGx5IGFncmVlZC4NCg0KPj4gSlNPTiBpcyB0b28gZ2VuZXJpYyBhIGNvbnRlbnQg Zm9ybWF0IGZvciBhIGNsaWVudCBhbmQgc2VydmVyIHRvDQo+PiBhZGVxdWF0ZWx5IHVuZGVyc3Rh bmQgd2hhdCB0aGUgV2ViU29ja2V0IHNlc3Npb24gd291bGQgYmUgdXNlZCBmb3IuDQoNClllcyBp bmRlZWQuIFNhbWUgZm9yIENCT1IuDQoNCj4+IElmIHRoZXJlIHdlcmUgYSBzcGVjaWZpY2F0aW9u IHRoYXQgbWFkZSBpdCBjbGVhcmVyIHdoYXQgdGhlIGludGVudCBpcywNCj4+IG15IG9waW5pb24g bWlnaHQgY2hhbmdlLg0KDQpZZXMuIEFzIGEgdmVyeSBzaG9ydCBzdW1tYXJ5LCBpdCB3b3VsZCBo YXZlIHRvIHNheSB3aGF0IGtpbmRzIG9mIEpTT04gDQpkYXRhIHRoZSBzZXJ2ZXIgc2VuZHMsIHdo YXQga2luZCBvZiBKU09OIGRhdGEgdGhlIGNsaWVudCBzZW5kcywgaW4gd2hhdCANCm9yZGVyLCBh bmQgd2hhdCB0aGUgbWVhbmluZyBvZiBlYWNoIG9mIHRoZXNlIG1lc3NhZ2VzIGlzLg0KDQpTaWxs eSBleGFtcGxlOiBUaGUgSUFOQSBwcm90b2NvbCByZWdpc3RyeSBhY2Nlc3MgV2ViU29ja2V0IHN1 YnByb3RvY29sOg0KDQpDbGllbnQgc2VuZHMgLi4uIChkZXRhaWxzIHRvIGJlIHdvcmtlZCBvdXQp LCBpbmRpY2F0aW5nIHRoZSBJQU5BIA0KcHJvdG9jb2wgcmVnaXN0cnkgZGF0YSB0aGF0IGlzIHJl cXVlc3RlZC4NCg0KU2VydmVyIHNlbmRzOiAuLi4gKGRldGFpbHMgdG8gYmUgd29ya2VkIG91dCks IGFjdHVhbCBwcm90b2NvbCByZWdpc3RyeSBkYXRhLg0KDQpPZiBjb3Vyc2UgdGhpcyBleGFtcGxl IGRvZXNuJ3QgbWFrZSBtdWNoIHNlbnNlLCBhcyBhIHZlcnkgc2ltaWxhciB0aGluZyANCmNhbiBi ZSBkb25lIG11Y2ggbW9yZSBlYXNpbHkgb3ZlciBIVFRQKFMpIGRpcmVjdGx5Lg0KDQpSZWdhcmRz LCAgIE1hcnRpbi4NCg0KDQo+Pg0KPj4gLSBtJm0NCj4+DQo+PiBNYXR0aGV3IEEuIE1pbGxlcg0K Pj4gT24gMTkvMDkvMjUgMTc6MzAsIEFtYW5kYSBCYWJlciB2aWEgUlQgd3JvdGU6DQo+Pj4gSGkg SnVsaWFuLCBhbGwsDQo+Pj4NCj4+PiBXZSByZWNlaXZlZCBhIHN1Z2dlc3Rpb24gZnJvbSB0aGUg QURzIHRoYXQgd2Ugc3BlY2lmaWNhbGx5IGFzayBhYm91dCB0aGUgdXRpbGl0eSBvZiB3ZWJzb2Nr ZXQgc3VicHJvdG9jb2wgSURzIGZvciBKU09OIChhbmQgQ0JPUiwgdGhlIHN1YmplY3Qgb2YgdGhl IG90aGVyIHJlcXVlc3Qgd2UgcmVjZWl2ZWQpLiBBcmUgdGhlcmUgaXNzdWVzIHRoZXJlPw0KPj4+ DQo+Pj4gdGhhbmtzLA0KPj4+DQo+Pj4gQW1hbmRhIEJhYmVyDQo+Pj4gTGVhZCBJQU5BIFNlcnZp Y2VzIFNwZWNpYWxpc3QNCg==