---
# System prepended metadata

title: Untitled

---

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

