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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 10 April 2019 20:58 UTC

Return-Path: <brian.e.carpenter@gmail.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 E41CD120611 for <cbor@ietfa.amsl.com>; Wed, 10 Apr 2019 13:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zoNNpcCUY2Kd for <cbor@ietfa.amsl.com>; Wed, 10 Apr 2019 13:58:26 -0700 (PDT)
Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4889120610 for <cbor@ietf.org>; Wed, 10 Apr 2019 13:58:25 -0700 (PDT)
Received: by mail-pg1-x542.google.com with SMTP id g8so2278762pgf.2 for <cbor@ietf.org>; Wed, 10 Apr 2019 13:58:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gxgLCyuOEe0x8hJxV2pBug3xa4bdk0AVy+K+u+YLTec=; b=PvxBo1azqEZPbJ0UAy2XvRZAzbg87gaIglGgLV5pU4uQnxPOcz11QaBtU1naekZKxP zPEYZSrlnaksYdYFtwyzy4eEm+E2nXD1BcPmi2PTcHMQfFvOBMyvrTcmkEMxVC4bv/D7 f9MlyiBjea3WHcykj5gPWFhoizzLeOBHUpTZG/wMx8L77PSOcRnphFZrPd1QEtSdjMoS rLrOh9722kbNZ/SwpfGsIdXxNje9JIHdTxLQtPVCCTbwjSgMmsbJeqY3tEOatF6gaQpt KjQtkfGqnpcpx8Djl5esyVmz1w6iS9Eg6IRQYePxcBayN4oS5ylxVJCgVwoJLfXA48fX pvGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gxgLCyuOEe0x8hJxV2pBug3xa4bdk0AVy+K+u+YLTec=; b=nt2LB/SN0SFnNHfQ21fgmuwhZpMqtEewGDOP2R1rxlSp/4ObA71solR776BDDyQs0W /QjgESO0OTtca8D0GAlp4sYqgPHjdw4Q97ci6iyzkbMHUGy7yqjrpaZ9J24jNKzJd/Y8 l9iBDxW8fh11x2ZtYZfQ2WxGLzdZUxTEC3sx5xX3c10lENS69Xe04woWTPWLWhmAWQWq NJQNpLjdFpPOIWFknQ/lSYtnXO07Gwwh7VqJUuDC8hGNE4xY+9u8lAfa65UbbrCyChmJ 6+2JpHA4f61e7pUoXy6WpYqQ1UICbdRl2pmbCSII58ymjiv8Vu6K6JBPY5QLNp/UTlDt s4rg==
X-Gm-Message-State: APjAAAX6NLpM0RQLlFMNbNBIrFWV208H1vMTe3yCJcPBd0U3Ik2N26O5 pDrZF3ZXtL8veyroNucMQjU=
X-Google-Smtp-Source: APXvYqwczCDUMfkxwrVuo5OhbCgtQsLsSFOHbv9TXgKyIkYDmkOlVee/ShvN/o/IyjFvoRAt65oWQw==
X-Received: by 2002:a65:62d2:: with SMTP id m18mr43303468pgv.122.1554929905141; Wed, 10 Apr 2019 13:58:25 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.95]) by smtp.gmail.com with ESMTPSA id t82sm98071586pfa.153.2019.04.10.13.58.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 13:58:24 -0700 (PDT)
To: Carsten Bormann <cabo@tzi.org>, Brian Sipos <BSipos@rkf-eng.com>
Cc: cbor@ietf.org, "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>
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> <508CCE17-8C7A-4FF1-8A19-992FCA5F5686@tzi.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <d6e93528-a5a1-e926-9e2b-e19ce5498013@gmail.com>
Date: Thu, 11 Apr 2019 08:58:19 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <508CCE17-8C7A-4FF1-8A19-992FCA5F5686@tzi.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/phYN6ZA5ZV4IbQOAOYvb_o_H1Pc>
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 20:58:28 -0000

I've dropped dtn since I doubt if they'd all be interested
in my comment.

I realised when reading this that I could definitely have used
optionally-tagged-embedded-cbor in GRASP. In fact I implemented
it in my code, when I realised that in some cases a user of the
GRASP API might be tempted to pass in a CBOR value. It's a bit
ugly, excuse my Python:

    if tname(_val) == "bytes":
        #see if user supplied value as CBOR bytes
        try:
            _ = cbor.loads(x.value)
            #seems to be valid CBOR, build Tag 24
            _tag24 = cbor.cbor.Tag(tag=24)
            _length = len(_val)
            #be lazy, don't optimise CBOR encoding
            if  _length<65536:
                _tag24.value = bytes.fromhex('59')+_length.to_bytes(2,byteorder='big')+_val
                _val = _tag24
            else:
                #byte string too big, we'll send the raw bytes
                pass
        except:
            #not valid CBOR, we'll send the raw bytes
            pass

(And some more messy code for de-tagging at the other end.)

Regards
   Brian Carpenter

On 10-Apr-19 20:58, Carsten Bormann wrote:
> (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.
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>