Minutes interim-2023-cbor-15: Wed 14:00
minutes-interim-2023-cbor-15-202310041400-00
| Meeting Minutes | Concise Binary Object Representation Maintenance and Extensions (cbor) WG | |
|---|---|---|
| Date and time | 2023-10-04 14:00 | |
| Title | Minutes interim-2023-cbor-15: Wed 14:00 | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2023-10-04 |
CBOR working group conference call, 2023-10-04
Meetecho:
https://meetings.conf.meetecho.com/interim/?short=2240f763-537c-486f-8f4d-fb8c6c5bcc06
Minutes: Marco Tiloca, Christian Amsüss
Preliminary results on draft-lenders-dns-cbor (15min)
WG documents status and issues
CB: Martine can go first
ML: Ok
dns-cbor: new -04
ML presenting
ML(p3): the goal is to have good performance and avoid fragmentation
e.g., in 802.15.4.
ML (p3-4): Now using a new dedicated Media-Type/Content-Format. Bottom
line, encode DNS messages in CBOR, avoiding redundant information, and
optionally using Packed CBOR.
ML (p5): Updates since last IETF
ML: assuming transport protocol can map requests to responses, so no ID
any more.
ML (p7): New CDDL. Tag 141 indicates "OPT" record and thus distinguishes
it from others.
ML (p8-11): Evaluation available as requested. Note that corpus is not
typical CoAP target audience, but best we have on IoT. Based on an
implementation cbor4dns from the last hackathon, trying both packed and
unpacked CBOR. Results are mainly about compression ratio and byte
savings
ML (p11): Long chain on the left: packed has extra tables, thus
overtaken. (p15) No compresion of names yet -- need it in base format?
ML (p17): Options.
ML (p18) based on CA's idea (domain name as components), not exactly the
current CBOR format. What would uint represent? How to detect end of
name?
ML (p21): overhead; looks like packed? number in media type for context?
Very open, welcoming comments.
ML (p24): do we want to rotate the flags? Only MSB is already in the
IANA registry. Also need better synching on name compression and to
better look on compression algorithms.
CB: Amused by the rotating idea; likely to get wrong by implementors.
ML: I have the same fear.
CB: What I do there is to put pseudocode into appendix.
ML: Sounds good, together with CDDL definitions that one should pay
attention to.
CB: Could define CDDL control that does this; right now we have a draft
open w/ new operators, maybe make an issue there. It's always 16bit,
right?
ML: Yes. Also for default flags, but not much to be gained there. (Maybe
do it for consistency).
CB: Probably so.
CB (on name compression): Happy to have numbers comparing cbor-packed
with the others.
ML: There is something on slide 14.
CB: Other approaches than Packed CBOR for packing? Interested in
comparing their effectiveness.
ML: So the name-referencing in there as well?
CB: Yes. Whichever other approaches you consider viable.
CA: A suggestion: is it possible for CBOR protocols as this one to imply
that on a particular position there is a string? It's otherwise a number
pointing to a packing table.
ML: Probably not as easy; we have here certain ints that should be
strings in CDDL, and some stuff where type and position of value
identifies kind of value. In p21 line 5, the 0 isn't easily
distinguished.
CA: This can work if CDDL allows to make it explicit. (May still be too
complicated)
CB: I'd like to see numbers here because it's unlikely to be more
efficient otherwise with simple values.
ML: At this point I'd use CBOR-packed, in a light version w/ only shared
values.
CB: Example in slides has names that are identical, but you often have
names that are similar except in lowest-level component. There,
prefix/suffix would be useful.
ML: Have some examples: ns1 is subdomain of example.org (p21)
CB: In this case (but it's probably not relistic), also v6 address would
benefit from prefix compression. That's something you have to look at
with the corpus. Other question: How realistic is that corpus really?
The testbed's characteristics could leak characteristics.
ML: We used the same corpus for our DoC paper. Names between testbed and
realistic data are similar.
draft-ietf-cbor-time-tag
AD review of -09:
https://mailarchive.ietf.org/arch/msg/cbor/XokBqX3rHiE5kJoYJIvQM6_XaT0
Quick response:
https://mailarchive.ietf.org/arch/msg/cbor/yUsu70SuHt1J4Np8t6Pv6CJURGM
Pull request: https://github.com/cbor-wg/time-tag/pull/19
- Are we OK with these changes?
- Should we maybe turn the proposed "CBOR Time Tag Parameters"
registry group into a “CBOR Tag Parameters” registry group instead?
That can then be used by other registries that Tag definitions might
want to create, instead of creating lots more registry groups for
each of these. Or maybe put the "Timescales" registry right into the
CBOR Tags registry group?
CB presenting
CB: Francesca AD-reviewed that. Authors generated PR, Francesca ACK'd.
Now WG eyes needed (we'll come back to it).
CB (p3): Right now, registries create a group specific to this spec; in
Timescales and Map Keys. Registry group is what has a web page. This is
creating many CBOR-something registry groups. Could define group open
for others. (Not littering "CBOR Tags"). Alternative ... just go into
CBOR Tags?
CA: Some registries already define tag parameters for other use cases.
That content would have been defined here instead, right?
CB: Assumption that common group is for thigns that are "CBOR
extensions" but not "own protocols" like CWT.
IMD: I favor "Use CBOR tags" and keep the CBOR ones together; list them
there. That's also what they did with ... with 14 regs under there,
helpful for implementers.
CB: With that, look at the PR; I think they're necessary (So
possibly wording discussions; no slide for changes; biggest item is
referencing PTP2.1 from IEEE b/c that's current, even though we don't
pull anything in from there).
CB: Plan to complete this quickly to have it in the next telechat
(before telechats get IETF118-busy), eg. before tomorrow evening.
CDDL 2.0 ?
draft-ietf-cbor-edn-literals open issues: https://github.com/cbor-wg/edn-literal/issues
(Not strictly CDDL 2.0, but in the same slate of documents)
CB presenting
CB (p4): Language overview. CDDL and EDN come from different worlds
(ABNF v JSON) and thus differ; almost-but-not-entirely-unlike.
CB (p5): edn-literals is older but has grown to get other EDN
maintenance:
-
Changes in -04 OK?
-
#8 End-of-line comments (with
#)being the loudest
-
#7 Hex floating point
useful for preserving precision
-
#6 Document when a number is floating point vs. integer
so far just assumed people do what C does
-
Example for fractional time in
dt'' -
Unicode editorial and ABNF fixes
ART and I18N lists provided input
-
More editorial fixes
-
CB (p6): Two things still open:
-
#11 encoding indicators
CB: Encoding indicators are good for diagnostic purposes but not
much implementation. Worse, it's not in current ABNF. (Existing ABNF
tool also doesn't give us ...)
CB: Possible to fix but we don't have a good testing tool.CB: Other thing is (that's #11): How to use it with dt'' etc?
Doesn't make much sense for dt, but possibly for others.
CA: It's fine it the verdict is "we don't do it". This can become
arbitrarily complex. But we should preserve the ability to have
encoding indicators. The Rust implementation of EDN has it.CB: My job will be to add it then. The good thing about the ABNF
tool is that it's taking ABNF from the draft directly, thus checking
it. We'll keep them, without anything special for application data. -
#12 IANA considerations for app-prefix registry
CB: Start from JSONPath function extensions? Wrote this already...
CB (p7): JSONPath function extensions are very similar. Policy in
the JSONPath RFC is "expert review". One'd think "specification
required" to give experts some leeway in order to allow early
registration. Thus has detailed and concise instructions: No let
anything through that's mistaken for existing technologies / vanity
registrations, and making it "specification desired" (not provided
by BCP26) in the guidance. Expert may just register for namespace
curation.
CB: So that's the policy I'd steal.CA: Sounds good to me.
IMD: I like the level of detail, but in particular 3rd and 2nd
sentences; early allocation was useful in other documents. Fine IANA
consideration.
CB: Ship it after #11 and #12 are addressed? Plan to work on -05 this
week, the WGLC on it. Latest Monday next week we need that -05 to be
able to complete the WGLC and then meet the cut-off deadline on October
23.
IMD: On your previous slide (p7), improve title? It's not only about
literals any more.
CB: It's "and ABNF" now.
IMD: Better. Also agree with WGLC.
CA: Submit whenever your're ready, then we do the WGLC.
draft-ietf-cbor-update-8610-grammar
(The authors believe this should be ready for WGLC, with comments
leading to a -01 before that also appreciated.
Proposal: WGLC this in parallel with EDN-literals, as both have
non-trivial amounts of ABNF, and it probably helps to look at them in a
comparative way; see also Appendix B of EDN-literal for some more
food for thought.)
CB presenting
CB: It's about errata reports. ABNF needs fixing. It should be ready for
WGLC now in version -00, though more feedback is welcome. Better to have
this WGLC run in parallel with the previous one, to have consistent
opinions on the two documents.
CB: Ready for WGLC? Ok to do in parallel with -literals?
CA: Good to have together. On the readiness, who has read it so far?
(none heard)
CA: If people can read this quickly and provide comments, please do and
we advance the two documents together. Please read and leave comments on
the list (also in the interest of a late Shepherd write-up).
CB: Good to do the reading also during a WGLC.
CA: If we start the WGLC after hearing nothing, if nothing also follows
the WGLC, we'll get delays.
CBOR use in IETF and other SDOs
IETF 118 (Prague) agenda
CA: Need to collect items for the 118 agenda; will finalize on next
call. We'll certainly have slots for items around/post WGLC.
AOB
Related enough to plug it here: Embedded Rust community is having a
party now, if you'd lioke to tag along:
https://www.eventbrite.de/e/a-decade-of-rust-with-ferrous-systems-tickets-680492891557