CBOR working group conference call, 2023-02-21

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=850007b6-efbb-4aba-9591-d3b99ec8666d

Stand-in values in CBOR (MM, moved from last interim that was possibly cancelled)

https://datatracker.ietf.org/doc/draft-bormann-cbor-yang-standin/

CB: Just sent -00 without coordinating with Maria.
CA: Good enough for discussion today?
CB: Not really; it has a number of issues, and more are in the repo.
They're hard do discuss without having read the document first.

CB: The draft defines some terminology, e.g., "intermediate encoder" for
YANG CBOR. We need to discuss this in itself and the model where this
happens. It matters if client and server are aware that this is going
on.

CB: And 2nd question ... do we need to do anything in YANG? Shouldn't
require anything in each module, b/c that'd prevent any deployment, but
maybe we still want some YANG extensions.
CB: 3rd thing: Union handling. YANG CBOR went through hoops to enable
that, not sure all bases are covered there.
CB: But PoC is complete enough it could be implemented now. Could be
implemented in MCR's work to try it out.

CA: Thanks for the summary; yes, this is best discussed after reading
the document. Comments are welcome.

packed

CB: MG had good input for packed -- deep thinking editorial comments.
But also made a technical proposal, folding in the "record" proposal
into packed: Can have a function tag in the dictionary that tells what
the map key values are, and at place where they are used you put the
values. This compresses a lot of things, including the current examples.
See recent mail to the group. Good stuff, should go in somewhere, but
decide whether we want to do this as-is or think more and do it in
separate document.
CB: Wait-and-think is a good thing, but doing packed with
batteries-included may be more CBOR-style.

MG: All was covered. The idea was a dictionary as an array, then
referring an entry points to an array again. If some keys/entries are
unneeded, they can be at the end, or otherwise use the CBOR simple value
undefined.

CA: Does the below match with your proposal?
compress-tag([42, 23]) expands to {"first": 42, "second": 23}

CB: The tag is in the dictionary.
CA: So the tag is one of those allocated for compression.
MG: Yes.
CA: I think this was discussed before.
MG: Yes, I saw that on the mailing list. It ended up in a tag
definition.
IMD (on chat): I like the proposal - I also like inline undefined simple
value as simplest representation
CA: I think the original discussion became more about extensions to
support larger things in the dictionary. This is an instance of that.
CA: I'm not sure if this is really something for packed CBOR, or
something using an extension point of packed CBOR.
CB: Didn't check in full yet, but I think it's a pure use of the
extension point. It's more about, do we build on the same document or on
a different one?
MG: See it that way too.

CB: Relatedly (see also list), given we now have a number of things
people may or may not want to implement, do we need defined subsets?
("Profiles" even though despising the word)?
CA: Discussed this around CRIs and CoRAL; not interested in compression
that can't happen in a constrained way. I was thinking more of an
application defining the profile. Having common subsets as profiles can
make sense.
CB: Indicating required or present capabilities will come up often.
Should we address that in packed? My favorite subset is "just sharing,
no functions".

CA: Describing that subset as recommended/suggested for small
applications would be good. The threads you mentioned are quite recent,
can't conclude here, discuss on list now that there is good awareness.
CA: The exact sentinel value to use as undefined or null is open for
discussion.
CB: Better to avoid null; undefined is better. An alternative is a new
Simple Value absent, which likely has meaning only in the context of
packed CBOR. Undefined would be mostly ok anyway, even though there is
no such concept in JSON.
CA: Could still be used in other places, but yes, if it's new it's less
likely.

CB: Next step, respin document w/ MG's editorial comments
MG: I can write it up.
CB: Contributor or co-author?
MG: Not sure if sufficient for co-authorship.
CB: Depends on what else you want to contribute, on editorial side,
useful.
MG: I'm working on Packed CBOR; if I find more stuff, I can surely
provide more content. Not sure I have to decide now.
CB: Not urgent; what do the Chairs think?
CA: One more co-author would be appreciated. Please coordinate with CB,
then can get back to this also on the mailing list.

IETF 119 (Brisbane) agenda

• Report on RFC editor status of draft-ietf-cbor-time-tag-12

• (draft-ietf-cbor-edn-literals-08 and
  draft-ietf-cbor-update-8610-grammar-03 should be with IESG by then)

• It seems the CBOR slot is free of management WGs, so maybe we can
  draw in some nm/ops people to a discussion of the standin draft.

CA: This was mostly to inform people about changes happening to CCDL. It
should work well, and likely take half of the CBOR session.

• cbor-packed received some fresh energy and should be in a state
  where we can discuss next steps

CA: There will be things to discuss, hopefully with both CB and MG as
co-authors.

• draft-ietf-cbor-cddl-modules-01 and
  draft-ietf-cbor-cddl-more-control-01 are in a state where we could
  ship them or add more.

CA: These go together with the CDDL cluster
CB: Getting ready, timeboxed to end-of-February. modules will have new
version soon, more-control raises whether there is to do this round.
CA: If something comes up great, otherwise next round. Depending on when
you submit the next revision, they might be in WGLC around the IETF
meeting.
CB: Ideally to have the WGLC results available to consider at the IETF
meeting.
CA: If we start WGLC now, we can have results by the cut-off deadline,
but we would be cutting the timebox now and possibly postponing some
things to be considered after WGLC.
CB: 2 weeks from now is already after the submission cut-off.
CA: If you think it can be in WGLC-shape today or tomorrow, we can issue
a shorter WGLC.
CB: Sounds good, will do.
CA: So at the IETF meeting we should be around the shepherding step. Not
urgent to decide about that, let's start with the WGLC.
IMD (on chat): I plan to do reviews for all CBOR WGLCs.

CA: Please contact users of these documents to solicit reviews.
CB: I got questions on -cbor-cddl-modules, so I can start asking them to
give comments on -cbor-cddl-more-control too.
CB: On more-control, it's about having things more open because then you
can do things more easily.
CA: I don't see compelling reasons not to do this, but from a
Shepherding point of view I'd like to see use cases behind it and people
enthusiastic about it.
CB: Came up in a use case, can try to find out what it was.
CA: That'd make everything easier.
IMD (on chat): I think testers and (actually) developers really need
more control Printf
CA: IMD, please provide pointers about it as you see fit

• other items from dispatch.

CA: I think that the topic on graph structuring will go through one more
round of dispatching. We can reserve some flextime to possible cover
that during the CBOR session.

CB: I didn't mention -cde that has some more editorial work in the
queue, but it's something that we can also cover.
CA: Let's not have it as full item, or we will exceed the available
time.

AOB

IMD (chat): I plan to do reviews for all CBOR WG LCs

Note taking: Marco Tiloca