CBOR working group conference call, 2 June 2021
Previous meeting’s minutes: https://datatracker.ietf.org/meeting/interim-2021-cbor-09/materials/minutes-interim-2021-cbor-09-202105191600-00
Agenda (please edit…):
WG documents status and issues
tags-oid is EDIT with the RFC editor
cddl-control entered WGLC but will need review from people who are neither author nor shepherd (ASDF?)
draft-ietf-cbor-network-addresses-04 (“address with netmask” issue)
draft-ietf-cbor-file-magic-01 (“On storing CBOR encoded items on stable storage”)
content-format tags
Discussion about bstr vs
Notes:
CA: Now with RFC Editor, IANA allocations already done.
CA: Sent out WGLC, no input received. We need reviews, some from the ASDF people can review or give feedback.
CB: There’s my mini-review. I’m using the document for a year now. The .feature control is setting up a little trap. More on the default behaviour for the .det control. You need it when you use .abnf.
CA: Recent issue on addresses with netmask. Heard anything more on it? Anything the WG would want to change in the document because of this? Otherwise we push forward to WGLC. The same would basically apply to the file-magic document.
None heard.
content-format tags
CB: Use content format IDs that we already allocated. Now allocate a range of tag numbers. Then we can tag something to identify the format of what tagged.
CB: Maybe a too small document to push forward as is; we may append this content to another document. Fine from a registration PoV, since that’s FCFS.
MCR: Good idea to append it to another document, perhaps file-magic.
CB: Agree it’s the best place, just not sure it would slow down file-magic, but I don’t think it will.
CA: Worst case, we split again, but this way sounds good to me.
CA: In file-magic we’re considering more the item itself rather than the CBOR encoding of the item. How does it match?
CB: We just know it’s a bstr using this media type, and we can know how to interpret it, so bstr is the only thing making sense. We can make an exception for tstr for JSON.
CA: Sounds more like what in senml-data-ct than what in file-magic. Could have same exercise again but only valid for +cbor (in any encoding)
CB: Often something+cbor comes also with an existing tag. So functionalities would be duplicated.
MCR: Wasn’t thinking to be congruent with file-magic, just useful.
CA: So it requires clarification to state what a file-magic style allocated tag for SomeFormat and using the tag for application/SomeFormat+cbor.
CB: I’ll file a PR to Michael’s document covering this.
CB: Handling possible duplicate keys, if they’re keys at all and used homogeneously. Need to address possible relation to tags (which address bizarre differences in certain platforms).
CB: What’s the representation used for semantics grouping? All in all still using an “array” alternating keys and values, but as a flattened list. Duplicate keys usually result in a huge duplication, there are more efficient ways to go like MList (that costs 1 byte per key-value pair).
CB: Trying to optimize, we can consider sequences of keys and sets of values. But these optimizations limit the expressiveness of the information model.
CA: How would this be used? Do we expect a particular format to be picked up or be flexible in handle alternatives? Or do we expect something to be minimally ensured?
CB: The table (slide 3) is about the information model. Encoding-wise, they’re all the same. The protocol would just pick a tag. But do we take one or two variants? The main use case was yang-cbor, that ended up using something different.
CB: Optimizations may also be skipped for now, and come later when a use case needs them.
-> CA ask Emile etc.
CBOR use in other SDOs
AOB
Attendance: