Minutes interim-2023-cbor-03: Wed 15:00
minutes-interim-2023-cbor-03-202302081500-00

CBOR working group conference call, 2023-02-08

WG documents status and issues

Carsten's slides for both items:
https://datatracker.ietf.org/meeting/interim-2023-cbor-03/materials/slides-interim-2023-cbor-03-sessa-carstens-slides-00

CBORpath ( https://github.com/cbor/cbor.github.io/issues/90)

Carsten: I’m not yet requesting any WG action but maybe we can have a
first look and bring this up at our Tuesday (JSONPath) and Wednesday
(CBOR) interims.

CB presenting

CB: This was foreseeable; I became editor of the JSONPath document, also
in the interest of considering this topic in CBOR. A simple adaptation
for CBOR would not use the extensive data model of CBOR. We're close to
wrap-up JSONPath, then WG Last Call.

CB: Michaël Catanzariti wrote a Rust implementation, not a bad plan to
get started. He contributed a structured CBOR form for the CBORPath
query right away.

CA: So the format of CBORPath would be CBOR already?
CB: Yes, and shown in CBOR diagnostic notation.
CB: Diagnostic notation that'd result from Michael's proposal is not
bad. So in the CDDL world, this would be good to have once we plan to
add the equivalent of what schematron is for Relax-NG.

CB: Please look at github issue, all is linked from there.

CA: Sounds a good thing to have.
CB: Mostly for people that are in the Venn diagram between JSONpath and
CBOR people. Trying to get more people interested.
CA: I was more thinking of people often not using traditional tools like
sed/cat/... but more modern tools. CBORpath would be useful to make
things better in this space.
CB: We may at some point discuss specifically tools.
CB: I found jq to be different in usage from what I'd use a cq for,
so no student there yet :-)
CA: Even if at a high-level, it sounds useful.

CDDL 2.0

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

https://mailarchive.ietf.org/arch/msg/cbor/tFdfiv58pOAzoFH2rpf8JDJ-uTY
and the thread below that.

Discussion today: Is the cddlc prototype for import/include a useful
step towards CDDL 2.0?
What else is actually needed to address the objectives?
E.g.,

• scraping IANA references

• scraping I-Ds for CDDL (sourcecode attributes such as @name ?)

  • rules for making RFCs "scrapable"?

• export as? (identify what is meant to be imported vs. what is
  internal by nature)

