Skip to main content

Minutes interim-2023-cbor-02: Wed 15:00
minutes-interim-2023-cbor-02-202301251500-00

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

minutes-interim-2023-cbor-02-202301251500-00

CBOR working group conference call, 2023-01-25
Meetecho:
https://meetings.conf.meetecho.com/interim/?short=40093a3a-d880-4ad3-8fd1-9ec668032ad2

Please add/tweak agenda items before the meeting.

WG documents status and issues

BL doing introductions

time-tag

Finishing WGLC. Need to discuss intended status (Informational vs
Proposed Standard).

BL: CB can you give an update on the discussion?
CB: Long-standing discussion on defining a tag in an informational
document.
CB: Happens time and again, people want to normatively reference the
spec of a tag that's defined in an originally informative document. We
need to get better with this cases, a standing rule.
CB: Some security applications would benefit from time-tag coming from a
normative document.
CB: Extensions come mixed in high and low priority components; going
from informational to standards track raises questions on them. In
total, we do have good arguments here for moving to standards track.

BL: Anyone objecting about moving to Standards Track? No objections on
the mailing list.
CB: There were GitHub discussions about clock quality, esp. as it's
defined in terms of an RFC that doesn't define anything and references
paywalled IEEE spec (not even available through Get IEEE).
BL: My inclination as a participant is to go standards track, and see
what IESG says.
BL: Any updates other than these?
CB: Yes, several comments on Github. A next version is planned, but CDDL
took priority. Now targeting next week.
BL: Let's say, on next version, make it standards track, and I'll change
the data tracker, and we'll ask on the list for objections.
CB: Works for me.

CDDL 2.0

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

(Last time Carsten said this: "New tool functionality not quite ready
for consumption yet, will probably have to wait for next interim. We
have a spec but not an implementation, though I'm working on one.")

CB presenting, CA taking over active chair mid-presentation.

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-cbor-02/materials/slides-interim-2023-cbor-02-sessa-cddl2-and-cddlc-00.pdf

CB (p1): Many requested the #include feature.
CB: ;# will be pragma prefix unless someone has better ideas.
MCR (on chat): ;# because it is kind of a comment?
CB: Yes, aligned with the spirit of comments in CDDL 1.
CB: The problem is that you get additional rules, then I'm thinking to
reduce to the imported rules and the transitive closure of the
reference.
CB: "prelude" is currently named specially. (Might not be necessary
anyway, to be checked when running through all RFCs)
CB (p2): There is a cddlc tool that does CDDL processing and produces an
output compatible with CDDL 1. Where are referenced documents found?
Plan to have all RFCs into the implementation. If new RFCs are
published, the gem has to be updated. An alternative is pulling from the
web but the workflow might not that well.

MCR: You should have another places as CDDL path. File extract from RFCs
to make a database is fine. Maybe you want to mechanically make a
separate gem. I'd like to be able to point to my own directory (e.g., if
working on a set of link documents).
CB: Not much needed for RFCs as stable. If you're on work-in-progress
document, they might not be anyware on the web.
Russ Housley (on chat): The extract of CDDL "files" sounds a lot like
yangcatalog.org for YANG modules.
CB: So far it should be manageable. Also need to think of old RFCs. The
problem is documents that have been edited right now.
CA: If we need a conversion from CDDL 2 to CDDL 1, why does pragma have
to rely on something common? A document that imports won't be usable
anyway, so why invoke the spirit of <!--[if !IE].
CB: No strong opinion. True that usefulness will decline over time, but
having #; sounds cheap to have anyway.
Russ: When other SDOs start using this, we need cross-SDO repo.
CB: Pragmatic 80% solution would be good. Finding the documents and
getting them through a Makefile into local directory worked for me.
MCR (on chat): being able to set $CDDLPATH would work for me, and would
let my Makefile ../other-sdo/module-foo:../yet-another-sdo/module-bar
CA: That should be implementation details, right?
CB: Yes, but important details, because if the impl can't do it, the
language will need to do it.
CB: Next version of the tool expected in the next few hours. This will
likely require a modern Ruby version (>3.0). The amount of work required
to make such a tool is not unreasonable.

CB: Question not from slides; when including something that has includes
on its own, CDDL path will become interesting.
CA: No suggestions other than using URIs (with the known issues of what
to fetch).

CBOR use in IETF and other SDOs

CA: Any news to share?
(heard none)

IETF 116 agenda

(Placeholder for when we're closer to meeting time.)

CA: Any item already to propose?
(heard none)

AOB

CA: Let's try out cddlc then!

Note taking: Marco Tiloca, Christian Amsüss