CBOR working group conference call, 2023-12-13

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=04c6286d-c456-4406-bbec-90442baa5164

WG documents status and issues

• Shepherding draft-ietf-cbor-update-8610-grammar-00 and
  draft-ietf-cbor-edn-literals-06 (chairs?)

CA: Now assigned as shepherd, starting reviews.
CB: Bottleneck at RFC-Editor anyway.

• Next steps for draft-ietf-cbor-cde (CB, all)

CB (p3): We want to do this w/o spending anothr year on it. NaN payloads
need some more attention, maybe others? Hoping for implementer feedback.

CB: IEEE745 interop has holes b/c implementations of NaN payloads have
diverged and IEEE didn't enforce anything. What should implementer of
generic CBOR en-/decoder do? Many probably won't implement basic NaN
payloads. More about helping implementers who want to do it.

CA: What are the issues on the NaN payload? There's a NaN flagged by the
exponent, then the mantissa doesn't add any equivalence.
CB: Correct.
CA: How does that affect/complicate an implementation and requires more
work and clarifications from an IEEE side?
CB: One issue is that bit that tells quiet-or-signalling is defined, but
it's unclear which value means which. There is some consensus, which we
reference in the preferred encoding discussion. Sending signalling NaNs
is usually not helpful b/c it signals immediately. The other things the
preferred encoding does is that it does request you to use the most
compact form (float16 for the quiet NaN everyone implements), but that
requires definition of which long payloads can be abbreviated with which
shorter payloads. 754 is not explicit about that, but there is a pattern
done for all other truncations (truncate if rightmost bits are zero).
CA: No opinion on this yet, but I know what I can reason about.

CA: Can anyone raise their hand if worked before with floats in CBOR at
all?
raise your hand: 1
do not raise your hand: 5
no opinion: 0

CA for later shepherding: This is a niche comment.
MCR chat: The only place I think that lack of NaN support matters is in
some protocol which didn't quite envision using floats at all, and then
they suddenly start (perhaps by mistake), and then the fact that
NaN!=NaN bites someone. (I have never worked with floats in CBOR)

MCR: So it's probably OK if the CBOR library has no support for floats
at all. It's dangerous when lib supports them but you don't use them,
then you try printing it.
CB: 2-3 years ago would have agreed completely; now with machine
learning, we'll see more in constrained environments. Will need to look
deeper there,
CA in tongue-in-cheek chat: CBOR posits when?
CB: also 8-bit floats.

CB: Take this to mean that it will be useful to have some discussion of
this in CDE.

CDDL 2.0

CB presenting (from page 4)

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-cbor-18/materials/slides-interim-2023-cbor-18-sessa-carstens-slides-00.pdf

• Next steps for draft-ietf-cbor-cddl-more-control (CB) (CB, all)

CB (p5): In this round: Doing more for supporting CBOR and text; base64
support etc. without ad-hoc code and comments. Examples coming in where
people want hex representations; printf could do this w/o per-format
controls. Will need some specifying down to what is supported.
CB: For that, would be useful to see what is used (by now, 100s of docs
using CDDL). Getting input from users would be useful -- how can we
solicit that? (not all of them are within the IETF). Good input from TCG
already.
CB: We can do another document later still, but every few years should
be a reasonable rhythm.
IMD (on chat): +1 to IETF and outside outreach for CDDL users

CA: Does it make sense to contact WGs that have used CDDL extensively?
There are 4 or 5 that can easily come to mind.
CB: Yes, pointing them to this slide and next one.
CB: Could also have CDDL focused interim segment for each of these WGs,
but maybe general call first.

• Next steps for draft-ietf-cddl-modules (CB) (CB, all)

CB (p6): In use already. Text avoids normative reference as it'd incur
delays. Here we also need feedback from users. Who has used the module
stuff?
raise your hand: 1
do not raise your hand: 5
no opinion: 0
CB: Not surprised -- CoRE (core?) people who use it use it for
constrained systems where you don't need that that much. May be part of
the problem: People doing more complicated stuff maybe don't go to CBOR
WG.
IMD (on chat): GlobalPlatform Trusted Platform Services new APIs (soon
to be published) heavily use CDDL and import/include functionality is
important

CA: Then it makes sense to invite joining a specific interim meeting
before IETF 119 to gather feedback.
CB: Sounds good. We can prioritize Global Platform then.

IMD: Editors of Client API (basically a TPM/SE) is also used by the
Entity Attestation API (using EATS, which is more mature than IETF
work), and a universal keystore (OS and application neutral, promoted by
Global Platform and will get wide use)
CB: Access?
IMD: All in public githubs. Can send mail. From their PoV,
import/include would be nice to be already published.

IMD: Also, about float numbers, long ago was decided to not have them in
their libraries.
CB: You may still have specific floting point values that you really
needed available to avoid stopping/failing some processing.
CA: But there are CBOR-encoded binary strings encoding floating point
numbers.

(for context, this paragraph happened after the "AO documents" but still
belonged in here)
IMD (on chat): Do we have a timeline for CDDL 2.0?
CA: No milestone about that (or any, for that matter)
CB: We have two independent items (control and modules). I'd be happy
with freezing those early next year too.
IMD (on chat): I agree that February would be a good feature freeze
cutoff for Modules and More Control.
CA: Sounds good.
IMD (chat): And communicating those feature freezes to other IETF WGs
would be excellent
CA: Carsten, will you send a mail out to the relevant WGs?
CB: Yes, or I'll prepare it for you to send, so it comes from a WG
Chair.
CA: Yes to either.
IMD (on chat): I can forward to Global Platform and TCG mailing lists.
CB: Then a third item is what I call CDDL 2.5 (annotation), that is
seemingly wanted by many applications. But I'd prefer not to put a
timeline on it yet.
CB: First thing for that is probably see how JSON Path can be useful for
CBOR / CDDL.

AO documents

CB (p7): packed

CA: timebox -- suggesting 2024-02-29. No more new features or ideas
after that, unless there is a fix.
CB: Ok; so second WG Last Call approximately at that time?
CA: Yes. So we should be done by the next IETF meeting.

CBOR use in IETF and other SDOs

Heads-up: increased interest in what might be a CBOR-LD

CB: JSON-LD people noted that people don't want JSON for efficiency
critical application. Started with YAML, so there is now YAML-LD
community group spec. There is already a CBOR-LD "document" that
describes what one implementation does, a variant of packed as defined
right now. We may want to do more there. Many non-technical aspects
coming in here.
CB: Question is ... just like JSON-LD is a good way to represent RDF in
JSON that's useful for people using RDF, same may be applicable for
CBOR. JSON-LD now has framing, which controls how RDF is shaped into
JSON.
CA, in a non-serious tone: Finally, after 10 years...

CA: Having used a lot of CBOR and RDF, we can shape only CBOR-LD. Shape
and context can always be provided out-of-band. Than it's more about
which transmission language is used. I should have a look at the
shaping.
CB: One problem is that those transformations can be very lossy. Then
there is the anti-pattern of shaping the design per the examples you
come up with (although examples are surely necessary to have). Would
like to avoid running into the same problem and related hidden semantics
hidden in transformation (what CURIEs are).

AOB

CA: Have good holidays and see you at the next interim in January!

Note taking: Marco Tiloca