• import from? (get some of the rules into the importer's namespace)
• ABNF integration?

CB presenting

CB: current spike on referencing and importing.
CB: Still, already 80% solution, and useful.
CB (p2) current goals: file inclusion; importing of "CDDL libraries";
organization in namespaces.
CB: include vs. import differs in whether all is needed (include) or
just a part (import)
CB: This is part of the overall CDDL 2.0 plan for the related document.

CB (p3): The goals above can be fulfilled by a CDDL processor.
CB: Not calling it a "preprocessor" because it fully understands CDDL.
Make CDDL-2 introduction not disruptive. A simple implementation may
even skip parts of CDDL1 and rely on the processor for that (although
the outcome might be not exactly as preferred).

CB (p5): comparison of include and import. Include triggers "unused
rule" warnings, which can be useful. Import includes only the rules
that, if absent, would trigger "undefined list".
CA: What if what is imported has missing items of its own? Would those
missing items just leak?
CB: That's the issue of isolation. The undefined-list of the imported
item doesn't leak to the list of the undefined items for the next
import. But the way this isolation acts needs to be discussed in real
examples. The thing import is used on I would expect to be stable and
somewhat complete. See next slide: Imported module can have own imports,
and those are conceptually handled before the outer import is handled.

CB (p6): answers isolation topic. Processing of an item happens before
its importing/inclusion. Referencing context does not influence meaning
of the imported data. ... (Should also address Jeremy's concern about
diamond nested includes, but includes are idempotent here and thus are
innocuous). So the tree gets disentangled.

CB (p7): Module targets are not nailed down in the files as, where
modules are, might be not known. The place should be defined in an
Environment Variable. Empty string means "batteries included" space --
this will need some agreement on what is there (but with only one
implementation, we can defer that problem).
CB: Not trying to address web sources here, because that's complicated.
But we can cover IANA registrations, Internet Drafts, and some
project-related resources like Github/Gitlab repositories. The problem
would be similar to the ones seen in the yangcatalog.org space.

CB (p8): That was import ... now export. Trivially, one can look for the
CDDL marker, extract all instances and concatenate them. Might also give
you examples in addition to normative text. Or use attributes (@name).
CB: Checkbox on slide is empty b/c convention is needed.

CB (p9): Do we need an actual directive for exporting? Maybe yes, if we
want to have accompanying information, e.g., selectively export only
some rules (think of COSE_Key, ... in RFC 9052). Still thinking if this
is actually useful to have; if so, it's possible.

CB (p10): IANA has no defined API; will need rework when IANA gets API.
They seem to have a defined API on their radar now, have discussions in
this year.
CB: Something can be done now anyway, e.g., for cose-algorithm
CB: .iana here more a general operator, not necessarily a directive
(b/c that would have weird interactions)
CA: Is this only for limiting values? Or would this allow to annotate
values too (given annotations are on the CDDL-2 road map)? It might be
convenient here.
CB: Good comment.
CB: Looking at the selection step for now, but some transformation might
also be involved.

CB (p11): Mostly covered (and always only for XML submitted). (CA: Wat?
CB: Yes, nroff still exists.) Pointing to a specific revision if fine
and stable, but pointing to the latest one can be an issue. (Ambiguity
when drafts end with -number ...)

CB (p12): "Luckily", all others using CDDL are currently stuck in IPR
issues. But this is about to change... please let the list know.

CB (p13):
CA: 9052 was thinking of using something like COSE_*. Does it makes
sense here too? Or let's call it a road not taken?
CB: Using wildcards to select from a name collection is brutal. It might
work here, but I'm hesitant. It seems hard to control and can break.
CA (chat): I'm happy with abandoning the wildcard thing, just might need
acknowledgement that we thought it'd be good until we had something
better.
CB: Still have to deal with transitive closure things ... eg. "label"
example.
CA: Do we have an actual issue with the "label" rule? It should be
covered by the undefined list. The internal label would still be around
internally.
CB: There isolation is not great. After importing 9052, then you have
the label in the ruleset.
CA: Also if not in the undefined list?
CB: It gets there because it is used. There are no scopes, since the
result is CDDL 1. You have to use namespaces to enforce scopes.
CA: If I write a document with a nasty label and I import RFC 9052?
CB: You get a conflict for multiple label definition.
CA: Wouldn't the processor rename the label?
CB: All I'm saying is it's probably easier to give user a way to decide
what scope name is.
CA: Then if I use a non-RFC document, troubles can come.
CB: You may not care.
CA: Well...
CB: Convention should be to use as; there may be reasons why you don't
need that, but then you need to know exactly what you import.

CB (p14): On the '.' character that can already be in use and create
strange conflicts. These should be under control as part of the import
process.

CB(p15): comparing pros and cons of using "as".

CB(p16): bikeshedding points would include syntax discussions e.g., use
of space after ;#.

CB(p17): ... and same for ABNF. (It's already used informally ...
digit etc.) Not changing ABNF, mainly for ABNF support in CDDL.

RH: "as" keyword could be both for import and include, right?
CB: Yes. Originally only for import, but found easier to be consistent.

MT: It's a lot to digest.
CB: It's just 80 lines of code :-)

CA: If we do import-as, items might want annotations for original name
in CDDL2 land.
CA: If my processor is CDDL2-aware, it might avoid the effort of some
processing such as expansion.
CB: Way out of this is covered by import from generating foo = COSE.foo rules. So information is in the rules.

CBOR use in IETF and other SDOs

IETF 116 agenda

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

AOB

• cddlc: Is default output (AST) stable / documented?
  CB: It's documented in freezer. It's an AST; turns out I want
  to process rules before working. cddlc -r -tneat has useful output
  for this slightly processed form (but that's not documented yet,
  Action Point for CB...).

CB: Please install it and use it in your project; I'd welcome feedback

• No link to the CBOR meeting in "upcoming" ... maybe b/c we don't
  upload agenda? → CA add dummy agenda that points to notes

Note taking: Marco Tiloca, Christian Amsüss, and a few fixes from
Carsten Bormann