Minutes interim-2025-cbor-02: Wed 15:00
minutes-interim-2025-cbor-02-202501221500-00

Meeting Minutes Concise Binary Object Representation Maintenance and Extensions (cbor) WG
Date and time 2025-01-22 15:00
Title Minutes interim-2025-cbor-02: Wed 15:00
State Active
Other versions markdown
Last updated 2025-02-17

minutes-interim-2025-cbor-02-202501221500-00

CBOR working group call, 2025-01-22

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=ca242f46-fa98-4afb-9355-86d9dc8caf2c

Please add items to the agenda

AGENDA

WG documents status and issues

CA doing introductions.

CA: not discussing EDN this time, a few open points are better
discussed on the mailing list for now.

CDE: check status

LL (p2): Long-time use of canonical CBOR, with no big issues arising /
no threats to CDE.
LL: Singular use case dCBOR -- no threat, just layers on it w/o ALDR.
LL: No use cases, no examples of ALDR profiles.
LL (p3): There's no justification for ALDR, still it might feel like
it's innocuous to have text about it. But that's just more text to
read/process in order to understand it can actually be ignored. That
doesn't feel good to do, also considering that this is a 3rd generation
CBOR document. Something like that would require community consensus,
which we don't seem to have. I don't think it's just innocuous and ok to
have that text.
LL (p4): Clarifying own position: CDE is critical, the -cbor-cde
document is useful. Trying to reach WG consensus, don't care about
outcome.

CA (not as Chair): This sounds convincing to me, especially on
introducing new concepts that are not backed up by good examples.
JH (on chat): This seems like a strong argument to me as well. I didn't
have a strong opinion before this.

CB (p3): recap on previous step and current status of CDE. (original
CBOR had surprises, 8949 had core requirements). Would be good to have a
WGLC now.
CB (p4): ALDR are a fact: if you want deterministic encoding, you need
deterministic application. Use cases are deterministic representatiojn
and not just deterministic encoding use cases.
CB: This is not unnecessary, it is needed for deterministic reprs.
JH (chat): I do have a strong opinion in this space, which is that if
you're doing deterministic encoding, there's often a different way to
think about your problem so you don't need to do that, or a different
related problem that is better to solve.
CB: That's not the part we talk about it.
CB: ALDR is not clear in previous documents (eg. 4.2.2 of 8949). No
clear separation between encoding and representation in the data model.

CB: If data-at-rest has to be represented at CBOR level you need rules
to convert to a CBOR data model.
CB: CDDL can express some ALDR.
CB: One can implement CBOR without understanding ALDR.
CB: One can probably use CDE without understanding ALDR, but someone has
to take care of the rules anyway.
CB: RFC 9679 defines the thubmprint of a COSE_Key and needs ALDR. Its
Section 4.2 is basically ALDR on RFC 9052 (COSE).
CB: I think we should have a name for this concept, like ALDR. If we
remove the text about it, there's sure less text, but we also have less
awareness that application have to take care of ALDR anyway, If
anything, there's risk of inefficient discussion, due to the missing
term.
CB: Also importantce for other SDOs: They don't know CBOR well and start
modifying CDE.

LL: No examples of where the threat is. Slides here sound like 4.2.2
refinement -- that's reasonable. But as layer that must be forced and
presented as layer and not technique, with difficult wording. With this
pres, it looks more reasonable.
CB: Good to discuss this now.

CA: if it does that. Many applications already described. Some users
come from JSONish background where format model is already the
information model. JH, would it help to preface this with conditions
when it is relevant? (eg. if your app already distinguishes tagged from
untagged data)
LL: I understand this as about serialization, not data model.
CB: It's about representation not serialization.
CB: Main mistake is to consider ALDR as layer. It's a technique, a way
to write specs. There is no new layer at all.

DR: (My world is ASN and JSON). Agreed that ALDR is a concept lacking a
name now.
DR: Why is this concept of a new term being burried in an appendix?
Seems, based on CB's disucssion, this applies to ASN, XML, JSON.
JH (chat): Extract a separate BCP?
CB: Agreed, it happens also in those format, where however it is not
discussed as much.
CB: We have doc for boundary btwn information and data model, 20y old.
Should have had another between application data modelling and data
serialization also of that age, but don't. Or move into explainer.
JH (on chat): Which probably would have to be done in ART?

LL: dCBOR was written in terms of an application profile; appeared there
as a layer.
CB: That's their choice. And it is valid to make the application a
layer.
LL: They used application profiles because they were guided to do so out
of IETF discussions.
CA: Can that be just an artifact of collecting learning experience?
LL: [hard to understand] could be (?)
CB: Wondered about their choices; found out that model of layers is not
as widely understood as it should be. Learned from that.
JH (on chat): So maybe the ART BCP could explain all of those conceptual
layers?
LL (on chat): It would be very valuable to describe data model vs
serialization, even if by reference. It would have shortened this
discussion by 6 months.

