Minutes interim-2023-cbor-05: Wed 15:00
minutes-interim-2023-cbor-05-202303081500-00

Meeting Minutes Concise Binary Object Representation Maintenance and Extensions (cbor) WG
Date and time 2023-03-08 15:00
Title Minutes interim-2023-cbor-05: Wed 15:00
State Active
Other versions markdown
Last updated 2023-03-10

minutes-interim-2023-cbor-05-202303081500-00

CBOR working group conference call, 2023-03-08
Meetecho:
https://meetings.conf.meetecho.com/interim/?short=c5da1038-9603-44ad-9950-a4e12975edeb

Note that the meeting will start 30' later than usual (at 15:30 UTC
instead of 15:00 UTC), and will only be 30' long.

CB chairing for the first half hour.

Early hallway discussion (until 15:30 UTC)

CB: Ongoing work on CDDL 2.0 module structure from
https://datatracker.ietf.org/meeting/interim-2023-cbor-05/materials/slides-interim-2023-cbor-05-sessa-cddl-112-00.pdf

CB (p4-5): showing examples on importing CDDL from RFCs.
CB (p6-7): showing examples of inclusion by pattern, with different
level of precision for the selection.
CB (p8): ... and with unnamespaced alias
CB (p9): overview of command line arguments for cddlc

Russ Housley: Thanks for the hard work
CB: Is this useful?
RH: Looks like it has all I need

Chris Lemmons: I'm trying to use this. You showed the import of
COSE_Key and some drafts may want to define different values. It seems
like using 'cut' is a good way.
CB: \'*\', \'->\' and similar are not entirely precise.
CL: It's ok as a workaround.
CB: The real solution is using socket instead of COSE labels and arrows.
Not fully supported yet in my implementation, but I plan to add support.

CB: What are you trying to put together?
CL: Out of IETF work. Considering an access token built on CWTs, using
CBOR for all the COSE elements. It's convenient to point to other
specifications rather than re-defining things ourselves. Also, some
elements are not defined in CDDL but they are defined in prose.
CB: There's -cbor-rfc-cddl-models that aims at collecting modules easy
to integrate. We may want to put more attention on this.
CL: I'll look at it.

CL: Isn't there a draft collecting things like alternative formats? It's
-notable-tags, currently expired.

CL: It's a bit odd that in CBOR we have registrations of things found in
drafts. That can be confusing for implementations. It's suggested to not
register something almost identical to another thing already registered.

CB: That reminds of Tag 38 (language tag information), which was just a
Github repo, non even an Internet Draft. Then it was needed for RFC
9290, where we needed to extend the tag to address also directionality.
We asked the original registrant to pull their registration in in the
new document. Depending on the license, you may just be able to copy in.
There's no good way to refer registered components as normative parts of
a specification - looks like the best possible way is a downref.
CL: It has an impact on usability.

CB: -notable-tags is trying to cover also the intended area of
applications. Should the Working Group control this? Or is it instead
better for an individual draft?
CL: That'd depend on the tag.

CB: Have you tried to find the original registrant? (~CRS)
CL: I sent an email, but no response yet. I think of following up on the
mailing list.
CB: We should try our best to reach the registrant; if no response, we
move on.

WG documents status and issues

time-tag

CB: From my point of view, the document is pretty complete.
CB: CDDL in the document isn't as complete as it should be. It's already
half-solved.
CB: Larger issue is that it is supposed to be clustered with SEDATE, and
that has been submitted to IESG, with unclear path forward. We can just
submit, but maybe better keep it here to understand SEDATE output.

CA: Anyone blocked on time-tag?
CB: Several related proposals are around. You may want to have signed
timestamps. Henk and Thomas would know better.
Discuss at IETF 116.
CA: Added to the 116 agenda then. We should still manage to advance
things quickly.
CB: Worst case we can split out SEDATE exts to separate draft.
CA: Do signed timestamps need the SEDATE properties?
CB: Probably not.

CDDL 2.0

https://datatracker.ietf.org/doc/html/draft-bormann-cbor-cddl-2-draft

The updated version has a revamped Section 4, which also has been
implemented in cddlc. We should discuss what our plans for this are.

