Friday, 7 November 2025, 9:30-11:00 Montréal time
Hackathon results readout (5 minutes)
Discussion of serialization and the issues from the CDE document (60
minutes)
Discussion of remaining issues on the other active documents (20
minutes)
Minute takers: MT, BG(?), CA
BL presenting, slides
(no changes to agenda)
BL: Just verified technical erratum on NaN, based on discussions on the
mailing list.
BL: CB asked to mention core-href
LL presenting, slides
CB: I wrote to the mailing list with questions about these slides.
LL: Just a basis for discussion, with no prioritized order. Being CBOR
an Internet Standard, we have to be more thorough than usual. 3rd take
now, should be refining now.
LL: Preferred serialization should be a familiar issue by now. List of
features of preferred serialization. It would be good to have more
definitions and clarifications.
LL (p5): An outstanding topic to elaborate more about is "Big numbers".
LL (p6): Another one is the set of information model, data modelS(!),
and serialization.
CB (on chat): (With the errata verified, it now very precisely says what
NaN equivalence is.)
LL (p7): Lot to say on duplicate map keys and how to detect/handle them.
LL: Observation: These are issues I saw over years. Not all
determinism/serialization issue (eg. duplicate detection is not).
LL: What document should address all this?
CB: I think LL set out to do revision of 8949, that is not CDE's
intention (which intended to make information in 8949 more available /
presented better; would be partially explainer and partially point to
good-practice places).
CB: When you say "clarify", it can be in unexpected place or wrong(?)
(as recently fixed Erratum was).
CB: How do we do this? My role model is JWT (defined in 7519, but rather
than doing revision they did BCP 225 pointing to stumbling stones,
leaving 7519 available as stable spec).
BL: Chairs' read of WG discussion on CDE is that it was not clear
what/how it said, would have needed cleanup. So what should a document
for that space say, and how can it be clarified?
RM: CB said that CDE wasn't for intended for this. Not particularly
relevant now.
RM: We have mandate to make something that implementers understand.
Clarity measured by questions and actions by implementers, who get
confused. LL's issues are all important. So let's decide what we want
implementers to do, and then if BCP/errata/update. Too early to decide
that without knowing which rules we want, only after which we can think
of how to state them.
CB: Yes.
CB: IMO discussion has culminated; we know issues and what to do.
CB: Hard to ascertain we know what to do until it is written up. CDE was
kept up to date and is not a good very document as a result.
BMA: +1 on RM. State of ecosystem in shambles. Given suggested changes,
an informational RFC will not help, implementers will not pick it.
Looking more for a CBOR2.
BMA: And the only thing implementers understand is test vectors.
LL: Not partial to it being BCP/update -- whatever works.
LL: My document is std track. Not update, just new named serializations.
No update to 8949, align closely, eg. new serialization only differs in
NaN handling.
LL: And +1 on vectors.
CB: The CDE document is quite good now in terms of test vectors, given
all the received input. Do we need two new serialization descriptions?
Why are we even writing about it?
CB: Write up so that any document using this can point to it and pick
from the choices we recommend to protocol designers (for their encoding
constrints).
CB: Adding to choice is counterproductive; deterministic is referenced,
implementers can need help. RFC 8949 changed the concept of
deterministic preferred serialization when obsoleting RFC 7049.
RM: Changed ordering; "preferred" was not defined in the original
document.
CB: We now have 3 choices in the wild. 1. well-known, 2. old canonical
("legacy deterministic"), 3. "common deterministic" in 8949 (???)
CB: 4th constraint: "definite length only", now disentangled from 8949
(b/c for writing partial implementations it's nice to have only this
which makes life of implementers easier)
CB: 2 and 3 affect both producer and consumer. Consumer wants to be
allowed to break if sender violates constraints.
CB: I'd prefer we limit ourselves to few choices. So there is no need to
introduce and point to preferred serialization.
CB: Litmus test for serialization: Do we get anything from it?
CB: "Preferred" is interesting recommendation ("do it this way and
people will not be surprised", but doesn't give us anything in terms of
interop)
RM on LL's p3.
RM: IIUC CB, no need for named "general encoding"
CB: I'd still call it "well-known CBOR".
RM: "well-formed"; slip indicates we need better term.
LL: Or "well formed"
CB: That'd work too
RM: Let's just give a short simple name with a justification. It's good
to have clear names to be used in documents that talk about using CBOR
in applications.
RM: Can we poll on this?
LL: The point is replacing preferred serialization. Same but definite
length is a requirement. It interops without decoding indefinite length,
which is difficult.
LL: Don't think need extra "only definite length" because ordinary is
good enough for that. And only difference to deterministic it's map
sorting (which is expensive, otherwise would have just one).
CB: Interesting that you talk of other serialization for getting into
definite length. Ordinary serialization becomes an interop constraint:
you need to get it right before you interop correctly.
CB: Ordinary serialization encodes promise that decoder does not need to
deal with things not in there, (?), and that's not worth having a
choice. Turning on ordinary as interop constraints just fractures
things, b/c it just uncovers bugs.
CB: Thus focus on definite-length-only.
CB: Older RFC that does explain why indef length is valuable somtimes –
valid entry in menu. (Also that's what most existing documents have
chosen).
LL: Disagree with that.
LL: Hardest thing is indefinite length, rest is widely implemented.
Everybody decodes shortest length arguments and floats (except some with
half that can decode but not encode). And int/bigint unification goes
with bigint support from environment. World handles this just fine.
JH: Confused by suggestion that interop constraint is bad, but DLO is
good.
JH: Comes back to whether receiver has to check whether data follows
protocol requirements.
CB (on chat): data model is orthogonal to encoding constraint
JH: Sometimes checking is necessary, sometimes not. Why does application
layer protocol need to (…)? The application layer should determine
whether there has to be a checking or not. If you check, there need to
be rules.
RM: +1 to JH.
RM: Plenty precedent for not having to check. Reason to reduce number of
choices is security, avoiding abuse. Lot of abuse possible in indefinite
length abuse. CWT currently doesn't require definite length, some
profiles do.
CB (on chat): It's not about havinbg to check, it is about allowing
partial implementations that don't implement. DLO is exactly that.
CA (on chat, as individual): +1 on CB (as individual)
CL: CWT prohibits indefinite length array. We found out they were
dangerous, so we prohibited them.
CL: What we want is "ordinary serialization", love that there are now
easy words to describe it. Difference between ordinary and deterministic
is valuable, we need not-sorting.
BL: Do you think LL's draft is right direction?
CL: It's precisely and exactly what we need. Our revised draft will just
say "ordinary serialization" if this is published.
LL: I understand that your implementation is super-size volume. So you
can still benefit even though the original mindset looks at constrained
devices.
CL: Anything you can do on a lightbulb, you can do a billion times.
CB: What does ordinary serialization give you in addition to DLO?
CL: We don't require decoders to enforce all the rules of serialization,
but that's permitted.
CL: If you encode it poorly, your tokens are not going to be
interoperable
CB: So that's an interoperability constraint.
CL: Correct.
LL: So from Ordinary over DLO, you get alginment with preferred
encoding. People already implement that.
LL: You get less bytes on wire, and basis for determinism. So it's
nicely stacking (compared to more complicated stack).
CB: We have to think of interoperability.
RM: All is on the same page about it, no need to say.
CB: Interop needs to influence two parties. What consumer does
influences producer. Shorter on-wire is quality-of-impl about producer,
but not about interoperability. You want to enable consumers to make the
constraint, which interferes with interoperability.
CL: The concern is that a consumer has to be able to process anything
that the producer can produce.
RM: It's most useful to define ordinary serialization.
CA (from-floor): CB, is there harm on having this unneded requirement?
Whoever produces non-preferred is probably not in a profile that does
DL-only. (My impl exp, only constrained do that when so small they talk
to big node anyway).
CB: Example: Situation when consumer was able to get data with half in
it, but producer could not produce it. In such a situation, most
protocols are fine. But if I switch on ordinary serialization, suddenly
producer needs to imlpements sending half.
RM: "Doctor! It hurts when I do that" … "Don't do that" ;-)
CB: People will switch this on without consideration for partial
implementations. Most constraints here are data model constraints,
important to separate them. If you don't want NaN, say that in the data
model. CBOR is designed so you don't need to know which style of CBOR
you need. Half-length is good demonstration.
JH (on chat): Chris's statement from before is a testament that Carsten
is not 100% correct here.
CL: Floats are a mess and shouldn't be in standards; we don't have them.
RM: People want to do things for reasons. CB, trying to discourge us
with same kind of moral arguments as Anders is using. Let us have things
on menu we want to eat.
JH: +1
LL: Preferred and canonical serialization have been around long, so it
shouldn't be a problem to still have them around and clarify their use.
CB: JSON uses floats all the time; one invariant of CBOR is it can do
what JSON can do (mod Unicode violations).
CB: If we do want to add making requirements that you don't need, can do
that (?).
CB: On interoperability result, suddenly sender and receiver have to
agree on details about preferred serialization. Have to do well on model
constrints: Right now it's hard to write CDDL to only allow finite
floats.
CL: It's a bit excessive to enforce on the recipient the same rules
enforced on the producer. Specific use cases must be able to do specific
things.
(Lots of nodding to clearly-defined-words and -libraries)
JH: +1 on CL. If application proto wants these constraints, it's nice to
have predefined set of choices.
CB (on chat): The point is that treating "ordinary" as an
interoperability constraint allows consumers to be partial
implementations, so it forces producers to enforce the constraint.
CA (only chat): I think that's clear to all; just needs clear words on
when you may not want to require Ordinary but just require well-formed.
JH (on chat): Carsten: that's what Chris wants. It's not a problem, it's
a goal.
JH (on chat): I mean, he said it, and I believed it? The technical
argument that he wants smaller implementations on the server side so
that he can scale seems reasonable.
Show of hands:
Is Lawrence's draft going in the direction we want a serialization
draft to go?
BL: What would it take for "no" to enhance? Any better qustion to
ask?
RM: "Would people with choices on menu (NaNs aside) in LL's draft?
General, Ordinary, Deterministc."
"Are you OK with choices of Genera, Ordinary, Deterministic."
BL wrapping up the topic for this meeting, to be continued on list
BL: We have an indication that this way of framing the topic is in the
right direction.
RM: Above encoding, do we want to talk about NaNs and duplicate map
keys?
BL: On list; good enough for now.
CB: Yesterday we got approved the document draft-ietf-core-href with
another choice that's not on this menu; documents will continue to do
that.
BL: As an off-shoot of General?
CB: Yes, all is optional generally speaking. The encoding decisions
happen when deta is translated into a media type.
LT: For SCHC in coreconf, same problem. Empty array, nul, we need to
have strict representation.
IMD (on chat): The words "general" and "ordinary" are nearly synonymous
in normal usage - I strongly dislike this ambiguity in serialization
discussions.
JL (chat): we can still argue about the names. I mostly agree with you.
CA (on chat): Yeah, but I don't think we're at the time of doing the
precise names (except some dislike for "well-formed")
JH (chat): i wanted "general" and "simplified"
AN (on chat): So the question should have been desiring any subset of
the set? :)
IMD (on chat): +1 to Joe for a distinct suggestion - the lack of
meaningful words for classes of serialization is in fact critical to
progress IMHO
CL (on chat): second not liking the precise words used for the
definitions, but I can live with a bikeshed that is blue if necessary.
\:)
CL (on chat): I need issuers to be able to not spend time sorting, and I
also "cheat" by allowing issuers to "hint" to relying parties which
claims are most probable to fail first. (This plays a touch fast and
loose with the prohibition against semantic variations between different
map orders... but it works great in practice.)
CB presenting, slides
CB (p21): Other drafts need edn-literal (moving their content in there).
CB: Idea to avoid escaping hell of JSON style escaping by supporting raw
strings. JH and I had 1:1 calls. Good way forward.
CB: (skipped many slides as covered several times in interim meetings)
BL: I think we can wrap this up soon. Any other opinions?
JH: We're really close. CB has an outstanding point that we still need
to agree about. Once we're internally done, we'll share with all. We'll
prioritize this.
CA: No strong opinion about either option.
CB: Would like to discuss results before Xmas.
JH: This Xmas. We just have to work through the current enpass.
BL: Yet it's a matter of weeks, not months.
CB (p20): Got impl feedback.
CB: Got comments about high tag consumption. Makes one way to implement
tags harder (hash table). Looked at tunables, and examples, and
A=12,B=8,C=8 is reasonable with minimal amount of hash table
disturbance.
CB: Error messages in map keys are now 1112(any).
CB: Still dissent. Please join web calls outside of interims.
BL: Interims will resume December 10th, provided there are agenda items;
next in Jan 7.
AN: Thanks to the Chairs for the session and everyone for the work into
this.
RM: Who expects to be at IETF125?
(most people in the room, none from remote)