Brian E Carpenter <[email protected]> wrote: >> You've used values >256. CBOR won't restrict you to just integers. >> You could strings, or even complex objects like an array, like for >> instance: [{TCP,UDP},{CoAP,HTTP,HTTPS,OSCORE,EDHOC}] (as the pattern: >> [TCP,HTTPS] being a single value)
> Yes. Doing that would be very natural for Python with its
> happy-go-lucky approach to typing, but I guess it would be a little
> more complicated for strongly typed languages.
1. Very early days still for GRASP.
2. My CBOR experiences with Rust and C is that they all would return some
kind of CBOR object, and I have inspect it anyway to make sure it's an
int before I can pull the int out.
(And Rust forces me to do _something_, when it's not an int)
> (The SDP proto registry has things like "UDP/MBMS-FEC/RTP/SAVP" in it,
> so their problem was clearly similar.)
Could we reuse that?
>> I know we struggled with something similiar as the BRSKI transports
>> multiplied. Where did that text go... ah.. into brski-discovery,
>> section 3.5.2.2. We used/adapted the last parameter of the objective,
>> the objective-value, to disambiguate. I'm not entirely happy with
>> this. I would adapt your work here into brski-discovery.
> Sounds good. PRs welcome (or should it be a separate draft?).
I'm not sure at this point.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
