CBOR working group conference call, 2024-01-10

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=9cce4c41-debd-4956-92ef-6a4d6ec7ebad

WG documents status and issues

CB presenting

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

• Discuss status of pending IESG submissions

CB (p2): Some documents at the tail end of their journey. -time-tag is
in the RFC editor queue for a while, tags 1001..1003 usable already. 2
documents passed WGLC, next step is the Shepherding. Still validating
-cbor-packed, still have to update my implementation to be aligned with
the latest version; we gave ourselves end of February as a deadline, a
further WGLC might follow, hoping to send to the IESG before IETF 119.

CB (p3): grammar and literals updated after shepherd review, now ready
to send to the IESG.

• Timeline for -more-control and -modules?

CB (p4): Anything we miss in this round we can do in the "next round" of
this document for in a few years.
CB (p4): CDDL 2.0 planning interim to be planned before Brisbane.

CB (p5): -cddl-modules is already used as a concept, but its use in
specifications is understandably requiring to progress more here. We
need feedback to progress.

CB (p6): packed updated today (no technical changes). Table setup may
interact w/ deterministic encoding. That should not influence this
document except in that we learn about it. Plan is to take feedback and
finish this by the end of February.

• Discuss draft-ietf-cbor-cde in relation to
  draft-mcnally-deterministic-cbor; discuss disposition of the latter

CB (p7): seccons will need some more thinking. List thread on full
coverage of CBOR and NaN. Mostly discussed on the mailing list if
there's actually a problem and what we can/have to say about it. The
2019 version of the IEEE standard covers a bit more, but we still need
to position ourselves. I think -01 says the right things, but will need
implementations. This does NOT mean that deterministic encoding sets a
new requirement for implementing this, but still it's an opportunity to
clarify for those who want to. Most people have application profile that
reduces NaNs to quiet-with-zero-payload, which is appropriate for many
cases.

LL: I'd like to see NaN payloads not supported, just use half-precision,
for couple of reasons:

• programming environments generally don't support NaN payloads (works
  in C/C++, hard anywhere else, and even there needs cast, bitshifts
  and reading). Not terribly hard, but not easy to figure out either.
  There is is_nan(), but no library support for getting NaN payload
  out. No literals in C, etc ... dusty corner.
