CBOR WG Meeting - Interim 20-04 Wednesday, February 26, 2020, 16:00 - 17:00 UTC Chairs: Francesca Palombini, Jim Schaad Presents: Jim Francesca Carsten Laurence Michael * CBOR Bis status update and open points * New PR: https://github.com/cbor-wg/CBORbis/pull/171 discussing the third option of duplicate key handling behavior - LL not satisfied by the text -> rather than encoder to be relied on specify protocols/applications that could support this. "in some scenarios you might consider the input not to be hostile but you should be cautious about that" Jim: proposal additional draft text "Applications may get different results for a specific key on different runs and with different libraries as which value is returned is based on library implementation and the actual order of keys in the map." LL: add text that requires implementer to specify which type they have implemented LL: if keep description of scenarios where encode can be relied on, expand it to the whole infrastructure, not only the encoder. Jim: happy with the text LL: content is there mostly; protocol design considerations missing mcr: read the text and ok with it * PR 165 - ask people to look at (still waiting on Jeffrey's approval of that one) * Laurence to check PR159 (already merged) and notify Carsten and mailing list * WGLC after next submission and to run for 2 weeks * new issue https://github.com/cbor-wg/CBORbis/issues/170 LL: not sure this is something you can do in CBOR Jim: you could make it an optional field mcr: or you could make it just null without tag. LL: it might not work for some protocols mcr: do we have examples? Carsten to write a response; do we add some explanatory text? dont think we want to change tags 0 and 1 - reach out to implementers (before WGLC) - WGLC after next submission and to run for 2 weeks