Minutes interim-2023-cbor-10: Wed 14:00
minutes-interim-2023-cbor-10-202306141400-00

CBOR working group conference call, 2023-06-14
Meetecho:
https://meetings.conf.meetecho.com/interim/?short=ac3c4618-46bc-4349-b870-4492c9cf1371

CA doing introductions

IETF 117 agenda

We need to start putting together a proposed agenda for the IETF 117
session. We will discuss that on this call.

CAl: How virtual will IETF 117 be?

CB presenting

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-cbor-10/materials/slides-interim-2023-cbor-10-sessa-cborietf117-00.pdf

CB: 3.5 weeks until the cut-off deadline. Will focus on some documents
on my radar, not completed yet.
CB (p2): time-tag; now stable for a while and tags registered. The IETF
Last Call on the related document in SEDATE finished with no impact on
this document, so this can resume now (WG Last Call was done). Changes,
but none relevant here. Planned final version by the IETF 117 cut-off,
ready to be shipped.
CB: For 117: Should already be submitted, so not necessary for agenda.

CB (p3): packed passed WGLC last year. Two parts: tables (now 2, shared
and argument) and setup. Need more experience with setup, aiming to
merge shared/argument by default.
CB: Intention is that other docs define more setup (possibly using tags,
possibly from media types and so on). DNS-cbor is an example of
application with its own table setup. One more interim meeting to work
on this would be useful, then we can somehow push forward at IETF 117.
Hope to synch with Martine on this topic.

CB (p4): CDDL block (3 items). WG Adoption completed now, we can also
cover these topics in detail at the next interim meeting, and then
continue at IETF 117. Some proposed operators might be abandoned if not
clear enough. I expect first two be ready for WG Last Call pretty soon.
Need for feedback on the modules from people that used those. Overall
all the three documents are implemented, but we don't have multiple
independent implementations.
For IETF 117: Modules will be discussed beyond 117.

CB (p5): EDN-literals. List discussion indicates we may want something
that goes beyond what is currently in. We may need to define ABNF for
EDN (now that it's adopted that'll need WG input), plus possible other
work on the diagnostic notation.
For IETF 117 (or earlier): Discuss ABNF of proposal -01-to-be and decide
direction.

CB (p6): work on deterministic encoding (we have standard deterministic
encoding, but also dCBOR numeric reduction) and discussion on
deterministic choices (informational). My suggestion on list: work on
those two documents.
CAl: That's reasonable, I like it. Not sure how to split, but we'll work
together on that. Important to understand how to well explain the choice
that we make in the documents. On numeric reduction, Wolf can refer to
specific test cases in different languages to show interesting cases in
point.
CB: On numeric reduction, you have made some choices that we might want
to discuss; we'll have to describe precisely the one reduction we're
agreeing on. But we'd have two widely recognized choices: deterministic
and deterministic-after-reduction.
CAl: Just two or same thing as multiple profiles in one? I don't mind
profiles.
CB: Agree, the goal is finding two points with the largest
attractiveness to have most people interested and avoid future
reinventing.
For IETF117: Have individual -00

CAl: So we're talking about two new drafts replacing the current dCBOR,
and move those forward in CBOR group?
CB: Can work on your text.
CAl: Please do.

CB: If we do numeric reduction, we have to think how to support it with
CDDL, which is close to the 8949 generic model. Not sure if it can be a
separate document and how to exactly do it.
CAl: In tools we have CDDL 1.0 support, but mostly use it for
diagnostic. Will move to newer CDDL.
CA: Not an issue how to represent the choices but how they represent
that there is no choice when there is reduction. Whether that's through
a known new type or a control, we'll see over time.
CB: Difficult part comes in when CDDL spans components that use NR
(numeric reduction) and those that don't. COSE doesn't do NR.
CA (on chat): On CDDL, I figure we'll just define a rnumber = (int /
float) .constrain "no floats when they can be int", and models will just
tell that they use rnumber instead of int or number.

CB (p7): other items as dns-cbor, -cddl-csv, -cddl-models and
-draft-numbers (procedural). On CSV: There are areas where it's widely
use, but maybe not much contact inside WG. On cddl-models: Some RFCs
have useful content but it needs to be "packaged" or cleaned up to be
useful. (Will be tricky b/c sounds informational but ppl will want to
reference it).
For 117: Not sure if time; but they're active.

CB: Anything else?

