CBOR working group conference call, 2022-02-23

Agenda and notes:

Minutes: Marco Tiloca, Christian Amsüss

CB: Got a mail from Robin Marx also asking the right questions. Will follow this a bit and write it up in an ID. Might become seeds of “using CDDL” text.
CA: Would be good to happen. Anything suggesting they are approaching a CDDL limit?
CB: Seems they have everything they need; to some extent a matter of “how to put CDDL in an I-D”. What we don’t have is a a perfectly working CDDL tool.
CA: Would be good to accept CDDL as a formal language for IDs.
CB: Can press for that when we have CDDL tool that’s up to speed. We can already do syntax checking, but validation and/or generation would be much better. QUIC picked up the generating-instances aspect. What isn’t done yet is ensuring full coverage in generated instances.

CB: Got a reminder on a proposal on having tags for compiler managed data items. Languages like Haskell thrive on things like that, would be good to have that supported in the compiler. Now added to the draft. Need for more eyes on this before asking IANA to take actions.
CB: Also problem-statement tag proposal around and to be picked up again.
CA: Helpful to say something on their semantics (e.g., on different stability guarantees from different protocols).
CB: please mail. (done)

MCR: So what’s the precise question?
CB: “Is the text in notable-tags good?”

CB: … and side discussion on “tunneling through JSON” … and cbor2diag has something for that (testing which resulted in new version of that feature); needs more experience, so not proposing to standardize now.
CA tongue-in-cheek: Other way than packing binary CBOR into a string?
CB: Might be an efficient way.

CA: Sent out a mail to the list on this where explaining a use case.
CA: proposing 88887([“cri”, [-2, …]]), 88889([“cri”, “http://”]) <=> cri’http://…’
CA: Especially latter would be useful for separating the concerns of processing and representing EDNs.
CB: 88887 would be useful; keep a structured indication of having a CRI around.
CA: No harm in registering; tools implementing those is a separate thing
CA: especially helpful in languages
CB: Need to think of effects in real protocol exchange.
CA: Same for 888; diagnostic tools may want to scream when they see this.

CB: More general concept of annotations … putting something at CBOR that can be ignored at application level but that provides add’l information for other applications like diagnostic processors. No previous thought on indicating annotations, but good they are visible as such. MUST PROCESS vs CAN IGNORE thing.
CB: Would be good to identify that as general concept.

CB: Looking at examples in docs we use, tools like cddl-tool already have annotations in diagnostic notation (as comments); again, a place to be able to hand that over.
CB: That’s a way if annotations are used for verifying CBOR.
CA: If we do this in a reifying way, we may want to do it simultaneously with CDDL (to not have the divergence we have in diagnostic notation).
CB: CDDL 2 builds a parallel tree for annotation, looking structurally like the CBOR tree but with annotations in it.
CA: can look into what YAML does there.
CB: For CDDL used instance variables … but only works for boxed types, and floats can’t do that in the Ruby implementation.
CB: But would need to transport these instance variables…
CA: … and then need a wire format for that.

CA: Annotations can be applicable to many tags, we might need to retrofit annotations anyway.

CA: Any pointer/experience to share on storing/expressing CBOR metadata?
CB: I’ll need to ingest the YANG metadata mechanism; they did something very XML-specific and made it available to JSON too.
CB: And in SDF there’s “mapping file” idea, with separate file containing pointers to main file. Think it’s a common pattern.

CB: Still one interim meeting on March 9?
CA: Yes, let’s keep it that way, also good since not meeting at IETF 113.


[CB]: Carsten Bormann
[BL]: Barry Leiba
[FP]: Francesca Palombini
[IMD]: Ira McDonald
[MCR]: Michael Richardson
[CA]: Christian Amsüss
[MT]: Marco Tiloca
[PP]: Philip Prindeville
[ST]: Sean Turner