CBOR working group conference call, 2022-02-09
Agenda and notes:
Note takers: MT, (CA)
WG documents status and issues
CA, summarizing: -08 is about document cleanup (normative vs. informative) and editorial changes – CB, wasn’t there “easily contested historical statements” you wanted removed? Or was that just relative to the editors’ copy?
CB: on PR 14 had actual changes, only cleanup on 15. Should be all covered.
CA: Happy to send to the IESG as is? (-08 came out just yesterday, if -07 was fine for you so will be -08).
(heard no objections)
CA: We go for a short WGLC (1 week). If nothing comes up, we go ahead with shepherd write-up and publication request.
MCR: Works for me.
Next steps:
CBOR use in IETF and other SDOs
CB presenting based on slides: https://datatracker.ietf.org/meeting/interim-2022-cbor-03/materials/slides-interim-2022-cbor-03-sessa-elision-00.pdf
(eg. RFC9052/9053 (?) AUTH48 comments)
CB: Not always needed to keep full value for bstr, tstr, in arrays and maps …
CB: created syntax, may not be final: three dots in the place of data items (p3) and more (p4). Not trying to express zero-or-more semantics visually.
CB: Sometimes some elision in the middle of a string can also be useful
CB: Still have to implement but need to fix a repo first.
MCR: Big question is what happens when you parse that? “Yes iot’s syntactically correct but you don’t get a value”?
MCR: Would it work and be useful in the other direction? What happens when parsing something incomplete?
CB: Have more slides… p5. This is different b/c examples of RFCs are often (hopefully more and more) machine generated, so generating CBOR data item expressed as if it had elisions would be helpful. Tag proposed (888 looks like elision) in cases when diagnostic notation tool is configured to use that. Could have different (non-standardized) tools, eg. eliptizing strings.
Both for verifying and generating examples.
CB: Diagnostic code already has half a dozen of flags; this one sounds reasonable.
CB: No text written yet, asking feedback first.
CB: Will implement it, then it can complement the eedn document or be a separate one.
CB: CDDL interaction? Could CDDL processor tell where to elide? Could it check examples with acceptance of elisions? No persuasive use case yet.
CA: I’ll have to think of what to think of this.
MCR: Not sure how I’d use 888 tag in practice. Many things might be “if you see 888, blow up” (?). Tag makes it visible. Fear it’d wind up as code, but people can do many stupid things.
CA (on chat): possible many ways to abuse of this.
ST: Using this in machine generation sounds useful and I’m all for it; machine generated stuff saves later checking.
CB: On abuse, flag to diagnostic notation tool will help.
CA: That’d curb a few of the bad ideas I’m having.
CA: On CDDL interaction, looks like .cat and wonder what it means here.
CB: .cat is in CDDL, this is diagnostic notation. In CDDL you’d say what is allowed and what not.
CA: Maybe .cat-related rules to be considered for an 888 tag verifier?
CB: Not so easy.
CA: True.
CB feels encouraged and will write this up at some point with companion implementation.
None discussed.
[CB]: Carsten Bormann
[BL]: Barry Leiba
[FP]: Francesca Palombini
[IMD]: Ira McDonald
[MCR]: Michael Richardson
[CA]: Christian Amsüss
[MT]: Marco Tiloca
[PP]: Philip Prindeville
[ST]: Sean Turner