CBOR working group conference call, 2024-04-17

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=07c8572a-d80a-45bb-92af-23febaaa8a12

WG documents status and issues

• more-control status and next steps?
  • positive feedback on the list: Ira, LL's addes split and b64 use
    (but sounds positive when all addressed)
  • AJS volunteering as shepherd, thanks!

CB presenting (based on older slides)

CB (p2): RFC editor progress around time tag document.
CA: On EDN and CDDL, I'm finishing the Shepherd write-up.

CB (p3): Laurence is re-rewriting the EAT part of a RATS document using
CDDL. He made several comments on the strictness requirements. We should
give more details and be more explicit on how strict they actually are
(related to RFC 4648)
CB (p3): PR on strictness is WIP, also thinking of where that content
should be.
CB (p4): Why .join is hard. There are two possible ways to implement
this; now trying both. PR waiting for implementation. But some .join
will be more difficult to process, eg. when no constant markers are
there. There is another way possibly requiring less code and about
parsing regexp, possibly out of the variable element and thus looking
for digits. I'd probably recommend that.

CA: Small correction: WGLC was extended, but with the latest input I do
consider that complete now given the feedback from AJS, LL and IMD
(assuming their concerns are being addressed, which is WIP). AJS has
volunteered as shepherd.

CB (p5, other documents): blocked by socket issue.

CB (p6): more ancillary documents, not urgent to be updated, but planned
to revise them before IETF 120.
CB: If you want to put things in there, tell us.

new work

• draft-bormann-cbor-e-ref-00 ready for adoption?

CB (p7): MT has used thyis mechanism in gm-admin (without normative
reference through duplication).

MT: PR is available. Addresses WG Last Call non-editorial comments
from Carsten. On using the e'' construct, I was originally biased by the
examples in the CBOR draft, as over-using it also for registered code
points, matter-of-taste choices about whether to use it there.
MT: Now using new notation for new code points only. Also used while
addressing IETF Last Call comments for
https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/
(see also the PR
https://github.com/ace-wg/ace-revoked-token-notification/pull/5 )
CB: Have you used the suggested boilerplate like if you are introducing
this construct yourself? (this avoids a normative dependency)
MT: Yes, with some rephrasing. That'd be the way to go for a while until
the CBOR draft gets approved.
MT: I support the proposal in the CBOR draft.

CA: cbor-e-ref has already received some positive feedback during 119,
starting WGA on list.

CB (p7): draft-numbers ("CPA" mechanism). Designed to never be
referenced in an RFC so it's just a downref before publication. Look at
it, don't think we need to publish, but may still be interesting to have
as WG document.

• (other documents)

CB (p8): Want to pick up speed on packed.
CB (p9): Skipping serialization disucssion today. Tag 201 -- need better
understanding of how tag and encoding interact (can it have the
semantics it describes?).

• quick heads-up for YANG metadata (RFC 7952) in YANG-CBOR

CB (p10): yang-standin in PoC stage, but technical substance stable.
Also interesting for high-performance/high-throughput applications. Andy
Bierman mentioned it'd be good to have metadata annotations, not mainly
for constrained space but in high-performance space. Instead of copying
JSON mechanisms, can replicate simplicity of XML version.
CB (p11): showing example with tag (CPA109). Draft not yet submitted,
linked on slides. Once believed ready, we'll submit v -00, question is
where. YANG-cbor was in the CoRE WG because it was the only reasonable
option; not the CBOR WG makes more sense. We'll have to discuss it,
involving also NETMOD in the announcement of the draft.
CA: Are there people in CoRE that can carry over here? We need YANG
expertise here for this.
CB: Andy would be useful; other people are using YANG-cbor in different
places. We need to reach out to them and have them joining.

MCR (chat): we probably need a YANG-CBOR roadmap wiki page.
CB: supports this ... maybe in yang-cbor repo.

• things outside CBOR

CB (p12): RFC 9542 published (BCP 141) including CBOR tags for MAC
addresses in IEEE 802. Also the work on CRIs in -core-href is ongoing,
with some issues left to solve. We define also a registry of integer
representation of URI schemes. Also working on test vectors. We will
have the CBOR WG in the loop when we reach WG Last Call.

CA, following up on YANG group question: "Familiar enough with YANG to
review YANG CBOR updates?"?

• raise your hand = 1
• do not raise your hand = 4
• no opinion = 4

CB: We surely need to get both the CBOR and YANG side right. It can
still happen in the CBOR WG.
CA: We really need to ensure that we have YANG feedback in this group,
otherwise ask netconf whether they'll have it and we provide CBOR
reviews.

AOB

Note taking: Marco Tiloca