Minutes interim-2024-cbor-10: Wed 14:00
minutes-interim-2024-cbor-10-202406121400-00
Meeting Minutes | Concise Binary Object Representation Maintenance and Extensions (cbor) WG | |
---|---|---|
Date and time | 2024-06-12 14:00 | |
Title | Minutes interim-2024-cbor-10: Wed 14:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2024-06-16 |
CBOR working group interim meeting (conference call), 2024-06-12
Action items are indicated with the "→" character.
WG documents status and issues
CA doing introductions
-
Updates on edn-literals and grammar updates
- edn-literals: Reviews are coming in; nits. Last call ended. IANA
OK, will act. - grammar: Reviews agree on ready; indicate a standalone version
rather than an update might be due at some point. Last call
ended. IANA OK no-op.
- edn-literals: Reviews are coming in; nits. Last call ended. IANA
-
Next up:
-
more-controls
- .cbordet removed, .join added during WGLC
- CA: mea culpa, support for AJS incoming
-
cde will need a shepherd
-
Carsten's updates
CBOR time tag which AUTH48 comments to incorporate
See thread.
Presented slides:
https://datatracker.ietf.org/meeting/interim-2024-cbor-10/materials/slides-interim-2024-cbor-10-sessa-document-status-00.pdf
CB presenting
CB(p2): -time-tag is back to the IESG from RFC-editor (0.5a). Found a
bug and proposed a fix based on an elective and critical map key (for
time scales, would need both critical and elective version).
CB: -1 would be "legacy"
FP: repeating from AUTH48: rest of changes are approved, for this to
follow process need other LC, not expecting changes. Couple of weeks
delay. No need for telechat. I requested the new Last Call already, the
mail should come up soon.
CB: Could have done this change in plain IANA request too, done in
document because it's the better place. Expect publication in July.
FP (on chat): Definitely agreed to having these in the doc, it makes
sense, just unfortunately can’t see this as a purely editorial AUTH48
Change, hence the LC.
CA (not as Chair): How legacy will -1 be? Has it been used much? This
document is not published yet after all.
CB: Not sure we can ignore it, the document has been around for 7 years
and is widely used in places we don't know about. Want to keep
compatibiltiy. As a "legacy" thing, -1 would be to stay around forever.
grammar
CB (p3): Observations; nothing that requires new draft. Wait for OS to
initiate IESG process unless other opinions from him.
OS: Updates were made and this was ready to go. Recall that this should
have progressed. Not sure why still the current status, I'll get back to
you.
CB: Sounds like no WG actions needed
OS (on chat): ahh apologies, for draft-ietf-cbor-update-8610-grammar I
have not yet confirmed directorate reviews and last call feedback
There may be a revised ID needed, but the action remains on my side, no
action for the working group. don't be afraid to remind me if there is
delay.
→ OS: (above)
edn(-literals)
CB (p4): issues open at GH, should spend some time on these.
RM: There were updates to CDDL in errata style. Would have been easier
in -bis.
RM: In same way, this document would have been better in standalone
form. No big deal though.
CB: On grammar, is one of updates that are ongoing. When all done, can
do that -- now would not be efficient.
CB: On edn-literals, this development was not expected when document
started. Maybe time to change the title. As we went through one IETF LC,
heavy change now.
CB: Will get back to that
OS (on chat): draft-ietf-cbor-edn-literals is in same state as CDDL
update, ball is in my court, I need to confirm directorate and last call
reviews, and a revised I-D might be needed, but its on me to complete a
final review
-more-control
CB (p5): Two recent observations: explanation of .join to be improved,
and wish for a clearer definition of .b64u/.b64c. Just submitted -05; in
the next few days, the WG can decide if we need a new WG Last Call or we
can request for its publication.
CA: The changes look few enough to not need a WG Last Call, I think.
Let's give a few more days, and, if nothing comes up, we'll proceed.
→ CA: check around weekend and then send out WGLC.
-e-ref
CB (p6): A WG Adoption Call happened, but not declared completed.
CA: That's on me, I'll look into that.
→ CA: verify and close
-packed-cbor
CB (p7): Kind of done in the WG, but it needs more feedback from
implementors. Maybe we need an interim meeting covering this document
and the companion -packed-by-reference.
CA: Could you update the additional resources or the information in the
repository with a list of existing implementations? If you don't happen
to have the needed permissions, send the information to me.
OS: As an author, you should be able to update the additional
information, otherwise in the draft itself.
OS: About -packed-by-reference, it has additional functionalities. Does
the WG considered those to be tested or worth testing by
implementations? Maybe you may want to wait for feedback about these
too.
CA: The merging of the two documents and set of features was not
discussed. As a co-author (not as Chair), merging is good if it helps.
CB: From architecture PoV, try to have separate areas (table setup,
table referencing). Latter is stable. Makes sense to push it through,
but needs batteries included so there are 2 simple setup mechanism in
packed. by-reference adds setup mechanisms (eg. DNS-CBOR might want to
set own mechanism). Not that wild on adding more batteries, but if it's
a good battery let's put it in. Will need impl feedback on that too.
-cde
- CDE ready?
CB: Open issues seem to be editorial tweaks. Is document as a whole
ready for a WG Last Call?
CA: I have the impression that it's ready. We go for a show-of-hands.
Show-of-hands
"Do you consider CDE ready for WGLC?"
Total participants: 10
- raise your hand: 3
- do not raise your hand: 1
- no opinion: 5
CA: Strong enough for a WG Last Call. I'll start it.
CB: One implementor with a strong opinion is not here today.
CA: → start WGLC
CB: Strong positions from one implementer might be added to poll, but
WGLC is where those positions will be seen.
[edited: Revisited action item, sending request for missing parts
instead]
-dcbor
- dCBOR:
https://mailarchive.ietf.org/arch/msg/cbor/NOwNDgeH2P5LkP0cn_OgXpM0sOk - dCBOR is an individual draft, on the ISE track.
- WG list looks like good channel to solicit and provide feedback if
the authors want to use that channel (and being taken up,
65bit-negative apparently led to removal of section in dCBOR).
Request for 1+1 range tag 201 is pending agreement among the authors
(which is in -10 now). - WMN: Should dCBOR be on the standards track instead?
CB: on dcbor, pointed to no-response: became ISE after initial
considerations in CoRE, but still in active use by WGs and RFCs.
Consensus of WG appears to me to be pretty rough. Provides answer to
people struggling w/ int/float in their reqs, but may not be main line
of CBOR.
RM: Main section (2) has much history, then goes to normative
requirements. Nice to have "what do you need to do" structure, happy to
make PR for that.
CB: Would history in appendix help?
RM: Section header "do this" might suffice.
CB: Sort order of maps still needs to be made more explicit in CDE.
WMN: Obviously not everyone agrees that dCBOR should move forward in any
sense (rough), not sure how that I-D should move forward. How do we
decide how to move forward
CB: More than 1person, just one loud. LL seems to be "works but I don't
need it"
CA (not as Chair): One more voice of objection: it's ok for people to
use this solution. But a WG taking it on is an endorsement, and it's not
a technical solution I would recommend people to do unless they have
specific reasons to.
WMN: I just hope for people having objections to raise them on the
mailing list so that we can discuss them. That helps understand if and
how this draft moves forward.
CA: → start thread to flush out concrete objections.
CA: → process Tag 201
modules
CB (p9): Not managed to do a prototype of sockets.
More documents
CB (p10): Adopt just for visibility; next time you use it, think about
it.
CB (p11): individual documents being worked on
CB (p12): cbor-det: "The Explainer", might go ISE, as with CSV if nobody
here cares.
EDN literals implementation question
Straw poll of implementers if having two-levels of parsing app-strings
is preferred or not-preferred.
Discussing open issues on the Github.
OS (on chat): I'd like to see all directorate reviews addressed /
resolved before advancing documents that are currently waiting for AD go
ahead... ideally no open issues in GitHub.
Issue #37
CB: This removes dead code.
CB: It is a technical change, hoping for Orie's OK.
CA: My impl has an assert on this S being always empty.
OS: If it's a confirmed bug (on-list), it's ok to fix. Gut feeling: If
impls have confirmed and it's documented, will be OK.
Issue #38
CB: Longnums have always been a part of EDN.
CB: CA again noticed that we don't need an encoding indication for big
integers.
CB: Leading zeros are not preferred, but that's what encoding indicators
are for.
CB: Labelled possibly-extension
CA: Fine with me. What I get from your statement is that longnums do go
to tag 2/3.
CB: The big integers are still meant to go for tag 2 and 3. This is
worth clarifying in the document.
Issue #41
CB: RM proposed changed app-string approach to internal syntax. Current
doc treats all app strings as the same: parse as UTF-8 byte string, pass
that to implementation, treat h like everything else.
RM: Found it complicated to run ABNF twice.
CA: FWIW, the nested part works quite well, from my implementation
experience.
CB: It's good feedback to see how things work on other platforms. With
risk from integrating, would prefer 2-layer model.
RM: So worry is that single layer will be hard? (Maybe misunderstanding:
didn't find it hard to do single layer)
RM: If we stick with 2 layers, text should be more clear. Was not clear
reading it. Over-all view: written own ABNF based on original
non-normative description with single layer, found that easier. If
reason is "it's hard", can show simple single layer.
CA: I see two layers confusing for the parsing process.
RM: No, you misunderstood. All ABNF you know is integrated into one
ABNF. If you know about single quoted stings w/o app string and know
about h and b64, then you parse ABNF for all of those; unknown are
parsed as generic app string. If you know more, you parse wiht the ABNF
you do know. Output is the same.
CA: Wouldn't the ABNF for other applications also need to define
escaping, line breaks and such?
RM: For ip, that's just described using ABNF productions provided. If
you use existing productions, pieces are there.
CB: ABNF doesn't have a "plugin" concept.
RM: It's not abstraction, you're just running code twice. For SIP and
mail, lived with this, and they are being extended. Also with unofficial
extensions.
CB: But you need to touch over-all ABNF every time again.
RM: True. Touching 2nd level ABNF is no better than 1st layer.
OS (not as AD): Difficult to look into multiple places to understand
things. Slight prference for single ABNF. Impact of layers is what we
need list discussion on.
CB: Let's discuss it on the mailing list then.
Issue #42
CB: We had a way to concatenate strings, which is now interfering with
other grammar updates. This is about turn down wished requests that
would otherwise impede string concatenations.
CA: People please take time to look at it and think about it.
RM on chat: "+" would work for me.
CA: Also a user, it's a big change, but I see it as welcome one.
CA: Overall good to have input on this.
Issue #43
CB: Not a technical change, just guidance for implementors.
CBOR use in other WGs and SDOs
- mimi-content (instant messaging)
RM: Encourage people w/ some spare cycles to have look and post
comments.
AOB
Note taking: Marco Tiloca, Christian Amsüss