(The 2’ slots for some documents are primarily to state document status / aliveness, and/or get room input on further directions, based on the standing assumptions that People Have Read The Drafts.)


Minute takers: Marco Tiloca, …

Introduction, agenda. Chairs, 3’

CA: showing up not well and agenda
On p3 of chairs slide, not notable-tags; it should be edn-literals

cddl-control, network-addresses

CA: Both now in RFC Editor’s queue.


CA: Adopted but waiting for input from the WG, to be aligned to SEDATE too.


CB: way now to use 8- and 12-byte prefixes 55799 and 55800. Now defined more for content-formats.
CB: Mistake in v -06 of the document to be fixed in examples, to really consider CBOR. Need for bstr wrapping. Wanted this ready for this meeting.
CB: possible fix (p4), prefix not entirely unlike a CBOR sequence. Only one item to take for the decoder, what follows is raw data. This should cover all content-formats.
CB: (p5) plan to update examples accordingly, then WGLC on v -07

MCR: 55801 is a good solution but tempted to just keep what we have; sounds like way beyond CBOR
Ira (on chat): +1 to the plans - certainly add 55801

CA: Still have use cases for content-formats under all these categories?
CB: Yes.
CA: Anything considerable for exclusion?
CB: We have use cases, have to include examples.
CA: As shepherd, bstr was there in -05/-06 as covered in WGLC. If we extend the scope, the document has to go through a 2nd WGLC and design revision.
CA: To explore in -07, examples should clarify the use cases.

CB: Example for 55801 would use cf=11552 LWM2M+TLV


CB: (p6) open points are table building through nesting; prefix/suffix/shared modes
CB: (p7) recap of packed components. Table building is well understood, maybe not well described yet.
CB: (p8) showing planned next steps for the base document (table model, setup tags, …)

CA: so records would be a use case for packed?
CB: I don’t know, a lot depends on what applications use the tags.

HB: Brendan not here; would be cool to use finalizing SUIT manifest as example for packed. Good exercise.
CB: Explain “use as an example”?
HB: Lot of reduntant references, e.g., identifiers, in the SUIT manifest. Brendan is trying to reduce size a lot. Some compression is alredy there, but could still be enhanced. This would help and worth trying out.
HB: Not for this document, but once this is stable and out, would like to immediately redo SUIT with packed.
CB: Can’t you use SUIT as is and packed as is in a good way already?
HB: That we’ll have to find out. Not this year, but maybe around next hackathon.

CB: Maybe general request for data items that can benefit of packed; we can try collecting them.
CB: Also good for evaluating packer implementations.

CA: Do you expect a wide use of this? Looks like packing is going to be static / predefined by application knowledge.
CB: “Generic packer” may save time in application, but requires building full structure. Not likely in constrained implementaton. Do see area where it’s useful, thus collect best practices, but packing friendly CBOR encoder APIs may also be an interesting subject.

HB: No gut feeling on this; how easy is it to pack features rather than manual configuration?
CB: Depends on how much machine learning and AI is in there ;-). Writing compressors is well understood. Would expect generic packer to be as good as manual packing, and find things you’d miss. In effect it might be better.
HB: In general, yes.

Application-oriented literals (EDN)

CB: Have good feedback at the interim; not implemented yet.
CB: Thus hesitant to go for WGLC, but adoption would be possible.

CA: Running a show of interest. Raise hand: 7; Do not raise hand: 0; total: ~20. Will handle the rest on the mailing list.

Future development of CDDL

CB: (p9) Discussed at IETF 111 and given some hints, I can give more directions now. Mostly about CDDL control beyond extension points; more low hanging fruits on annotation and composition.
CB: (p10f) on composition, first rule is the type as entry point. But we want to build libraries as files exporting more rules, and to import rules from other specs. Thi requires to name libraries; possible to import implicitly or implicitly (p12); naming and linkage proposal for libraries (p13).
CB: (p14) namespacing also to handle
CB: (p15) use of CDDL in alternative applications, making it more first-class
CB: (p16) improve automation, for generating libraries from RFC/IDs, IANA registries and other sources
CB: (p17) as to syntax, 1.0 files fit in, 1.0 processors can be useful in 2.0 too
CB: (p18f) on annotation, extending with .feature, the cddl tool can annotate tree with rule names. MVP is relying on rulename attributes
CB: timeline (p21) is having a prototype by end of 2021 for composition and for parts of annotation; aim at having the full spec for IETF 113. Then discuss whether to publish in its entirety or split, and other steps.

HB: I strongly support this, thinking also of defining codepoints in maps. Don’t think this will come to WGLC before IETF 113. On the annotation part, that requires more elaboration with Brendan.
CB: We can have design team meetings.
HB: Yes, and then interim meetings to discuss main points.

CA: Ambitious timescale, needs much interim work (15Dec, design team), and yet ambicious given the holiday period.
CA: CB and HB, would you collaborate? Other interested parties that would volunteer? Not WG document yet, just anticipating.
CB: I expect to start, people will contribute, then we’ll figure out authors. Thinking of Henk already.
CA: Ad annotation: also no way for rule writer to know whether annotation is unambiguous (doesn’t matteCCr for validation). I’d appreciate if CDDL could be shown to be annotation-supporting by tools.

HB: (…) There are further interested parties, can’t name any right now.

CB: SCIM WG meeting 2h ago, this would be nice benchmark.

HB: The other project is called SCIM, too (Supply Chain Integrity Management)…