Preliminary agenda:

  1. Discuss errata reports 6527 and 6543, see https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-freezer-07.html#name-clarifications
  2. CBOR tags for alternatives/unions:
    https://docs.google.com/document/d/16aiDEBhJj3kipj_7PVppEhxAr5E6QhQreN61eCxvBjU/edit
  3. Discuss Rob Wilton’s comments on cbor-tags-oid; see https://mailarchive.ietf.org/arch/msg/cbor/QoS55EJAFylmBR6vnNbdg2C-aGg/
  4. WG documents status and issues
  5. AOB

Notes:

Item 1: Errata reports

CB: coming from CBOR diagnostic notation implementation, not CDDL. Problems in the ABNF:

Do we agree on the proposed resolutions? Should these be handled as errata, or in another way?

Item 2

Carsten was tasked with asking the authors about the relationship to Optional data structures. The authors answered that they see this as a separate item that is best handled separately, so that the currently discussed set of tags can be cleanly focused on the specific use case, and Carsten agrees. We’re looking for additional input today, before the designated expert (Carsten) approves the registration request.

Item 3

Discussing Rob Wilton’s discuss

CB: Draft was from 2014, and pretty clear altogether – and then TBD112 was a late addition. It’s abbreviated version of an absolute OID (removing first 5 bytes, 1.3.6.1.4.1). What we didn’t think through was that it creates one of these “preferred encoding” issues with an encoder having a choice (between absolute and abbreviated version). What is guiding that choice? In CBOR we guide towards “shorter encoding”, and if we can assume TBD110(111?) implementation implies TBD112 implementation, we can make that recommendation (and even REQUIRE it). Opens previously non-discussed questions. (Abbreviation feature sounded simple, unfortunately it’s not)

MCR: Don’t see implementing 111 and 112 as being so hard on a decoder. Anyone dealing with OIDs probably is dealing with […]. Don’t think that’s a terrible problem. Should always use shorter tag. Why not MUST? We can tolerate having the other one in the stream for some reason, eg. because you may not know yet when encoding or so.
CB: Complicated when it gets to tag factoring. If most OIDs can be absolute and some that would need to be TBD112, you can put TBD112 still in there explicitly because it’s an optimization, and at some point you would see that all of them are 112-style … and then it’s more work.
CA: In the array case there’s already the ambiguity of doing tag(array(…)) or array(tag(), tag())
BL: Are we prepared to respond to Rob on this?
CB: There are 4 options. We can say “good point but we don’t care”, second is “declare 112 as preferred”; 2a would be making it a requirement for deterministic encoding. But deterministic encoding is just guidelines, and applications can do it differenlty. And then there is “never have explicit prefix”. The last is easiest, but adds checking requirement on recipient (because something needs to be rejected … and then someone big will get it wrong and then it needs to be accepted again).
MCR: Unless that specific problem comes up, I think I prefer “encoder SHOULD use 112 whenever they can”, and don’t care too much about array case (except that decoders have to deal with it, CB: as they already do). It’s a bit like packed CBOR, we need to make encoding rules clear and won’t always get best encoding but sometimes doesn’t matter.
CB: Sounds like 2a [from the discuss]
BL: Sounds like 2a is the answer, and CB can put it in text.
CB: Will make PR, send mail, then go ahead.

BL: Any of the non-DISCUSS parts to discuss?
CB: Hope people have read it.
[people silently skimming the mail, I guess]
BL: Respond on-list if you find something.

Other WG documents

MCR: Address and file magic documents done as far as I’m concerned, have allocations and I’m using them. I think ready for review, and possibly last call.
BL: Post that to the list.

AOB

CB: cbor-packed. Promised implementation, and it’s really close, stay tuned.

CB: Where is time tag?
CA: Oups, will check.


Attendees:

  1. Barry Leiba, Chair
  2. Christian Amsüss, Chair
  3. Francesca Palombini, AD
  4. Carsten Bormann, Uni Bremen TZI
  5. Marco Tiloca, RISE
  6. Peter Yee, AKAYLA
  7. Rikard Höglund, RISE
  8. Michael Richardson, Sandelman Software