# CBOR session at IETF 118 (Tuesday, November 7, 2023, at 15:30) {#cbor-session-at-ietf-118-tuesday-november-7-2023-at-1530} ## Agenda {#agenda} * Intro and agenda review (chairs, 2') * Documents that are finishing up (chairs, 5'?) * IETF evaluation for time-tag * WGLC for edn-literals and cbor-update * Other in-progress documents * draft-ietf-cbor-packed (CB, 15'?) * draft-lenders-dns-cbor (ML, 10'?) * Brief mention of deterministic encoding profiles (chair summary?, 20' based on list disussions?) * Dates for interim calls through IETF 119 * Proposed dates, coordinated with CORE: 29 Nov, 13 Dec, 10 Jan, 24 Jan, 7 Feb, 21 Feb, 6 Mar Same cadence, continuing as we were. * AOB ### Agenda additions {#agenda-additions} * JSON-NTV from dispatch? (chairs' pointer, 1') ## Intro and agenda review {#intro-and-agenda-review} CA doing introductions CA: Any agenda bashing? CA: There is a thread on the mailing list about the discussion in DISPATCH on JSON-NTV DE: The -bis for RFC 7042, draft-ietf-intarea-rfc7042bis-11 (currently in RFC editor queue), has CBOR tag registrations for MAC addresses \[post-meeting addition: tag 48\] and OUIs \[post-meeting addition: tag 1048\] ## Documents that are finishing up {#documents-that-are-finishing-up} CA: time-tag is in IESG evaluation; a DISCUSS is resolved FP: I just have to give a quick look, then press the button and it's done \[post-meeting addition: Document was approved during the meeting [https://mailarchive.ietf.org/arch/msg/cbor/9YALc9UT3WBgNP91-zlB-7mPbys][1]\] CA: Had WGLC on edn-literals and cbor-update, finished yesterday. No feedback on the mailing list. I'd like to extend the WGLC for one more week. WG, please comment. CB: If it helps, I have slides about that. CA: Yes, that helps. ## edn-literals and -update-cddl-grammar {#edn-literals-and--update-cddl-grammar} CB presenting CB (p2): CBOR is a representation format, not a language. Then we have two languages: the extended diagnostic notation (EDN, used for examples) and CDDL (for specification/validation). CB (p3-4): The two related drafts -edn-literals and -update-8610-grammar ended WGLC yesterday. We received a lot of feedback on the former before the WGLC, so not surprised that no more comments came, but please have one more look. The latter mostly focused on addressing errata against RFC 8610. CB (p5): People often use text strings in early EDN examples, even though they actually mean a placeholder for a later, to-be-registered integer (it came up again also in COSE earlier today). This might be also addressed in a further application-identifier registration to EDN, once we have a Designated Expert to take care of the newly created registry. ## draft-ietf-cbor-packed {#draft-ietf-cbor-packed} CB presenting CB (p6): Recap of history and rationale, wanted an in-place used of packed CBOR data items. That builds on two separate elements: reference tables to build first, and then refer the right table entries from a "rump". CB (p7): The part on references set is pretty much ready. CB (p8): The table building in itself is application specific, with different possible methods envisioned. Some simple setups are provided as "batteries included". CB (p9): Tables can be built implicitly, starting from the rump that needs to build the table. The building can also be incremental, to allow immediate use after the primitive. CB (p10): Next steps are getting more feedback from benchmarks (e.g., DNS in CBOR) and implementors. Eventually, we have declare this done and have WGLC on what we have, somewhere before the next IETF meeting. CA (not as Chair): on the trouble with maps, if the application requires using deterministic encoding, can one rely on deserialization sequence? CB: Sounds good to me. (Further "sounds good" from the room) → Confirm time box? ## draft-lenders-dns-cbor {#draft-lenders-dns-cbor} ML presenting ML (p2-3): motivation backed by results on message size when using DNS over CoAP. ML (p4): work about encoding DNS messages in CBOR to achieve concise encoding, also with some optimizations. CBOR-packed was also considered. ML (p5): Some DNS fields can be omitted altogether. This is possible both on query requests and on responses. ML (p6): Summary of changes since IETF 117 and version -03: more on representation and format description, and on implementation status; made simplifications and clean-up. ML (p7): Example of achieved gain using CBOR. ML (p9): Implementation activities. ML (p10): results on compression ratio and byte savings. Compression of the name format was clearly needed. ML (p11): On compressing names: none, or bespoke DNS approach, or CBOR-based approach. ML (p12-14): Approaches and examples for compressing names. ML (p14): The first approach splits the domain name into different components, building on what is being defined in draft-ietf-core-href. This looks like a variant of Packed-CBOR. ML (p15): The second approach is a lighter version of a proposal by Lemogue et al., using only names into account for table building. ML (p16): Showing results of gain due to compression. The dataset was limited, so more research is needed. ML (p17): The first approach is concise, simple, and familiar. The second approach is consistent and efficient. ML (p18): Question to the WG: which way should we take? Or should we have the implicit table building for packed-CBOR in general? CB: Thanks, that's the work that we needed to make a decision. CB: On slide 14 (43rd slide) "Idea 1: Reference Name Components", we would need slicing references. We would need to insert an array into something that is becoming an array, basically what is happening here. Maybe it's good to add this slicing reference to Packed CBOR in the first place. CA: Do you mean that by slightly extending Packed CBOR, then what is on the slide can be packed? CB: Yes. CB: The CDF graphs are based on a corpus; as always, the choices going into that could be debated. Typical issue: From some lab implementation -- it's million packets all from one source. So the numbers are not perfectly valid. Anyone got more data? Contact us. DE: DNS labels can contain periods. ML: That's why CA proposed to rely on the CBOR format for names. ED: About the DNS request, can I have an example when the query count is greater than 1? I'm not sure if it fits that format. Although the support for it is debatable, there are implementations that use it. ML: Followed it on DNSOP; need to think, not sure of use case. ED: The use case was pre-decided in a side-meeting yesterday, and there were better ways to do it. It was about requesting two records for the same name, but it's better to use EDNS options and rely on better properties also for legacy receivers. CA: We take this offline in the interest of time. ## deterministic encoding profiles {#deterministic-encoding-profiles} CA, summarizing traffic on the mailing list CA (p7): This started with requirements from the Gordian project. Now we have on the table a common deterministic profile (CDE) as related to dCBOR on top of it and providing numeric reduction, removing a few things like "undefined" and other simple values, and half negative integers. A few controversial open points remain. Hope that CB and WMN will collaborate to converge. CB: dCBOR is perfect for that kind of applications, but not for others. But the basic model can instead do something different and more general. WMN: CBOR is fine as-in on representing things. dCBOR is a bit different and focused on a specific problem space. Agree with Carsten dCBOR is a profile on top of CDE on top of CBOR, and that we should merge the two dCBOR documents. I'd like dCBOR on the Standards Track. CB (p12): Deterministic Encoding comes already from RFC 8949, but some things are left to the application. This is not trivial to take into account for writers of encoders/decoders. Such clarifications now come from CDE as a Common Deterministic Encoding profile, on top of which one can build Application Profiles such as dCBOR. I don't expect many Application Profiles to come up as the latitude to operate with is not that much. CB (p13): I propose to be quick in adopting the CDE document (now as BCP, but it can be a Standards Track just as well). Already had some discussion with Wolf on the merging with the dCBOR document. We can also get rid of the extensibility aspect, which is not for dCBOR. We should be able to do this next month. CB: Please have a look to the CDE document, especially for deciding between BCP and Standards Track. CA: For all in the room, would you support adopting the CDE document? Show of hands: yes: 16; no: 0; participants: 23 CA: We'll start a WG adoption call on the mailing list. ## Dates for interim calls through IETF 119 {#dates-for-interim-calls-through-ietf-119} CA: We had successful interim meetings, alternating with the CoRE WG. * Dates for the next series of interim meetings, coordinated with CORE WG: * 29 Nov, 13 Dec, 10 Jan, 24 Jan, 7 Feb, 21 Feb, 6 Mar * Same cadence, continuing as we were. ## AOB {#aob} (chair action note-to-self: make sure downstream documents defining tags are linked in datatracker by explicit inclusion as documents of interest to the WG) * * * [1]: https://mailarchive.ietf.org/arch/msg/cbor/9YALc9UT3WBgNP91-zlB-7mPbys *[BL]: Barry Leiba *[MT]: Marco Tiloca *[LL]: Laurence Lundblade *[RHo]: Russ Housley *[JJ]: Jaime Jiménez *[FP]: Francesca Palombini *[JPM]: John Preuß Mattsson *[CB]: Carsten Bormann *[CA]: Christian Amsüss *[KH]: Klaus Hartke *[RH]: Rikard Höglund *[TF]: Thomas Fossati *[MG]: Matthew Gillmore *[DN]: David Navarro *[GS]: Göran Selander *[BS]: Bilhanan Silverajan *[AS]: Alan Soloway *[MCR]: Michael Richardson *[AK]: Ari Keränen *[MJK]: Michael Koster *[NW]: Niklas Widell *[ED]: Esko Dijk *[HB]: Henk Birkholz *[ST]: Sean Turner *[ML]: Martine Lenders *[MW]: Matthias Wählisch *[KZ]: Koen Zandberg *[GF]: Giuseppe Fioccola *[MN]: Massimo Nilo *[LT]: Laurent Toutain *[AB]: Andy Bierman *[JT]: Jernej Tuljak *[RML]: Rafael Marin-Lopez *[AF]: Alex Fernandez *[MK]: Matthias Kovatsch *[RW]: Rob Wilton *[IP]: Ivaylo Petrov *[BSc]: Ben Schwartz *[WMN]: Wolf McNally *[DE]: Donald Eastlake