From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D3E7E385AC26 for ; Tue, 30 Nov 2021 16:25:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D3E7E385AC26 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-553-Ylryya3UPwacKt7ZZnUSqQ-1; Tue, 30 Nov 2021 11:25:27 -0500 X-MC-Unique: Ylryya3UPwacKt7ZZnUSqQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3DA1B192FDC2; Tue, 30 Nov 2021 16:23:54 +0000 (UTC) Received: from redhat.com (ovpn-112-96.phx2.redhat.com [10.3.112.96]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 256A55D6BA; Tue, 30 Nov 2021 16:23:54 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1ms5v6-0006Gk-Nk; Tue, 30 Nov 2021 11:23:52 -0500 Date: Tue, 30 Nov 2021 11:23:52 -0500 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: Luca Boccassi , elfutils-devel@sourceware.org Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note Message-ID: <20211130162352.GC17988@redhat.com> References: <20211119003127.466778-1-luca.boccassi@gmail.com> <20211121194318.105654-1-luca.boccassi@gmail.com> <40a5de54f089f344697ece88e11eb41e526462ac.camel@gmail.com> <17e1d554c9a52598d2c7d27e7a40f17381285ba5.camel@klomp.org> MIME-Version: 1.0 In-Reply-To: <17e1d554c9a52598d2c7d27e7a40f17381285ba5.camel@klomp.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 16:25:32 -0000 Hi - On Tue, Nov 30, 2021 at 12:25:41PM +0100, Mark Wielaard wrote: > [...] > The spec does explain the requirements for JSON numbers, but doesn't > mention any for JSON strings or JSON objects. It would be good to also > explain how to make the strings and objects unambiguous. [...] > For Objects it should require that all names are unique. [...] > For Strings it should require that \uXXXX escaping isn't used [...] > > That should get rid of various corner cases that different parsers are > known to get wrong. Are such buggy parsers seen in the wild, now, after all this time with JSON? It seems to me it's not really elfutils' or systemd's place to impose -additional- constraints on customary JSON. > Especially \uXXXX escaping is really confusing when using the UTF-8 > encoding (and it is totally necessary since UTF-8 can express any > valid UTF character already). Yes, and yet we have had the bidi situation recently where UTF-8 raw codes could visually confuse a human reader whereas escaped \uXXXX wouldn't. If we forbid \uXXXX unilaterally, we literally become incompatible with JSON (RFC8259 7. String. "Any character may be escaped."), and for what? Both these seem to be personal aesthetic decisions that need not be imposed on a routine application of well-established standards. We have many industrial-strength json parser libraries to choose from, so that part is IMO no longer a timely concern. - FChE