CBOR working group conference call, 2024-06-26

Meetecho:
https://meetings.conf.meetecho.com/interim/?group=b40d383e-b6d0-498e-a3dd-7f90c58e6e35

Action items are indicated with the "→" character.

WG documents status and issues

• time-tag ➔ AUTH48-DONE

CB (p2): was in AUTH-48, had late comment on -1, FP as AD decided second
IETF LC, concluded a few hours ago, thus awaiting her button press to
put it back into RFC editor queue where it can go its course.

• update-8610-grammar ➔ Approved

CB (p3): Revised I-D was submitted, to be verified by OS
CB: … and IESG is in a retret where likely no buttons will be pressed

• e-ref is now a WG item, CB please resubmit as draft-ietf-cbor-e-ref

draft-ietf-cbor-edn-literals

• To PR #42 or not to PR #42?
• If yes, what is the formal process?

CB (p4): Working on a new version today based on the received input,
input from -09 processed in -10.
CB (p5): 5 PRs that address LC review comments, three got approved on
Github.

IMD: Any idea of actually improving the title? IMO long-winded and too
obscure.
CB: Good point; now point to do this. By now, it rolls up everything we
do in EDN, it's effectively a bis draft, title could say that.
(also in issue #51 now)
IMD: "EDN Udpate"?
CB: difficult b/c those are standards track, this is informational.
IMD: "EDN extensions"?
CA: Maybe something "Comprehensive (looking-for-word) for CBOR
Diagnostic Notation (EDN)"
CB: Should do something, needs wordsmithing.
IMD: The latest version puts focus on those particular items, but it's
good to give an idea of the big picture that is being extended.
CB: "Release 2024" … but that's now how we say it in RFCs. Recent
extensions plus rolled-up ABNF.

IMD: Why is it Informational and not Standards Track?
CB: This is not meant to be a format for interchange (except for
examples, specifications, interfaces between tools); traditionally, what
doesn't control interchange is informational. If we break something
here, that won't break CBOR application, just makes working with tools
harder. Not the same backwards compat requirements as for CBOR.
IMD: But it's the first time we have ABNF.
CB: Yes. Appendix even says it is normative.
IMD: … in an informational document. Sounds like something IESG might
complain.
IMD: We don't want people to deviate from the ABNF, do we?
CB: We do. There was an alternative proposal for a single ABNF level,
which is fine. What is normative here is what is a valid instance, but
it's informative as to an application that can achieve the same in a
different way.
CB: May seem paradox, but with some more thinking it means "there is no
normative intent for whole spec, but if you use it, there are parts you
better stay compatible with"
CB: Let's note that as a todo issue.

CB (p5): Some PRs w/o review so far; don't mind a review, but can go
ahead w/o too.

CB (p6): PR #49 is about a single-pass ABNF proposal by RM. Two
implementors have said that it makes their work harder. With modern AST
parsers it's easy to do in two passes. Merging the two levels is also
very prone to errors and bad side effects.
(CA, chat only): Same with PEG parsers
CB: Every new application-oriented literal would need extra work for the
merged form. Anyway, you can write your own ABNF: WIP PR could be
developed to working ABNF, could go into wiki page or other referencable
place.
CB: Any disagreement here? (none heard)
CB: It's also in line with CBOR being an innovative format

CB (p7): About the elephant in the room: concatenation.
CB: Back when introduced, thought to be close to C language that has
implicit concatenation (appendix G4 of RFC8610). This works (but nobody
implented it)
CA: I implemented it, based on ABNF in the current draft. But just for
completeness sake.
CB: I implemented it in my PoC tool.
CB: Point is, we don't have large user community that already use it.
Not aware of anybody actually using this in specs, so damage is probably
limited. RM would like to have concatenation mechanism, eg. for
limited-length lines.

CB: Why would we want an operator? As long as this is implicit, we can't
make commas optional. By using the rare concatenation explicit, we can
make the commas implicit (as was more frequently requested).
CB (p8): No PR yet, but implemented, slide shows changes. (streamstrings
are not concatenation, they are indefinite length encoding)
CB: Inexpensive from implementation PoV

CB (p9-10): pros and cons.
CB: I dislike when non-backward-compatible changes don't lead to error
messages – this would happen here. A bit ugly; I think it's worth the
cost.
CB: Wonderful ellipsis notation now gets noise; we got used to first
way, are stuck with 2nd way, but it's not that much worse after 5
minutes.

CB (p11): bikeshedding. Currently "+" in prototype. I think "+" is least
surprising one; YANG also uses it that way. Don't think we have to open
this up.

CB (p12): Plan to merge the ready-to-merge PRs; add one more, then send
a new version.
CB: Then it's OS's decision to move this forward in this state to IESG
ballot (b/c it reflects LC outcome) or do new LC due to the change.

CA: Where is the WG on this?
CB: Most of the discussion happened on the JSON mailing list.

Show of hands "Followed optional commas / explicit concatenation enough
to have opinoon?"
TOTAL PARTICIPANTS: 8
Yes: 4
No: 0
No Opinion: 0

Show of hands "Do you have an opinion on OC/+?"
TOTAL PARTICIPANTS: 8
Yes: 4
No: 0
No Opinion: 2

Show of hands "What's your opinion on OC/+?"
TOTAL PARTICIPANTS: 8
Yes: 5
No: 0
No Opinion: 0

Does a generic "none of the above" tag make sense?

dcbor asks for tag, uses it in draft-mcnally-envelope to disambiguate

envelope-content =
    leaf /
    elided /
    node /
    assertion /
    wrapped

leaf = #6.201(any)

{: .language-cddl}

CA: Had similar pattern in earlier iterations of CoRAL – generic thing,
"I'm tagging some Any just for the purpose of not being a
list/dict/whatever the alternatives are"
CB:
https://www.ietf.org/archive/id/draft-bormann-cbor-notable-tags-10.html#section-9.1
are the inverse; escaling
CA: 201 also does this (just for another group of items)

CA: Can you think of other examples / had cases where a gewneric tag for
this can be useful?
CB: Can't remember cases, but designing syntax for CRIs was driven by
limiting the number of bytes involved. If 1+0 version existed, might
have used it. Pattern of having a strudcture that is to be interpreted
in a certain way and then embedding something else that needs "escape"
from top-level structure into what is embedded is a quite likely
pattern. Most applications that need this actually use embedded CBOR;
that happens at encoding level, might be convenient at data model level.
Might not solve dCBOR's problem.
CB: Should keep that on stove and see whether we can turn it into
something useful.

CA: Let's keep the idea floating, but for dcbor they'd prefer not to
wait for this, so I'd rather accept a request for a 1+2 tag from them.

AOB

We have one more call before Vancouver, so one agenda item in two weeks
will be to settle on the session agenda for IETF 120.

CA: Please start proposing items to discuss during the interim in two
weeks. You can add those to the notes that are already up for it.

CA: Can't be sure to take the next interim meeting.
BL: I will take it.

CB: Upcoming side meeting for those working on -core-sid AUTH48
(cbor-related).

carry-over action items

• → CA: start more-control WGLC, 201 tag

Note taking: MT, CA