Re: [Cbor] Using packed CBOR in BIRD's custom protocol

Hi Maria,

This is a very interesting use case, thank you for bringing it to the WG.

The idea behind CBOR-packed is that we have a common unpacking mechanism, but leave room for multiple table (dictionary) building mechanisms; the CBOR-packed spec only provides a basic one (as a “batteries included” starter kit).
So you definitely are not bound to tag 113 if you have a different way to build the table.

The nesting behavior of tag 113 is really of interest if you have a common dictionary to which further instance-specific updates need to be made.  You wouldn’t necessarily use tag 113 for the outer dictionary — that might come from an application-defined tag or even from the knowledge of the media type (or other context).

I don’t think 28/29 are a good way forward, as they rely on order-preserving processing, which may not be supported by a CBOR library.

You do know about tag 52/54?  (RFC 9164.)
Do you have an example where length indication (beyond what a byte string already does) would lead to easier data management?

Defining a representation of BGP attributes in CBOR is a valid subject of an RFC.
That could define tags, but your actual use of this might elide them (which would be seen as an “unwrap”, ~tag, in CDDL).
Note that the BGP YANG project already provides such a representation (via YANG-CBOR); that may or may not be expeditious for your use.

This message is just a quick response; we could pick up this subject in one of the next interims of the CBOR WG (next: 2023-06-14).
Let’s prepare that with a few messages on the mailing list.

Grüße, Carsten

> On 2023-06-07, at 12:35, Maria Matejka <maria.matejka=40nic.cz@dmarc.ietf.org> wrote:
> 
> Hello!
> 
> We're planning to implement a machine-friendly protocol for common and generic communication between BIRD and the surroundings, like GUIs and CLIs or automation machinery. (Currently, everybody is parsing our CLI, which is an awful mess.) We decided to go with CBOR and I'd like to consult with you whether our way is reasonable, and also ask some questions, as we're newbies in this area, if you don't mind.
> 
> We're definitely going for the packed CBOR as our data can easily get annoyingly big if not packed. Yet we typically don't know the actual contents of the dictionary when starting to pack – and we don't like caching the data either before sending it to generate the dictionary to the beginning. Is there any possibility to send dictionary updates? I'm quite confused by the wording of section 3 of draft-ietf-cbor-packed-08 – at least my concerns are partially relieved by the Appendix A. I'm reading it this way – when we have anything to pack, we open a new 113-tag enclosing the rest of the message … and as soon as we find something more to add to the dictionary, we nest the 113-tags and we put the new values to the end of the dictionary by explicitly marking them by their tags. Is this a valid understanding of that section?
> 
> Or should we better go for value-sharing by Marc A. Lehmann with tags 28 and 29 in this kind of setup?
> 
> For the in-socket format, I'm also missing a possibility to explicitly say "the following object (data item) is exactly N bytes long" to allow for easier data management – shall we define this functionality and register it as a tag?
> 
> And also we're going to encode routing information (like BGP attributes) which may need a standardized representation, yet it's just a map (in case of one route) or a map of maps (full RIB). I think that in this case, it doesn't deserve a tag, yet it may be handy to write an informational RFC about that. Is this the right way to go?
> 
> Thank you for helping us.
> 
> -- 
> Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor