Re: [netmod] ?==?utf-8?q? JSON to XML lossy conversion

Michal Vaško <mvasko@cesnet.cz> Fri, 17 July 2020 06:57 UTC

Return-Path: <mvasko@cesnet.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 8F8653A12FB for <netmod@ietfa.amsl.com>; Thu, 16 Jul 2020 23:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.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 C9An4iohNNiy for <netmod@ietfa.amsl.com>; Thu, 16 Jul 2020 23:57:53 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599BD3A12E5 for <netmod@ietf.org>; Thu, 16 Jul 2020 23:57:52 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 949BC60287; Fri, 17 Jul 2020 08:57:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1594969070; bh=9l62UOQ2H5bfpB3PiFRfaeXhgZTNLdxdMfsTgxJ1raw=; h=In-Reply-To:From:Date:Cc:To:Subject; b=G9hWsD6b4+VdVBEqPMEA7rb9HKc6+NHTEQlVtliDZhpmnuIJPOq6Zmd9wPrtISGfR aOb3Fm8h3Z+SVXt4AOCTiDe88hwevlzlIGjDm1Dq36zG14bQWCKj1cPMzoABYvCrme Xqsw8RcEeJ0vAlFF98tAYjrP6m4dMCfktFnRweaQ=
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <3A6BD609-92FE-4646-8CDA-6EF514353012@tzi.org>
From: =?utf-8?q?Michal_Va=C5=A1ko?= <mvasko@cesnet.cz>
X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636
Date: Fri, 17 Jul 2020 08:57:50 +0200
Cc: "Ladislav Lhotka" <ladislav.lhotka@nic.cz>, "netmod" <netmod@ietf.org>
To: "Carsten Bormann" <cabo@tzi.org>
MIME-Version: 1.0
Message-ID: <1da7-5f114c00-115-50d47000@26535751>
User-Agent: SOGoMail 2.3.23
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jBzPvvDX9ZPw0DTmkNjVJ0Xm2Ck>
Subject: Re: [netmod] =?utf-8?b?Pz09P3V0Zi04P3E/ICBKU09OIHRvIFhNTCBsb3NzeSBj?= =?utf-8?q?onversion?=
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: Fri, 17 Jul 2020 06:57:57 -0000

Hi Carsten,
you had an interesting idea to have tools that could warn about these problems (although that is hardly a proper solution) but it is not really possible because the problem may occur whenever there is union with a 'string' and 'int8' - 'int32', 'uint8' - 'uint32', or 'boolean', in any order. Meaning in lots of, if not most, unions. And I have considered only XML and JSON, I have not looked into CBOR, which may make it even worse.

Regards,
Michal
 
> 
> > In my view, if it is a bug, it is in the design of the union type in YANG - there is no general way to signal the actual union member type for an instance.
> 
> Right.  The ambiguity is normally not a problem for a type choice (which is just a union of the possible values of all types given), unless what specific alternative was chosen is intended to carry semantics.
> 
> > I believe it is a good thing that some encodings allow for at least partial signalling.
> > 
> > Note that similar issues may arise even more often in CBOR, see e.g. comments for section 5.12 in
> > 
> > https://mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4/
> 
> In the original YANG (XML-only), everything was represented as a text string, so the ambiguity was the highest we see now.  YANG-JSON and YANG-CBOR provide progressively more disambiguating information, so the interpretation (which chosen alternative) may be different from the one after converting to YANG-XML.
> 
> It gets slightly worse if the non-text type has a conversion to text that is not fully nailed down; I don’t know if that is a problem with the current set of YANG types, but any new type could of course worsen the situation.
> 
> The onus is now on the author of the YANG module to make sure that the varying levels of ambiguity do not cause a problem.  I would be interested to know whether there is any tool support for this.
> 
> Grüße, Carsten
>