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

[Wolf McNally <[e-mail]>]

Maria,

You might want to consider the emerging Gordian Envelope technology which is based on CBOR, and supports DEFLATE compression, which in our experiments yields better compression than packed CBOR, and doesn’t require knowing anything about the content in advance. If all you want is compressed CBOR, a Gordian Envelope adds only a few bytes of overhead, and it advertises the hash of the uncompressed contents.

https://www.blockchaincommons.com/introduction/Envelope-Intro/
An Introduction to Gordian Envelopes
blockchaincommons.com


> On Jun 7, 2023, at 3:35 AM, Maria Matejka <maria.matejka=[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor