Minutes IETF116: cbor: Thu 06:00
minutes-116-cbor-202303300600-00

Meeting Minutes Concise Binary Object Representation Maintenance and Extensions (cbor) WG
Date and time 2023-03-30 06:00
Title Minutes IETF116: cbor: Thu 06:00
State Active
Other versions markdown
Last updated 2023-03-30

minutes-116-cbor-202303300600-00

CBOR at IETF116

Agenda

Minutes

Chairs introduction

Minute takers: Marco Tiloca

BL doing introduction

CA giving a document status update
CA: Carsten will cover one on deterministic CBOR; then we have Packed
CBOR also progressing, we have to finish the part on the table setups
based on requirements from other documents using Packed CBOR.

Carsten's bag of pointers

CB presenting

  • Usable Formal Methods pRG met yesterday; they not only talk about
    validation but also specification (which CDDL is about), we'll be in
    contact with them.

  • "profiles"
    CB (p2): many asks for "profiles", the -deterministic-cbor document
    is an example of those, -cose-profiles is another one.
    JPM: What's the difference between -deterministic-cbor and the CBOR
    standard? What seems to be only missing from the standard is
    implementation.
    CB: The difference is not much, it expands on RFC 8949. But it also
    takes some decisions, e.g., the application should not differ
    between integers and protocol values.
    JPM: Ok; more focus on deterministic CBOR can be good, maybe we can
    get an implementation.
    CB: One can always re-encode and compare against what received to
    check about determinism.
    JPM: And that's suboptimal.
    CB: Can't be done much better.
    JPM (on chat): Regarding deterministic CBOR implementations. I would
    assume that an implementation that receives CBOR, does D =
    decode(CBOR), and then checks that encode(D) == CBOR uses twice as
    many clock cycles as an optimal implementation and uses
    significantly more memory as CBOR, D, and encode(D) have to be in
    memory at the same time. Or am I missing something? The described
    implementation is however likely optimal in code size if you want to
    support both deterministic and non-deterministic CBOR.
    CA (on chat): As I understand, Carsten's implementation is a Ruby
    one. If cycles matter to you, that's not what you'd use.

CB (p3): Image from hackathon... This can get very ugly very quickly.
Maybe we need to invent some concepts, such as profiles in common usage
or whatsoever. Proposing to do this in interims. That people come here
indicates it's needed.

CB (p4): Media type for EDN? (Everyone is using extended diagnostic
notation these days). In 2013, we were wary about people thinking of the
DN as an interchange format -- not the intention, so we intentionally we
did not register a media type. Now that is no longer a concern.
Currently in EDN-literals. Document could go forward, I think it's
convenient to pack them. Please have a look, draft is fresh. Once WG
document, we can discuss the registration policies in detail.
CB: This slide is implying a hope for call for adoption.

ietf-cbor-time-tag

CB presenting

CB: Adopted some time ago, had no rush completing (tags are registered).
Completed WGLC in January, all comments should have been addressed in
-05 submitted before the cut-off.
CB: Wish to synch with the companion document in SEDATE, which should
have been unblocked after a charter update.

lenders-dns-cbor

ML presenting

ML: When running DNS over CoAP (even with DNS compression), we quickly
ran into message fragmentation. Hence this work for encoding in CBOR.
ML (p6): showing updates since IETF 115 (mostly based on feedback from
Carsten (now co-author), Ben and Vadim. Updated format of queries,
aligned with that of responses.
ML (p7): Ongoing work on using Packed CBOR (specific algorithms left to
the implementation); todo: examples with compression, comparison of
different encoding alternatives
ML (p8): plan to implement and evaluate, also with more investigation on
Packed CBOR.

CA: Have people looked at the DNS CBOR draft? It'd benefit from
feedback. Please have a look at the draft.
ML: I second that.
CB: Little incencentives now with 5 authors, but please give comments.

CDDL 2 block

CB presenting

CB: Looking at the prev' presentation: It seems to be a pattern to
extract the data model out of older formats and express them in CBOR.

Overview

CB (p7): CDDL 2.0 was a placeholder for things, now we have better
understanding of what we want to do. Most of these documents are now
close to be ready for a WG adoption call. Showing time plan for the
documents to follow this year.

CB (p7): 8610 does all the ABNF changes. Mostly implemented (eg. b/c you
can't do it anyway w/o considering the errata).
CB: control-operators we already did once (RFC9165), just another set.
Both can be done before IETF117 (San Francisco).
CB: cddl-modules (what I call "2.0"). More complex than the above. Good
thing: Implemented. People may still want this or that in it. Programme
for this year, should be done by IETF118 (Prague)

CB (p8): Showing plan for CDDL 2.5, intended for 2024. More info
intended to be included in the CDDL model, e.g., through
"functionalities". Freezer has examples.

CB (p9): (minute takers' remark from seeing these slides earlier:
I:=Informational, S:=Standars-Track, B: =BCP) CDDL-in-JSON to be changed
once more (and then decide whether it's to be a document or wiki).
cddl-models is for use with 2.0. Literals in CDDL to be developed
together with edn-literals. New document on using CBOR in drafts before
codepoints get assigned; got reviews to process, this can be a BCP.
Finally, document on csv.

8610-grammar

CB (p10): small updates and bug fixes.
CB: Proposing adoption

more-controls

CB (p11): list of new, proposed controls.
CB: Already thinking about YANG-CBOR encoded in there, will likely make
a proposal.

Module

CB (p12): concatenating files with backward compatibility
CB (p13): two types of usage environments: in the project (;#include) or
between projects (;#import); supporting for aliasing and scope
narrowing.

CDDL 2.0 status

CB (p14): implementation status for the cddlc tool, possible to combine
with the cddl tool. Please try the tool. Feedback suggests that this is
well understood.

CA: I'd like a round of adoption show-of-hands at the end of the
session, about the three documents discussed before.

CDDL 2.5

CB (p15): Annotation changes "yes-no" validation to "what-is-what"
annotation. The next step will be transformation.

CB (p16): Proposed syntax for annotations. (s/unit/uint/ in slides).
CB (p17): CBORPath is good input to consider (see issue #90 on the
Github). JSONPath will soon be in WGLC. YANG uses XPath because it was
originally XML based. We could use XPath 3.1, but wouldn't be a big fan.
Might still happen if we don't do something.
CB (p18):

MT: What if the value can be integer or string, some registries can do
that. Does it impact?
CB: This is a straw man proposal; the hard part will be converting the
textual information (sequence-of-digits) into the data model.

CB (p19): everything here (module structure etc) we probably want to do
with ABNF as well.

BL: Questions / discussions?

Administrative business

  • WGA calls

    • edn-literals

      BL: objections on adopting this document?
      (heard none)
      BL: We'll take it to the mailing list.

    • cddl-modules

    • 8610-grammar

    • more-controls

      BL: objections on adopting these three documents?
      (heard none)
      BL: We'll take it to the mailing list.
      Chris Lemmons (on chat): Please adopt these. :)

      AR: Hard for a newcomer to understand the distinction between
      "import" and "include".
      CB: They'd have to learn these.
      AR: Is that distinction necessary?
      CB: import alone is enough, but there is a class of errors you
      can avoid by doing some this way and some that way. include is
      for within your project (ensuring consistency), and import when
      using a library. Import also prevents recursion.

      BL: We'll post to the list to confirm these adoptions.

      Chris Lemmons: Ability to import from documents that are not
      necessarily RFCs -- it's used in a variety of places. Should be
      useful there as well.
      CB: Current definition cheats there. Thing right of an import is
      "a name". How that is mapped is defined by the tool. cddlc just
      takes a PATH-like environment variable. The last item there is a
      collection of data the tool has imported from the RFCs. If you
      have a draft, a recent copy will be in a place referenced there.
      Hard to specify versions, given drafts can move forward (the
      only way to not break things as drafts move forward is to place
      them in a place you control). Don't think the spec can solve
      that, but would love to learn about ways to do it.
      CL: I'll think more about this, but it's going in a good
      direction. Can discuss as work progresses.
      CB: I always rsync the drafts collection, that's in the include
      path.

      Esko Dijk (on chat): CDDL import: RFCs with errata are another
      risk factor here.

  • Weekly resuming April 19th?

BL: Coordinated with CoRE and we plan to keep the same schedule.
Biweekly starting from April 19. Does anyone have a problem with that?
(none heard)