• use cases -- would like to see end-to-end use case, not just do it
  just b/c IEEE 754 supports it. Joe Hildebrand suggested one, but
  would like to see more.
  LL: We're trying to do determinism here. CBOR serialization is hard
  to understand, seems reasonable to lock this down. For the new
  deterministic specification to have a dusty corner like this ("we
  say this, but mean that" / shortcut), that seems off.
• Don't think we're obligated to support all of CBOR. Doesn't mean
  we're closing this off, this is just CDE, have option to do it for
  some other cases where CDE is not necessary, just like indefinite
  length. Just don't do CDE if you want a NaN payload.

CB responding to LL: Would have been good in 2013 when deciding what
CBOR is, but using CDE to deprecate NaN payloads doesn't strike me as
right. As you said, it's not that hard to do it right. 3 lines
pseudocode? When did initial Erlang support, Erlang has neither NaN nor
infinities, so CBOR for Erlang needs to invent their own runtime
representation for that. Can be done when people want to have it in
their application protocols.
LL: It's been this dusty corner since 2013, and it'll still be a dusty
messy corner, never mainline, with no important use cases. I'd like to
have CDE w/ no dusty corners.
CB: I'm optimistic that we can define CDE well and to be very clear. We
can't help about what implementations end up doing.

WMN: Our reason for leaving it out in dCBOR was that it's semantically
ill-defined. Often used internally, not in interchange. When talking
about determinism (esp. in the narrower dCBOR way), guiding principle of
dCBOR is that things w/ same semantics should have same representation.
It has no semantics, therefore can't be expressed.
WMN: Not objecting if CDE closed it off in same way, but also fine with
keeping that opinion at dCBOR. So, not about being dusty, just about not
having semantics.
LL (on the chat): Agree with Wolf's point about internal format, not
interchange format.

CB: One thing we could do is to define an application profile that
relieves users of NaN payload headaches. dCBOR is a subset of that
profile; content of the application profile is that only that one NaN we
all like is supported.
LL: Not in favor of that. Here in the WG we're familiar w/ this, but
majority of the world is not, and having preferred serialization and CDE
and dCBOR is already confusing enough. More complicated than JSON world.
If you first have to pick CDE and then a profile, it's contortionist and
not too user friendly.
CB: I was talking of making an application profile, not a profile of
CDE.
LL: Distinguishing these is confusing in the first place.

CB: I was talking of the application profiles meaning in this context.
Not necessarily have to do it. Every application will have its
definition of what to consider valid (which can be called "application
profile"). Based on that, a decoder/encoder has to rely on platform
considerations.

CAl: IDK who the customer is here. Question at dispatch was who in IETF
uses this ... so who is customer for exchanging NaNs in IETF?
CB: Valid perspective; I'm more arguing from ecosystem perspective here;
people have those in their data sources. Taking them out and exclusing
their users from CDE.
CB: Read text in -01 -- maybe it's sufficient, but I think we need to
take some ecosystem-oriented decisions here.

CA: How is this different from indefinite-length encoding, which is also
not part of CDE?
CB: Applications are not supposed to make a difference between definite
and indefinite length encoded, so the choices are semantically
equivalent. CDE takes position that all should be done w/ definite
length (cf. ASN1). So it's a different issue.
LL: There are clear use cases for indefinite length encoding, but not
clear use cases for NaN payloads. Indefinite length encoding is easy to
implement anywhere, NaN payloads can't. NaN payloads are the weirder
thing to eliminate.
CB: But that's 2013 discussion, currently discussing CDE.
LL: Also discussing CDE.

CA: Not expecting much progress on this today. As the existence of use
cases was mentioned, Carsten could you find those? If they are
substantial enough, that helps easing the discussion. (Not saying we
need a use case, but if we have one, it may simplify the discussion).
CB: Suggest reading 9.7 of 2019 edition of IEEE 754 -- that's the API
they put in now. API hasn't been picked up by C/C++ yet, but this helps
shape the expectation (encoding whether it's div-by-0 or something
else). I can prepare a summary message.
CA: That'd be helpful, thanks.

dCBOR

WMN and CB collaborating on dCBOR more closely.

CB (p8): it took some effort, but it's now a quite simple document built
on CDE. Other than further editorial improvements, what do we (authors &
WG) want to do procedurally?
CB: Of checkboxes, would not be happy with "discard"; 5 left.

WMN: Not super familiar with the details of the alternatives. Haven't
discussed that dCBOR is now based on CDE, and same decisions have not
been discussed or decided. Seems like a decision that needs to be made.
If CDE is std track, we'd prefer dCBOR to be alg.
CA: I'd have to look it up but think CDE is on the std track, as it's
replacing the deterministic encoding considerations of the CBOR RFC. We
also try to avoid downreferences (e.g., normative reference to non std
document).
CB: I think that for CDE we wanted it as std due to its
clarifications/fillings to RFC 8949, and intended to be useful for other
standards documents. dCBOR is a more active decision an application
takes on its data model constraints. That's why I'm not particularly
sure which of these we should take. Useful to hear that some people want
to go standards track.
LL (on chat): In favor of CDE as standards track
CA (on chat): Yeah, I'm now remembering the discussion and indeed that
is its path.

IMD: Both November and January drafts of CDE do not say
proposed-standard, they stay BCP. That is not standards track. A BCP
makes sense to me for CDE, but that hasn't been discussed here. Either
CDE changes to std (which I think is less appropriate), or we should
extend the discussion.

CA (not as Chair): CAl mentioned use cases for dCBOR in the IETF. Their
path may narrow what we do here.
CAl: There has been expressed interest in elision supporting formats in
human rights area, but nothing done there yet.
CA: So no concrete work yet.
CB: There is work in the JOSE WG also applicable to COSE, also related
to elision-friendly formats. We should examine it, and elision-friendly
formats may also benefit from additional criptography. So dCBOR being
std would be useful if there were works that expect to use it as "the
way to go".

WMN: So, CB feels like CDE ought to be standards track and not BCP?
Given dCBOR has audience and future, if CDE is to be there, we
(blockchain commons) would prefer dCBOR to be there too.
CB: We do allow normative references to BCPs in std track docs.

CAl:

• Feel like CDE direcly implies profiles; having an example of a
  profile is a good one -- but don't quite understand exp vs
  informative.
• What Envelope does is support graph structures. I hope that CBOR
  community will want such sophisticated structures, b/c that's one
  thing that's limiting.

LL: In favor of std for both. dCBOR is well enough defined, not too
difficult. Extra review and backing is good.

CA (not as Chair): std will mean people put in caveats.

CA (not as Chair): Yes to graphs, but not with the limited types of
dCBOR. So it would be nice if the two topics are independent.

CB: Have experimental there only b/c it's a possibility, but I believe
it can also be struck out. Some for stricking out BCP as at least
confusing.

CB: Don't think BCP fits b/c it's not best but some.

CA: I've heard nobody speaking against, it seems really about BCP or
STD; we can consider having a WG adoption call soon.

Gordian Envelope

• Built on top of dCBOR
• The Gordian Envelope Structured Data Format
  draft-mcnally-envelope-05

• We have early version of a Hashed Data Elision: Problem Statement
  and Areas of Work to propose form a BOF.

  • hopefully in art - Applications and Real-Time Area )

• Is there any interest in CBOR WG to consider either?

  • Is there any interest in Envelope from this WG?

(We were over time already entering into this)

CB: On Gordian, support modularization of graph v. dCBOR.

CAl: If we do this separately from this WG, we need to go through
process/problem statements/areas. I'm open to subsetting [...] if
there is interest in structured data for separate WG, happy to do. Part
of me feels it belongs here.

Encoding of YANG-derived types in CBOR

eg. IP address/prefix, datetime

CB: On content of remainig slides, see draft that will be available.

Note taking: Marco Tiloca