# CBOR working group call, 2026-01-21   {#cbor-working-group-call-2026-01-21}

Meetecho: https://meetings.conf.meetecho.com/interim/?session=35048

## Please add agenda items below.   {#please-add-agenda-items-below}

## If there is nothing concrete on the agenda by Tuesday afternoon, the Wednesday call will be cancelled.   {#if-there-is-nothing-concrete-on-the-agenda-by-tuesday-afternoon-the-wednesday-call-will-be-cancelled}

# AGENDA   {#agenda}

## WG documents status and issues   {#wg-documents-status-and-issues}

### Intro   {#intro}

PH doing introductions.

PH: I asked not to make comments on the GitHub (e.g., on PRs). I got
pushback but confirm my request. These comments should be on the mailing
list as more helpful to build consensus in an inclusive way (and also
thinking about the later WG Last Call).

LL: Fine to me to use GitHub comments for fixing typos and so on. But I
also prefer the mailing list for discussing actual content.

### Serialization...   {#serialization}

-- Updates on issues and PRs for serialization draft

-- Discuss what the serialization draft recommends for libraries,
designers and implementers

Presented slides:
https://datatracker.ietf.org/meeting/interim-2026-cbor-02/materials/slides-interim-2026-cbor-02-sessa-draft-serialization-status-update-and-discussion-of-recommendation-for-ordinary-serialization-00

LL presenting

LL: Still 16 open issues, some with related open PRs.  
LL: I think we have consensus on what to do with big numbers (SHOULDs
and appendices).  
CB (on chat): +1 -- that agreement looks great  
CB: It's hard to handle a document with 16 PRs open at the same time.
I'd prefer to have a new version of the draft published soon.  
PH (on chat): +1 to Carsten about getting a new draft soon.  
RM (on chat): there are only 5 PRs, not 16. but no objection to a new
version  
CB: Right, still good to have a new version.  
PH: In a new version, it's ok to have some text marked as not yet having
consensus about it.  
CB (on chat): +1

LL (p6-7): Section 2 aims to give recommendations on
ordinary/deterministic serialization, thinking of different participants
in the CBOR ecosystem (libraries, protocol designs, protocol
implementations). There are different options about what to recommend,
each with pros and cons.  
PH: I think that right now we don't have consensus on the suggested
recommendation for CBOR libraries (first bullet on p6). What is a "CBOR
library"? The other recommendations seem just fine although one might
still disagree on the specific recommendation given.  
LL: We need more comments from more people.

MG (on chat): "MUST support ordinary" would practically restrict CBOR
encoding choices retroactively, i.e. remove options available in RF8949,
right?  
CB (on chat): Mikolai: Where that would be the outcome, we cannot do
that for other peoples' protocols  
LL (on chat): That would be my reading. That's why I like the SHOULD

CB: What do the terms "support" and "use" mean? We need definitions for
those. More in separate slides archived at
https://tzi.de/~cabo/cbor-2026-01-21-serialization.pdf  
CB: The separation in the three categories of participants is good, but
it might not cover everything.

PH: Whatever wording we use, let's be consistent.  
CB (on chat): We are using the terinology of RFC 8949 unless that is bad

LL (on chat): Yes, 8949 -- encoding/decoding  
PH (on chat): Fair point

RM: SHOULD comes with the need to motivate when it might not be met and
what happens then. Recommendations are meant to build on what we know
has been working well.

LL: Many implementations are incomplete (e.g., COSE).

CB: We need to use keywords from RFC 2119 as they are meant to, in the
interest to ensure interoperability. We may also want to give
recommendations that have a different scope and are about what's good to
do to get advantages.  
LL (on chat): Yes, agree that we can considered other than SHOULD in
this case.  
PH (on chat): +1 to us saying "good for you" vs. "good for interop"  
JH: I think it's good to give advice to libraries about what to check.  
CB (on chat): Giving advice is fine!

MG (on chat): can you reiterate why you treat protocol implementations
separate from protocol specifications (designs)? if protocols use
ordinary seralization, implementations must do so, too?  
LL: Protocol libraries are often incomplete.  
CB (on chat): (Doing good work with Partial implementations is an
important concept)  
LL: I think that CWTs and COSE are more toolboxes than protocols. They
are eligible for incomplete implementations.  
CB (on chat): CBOR definitely embraces the toolbox concept  
CB (on chat): Protocol implementations need protocol speciications.
These do not all come from just the framework/toolbox specification.

