Minutes interim-2023-cbor-12: Wed 14:00
minutes-interim-2023-cbor-12-202308231400-00

CBOR working group conference call, 2023-08-23
Meetecho:
https://meetings.conf.meetecho.com/interim/?short=af523eb2-220b-468f-965f-f96e89c6d1cb

WG documents status and issues

(waited a bit for more participants to show)

Quick update on draft-ietf-cbor-edn-literals (CB)

CDDL 2.0

CBOR use in IETF and other SDOs

Progress on Deterministic Encoding Profiles; Layering Model (CB)

CB presenting

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-cbor-12/materials/slides-interim-2023-cbor-12-sessa-edn-cde-00.pdf

CB (p2): not to cover today but ongoing: -time-tag and -packed.
CB: -time-tag is decoupled from SEDATE now. The writeup is in progress,
publication request should be possible soon.
BL: I'll get on it soon for requesting publication.

CB: packed can make more progress as German vacations finish, waiting
for experience from DNS CBOR.

CB (p3): recap on what CBOR is. Then recap on EDN and CDDL.
CB (p4): DN introduced as second-class citizen (no grammar). EDN-literal
was intended to just provide domain specific literals, but has now
acquired ABNF and explanations.
CB: Go into reviews once github issues are addressed.

CB (p5): favorite misgivings about JSON based syntaxes are coming in.
For comments, # and ; have already been seen in the wild. Propose
going for one or both of them. Keep slash based for small mid-line
annotations. On commas, PR available. Hex float is useful for exact
floats (not inherited from JSON). I need some reviews on Github and the
Pull Requests. Please do.

IMD: I'm in favor of defining the use of end-of lines-comment in both
ways. It's harmless to allow both. Maybe recommend the use of one over
the other. I strongly oppose the double slash "//".

CB (p6): Now on deterministic encoding, specifically:
draft-bormann-cbor-det (deterministic encoding from RFC 8949);
-bormann-cbor-dcbor (profile with numeric reduction with no
restatements). Then there's -mcnally-deterministic-cbor (dCBOR) and
-rundgren-deterministic-cbor (D-CBOR). The latter has had many
revisions, still unclear to me what it does. Maybe for the Independent
Stream? (Although we usually don't push things out of the WG in the
middle of ongoing work)
BL: On the Independent Stream, I agree with Elliot Lear's views. For
-rundgren-deterministic-cbor, maybe it can go to the Independent Streams
at some point, but not now that this whole topic is still processed in
the WG. Objections?
(CA concurring on chat)
(none heard)
BL: I'll explain on the mailing list to confirm.

CB (p6): background including topics such as subnormal floats. At some
point will ask whether relevant as WG document.
CB (p6): 2 parts out of WMN's document. Not perfect yet. Split:
CB (p7): Layer split shown as a figure. CBOR as applies to everything at
the bottom. 8949 has holes closed by CDE (common deterministic encoding
profile); this is for the majority of deterministic encoding
applications. Domain profiles on top of it map application data model
(may be related to platform model, eg. if you only have int64/uint64).
Will have several of those.

CB (p8): examples with reference to the different layers
CB: CDE creates a bijection betwen data model items and the encoding
items we prefer to see. Figure hides the fact that CBOR is extensible --
so its beauty is hard to maintain when adding extensions, which is why
CDE needs work.
CB: Next step is that application needs to provide deterministic data
model items. Two relevant functions provided by a profile are exclusion
(what can't be represented) and reduction (multiple things represented
in a single common way). This discussion on the layering was very good.

CB (p9): I think this is about helping use deterministic serialization.
Wolf provided a list of many use cases that can benefit (by no means
devalueing the core CBOR). This help is about a common set of encoding
decisions and the possibility to create multiple simple domain profiles.

CB (p10): I think the outcome should be: -cbor-det as informational;
-dcbor as Standards Track (rather than Experimental as Wolf suggested)
which can absorb -mcnally and/or -rundgren. Asking WGA would be too
early now.
CB (p11): some work is needed on a few technical issues (unlikely that
anyone has faced those in implementations yet).

IMD: Yes, -dcbor should be Standards Track. I like the suggestion of
using some of Wolf's profiles as examples in CDE standards track
document, encouraging rigor on profile definitions. Any reason you don't
think backgrounder text is not good for the standards track document?
CB: We made a mistake in the past, putting too many things in Standards
Track documents. People think the more pages make it more complicated.
Splitting off informational text is good and should be done more often.

IMD: I think it's overall a good direction. (Being concise, not
restating makes easier-to-read documents)
IMD: The IEEE parts, are they hard b/c they're controversial or because
the IEEE source is ambiguous?
CB: It's mainly hard because IEEE leaves a lot to implementations on
NaNs. For those few who use NaN payloads we want to keep it useful, but
vast majority of applications just need a single NaN.
CA: Overall liking the direction things are taking.
MT: Same; thanks for the summary of the dense discussion on the mailing
list.
BL: Good, then let's develop this and hope to reach a satisfying
consensus point.
BL: Not sure I understand Anders yet.
CB: Valid technical points, but yes hard to understand. Will have to
work with it.

IETF 118 (Prague) agenda

Placeholder for when the time comes. Please enter items at any time.

AOB

CB: Will not be around in 2 weeks.

Note taking: Marco Tiloca, Christian Amsüss