Re: [Cbor] [dtn] BPv7 CDDL and CBOR tagging

Carsten Bormann <cabo@tzi.org> Wed, 10 April 2019 08:58 UTC

Return-Path: <cabo@tzi.org>
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 2C95E120383; Wed, 10 Apr 2019 01:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 b32OkE8fGMlo; Wed, 10 Apr 2019 01:58:18 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331A71202BB; Wed, 10 Apr 2019 01:58:18 -0700 (PDT)
Received: from [192.168.217.106] (p54A6CE73.dip0.t-ipconnect.de [84.166.206.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44fJ3C73lRzygC; Wed, 10 Apr 2019 10:58:15 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1069e920de24c960ca46b3172d99db44802a3b2b.camel@rkf-eng.com>
Date: Wed, 10 Apr 2019 10:58:15 +0200
Cc: "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>, "dtn@ietf.org" <dtn@ietf.org>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 576579493.5323679-46df80c43ad0966b7ac4fb4acd68f1b1
Content-Transfer-Encoding: quoted-printable
Message-Id: <508CCE17-8C7A-4FF1-8A19-992FCA5F5686@tzi.org>
References: <CY4PR1301MB20399B0DD6B59D2D566257379F570@CY4PR1301MB2039.namprd13.prod.outlook.com> <B8DF4499-2EEC-4680-B1AD-9FEF00A907D7@tzi.org> <6773e0f0e03e6e4ddb935f0f02de7ade2bc606b8.camel@rkf-eng.com> <670af7e65e8c4746947b0833690f4625@jpl.nasa.gov> <1069e920de24c960ca46b3172d99db44802a3b2b.camel@rkf-eng.com>
To: Brian Sipos <BSipos@rkf-eng.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/dWTwPWLwGfFvxtGDbkFbs_2PJkc>
Subject: Re: [Cbor] [dtn] BPv7 CDDL and CBOR tagging
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, 10 Apr 2019 08:58:23 -0000

(CBOR WG: replying on
https://mailarchive.ietf.org/arch/msg/dtn/3qn38t9lYR_e-7IicyARKfimLPk
as this is an interesting use case of specialization.)

Thanks!  This already looks pretty good (once I fix the three cases of line-wrapping).

> On Apr 10, 2019, at 04:17, Brian Sipos <BSipos@rkf-eng.com>; wrote:
> 
> The reference program can be tested as in:

For me, the tool has the problem that it can’t generate

 (block-type-specific-data .cbor ext-data-hop-count)

With the former being

block-type-specific-data = bstr / #6.24(bstr)

What you are trying to say is that the bstr in there conforms to “.cbor ext-data-hop-count”, but the tool is applying the .cbor to the choice, and its brain is too small for that.

I think some unraveling is required to properly address this.

I would probably define a generic for this (sorry for the long names):

optionally-tagged—embedded-cbor<T> = T / #6.24(T)

block-type-specific-data = optionally-tagged-embedded-cbor<bstr>

And then, e.g.:

$extension-block-structure /= [
 block-type-code: 7,
 extension-block-number,
 block-control-flags,
 crc-type,
 optionally-tagged-embedded-cbor<(bstr .cbor ext-data-previous-node)>
 ? crc-value
]

OK, for readability maybe add

embedded-cbor-optionally-tagged<E> = optionally-tagged-embedded-cbor<bstr .cbor E>

and then 

$extension-block-structure /= [
 block-type-code: 7,
 extension-block-number,
 block-control-flags,
 crc-type,
 embedded-cbor-optionally-tagged<ext-data-previous-node>
 ? crc-value
]

That is not wonderful, as it repeats the fact that the thing is optionally tagged “embedded CBOR” all over the individual block type definitions, but it starts enabling focus on the actual structure again.

(I’m still not entirely convinced that the tag 24 here is very useful, but I’m trying to play along the design.)

Grüße, Carsten


PS.: If I were writing this, I’d also add

extension-block-of<N, T> = [
 block-type-code: N,
 extension-block-number,
 block-control-flags,
 crc-type,
 embedded-cbor-optionally-tagged<T>
 ? crc-value
]

And then just say

$extension-block-structure /= extension-block-of<7, ext-data-previous-node>

but how much abstraction to add is a matter of preference; this at least gets rid of the “sprinkle the structure all over the place” problem.