Re: [Cbor] CDDL Module Design

Jim Schaad <ietf@augustcellars.com> Wed, 01 July 2020 05:17 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 370AE3A0D04 for <cbor@ietfa.amsl.com>; Tue, 30 Jun 2020 22:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2IeRwk2aj3tf for <cbor@ietfa.amsl.com>; Tue, 30 Jun 2020 22:17:03 -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 A4EA93A0D03 for <cbor@ietf.org>; Tue, 30 Jun 2020 22:17:02 -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 22:16:38 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Michael Richardson' <mcr+ietf@sandelman.ca>
CC: cbor@ietf.org
References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost>
In-Reply-To: <24433.1593575640@localhost>
Date: Tue, 30 Jun 2020 22:16:35 -0700
Message-ID: <03db01d64f66$cc797a20$656c6e60$@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: AQJ5T9b3i55/+CwwqSdD3kqEjEw/wAJfVF68p5kow9A=
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/frIBrgPmwlxgE5GL74zXvk0YHG0>
Subject: Re: [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 05:17:05 -0000


> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: Tuesday, June 30, 2020 8:54 PM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: cbor@ietf.org
> Subject: Re: [Cbor] CDDL Module Design
> 
> 
> Jim Schaad <ietf@augustcellars.com> wrote:
>     > 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.
> 
> Doesn't the version problem also include the "DLL hell" problem?
> That is:
>      module A includes module B.1 which includes C.1
>             A includes module D.1 which includes C.2
> 
> and who knows if C.1 and C.2 can be used at the same time?
> 
> So I totally agree that this is a problem.
> 
>     > 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.
> 
> I think that this is probably a very elegant solution.
> 
>     > 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?
> 
> A think that I dislike about the ENTITY stuff in XML is that the URLs are
way
> too specific.   Do you want avoid that?  Will it be some URN space?

I was thinking about the question of doing a URN instead of a URL - hence
the term naming scheme.  The interesting question is how should the naming
be done and what short of mapping is needed.  One of the nice things about
DOIs is that they can be used as an indirect reference with a well known
server to get actual URLs

> 
>     > 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
> 
> Can you give an example of (b)?
> I think that Python mostly got this process right.

(b) is just - don't define any conflicts between what I am importing and
what I have written in the text.  If I am going to use COSE_Signed as an
import, then I really should define a different symbol in the current CDDL
file by that name.  

> 
>     > 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?
> 
> No. It just leads to stupid work arounds.
> _ for things that should not be exported, but not enforced.

I tend to agree with this.  One of the interesting questions would be
transitive imports though.  If module A imports COSE_Signed from module B
can module B import COSE_Signed from module B or must it reference module A.
I remember the first time I figured out that ASN.1 allows this and to be
frank I found it somewhat irritating.  It does allow moving symbols between
modules, but that has the potential to break other modules suddenly.

> 
>     > 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.
> 
> I prefer that the statement not be a pre-processor-like hack.

The interesting question then, is how much do we want to change the CDDL
language.  If we do pragmas this is a standalone document.  If we do changes
in the grammar then it is harder to make this standalone.

> 
>     > 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.
> 
> I don't understand.

Suppose I write a CDDL compiler - called my_great_cddl_compiler and Carsten
writes one called no_so_good_cddl_compiler.  I could reference pragmas as
ME:UseInt32 and CB:UseInt32 as separate pragmas in the same file and each
compiler would recognize that one that it implements and do the right thing
(which is to use some int sized at least 32 bits?)  They could have
different behavior for the same name.  

> 
>     > 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.
> 
> This is useful at the top-level file.
> Particularly for a group of people who are working together.
> For "location on my machine", I think that I'd rather be providing a
command
> flag, but I don't object to having ../.. paths or
https://my.little.server.example/
> in a file.

Another one at the top level might be to use one of the more interesting
things that the OSS compiler does is to allow one to say - This is the list
of symbols to emit which can be used rather than either emit everything or
emit the first symbol in the file which made me do some really strange
things in the COSE CDDL.

Jim


> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -
> = IPv6 IoT consulting =-