[dtn] BPv7 CDDL and CBOR tagging

[Brian Sipos <[e-mail]>]

This is addressed mostly to Scott B, but also to the WG for discussion,

The CBOR Data Definition Language (CDDL) has now advanced to the "Submitted to IESG" state, and appears to have been refined since the BPv7 Appendix B [1] was originally written. I would like to update the Appendix B to:

  1.  Fix some typos:
     *   The type "dtn-time" should allow negative values so type "int" instead of "uint"
     *   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").
  2.  Indicate some likely places where CBOR tags can be used to augment encoded bundles for troubleshooting. In my mind, the reasonable tag sites are:
     *   Tagging the whole bundle as "#6.55799(bundle) as a sentinel for content-type-scanning tools.
     *   Tagging the "block-type-specific-data" as "encoded-cbor = #6.24(bstr)" when it is in fact CBOR.

Additionally, there was a question brought up to the WG in November 2018 about the almost-typical-but-not-quite use of URIs in the EID encoding. In my first read-through of the draft (having not had direct experience with RFC 5050 implementation), I thought that the EID was an actual URI rather than a compressed form of a small subset of URIs in the "dtn" and "ipn" schemes. I see the value in having a compressed form for some specialized URIs, but there is currently no way to encode as an EID something which is 'just a URI'. Is the intent here that "all EIDs are URIs" but not "all URIs are EIDs"? Is there any value in having an EID code for "just a URI" or is prohibiting a generic URI intentional?

Thanks,
Brian S.

[1]: https://tools.ietf.org/html/draft-ietf-dtn-bpbis-12#appendix-B
[2]: https://tools.ietf.org/html/draft-ietf-cbor-cddl-08#section-3.9