MT (on chat): On "Protocol implementations need protocol speciications.
These do not all come from just the framework/toolbox specification.":
confirmed, thinking of EDHOC

PH: We need comments to build consensus on the document, make it
proceed, and have a WG Last Call. If we don't get to that point, the
document is at risk and the WG is at risk (relaying from our responsible
AD). We need more activity on the mailing list, or the WG risks to be
shut down as unable to have a productive discussion on an important
topic. Regardless, we still need a new version of this document.

LL: On what to say in the recommendations, SHOULD or MUST?  
CB (on chat): SHOULD is not useful.  
PH (on chat): SHOULD is useful if we say why it is not MUST  
CB (on chat): DLO is generally good for constrained environment.  
CB (on chat): It only works with MUST, though.  
JH: I think that document coming after this one should say something
about serialization. I agree with CB that, when doing that, those
documents ought to use only MUST or MUST NOT.

CB: This is not about inventing new serializations. It's only about
constraining what can be done in the boundaries of CBOR.  
LL: What about COSE then?  
CB: COSE is a toolbox (with labels, names, ...).  
LL: So the toolboxes using CBOR don't guarantee interoperability.  
JH: So a new document that does not call out any constraint, it
implicitly refers to well-formed CBOR only.  
CB: Correct.  
JH: If it says something, then here we recommend what it should say and
how.  
CB (on chat): +1  
CB (on chat): (MUST implement within the data model confines, which is
orthogonal to serialization)  
PH: I like what JH just said, related to the second bullet of p6.  
RM (on chat): +1 to what Joe just said

JH (on chat): No. MUST implement everything, because otherwise you can't
check the data model correctness.  
CB (on chat): OK, interesting: erroring out on a floating point value if
the data model doesn't have them is a valid implementation strategy  
MG (on chat): +1 to say "SHOULD say something", instead of imposing
ordinary

LL: FIDO seems to me something that requires end-to-end
interoperability. But CWTs and COSE are toolboxes; if they say nothing,
it feels like one is supposed to imlement them fully but nobody does.  
JH: Good toolboxes don't have to say something about it, but they
should.  
CB (on chat): Ordinary (if that is DLO+PS) is not a good MUST enforce in
the decoder.  
VG (on chat): +1, not MUST

CB: Another example is -core-href (soon RFC), which does say something
about serialization, when considered in isolation or when used within a
protocol (which then has to say something).

PH: LL, is there anything here for you to modify the PRs? Anything that
can be moved towards consensus?  
LL: I think so, this is helpful.  
PH: Good. Honestly I don't like these interims and prefer the mailing
list. But this seems useful. LL, could you produce a new version of the
draft by Friday or Monday?  
LL: Maybe Monday.  
PH: Because then we can keep the discussion going. There is momentum and
ongoing consensus building; I'd like to keep it going.

MG (on chat): re Joe, Carsten above: MUST not implement fully but,
"everything that the data model allows"  
IMD (on chat): LL's example of COSE (no one implements it all, it's not
a protocol like TLS) is a relevant example - since CBOR is never a
protcol itself.  
LL (on chat): Yes, COSE is different than TLS. TLS and FIDO are similar
in this way.  
CB (on chat): TLS is a protocol in the sense of sending back and forth
messages; CBOR is a data representation format -- that is bound to be
different

PH: Keep providing comment on the mailing list, well before a new
version of the draft is published. I'd like the mailing list to focus on
this topic and not other ones. We need to show that we are able to come
to consensus about this. Again, I was skeptical that this meeting was
going to be useful, but I'm happy to be wrong.

## AOB   {#aob}

Note taking: Marco Tiloca

*[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


*[BM]: Brendan Moran


*[KC]: Kal Conley


*[RHo]: Russ Housley


*[ML]: Martine Lenders


*[MM]: Maria Matějka


*[OS]: Orie Steele


*[RM]: Rohan Mahy


*[JH]: Joe Hildebrand


*[LL]: Lawrence Lundblade


*[VG]: Vadim Goncharov


*[PH]: Paul Hoffman


*[AN]: Andy Newton