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:

• one erratum editorial, should be obvious.
• 6527 on text strings: Literal notation copied from JSON (supposed to be the same), but ABNF doesn’t reflect it correctly, and nobody noticed. ABNF is more permissive than JSON’s, and doesn’t handle \u escape (that’s a bug, my tool doesn’t handle it either). Addressing this: Do we have consensus on using just JSON notation here? ABNF was different, not quite clear what consensus was.
  • Wrote text into CDDL freezer document that should be minimally disruptive, that’s the proposed way forward. Handle this in errata report (few new lines added, also looked at by Unicode list, and disucssion is converging)? [showing 3.3 of cddl-freezer-07]
  • FP: Sounds like hold-for-document-update rather than reject.
  • CB: Like hold-for-document-update because it keeps it accessible.
  • BL: Accessible it still would be, but it’s hard to understand what the statement is.
  • FP: Can refer to mailing list post and thus this text in the note that goes with it.
  • BL: Could also paste the snippet into note, would be useful to have both.
  • FP: Will do that (unless objections) [none]
• 6543 on byte strings: changed by text string change because there are the single-quote byte strings. [showing cddl-freezer-07 section ?]
  • One possible handling: be aware that there can be comments, and allow single quotes
  • Alternative: Do parsing of text between single quotes first, as with byte strings shaped like text strings. This is supported by existing ABNF and thus a smaller change (but maybe also less easy to use).
  • Feature of allowing comments in hex and base64 strings is already a bit of a bonus here, doing much work to interpret that differently does complicate implementations. Thus, undecided. (Leaning towards the latter, but the text doesn’t decide)
  • BL: From errata processing, sounds like hold-for-document-update
  • FP: Needs a bit more thinking.
  • CB: Hint to implementers?
  • BL: No comments from WG?
  • MCR: It’s a detail of CDDL I try to ignore.
  • CB: It’s also not a common use case. You normally don’t put complicated literals into CDDL.
  • BL: It’s in the nature of errata that you get lots of meaningless typos, and some bizarre edge cases nobody is really using.
  • FP: If we were doing this in draft stage, I’d say “authors, propose something”.
  • BL: If nobody else cares, CB propose what you think best.
  • CB: Will update freezer with concrete proposal, then we can finish discussion on list.

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.

• CB: Some people brought up that “Optional” is common and that these are often implemented using tagged unions. Authors say it’s messing things up, trying to identify which are null-like and which not opens a can of worms they’d like to keep closed.
  • CA: Having proposed this, “we’ve considered it and we don’t want to do it because” is perfectly fine.

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