#5 is discussing the general serialization format, but also mixes in the dev ux related discussion points.
My take-away from the discussions at IETF 126 was that people were pointing towards CDDL and defining CBOR and JSON in one CDDL. Make sure it is clear that we use CBOR over the wire, but have a clear definition of JSON representations for configuration, debugging, etc.
Copied over from the other issue:
If we use integer based maps in CBOR, we could in theory define in CDDL values that are different between CBOR and JSON representation which would allow us to define keys in the map that are different from CBOR (integer) and JSON (string). Taken from cbor-wg Wiki:
JC<"v", 2>
binary-value = JC<base64-string, bstr>
JC<"v",2> defines the value as "v" for JSON and 2 for CBOR.
RFC9741 introduces control operators that allows to express things like base64 encoding in CDDL:
signature-for-json = text .b64u signature
signature = bytes .cbor COSE_Sign1
#5 is discussing the general serialization format, but also mixes in the dev ux related discussion points.
My take-away from the discussions at IETF 126 was that people were pointing towards CDDL and defining CBOR and JSON in one CDDL. Make sure it is clear that we use CBOR over the wire, but have a clear definition of JSON representations for configuration, debugging, etc.
Copied over from the other issue:
If we use integer based maps in CBOR, we could in theory define in CDDL values that are different between CBOR and JSON representation which would allow us to define keys in the map that are different from CBOR (integer) and JSON (string). Taken from cbor-wg Wiki:
JC<"v",2> defines the value as
"v"for JSON and2for CBOR.RFC9741 introduces control operators that allows to express things like base64 encoding in CDDL: