Re: [dtn] BPv7 CDDL and CBOR tagging

On Apr 6, 2019, at 22:04, Brian Sipos <BSipos@rkf-eng.com> wrote:
> 
> Carsten,
> My purpose of marking these potentially-tagged items in the CDDL is less for the BP agent encoder implementer to say “where should tags be" but for the bundle troubleshooting / validating tool implementer to give indication of "where may tags be" to have some value.

That is certainly useful.

> The CDDL itself is all informational, so it’s not an issue for the BPv7 spec itself.

By the way, you *could* now go ahead and make it normative, as the CDDL standard has been approved on March 25.

> The actual value in the tags themselves is not for the BP agent (the agent would just skip over the tags, as neither changes the block-data semantics of the tagged-item), but for troubleshooting with non-BP-specific tools.

OK.  I was also trying to gauge how important saving a few bytes is for you.  If you make the tags optional, there is less reliance diagnostic tools can have on them, but you also don’t have to spend the bytes in situations that are tight.  And v.v.

> I had earlier brought up to the WG the question of whether there is any value in registering a BPv7 media type. That was seen as unnecessary since bundles should only appear in a BP context (either at-rest or on-the-wire) and CBOR encoding itself already has a media type. I think a BP-specific tag would have the same amount of support, which is why my suggestion for a content-type hint on an encoded bundle is just the “yes it's CBOR” tag.

I’m still not entirely sure I’d forego that information (as in do a “file x.x” and get the information “bundle protocol bundle” vs. just “CBOR data item”), but I think I get this point of view, too.

Thank you for the quick reply!

Grüße, Carsten

> 
> From: Carsten Bormann <cabo@tzi.org>
> Sent: Saturday, April 6, 2019 08:25
> To: Brian Sipos
> Cc: dtn@ietf.org; Scott Burleigh
> Subject: Re: [dtn] BPv7 CDDL and CBOR tagging
>  
> On Apr 3, 2019, at 21:14, Brian Sipos <BSipos@rkf-eng.com> wrote:
> > 
> >        • 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.
> > 
> 
> Hi Brian,
> 
> can you indicate what the purpose of the tagging would be?
> 
> Tagging the whole bundle as 55799 would identify it as a CBOR data item, but not yet really as a bundle.  If the purpose is to facilitate working with generic CBOR tools on the data items, that may be useful if there are other formats flying around in the same space the bundle is being used.  If the purpose is to identify this as a bundle, why not go for a specific tag just for bundles?  55798 is still free…  Or any number that is even more visibly tagging (such as 25200, which would be visible in a hex/ASCII dump as ‘bp’, or maybe four-byte or even an eight-byte number).  I understand these tags would be stripped off for actual transmission through a convergence layer?
> 
> The encoded-cbor tag (24) is great for identifying embedded CBOR, but what do you do for the other kinds of block-type-specific data?  Sorry, it’s been a while since I looked in detail into the bundle protocol.
> 
> (Why is the CDDL in appendix B double-spaced, by the way?)
> 
> Grüße, Carsten
> 
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn