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 =-
- [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Michael Richardson
- Re: [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Michael Richardson
- Re: [Cbor] CDDL Module Design Jim Schaad
- Re: [Cbor] CDDL Module Design Carsten Bormann
- Re: [Cbor] CDDL Module Design Michael Richardson
- Re: [Cbor] CDDL Module Design Carsten Bormann