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

[Brian E Carpenter <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor
>