CBOR working group conference call, 2024-10-16

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=7a5f2afe-9188-4255-a829-b0eece0daed9

CA doing introductions

WG documents status and issues

• draft-ietf-cbor-update-8610-grammar-06: in RFC-EDITOR state (5.9
  weeks)

• edn-literals: Awaiting outcome of Carsten and Pete's discussions.
  "Will there be any technical change?"

  1. Complete current editorial round
  2. Apply editorial changes agreed in the first design team meeting

CB: We checked about useful editorial changes to make -- by applying to
the result of current editorial round (moving detailed comments to
ABNF) which should be non-controversial.
CB: Editorial changes agreed on with Pete will come after that.
CB: Then, checkpoint where Pete talks to imlpementors; let's see what
that yields.

CA: So the editorial changes will come up after the cut-off?
CB: I can start, we'll see if they will be sufficient. Maybe the
discussion between Pete and implementors will indicate that we need more
changes.

• edn-e-ref: Waiting for edn-literals, but could progress to that
  limit

• draft-ietf-cbor-cddl-more-control-06

  • Publication has been requested. CA apologizes for the delay.

• packed:

  • "implementation draft" status: technically done, but want to
    play with it
  • CA's AOB-item around this: Trying to play some of its strengths
    at https://pad.riot-os.org/bg3i8ko6Qnya2003vDDMag?view in
    comparison with Postcard, Brief and defmt. Possibly notable:
    Functional dictionary entries that behave like format strings
    (might there be any good meaning to apply them in reverse?)

CA: There is a desire to play with implementations.

• draft-ietf-cbor-cddl-modules-03

CB: Complete and fulfills initial requirements, but importing module
with addition to sockets is problematic (don't know: Will the socket be
used by the importing module?). Imported module might pull in stuff to
populate socket, but importing module does not use it. Importing module
might import another module that does use the socket. Need better
model, not done yet.
CB: So it's usable unless you run into that very issue.
CB: Play around with it. Other than the socket part, it should work
fine.

CA: Do we have any way to indicate that this is complete in the header
of the document?
CB: I hoped that the transition could be shorter. We should use more the
concept of implementation draft.
CB: Made changes in Vancouver that there should be import * in there,
that is now in the document.
OS (chat): https://datatracker.ietf.org/doc/bcp205/
CA: Sounds good, please update in that direction if you can.
CB: Section 2.7 describes a CLI, probably want to keep some discussion
in there, add other tools.
CA: Could be parallel, with some cross-referencing.

CA: Everyone, the Datatracker allows to include additional resources
(e.g., a link to implementation) about a document. If it's about a WG
document, the Chairs can do that, so ping me or Barry.

CDE

https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/

• updated today
• Issue 14 Application Profiles
  https://github.com/cbor-wg/draft-ietf-cbor-cde/issues/14:
• Addressed by PR #21 in draft-ietf-cbor-cde-06

CB: Did the "just do it" points for this interim. 14 clarifies that
application profiles are not needed (important: ETSI did it). -06 has
that.
CB: -21 PR still open to invite discussion -- deletes "Application
Profile", instead adds "Application Level Deterministic Representation
(ALDR)", stop talking about APs when we mean ALDR (b/c most ALDR rules
will be in protocols and not in general profiles). dCBOR is only
document that makes ALDR rules beyond a single protocol.

CB: ALDRs are around already, eg. in CWT that doesn't want tags around
items where it works without them. CWT doesn't use deterministic
representation, but it still indicates that ALDRs are common.

OS (chat): CWT application profile related section:
https://www.rfc-editor.org/rfc/rfc8392.html#section-6

LL (chat): have looked; seems good direction
LL: had brief look, appreciate change, will provide comments in next
days. Also have more comments to share.
CB: Appreciated if allows processing before deadline.

CA: Everyone, please have a look and leave upvote or comment.

Agenda for our session at IETF 121

We have a one-hour session in Dublin, and need to prepare the agenda
now.

• edn-literals, inviting Pete and Rohan
• cde
• cddl-modules? (explaining problem and proposed solution)
• hackathon report (e.g., packed?)

Hackathon?

• packed: CA, CB, OS, ask ML and MG

Proposed dates for interim calls between IETF 121 and IETF 122

• ? [alternate (even) Wednesdays]
• Same time: 16:00 Europe/Berlin [10:00 America/New_York; 15:00
  UTC]
  • 27 Nov, 11 Dec, 8 & 22 Jan, 5 & 19 Feb, 5 Mar

CA: Reduce cadence (to once every 4 weeks maybe) b/c we had few actual
meetings?
RM: Best to reserve, and cancel on demand.
CA: Can support cancellations by making them more timely through
calendar addition
CB: Yes please.

AOB

CA relaying for OS from chat: Good luck with the cut-off.
CA: See you in Dublin.

Note taking: MT, CA, CB