Re: [dtn] BPv7 CDDL and CBOR tagging

[Carsten Bormann <[e-mail]>]

On Apr 3, 2019, at 21:14, Brian Sipos <[e-mail]> wrote:
> 
> 		• A disconnect between the “canonical-block" definition and the "extension-block" and "payload-block" uses (which are just canonical-block type with value restrictions, probably using ".within").

Right, it would help to define payload-block and extension-block, and .within could be used to reference canonical-block (which is currently unused).

The text of 4.2.1 in -12 starts with a paragraph that ends in:

   The last item of
   the array SHALL be a CBOR “break" stop code.

A break stop code is not a data item, but is the part of an indefinite-length array encoding that ends it (the same change needs to be made in the second paragraph of the start of section 4).  So the text seems to be trying to say

   bundle = [primary-block, *canonical-block]

The CDDL in Appendix B is more specific:

   bundle = [primary-block, *extension-block, payload-block]

So there must be a payload-block as the last data item, and zero or more extension-blocks preceding it, which according to the text in 4.2.1 all need to be of canonical-block structure.

Is there something from the text about extension-block and payload-block that could be encoded in a CDDL definition of these two?

So far, I have found text that makes be believe

payload-block = ([block-type-code: 1, canonical-block-common, ?crc]) .within canonical-block

and

extension-block = ([block-type-code: (uint .ne 1), canonical-block-common, ?crc]) .within canonical-block

BTW, the CDDL for primary block ends in three optional components, two of which are of the same type, so it is not clear whether you have a primary-block with a fragment-offset but without a total-application-data-length or a primary block with a total-application-data-length but no fragment-offset.

Grüße, Carsten