DR: Agree that this is huge wide-ranging concept, not taught in schools;
as important as 7-layer rule (?). Needs to be elevated. But why here?
Deserves to be brought out separately. Appendix doesn't seem
appropriate.
VG: +1 on separate document.

JH: Makes sense to me. It would well set the ground for future ART
protocols.
CB: Sounds like right way to do if 10 years time. Meanwhile, new
protocols are designed without awareness or coordinated use of this
concept.
JH (on chat): Second best time to start is today.

CA: Would you be willing to write this up as a larger concept? And
what's the minimum pointer you are willing to provide to make people not
fall into this trap.
CB: We need doc to introduce 3-layer model (indep'ly of determinism),
see 2016 San Francisco IAB workshop (understood there and participants
apply it, but general ART environment, will have many influences). Would
prefer to describe little corner of that space.

(some chat on ChatGPT)

LL: Still don't think so many people design protocols incorrectly (CB:
outside IETF!)
LL: Please describe them. Disrespectful to claim it exists but not
point. Mysterious thing we don't know about.
CB: Other SDOs have other rules on opennes of their works. Will try to
cook up something that doesn't violate their rules. Eg. ETSI has run
into problems with this.

CA: Not full conclusion. CB, do you have takeaways to move forward?
CB: Would like to get rid of the profile from the draft.
CB: Can use COSE key thumbprint example, some editorial rework. Get a
-08 before next interim.
CB: Would also help to review the other parts, people will need to have
read that by WGLC.

Packed CBOR: Status

CB (p13): Recap on packed CBOR. About saving space on data model level.
(We may need preferred compression for for constrained devices too, but
that's different)
CB: … both constrained and high-performance …
CB (p14): Stable (reference tags) and flexible (table building) aspects

CB: There is a generic compressor, but that's for explorative purposes.

CB: Why common tags across applications? Allows generic ingestors (even
if only for diagnostics), sharing tags btwn protocols, saves
reinvention.
CB (p15): On compression (which is not the case here) and packing (more
appropriate).
CB: Will look at compression factor occasionally, but it's not the main
point

CB (p16): Discussion: tag ranges (fix for lack of two-argument tags,
have been used), haggling, delicate to allocate the right amount of tag
numbers in the right range.
JH: ad ranges: CB does it that way. CB: not just my documents.

CA: On using ranges. The ranges I see are base hash values and
Content-Formats (both involving), but also other ones (e.g., Chris P.
(?), W3C applications with ~14 M tag range)

CBAR as cbor-packed alternative: intro (VG)

VG: CBAR have same abilities as cbor-packed (to access without copy,
compress ratio, etc.) and even more but without so many tags in scarce
ranges

As it was not enough time for properly formatted Slides, markdown text
version is available at
https://mailarchive.ietf.org/arch/msg/cbor/zxlQSH6TrEleoy3i1N59D5vQSkc/

VG (p2-6): Background on protocols that benefit of compression.
VG (p7): Actual need to compress both CBOR and generic BLOBs.
VG (p8): Alternative approach CBAR
VG: CBAR supports sequences unlike packed.
VG: Ideally used on byte strings; access in-place works in simple cases
too (?)

CA: Example of full document?
VG: The latest is the text that I posted on the mailing list. I can see
that there's some confusion.

VG (p20): Unclear what class of devices is Packed CBOR actually
targeting and aiming to crucially benefit.

VG: Cheaper price -- just 1 tag.
VG (p24): CBAR can arguably completely replace Packed CBOR.

CA: One takeaway: Packed CBOR might need to better show some realistic
examples.
CA: Link to implementation?
VG: I don't have an implementation yet. A comparison of the
specifications already shows that CBAR is simpler for simple use cases,
because there's no need to keep cross-references.
VG: Common wisdom that DNS compression was a mistake.

ML: Are you aware on the draft about DNS in CBOR that uses Packed CBOR
for name compression? Do you think CBAR can be used instead?
VG: Look at it; doesn't have section for applying CBOR packed.
ML: Name compression PR open (see
https://github.com/anr-bmbf-pivot/draft-lenders-dns-cbor/pull/7 ),
moving that to packed CBOR. I welcome an opinion.
VG: packed has prefix or suffix; CBAR has multiple atoms in one string.
So it should make things simpler.

CA: Let's continue on the mailing list.

Errata report on non-scalar keys (not an erratum)

(not discussed; already 5' over time)

https://www.rfc-editor.org/errata/eid8255
Discussion:
https://mailarchive.ietf.org/arch/msg/cbor/rEHjpznDqsstS9YMqGRtoY5tzeo

Is there anything left to take away from this?

AOB

Note taking: (volunteer here)