IETF Logo Mail Archive

Re: [Cbor] CDDL 2.0 import and paths

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 25 January 2023 19:23 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE6AC151538 for <cbor@ietfa.amsl.com>; Wed, 25 Jan 2023 11:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYj-R0KinYmX for <cbor@ietfa.amsl.com>; Wed, 25 Jan 2023 11:23:15 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBA6C15153D for <cbor@ietf.org>; Wed, 25 Jan 2023 11:23:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A0F0438990; Wed, 25 Jan 2023 14:52:50 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pfykrllLorLE; Wed, 25 Jan 2023 14:52:49 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2C10B3898F; Wed, 25 Jan 2023 14:52:49 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1674676369; bh=ngoyF0ixbgTKWL6biW3LPOKMtfbGxREDxDzo6udyWNQ=; h=From:To:Subject:In-Reply-To:References:Date:From; b=TFfzyW90CQ06jU3pdTNCFGQpGeLWrQrsFRZysqzRddsYqLtXVWWBwTlKG5i4wCsYM zPrUj+1lehVK4NOmFa/+d+3++FwgOKzj/wnu4JXsITFSf7QGIU91cxFcSJrl1yf/6s w7X2RnxvgkawcTU7IVjaoCuoda+J0Fa0tEIbKY14DCsTM1JfJlVcsCMHZT1gEolFQb QFG/ypjHDMpHIzB9pyEJzyUsH9CIJy8eWoxWpQmzyYqnrSsdzE5FhDmDmBslwz7uTg nMa+xHkijfTXJWekZpxOARZVXfL3bomXnJXl9T795t7DIFFE16ycT2j44q+P9Rcp3S p4ERY2S4sHX3w==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 31D139F; Wed, 25 Jan 2023 14:23:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>, cbor@ietf.org
In-Reply-To: <Y9FYSKde6bXgzep3@hephaistos.amsuess.com>
References: <Y9FYSKde6bXgzep3@hephaistos.amsuess.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 25 Jan 2023 14:23:13 -0500
Message-ID: <11367.1674674593@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/o8iY2bQIcW8I8zmkFpUn2tXQrRs>
Subject: Re: [Cbor] CDDL 2.0 import and paths
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2023 19:23:20 -0000

Christian Amsüss <christian@amsuess.com> wrote:
    > Today's interim had some discussion about how bare-name CDDL files can
    > be imported from statically shipped libraries, the local directory, and
    > eventually a web-wide catalog.

    > I made a very incomplete suggestion of "could be URIs" to the question
    > of how to treat nested references; here's what I'd propose for this in a
    > slightly fuller form:

    > * Import "from"s are URI references.

Could they be URNs?
Didn't we go down this path with DTD references in XML?
It was a well intentioned, but turned into a foot gun.
I'm not quite sure what went wrong, but it definitely went wrong.

If we are assuming that we always have a tool to resolve things, then we can
do that.  I think you aren't assuming much though:

    > * Tools are encouraged to ship cache directories that are enabled by
    > default. These look roughly like `wget -m` outputs in the file system,
    > are used in sequence to resolve files (maybe with --web as a
    > fallback). The user should be allowed to add such caches (a la
    > CDDLPATH).

    > * An online catalog service can offer an easy to upload and quality
    > controlled archive, which tools may auto-update from, possibly lazily
    > (hitting an unknown URI in non--web mode, and the archive is stale?
    > Better refresh from the catalog...).

Yangcatalog literally could extract cddl definitions along with YANG files.

    > * Locally used tools may have a path of bases to try when dereferencing
    > as long as references are only relative. For example, when working in
    > an I-D repository, there could be a fallback base that smoothes over
    > the differences between the draft being hosted locally and its
    > uploaded form.

Yes.

    > I'm not sure this solves all issues, but I think it might work. To some
    > extent it hinges on IETF documents being assigned stable canonical URIs,
    > though :-/

I think that we got that part for published RFCs.
We also mostly win for IDs, but many users of CDDL might have some internal
stuff that depends upon external (standard) things.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email