IETF Logo Mail Archive

Re: [netmod] RFC7952 JSON streaming decoding efficiency?

Ladislav Lhotka <lhotka@nic.cz> Thu, 28 February 2019 11:53 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86264130E9C for <netmod@ietfa.amsl.com>; Thu, 28 Feb 2019 03:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.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_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 pPugQelTUtXZ for <netmod@ietfa.amsl.com>; Thu, 28 Feb 2019 03:53:10 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 D33C2130EA5 for <netmod@ietf.org>; Thu, 28 Feb 2019 03:53:09 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a744:2697:a0ec:a420]) by mail.nic.cz (Postfix) with ESMTPSA id D3F9B60134 for <netmod@ietf.org>; Thu, 28 Feb 2019 12:53:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1551354785; bh=C8Wn15frkQ9JdJ3Pn3ZNd3AIi5BSW/Cr/XALNoo5SXU=; h=From:To:Date; b=EALKj5tpHi4KMz4G5O1Gerf/DMwVK6Yq6yvir9/4QXJalRu+B3TisbTurNFTpqN9t pXkWgDp/eRxkC1+6W7e/oCH1yuUUmJEgBuNcEEtE0f8Nxm2AHtqlXIE4/pGPv/BiFu hT2xbNYMIDs0t4pZqUsDpM7ZLNSKSFKWxDYB5FnU=
Message-ID: <c5d3a4523cccea2f9c1735881bb72634241bc4cf.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Date: Thu, 28 Feb 2019 12:53:05 +0100
In-Reply-To: <e3c0f277-9706-3b20-f4ac-23d926e5cfe6@hq.sk>
References: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> <822cb25f1b894be9953a49ae12c91df9@XCH-RCD-007.cisco.com> <e3c0f277-9706-3b20-f4ac-23d926e5cfe6@hq.sk>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/68FKYszq35-XFcAI-JxBgKQWmY0>
Subject: Re: [netmod] RFC7952 JSON streaming decoding efficiency?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 11:53:13 -0000

Hi Robert,

On Thu, 2019-02-28 at 10:46 +0100, Robert Varga wrote:
> On 28/02/2019 10:29, Rob Wilton (rwilton) wrote:
> > Hi Robert,
> 
> Hey Rob,
> 
> > Isn't this just a limitation of JSON, in that the elements in an object are
> > unordered (RFC 8259)?
> 
> Yes, but I believe this is object semantics leaking to on-wire format:
> while a JSON object is inherently unordered, when emitting object to the
> wire, implementations can choose to order the pairs to make
> receiver-side processing more efficient.

While this is possible in principle, it would require custom
serializers/deserializers, at least in some programming languages.

We tried to adhere to I-JSON [RFC 7494] that states: "The order of object
members in an I-JSON message does not change the meaning of an I-JSON message."

JSON has other issues when it comes to streaming, so perhaps it would be better
to use another representation.

Lada

> 
> I wonder if it would be of value to communicate such assumptions out of
> band, like separate content-types. In case of RFC7952 the following
> hints would be useful:
> - the document does not contain metadata (i.e. plain RFC7951)
> - "@" occurs as a first element in an object or not at all
> - "@foo" occurs immediately after "foo" or not at all
> 
> This, of course, would be purely optional optimization...
> 
> Regards,
> Robert
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

v2.23.0 | Report a Bug | By Email