CAl: We got pushback from some communities discouraging about using CBOR
due to complications with IANA registrations.
CAl: Shouldn't be hard, because there are ranges that just need a
specification. We asked for 6 of them for Gordian, and IANA went back
and forth, so we're experiencing what people warned about. Some way to
add clarity?
CA: The pushback from IANA was because there was something dispatched to
a WG. IANA reacts differently depending on the specification coming from
the IETF (through the expected process) or not.
CAl: There was confusion here -- dCBOR was dispatched; Gordian was not
dispatched ("you need problem statement etc"). We also have more tags
we'll want to register (for industry specific stuff). So not sure how
this could have been handled better.
CB: The operation of registries is defined in BCP 26. The text in RFC
8949 for CBOR uses terms from RFC 8126, which talks about Designated
Expert (DE). In general, a DE is unrelated to a WG. For the registries
in question, CA and I are the DEs, and the tag numbers of interest this
falls on the "Specification Required" model. This is a special case of
Expert Review, where a specification also has to be provided together
with the registration request. If priority is on speed, go for number
range FCFS, although they take 3 bytes.
CB: On this case, we looked at the specification. My confusion was that
the specification was complete and tried to get tags, but also eligible
as input to an IETF document that could make more requests. Think of
prioritizing speed of obtaining tags (larger in size) or efficiency
(slower process).

Following up on WGA call for EDN-literals and CDDL 2.0 documents

WGA calls (EDN literals and CDDL 2.0) were not formally
completed and now formally accepted

CA: They are adopted now; let's go ahead and please resubmit as IETF
documents.

Intention w/rt data format in Gordian

CAl: Pieces of Gordian have been used in cryptocurrency applications,
and some W3C (wherever there is frustration with JSON-LD) actions. Not
many people in IETF community are demanding graph CBOR data. ISO(?)
community is working on MDL (mobile driver license) in parallel (very
intransparent process, but using CBOR too, currently with simple
hash-based elision).

CAl: Is there IETF interest in the data minimization and human rights
aspect? No IETF specs we know of do hash based elision. SCITT might want
to use Gordian Envelope later on, but they are not really looking at it
at the moment.
CAl: We really want Gordian envelope to NOT be in the Security area. We
think we're using well-understood security building blocks, and we'd
like it to be a data standard. We don't want to get bundled into COSE.
We'd like to focus on representing graph data in CBOR.
CAl: Is CBOR interested in having a CBOR RFC speciphically on graph data
starting from Gordian envelope? We'd prefer standards first, while there
also are several companies using envelopes.
CA, chair hat on: Not much to say -- just have to gauge WG interest.
CA, chair hat off: I have some personal interest in graph data, thinking
of CoRAL and using CBOR in constrained applications. But focusing on
constrained devices, little interest in working with data sets that need
much extra data to verify (if data needs to be minimized, it will be
minimized for the constrained device).
CB: Looking at the document, it's interesting and it collects things not
really close to each other. Tags 204-206 are interesting in emboding the
choice of the specific algorithm about doing something. These tags are
old and will change over time (e.g., when introducing better compression
libraries).
CAl: I think we failed in conveying that these were simple default
choices. Of course other people will do other things. We don't want to
define compression standards. The tag is just about signaling what
happened. More challenging for the hash case, where we ended up for
SHA-256, leaving any different need to future tags to define. We'd like
guidance on expressing this intention better.
CAl: If people are interested, we can continue in this direction. While
for dCBOR and numeric reduction we really want to do everything we can.

CB: We have a registry for hash algorithms (RFC 9054), we'd like to rely
on it. There is a similar registry for encryption algorithm (see RFC
9052 and RFC 9053). There is no CBOR registry for compression
mechanisms, which we may want to think about. Then there is 202 to
indicate a function to be indicated somewhere else, but those functions
are not really defined.
CAl: If to be done in CBOR group, this will need to be addressed, but
that will be a year, and we need to move ahead. If this isn't going to
be a CBOR work item, is the choice to move to the 3 bytes? About known
items, we've kept running into assertions that we run into all the time
(common predicates) that we don't want to run by IANA all the time. But
all the other elements should be independent (with exceptions, eg. hash
algorithm). Experience with filecoin (tagging of hashes) is something we
want to get out of, we just need a relatively safe hash tree.
CAl: Overall hoping to have the CBOR tags assigned shortly, without
having to resort to the 3-byte tags.
CB: DE will have conversation about why things can't be done in 3 bytes
then. But first need to understand the spec's approach to algorithm
agility.

CAl: Coming back to earlier question, that's not what spec says -- spec
says doc need clear specification. If this is what everyone has to go
through, that's an example. Don't think everyone going for 3-byte tag is
a good idea. Would like clarity on what DE does.
CB: Section 4.6 of RFC 8126 explains. Some things are required about a
spec that are written only there.
CA: On Algorithm agility, if the DE sees that an algorithm is picked and
"good for a long time", I think DEs will generally say this is better of
with a 3-byte tag.

CAl: I'll talk with Wolf and other people in the Gordian community. Is
any of this a topic for IETF 117?
CB: I hope we have completed the discussion before then,.
CA: Our slot is 1 hour. This can get maximum 15 minutes. You'll need to
get to your point very fast to leave time for actual discussion.
CAl: It can also come at side meetings.
CA: That's good.

AOB

CA: Will come back with a tentative agenda for IETF 117.

Note taking: Marco Tiloca, Christian Amsüss