Attendees:
Minutes:
CA: module superstructure makes sense to start working on.
CB: Documents that define tags would benefit to add to the prelude, but the prelude is defined to be constant. Module structure would help because prelude component from a particular standard could be included.
CA: do you replace or do you import from another document?
CB: Mix-and-match thing. Can do CDDL 2.0 with different prelude, but inverse direction is better where prelude is another namespace implicitly imported. So no big difference btwn prelude and other modules. Proposal to make a strawman proposal and discuss this at an interim meeting (in 4 weeks?)
CA: to the group: any particular use case that you’d like to use this with?
…
CA: would be good to have examples.
CB: we can try to collect pointers to various CDDL specifications.
FP: Jim and I did this where we interviewed people. Now there’s more documents even.
CB: Maybe I open a repo where I collect examples, with Wiki page to write up what they care about.
FP: HTTPbis started to use github discussions instead of the Wiki.
CB: wiki could contain the result of github discussion.
CA: go ahead CB to set up repo/what you need.
Emile: use case - when receiving a typed array of 128 bit floats and when decoding does not understand typed arrays. currently can handle all typed array cases except for 128 bit floats. I could use tag 5 but then there is a lot of tricky computation involved, I’d like to just encode it as a IEEE format. I’d be happy with just a tag rather than extending the standard.
CA: would the tag really help, given that it’s the other party that does support or not?
Emile: I understand what you’re saying. What I am doing right now is not using tags, hoping that the receiver can make use of that.
CB: if we just go with tag83 with a single item, we lose single value / array of values. At some point we should define the tag.
CB: Fortunately no need for decimals yet ;-)
CA: what you need is to have a complete converter, you don’t really need the tag?
Emile: right.
CA: ok so for your case it’s not urgent but we see it as something coming up.
CB: I was going to propose to write a new section and put in the IANA request.
Emile: if we do add the tags for binary 128, could someone come along and ask for big int expressed as …
CB: that’s easy to convert.
CB: is there any C++ support for binary 256?
Emile: not AFAIK. not even official support for 128, just language extension.
Emile: GCC has an extension, I believe. [note taker’s addition: It does https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html]
CB: My suggestion is to define the tag for bin 128.
CA: sounds good.
CA: my impression is that one could do that, but it wouldn’t be interoperable - is there more to the discussion?
CB: One design win we didn’t get because of it’s big endian is known – those thigns happen, but OTOH the cost of splitting the universe by endianness is quite high. I think the threshold is not reached where that’s needed.
CA: it might be good to put it somewhere / in a wiki.
CB: Explaining … 8949 has little text with rationale; rationale is most of us have experience with standards with single endianness and those that allow both, and they are icky. Remember X-windows.
MCR (on Jabber): pointing out big endian spacecraft.
CB: Most IoT platforms are LE, but code generating arguments indifferent sizes can handle that with little overhead. Don’t see that strong an argument.
CA: could someone come up with a small benchmark?
CB: I’m not using equivalents of ntohl() in my code.
CA: to summarize: no momentum here to do anything about this, so the best we can do is to write about the rationale.
CB: momentum is not there because we think the cost is larger than the benefit.
CB: Just want to make sure that people are aware of this, and if they have related use cases they bring it to the table.
CA: See some overlap with compression, where the tagged item says “This is an item of type X, and its value is …”
CB: not an equivalent of a longer CBOR structure, it is introducing number space meant to be managed by a compiler.
CA: Any wrapping around explaining what they values are, a preamble to the CBOR or the tag itself?
CB: That’s not how it’d be used; the compiler has a schema but never expresses it.
CA: to the wg: please read this document and bring comments.
Emile: proposal seems very useful to encode optional values, where one alternative is null / any, and also for encoding variants (C++) or tagged unions. Question: instead of a set of tags, was it considered to have a single tag with an array of elements, with the first element being the alternative number, and the second to contain the value?
CB: That’s in there as tag 102; proposal is to have 128 tags from 2 spaces that are efficient in indicating union tags, and when that’s not enough, there’s tag 102.
Emile: missed that, thanks, that makes sense.
CA: well-known Some()?
CB: Good question for Duncan and Michael.
CB: I take an AP to ask the authors of this spec (google docs)
CB: map-like structures structures submitted over Easter; would be good to have some feedback. Already got some for a -01, but also hear from others whether this is a good solutions. Goes a bit beyond just the dictionary case.
https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-map-like-data-00.html
Also pointed to a 1y old mail on the representation side; this opens it up on the semantics side, but for some semantics there are different representations. Do these add something? Or is it just like the endianness, introducing additional choice?
This is a really old topic, way before we had YANG represented in CBOR. Fell out of collective consciousness. Do we still have these topics? Does everyone use workarounds now?
Will ask for adoption soon.
CA: sounds good.