interim-2021-cbor-01
2021-01-13 15:00 - 16:00 UTC
Recordings: https://youtu.be/JIZ7y8Dd2Ng
Attendees:
Minutes
Intro (FP)
WG documents status and issues - https://datatracker.ietf.org/wg/cbor/documents/
Last meeting: https://datatracker.ietf.org/meeting/109/materials/minutes-109-cbor-00.html
WGLC on draft-ietf-cbor-tags-oid-02 status
FP: call ended, review posted. Looking for more review, even very brief ones. CB → ping whoever would write one.
CB: Expected to do another update based on the reviewes, waiting for the pending review.
Pick up time tag document? What to priorize in WG?
CB: No rush with time tag – registered and being used. But learnings from the date tag could help making this into a WG document.
(draft-bormann-cbor-time-tag-01; expired, but registration is valid nonetheless)
Way forward for packed draft-ietf-cbor-packed-00 is clear on the high level; the “little issues” can go to the mailing list (→CB)
controls: CB: Got implementations, but of abnf control there is none. Can we wait to have implementations, or split it off? Once a document using eg. .feature, getting close to WGLC would be good.
FP: asdf[?] uses it. CB: Will have a WGLC in fall; but hard to predict. FP: Slight preference for one document. CB: Maybe nudge Anerew [?] → CB will nudge him.
FP: Need more interaction with other WGs, eg. for OID? How do we reach them? CB: Maybe with next version go to SAAG. MR: Just OID or other docs for contacts? FP: OID as example; general “doing things better”. MR: Could present CBOR including OIDs at SAAG, from the “security advantages of a standard encoding” perspective, rather general. Some people know CBOR well at IETF, others not at all. cf. 6MAN discussion about general RAs with CBOR encoding. FP: MR, take lead on that? MR: Willing to speak, but need help. CB: Can help. (several): Not tutorial, just overview.
MR: Not all CBOR libraries in Rust and C (surveyed 6) are equal, some “hostile to CBOR good-points”. How to welcome more implementors into github discussions? Eg. “X wants CBOR tags, Y considers them irrelevant”, those discussions should hit WG. “Implementation Survey” (what implemented, what not, what not intended; eg. no tags in serde-cbor).
FP: In 2017, started implementation matrix for CBOR https://github.com/cbor-wg/CBORbis/wiki/Implementation-matrix
CB: Survey would come from how people design APIs, not from CBOR features. The problem of serde is not that it’s hard, it’s that the API is not designed to enable that. Needs participation from them, few people speak all the languages.
FP: need survey itself and contacting implementers (CB: and input processing). cbor.io? CB: There’s no tagging on the list there yet. CA: Share infrastructure with CoAP where something similar has been started. CB: Draft for implementation survey? MR: Could start that, not sure if can finish. → for next interim. Progress should be to the end of year. Draft not to be published, just “technical marketing”.
IM: Back to SAAG “overview”. Should be first of several area-wide group (artarea, rtgarea etc) series. Agree there’s [paraphrasing] those who love it and those who don’t know it. Make it objective that in 2021 we touch everyone once in some way. (Starting with SAAG). For SDO reachout (ETSI, 3GPP)
CBOR use in other SDOs
MR: chairs & co gathering contacts to communicate with at strategic times (“how is it going, give us feedback, btw new RFC”). FP: Bit of that is already in CBOR list – but not all relevant people on there because it’s also technical discussion. MR: Plus EMail phobic environments. IM: More talking to colleagues active in other SDOs, maybe take canned presentations there. To 3GPP SA3 (security), for example.
CB: extending (with https://docs.google.com/document/d/16aiDEBhJj3kipj_7PVppEhxAr5E6QhQreN61eCxvBjU) and resubmitting notable-tags
CB: People are shaping proposals for extensions so they do fit the extension points (ie. the WG can just let them do it). Occasionally, may want to exert some control/oversight. Some languages want their language structures represented. CBOR doesn’t have discriminiated unions (int vs string works in one place; int vs int does not).
Tags work, but defining a tag is high-effort and global; discriminating unions are often program specific.
Proposal: Anonymous set of tags (chosen to be efficient).
Sounds good, if you think compiler-generated unions should be supported. Could go into notable-tags, or separate. Adoption would make it more visible for this purpose.
CA: How is this better than [discriminator, value]?
CB: More efficient. Back then, didn’t think of tags with arity >1. They propose some tag space here and some there.
MR: “standardized tag” for this purpose is b/c compiler will keep track of their usage, and we don’t want compilers contacting IANA? Also sounds like protocol designers shouldn’t describe that b/c details are burried in the compiler.
CB: Example: YANG also has typed unions (undiscriminated, but assume they were discriminated). Then we’d have a set of tags for YANG. It’s nice to have standard tags for these things.
CA: But composibility?
CB: If you need that, register unique tags. But where compiler generated discriminators make sense, you have something right away.
Tags would be interpreted in context. Even in the same program, there can be different contexts.
FP: Preference for a different draft (not notable-tags).
CB: Up to then, please comment on google document.
AOB