CBOR working group call, 2025-04-30

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=2a809fd9-78af-4f73-8f19-7f3f6a7011bc

Please add items to the agenda below and flesh out the details.

We have discussion carried over from last time, so cancelling isn't likely.

AGENDA

WG documents status and issues

cde

There were discussions in list since last interim, should they be
continued?

CB presenting

CB: Still looking at CDE v -10, past WGLC but still waiting for some
comments.
LL: What's your timebox?
CB: Nothing clear to be done. I'm waiting for input from the WG.
LL: Some issues are still open.
CB: I'm not aware of those.
LL: They are on the Github and are not closed.
CB: If anything, there is nothing actionable for me at the moment.
LL: I have a few more to file, I can spend a few hours per day. If the
Chairs think that this is not useful, we can call it.
BL: Do you want to discuss any of those issues in this meeting? We can
start from it, especially if they were not discussed on the mailing
list. If new issues appear, they have to be discussed.
LL: There were back-and-forth comments on the mailing list.
RM: We can have screen sharing and go through the issues.

BL: Let's resolve what we can on the mailing list between today and the
next call where we can take decisions.
BL: Are we done with CDE for now?
CB: Yes.

packed

See
https://mailarchive.ietf.org/arch/msg/cbor/kbU6wU5X4x2EkIjLNYmxeOB-_fs

Vadim's slides
https://datatracker.ietf.org/meeting/interim-2025-cbor-08/materials/slides-interim-2025-cbor-08-sessa-vadims-slides-on-packed-00.pdf

• Tag composability:
  https://mailarchive.ietf.org/arch/msg/cbor/iPHSDPKUTokMTRokoKZMlbiowz4/

CB presenting

CB: Recently discussed a proposal for radically reducing the consumed
resources (i.e,. amount of registered tag numbers). There is now a PR

24 with the proposal "Radical" and a variant of it called "Economic".

These proposals are parameterized by a triple (A,B,C), for which I
proposed (12,8,8) that I think to be balanced.
CB: We need to discuss this, agree on something, and have experiments.
Then merge the PR, have another WGLC and request publication hopefully
in May.

RM: It sounds like there would be nothing wrong with having the triple
(0,0,0), which would be really radical. That makes sense to admit and it
does not clash with the requirements stated in the document. It's also
better to think of possible to characterize in terms better and more
precise than "balanced".
CB: People can look at applications they have for packed. The audience
for this doc is people coming up with CBOR-based protocols. They need to
decide between bespoke stuff (like SUIT did), or use common
infrastructure like the packed protocol. They people doing this
comparison will probably look at the numbers (overhead/efficiency)

RM: It's good to have early defined a way to determine whether we have
met our requirements, irrespective of the specific applications used for
testing.
ML (on chat): I can adapt dns+cbor and rerun my experiments with the new
packed proposals, but not before end of May.
CB: Would be good. We can spend time on this (thanks Martine!). I want
to hear from people using packed, what are their numbers?
ML: My application is very sensitive to variations on these parameters.
Trying to reach same compression rate or better as DNS name compression,
so reference size of 2 bytes or less would be great.

CB: Regarding Vadim's proposal. This is a new work item, nothing to do
with CBOR packed. Not sure it's on the same track. Have no draft for it.

VG: I have 2 slides with ideas specifically for CBOR packed.

VG (p1-3): Overview and recap of CBAR/CBAPT compared with packed CBOR.
Showing different proposals and their properties in terms of bytes and
structure.

VG: We don't have quantitative criteria. Explaining logic and his
preference on design approaches. Proposals of possible tweaks to packed
CBOR.
CB (on chat): it's redefining all that CBOR (and UTF-8!) is, which of
course can be done, but is quite different from cbor-packed.
VG: Not redefining, it's just an extension.
OS (on chat): It requires changes to the encoder / decoder correct?
CB (on chat): Yes

CB (in chat): No, it is not that bad. Great ideas, but not all fit very
well into CBOR
CB (in chat): Using the gaps in UTF-8 as a bytecode certainly is
innovative...

CB: This does not change the whole CBOR but all the invariants of CBOR.
It's in principle possible, but it is quite a different thing from
packed CBOR. Packed CBOR can do some re-interpratation, e.g., of the
referenced items depending on how the tables are set. Hard to look at
this without a complete spec, would need a draft. Good ideas but not all
fit into CBOR well.
VG: Byte code is not for CBOR packed, but for my proposal (CBAR/CBAPT).
Do you think that the tag composition proposed is problematic?
CB: Yes. Because allocated tags already have a meaning. E.g. changing
meaning of Tag 0 inside tag 6 is complex and hard for decoder to handle.

VG: If it's a generic decoder, it shouldn't be a problem.
CB: So you need a different decoder, not a CBOR decoder. So it's
changing all of CBOR.
VG: We don't know since nobody yet uses more than 1 tag on an item.
Considering questions in chat: It seems reasonable that a decoder that
doesn't understand this construction, it doesn't understand CBOR packed
and should fail. Agree that this is true?

MT (in chat): Nested tagging here:
https://www.rfc-editor.org/rfc/rfc8392#section-6

BL: Is this a direction we want to go?
VG: It was sent around on the list but not evaluated.
JH: I think we have decided from a requirements perspective that we're
doing a compression format? Assuming yes, I don't believe we have the
correct people in the room to do a compression format. If we're not
doing a compression format I'm not sure what we're doing.
CB: This is not compression in the sense of the normal meaning of
compression. It's a way to exploit redundancy in a CBOR data item,
giving the same results as compression. Does not require converting
compressed data into uncompressed data before the data can be operated
on. So it's different from compression from that point of view. It's not
a codec either. YAML has compression with anchors and another thing,
people often use it to reduce sharing in a data structure. CBOR packed
can do the same. This doesn't mean the data has to be re-coded into a
format that needs to be completely decode before operated on.
RM (in chat): You still need to "unpack" the packed CBOR before you can
process it.
CB: No since there are ways to implement this without requiring
unpacking before processing.

RM: I'm puzzled. Full processing vs. streaming? Can I do ordinary
processing on a packed CBOR doc without unpacking?
CB: A shared item is used in two different places in the tree. A same
representation can be shared by different sub-trees.
RM: Agreed, but that doesn't mean that you didn't perform an algorithm
on the packed data.
CB: Most people will understand "unpack" as build the original. Complete
unpacking of the data structure is not needed before you can use it.

VG: Packed CBOR is not for streaming applications, right?
CB: Not the first thing in mind. Can still be applicable probably

VG: So the main point is using the data without allocating an additional
buffer. My proposal (CBAR/CBAPT) also allows this.

BL: What do we need to resolve on packed to move forward?
CB: We need to set the values for the triple (A,B,C).
BL: Take it on mailing list. Is Vadim's proposal something we want to
discuss more on the list?
VG: Note that this is different from CBOR packed, could co-exist.
Explaining it all would probably take a whole interim.

BL: Does the WG want to proceed with it? If so, we can park it for now
until the 3 main items are under active discussion, and come back to it
later.
BL: Packed discussion can proceed on the list.

BL: Any further points for the next 10 min?
CB: People please look at the open PR for EDN. Could spend remainder of
time on points about EDN

RM: We were talking of app sequences in general and having a hash. What
about doing AEAD encrypt or HPKE-seal? Nice to be able to confirm a
value is as expected. Seems wrong to stuff into EDN. Better to have this
in CDDL. Keeping syntax-layer simple and adding complexity in next layer
up seems like a good approach.

CB: That's interesting. CDDL has as job taking care of the structure of
CBOR data. The hash app extension in EDN is about other things. In some
appications, that notation helps indicate the input of a hash instead of
the output.
RM: Have a way of doing this. Example: Put Tag on values to be redacted.
Pre-processor removes tag and turns data into a redacted disclosure.
Similar solution can be used for the hash. We can express this easily
with a new CDDL control. Can be done in a correct and strict way in
CDDL, which EDN cannot do. Have all things we need, without needing to
add new things to EDN. Adding too much to EDN is harmful to the adoption
of the ecosystem.

CB: Had an old paper on extension mechanisms, objective is not to create
some kind of "turing complete" bad programming language. We're going to
have an alignment/symmetry between EDN operators and CDDL in the long
run. Having something simple like app extensions is helpful.
RM: App extensions are not simple to specify correctly.
CB: Took me 20 min to implement.
RM: Anyone has an opinion? Would what I describe work? Using existing
mechanisms instead of adding things to EDN.
RM: Why not using CDDL to describe the semantics of cyphertext, hash,
etc.?
VG: Does not contradict EDN.
CB: Pretty useful to keep CDDL and EDN isolated, until we fully
understand the symmetry that are probably end up building.
RM: Not saying we put CDDL in EDN. Let the tool process the EDN and
CDDL, or the CBOR and CDDL.
VG: Would be excellent.
CB: You can use app sequences to tell your tool what to do.
VG: The tool would be good, but it's not a stop for EDN.
CB: We can explore more on the mailing list also using examples. Please
mostly look at PR #77 on addressing the remaining issues.
VG: I think that's the right direction. Merge the PR and go on.

edn-literals

Planning to have a consolidated ABNF for discussion that addresses
recent consensus (and two implementations for testing that)

People have noted that they need time to digest the very recent post, so
we should do that on the list and bring this back next time. The nest
session will focus on resolving CDE issues, and then coming to EDN if
there's time.

Also: https://github.com/cbor-wg/edn-literal/issues/76

BL: Can look at this next time to give people time to digest.

AOB

Note taking: Marco Tiloca, Rikard Höglund (others please help)