CBOR WG Meeting IETF 100 - Singapore Thursday, Nov 16, 2017, 15:50-17:50 Chairs: Joe Hildebrand (JH), Francesca Palombini (FP) Minute takers: * Stéphane Bortzmeyer * Jim Schaad * Introduction [15'] : Chairs Agenda bashing and status update * CDDL [30'] : Carsten (CB), Henk (HB) https://tools.ietf.org/html/draft-ietf-cbor-cddl-00 (Requires some ABNF background) CDDL wants to be "like ABNF" except that CBOR is not text (tree of items, with structures likes arrays) Example of use of CDDL : GRASP (in Anima) To do: * appendix B on matching rules. (currently in Github only ? ) * wildcard vs. "more specific" in a map definition We would like the "more specific" to win. How to express that? Proposal: use "cuts" Get inspiration from draft-miller-json-constrained-notation? (pull request to be sent) Typo in slide 18 : the second ant is an elk Sean Leonard (SL): I have a different method which could express this by doing a general with a restriction on the general I will do a pull request for more clarification Jim Schaad: I do not understand why this needs to be expressed in the grammar rather than as semantic information. SL: Currently no normative reference in CDDL for doing regular expression Regular expressions should be first class items in the language When REs are in a string, the escaping makes it difficult to read. JH: Like the proposal of killing slashes. Brian Carpenter (BC): The cuts proposal too complicated, let's keep REs for CDDL v2 - also want to keep number of changes to absolute minimum SL: Currently the controls are both overly general and too constrained. Want to be able to do something like .size only allows lengths which are multiples of 2. Allowing REs at the top might be able to allow this. CB: Right now REs are only for text strings.(but SL would like them to be more general: sequences of items, not just of characters) FP: First question is: Is the work useful? Once we answer that, if the answer is yes, we can move to next question: should it be delayed? CB: PCRE is not currently defined in a normative spec, even if it is the right one. Alexey Melnikov: One of the sip docs has this - JH: One of the ECMA has a slightly less powerful/expressive version. [ACTION ITEM]: Alexey to look for regex normative reference document See also the wrap-up * CBOR specification status [30'] : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis-01 Taking CBOR to full Internet standard (don't change it) The only really new part is the one about CBOR data model ("the biggest failing of JSON") Reminder that not all extensions are mandatory in CBOR. Except false and true and null :-) SL: Currently document says undefined is a core element - CB: Need to look - Expects undefined to be optional 40 implementations (personal opinion: they vary widely in quality, and level of maintenance) Interoperability problem with the padding. Tags 22, 33, 34 no perfectly defined.Base64url typically used without padding, Base64 often with padding. And case issue, also. SL: Is there a canonicalization reason for making the decision? Dave Thaler: Does anybody care? Yes OCF does want to be able to do this. It uses both (or either) JSON-Schema and Swagger to specify things in JSON but puts CBOR on wire - Both Json Schema and Swagger define BASE64 but not BASE64url. TinyCBOR maintainer would love to fix that if either json-schema or swagger added spec support for base64url. Thinks the proposal should be fine - needs to check - look at tiny-CBOR https://github.com/intel/tinycbor Matt Miller: Safest to keep the padding for base64 JH: Argue to remove all Base64 because you have binary and don't need it. The tags could be removed from standard. [ACTION ITEM] Put base64 issue on the mailing list [ACTION ITEM] Jim does PeterO implementation in matrix [ACTION ITEM] DT to poke tinyCBOR author (Thiago Macieira) to fill in implementation matrix for tinycbor * OID Tags [10'] : Carsten, Sean https://tools.ietf.org/html/draft-bormann-cbor-tags-oid-06 Many tags (besides the ones in RFC 7049), sometimes in RFC; sometimes not. Some are on-charter but not all. * Array Tags [10'] : Carsten https://tools.ietf.org/html/draft-jroatch-cbor-tags-06 Careful on the encoding: the space is not unlimited JH: General concept of - one big thing plus lots of variations - may want to have a pattern version - example two item array - first item is format, second is data Could do this type of pattern here. SL: The fact that tagging is optional may make the case of a small array (such as an RGB) value having a large tag normally for an array of bytes would be easier. JH: Having a document on when and how to use tags as suggested by SL would be useful FP: Blocking issue on adoption at the last meeting was people who read and reviewed. Consensus on 3-bytes tags, it seems * Time Tags [5'] : Carsten https://tools.ietf.org/html/draft-bormann-cbor-time-tag-01 Document tag 1001, if the WG agrees CB: Should we allow this as an independent or wait and then do this AM: Do current things first, but no other opinion. Who wants to work on time formats? Three people. JH: this is not enough * Wrap-up [10'] : Chairs JH: How many people think we need to do much more work on CDDL before going out - (none?) How many people think we should polish and call it good - many hands Request of Alexey to look for people wanting to use CDDL for JSON schema. - need more review of Appendix B. Things that need to be looked at - if no reference RE should be on the bubble. Rip out features w/o full consensus and can be put into the next version of CDDL. Need to have something that talks about the difference between a validation compiler and a documentation of what the language should to be. This ought to be added to the Philosophy document that SL volunteered for.