There also is a Section 2, which after a few more tweaks could be
published. This fixes errata and provides much-needed non-literal-based
tags. Again, let's discuss what our plans for this are.

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-cbor-05/materials/slides-interim-2023-cbor-05-sessa-cddl-112-00.pdf

CA: Picking up from the notes above, looks like CDDL 2 is getting
better.

CB: Seems we are converging on well-defined plan for this year.
CB (p1): Plan. 1.1 would not be changing much, just fixes. Control
operators will then be added, well before IETF 118. Next versions will
be 2.0 before IETF 118 (based on -cbor-cddl-2-draft) with focus on
modules, followed by 2.5 in 2024 with focus on annotations. RelaxNG has
them, we can do at least that well. From that, co-occurrence constraints
etc. Converge with JSON-path input.

CB (p2): That was the main line. Outside of that: ...
CB (p2): (I := informational, ... = Standard, BCP)
RH: YANG have yang-catalog.org ... familiar with that (CB: Yes)
Brainstorming: Should we have a cddl-catalog.org?
CB: My view: Would be great. yang-catalog.org is not an IETF activity,
just closely cooperating (and mutually helpful). RH: Run by IETF tools
team, and LLC fund. CB: Both correct...
CB: Question is how to make it useful w/o going through tight IETF
processes. RH: yang-catalog.org has it sorted out. CB: Great. May not
make cddl-modules superfluous (b/c it's referencable, cddl-catalog.org
may not).

CB (p2): 'I'-items pretty important IMO. Others on backburner:
extensible EDN (eg. for CRIs). -draft-numbers suggests how to use
temporary identifiers in examples in CBOR diagnostic notation, until the
document is published, they're registered and replaced with their
registered version by the RFC Editor (not strictly need to become RFC).

MT: on -draft-numbers. Examples look at map keys. Also usable for map
values? CB: You mean, like enums? MT: There can be values (besides keys)
in the CBOR map defined in the draft and to be registered; probably
difficult to define and phrase how the proposed practice would work for
those compared to the map keys (but see mail
https://mailarchive.ietf.org/arch/msg/cbor/yypHn_kNYstpe9RsJQnK9R1ylXA/
).

CB: Is mainline and non-mainline a good way forward?
MT (chat): looks good.
IMD: Is 2.5 really 2.5 (other document), or just ...?
CB: Main statement is that we can get modules done before we get
annotations done.
IMD: Are we going to move toward an RFC for 2.0 this year? CB: Yes. We
may not call it 2.0 and just "a module system for CDDL", but yes, people
need this and are starting to use it.
CA: Summarizing, looks like a good roadmap.

CBOR use in IETF and other SDOs

dCBOR implementation

See the mailing list for some discussion about discussing the dCBOR
implementation and their form of deterministic encoding.

Library, docs and presentations from Blockchain Commons:

IETF 116 agenda

We need to start working up a preliminary agenda for our session at IETF
116.
The sesson is currently scheduled for Thursday, 30 March, at 15:00 Japan
time.

  • time-tag
  • CDDL 2 and roadmap

CB: Grammar fixes and control can be on mailing list (so just
disseminating). Should focus on modules, and will not have good input
for annotations. First 3 of (p1) should make progress, aiming for WGA.

CA: I'll take them in with the role of WG adoption.

CB: Draft numbers.
CA: draft numbers to be emphasisze to ART.

AOB

Wolf McNally: about to publish draft; will be at 116
CA: That's a good starting point. Can you give a brief intro of your
work and goals?
WMN: Blockchain Commons is not-for-profit in blockchain space, but also
helping ppl not re-invent the wheel outside blockchain where it comes to
cryptography.
WMN: Want to serialize data in a stable way (hash-identically),
including Merkle-Tree elision of parts of the document. Published some
CBOR structures, and doing Gordian Envelope needs a stable CBOR
serialization (especially deterministically). We want structures
adoptable widely, and that needs ease-of-use and approachability. CBOR
found to be right choice. Deterministic encoding had some lose ends,
tightening it up. Mostly about things like requirements for CBOR codecs
(must-implement, best practices). dCBOR is subset of CBOR, requiring
in-order keys, and put load on codec to relieve the developer (but
admonitions to devs where codec can't help)

Note taking: Marco Tiloca