[Cbor] CDDL Module Design

Jim Schaad <ietf@augustcellars.com> Wed, 01 July 2020 00:52 UTC

Return-Path: <ietf@augustcellars.com>
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 3F9843A0842 for <cbor@ietfa.amsl.com>; Tue, 30 Jun 2020 17:52:28 -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, 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 gRKsIHS4IHqo for <cbor@ietfa.amsl.com>; Tue, 30 Jun 2020 17:52:26 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3153A083F for <cbor@ietf.org>; Tue, 30 Jun 2020 17:52:26 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 17:52:21 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: cbor@ietf.org
Date: Tue, 30 Jun 2020 17:52:19 -0700
Message-ID: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
thread-index: AdZPP7lFcxcs7rTWQ96MobGVRLmIuA==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/BayziLDbvL8zghvYYqsdJpiTp-0>
Subject: [Cbor] CDDL Module Design
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Jul 2020 00:52:28 -0000

Here is a topic that we can potentially discuss tomorrow if there is extra
time on the agenda.

When looking at a CDDL module design, there are a set of questions that I
think need to be addressed:

1.  What is the naming scheme to be used?  Both XML Schema and ASN.1 use
unique identifiers for a module.  The problem with this approach is that a
revised module has a new identifier even if all of the changes were
preserving of the old module.  This can also present problems if two
different versions of the same module are used as it can be difficult to
know which version of a module is being provided.   I think therefore it
would be nice to have a naming system that recognizes version numbers, but
can be used with a "latest version" mode.  One possible way to do this would
be to use a query parameter to get a specific version of a module while
without the query parameter the compiler grabs the most recent version it
has.

2.  Do want the naming scheme to be used to access a module name from the
web, and to create a server to host all of the IETF based CDDL modules?

3.  For any number of reasons we need to be able to state that some symbols
are going to be imported from a different module.  There are some issues
around doing a couple of other things:
*  If all symbols are imported then you either need to have a module based
naming system or you need to ensure that there are no collisions.
*  If only specific symbols are imported, then they could either be a) made
to be unique by renaming or b) made to be unique in the current module
simply by how the module is written

4.  ASN.1 has a method to say that only specific symbols can be exported
from a module.  I have never used this capability and I am not clear that it
would be useful to have here.  Should we support it anyway?

5.  How should the system be setup to be able to recognize this capability.
The suggestion in the freezer document currently is to use a pragma system.
Introducing a pragma system can easily be seen as a step to allow for
compilers of CDDL to be written.   The A2C compiler that I wrote used --#
and #-- as the start and stop delimiters for pragmas as "--" is the
start/stop comment character.  (ASN.1 is not line based so there is no
comment till a return.)  A similar approach can easily be used here.

6.  If we use a pragma naming system, do we want to setup in advance for it
to have namespaces so that a single module could be used with different
compilers.  I ended up using a different string  than the OSS compiler did
("--<" ">--") to be able to do this but having a namespace could also
support this.

7.  What set of pragmas are we looking at to start with.  XML Schema has
some attributes that can be used for controlling the compiler.  One of this
is a location hint attribute which can be used for giving alternate
locations to use for finding a module (such as a location on my machine).
There might be some other pragmas that might be useful to specify as well.
It might be easier to specify co-occurrence constraints using pragmas rather
than trying to put it directly into the language.

Jim