Subject: [Cbor] Minutes IETF100 CBOR

From: Francesca Palombini <[email-masked]>
Date: Wed, 29 Nov 2017 09:50:06 +0000

Hi all,

I uploaded the minutes for the CBOR meeting at IETF100 on the datatracker: https://datatracker.ietf.org/meeting/100/materials/minutes-100-cbor/
Many thanks to Jim Schaad and Stéphane Bortzmeyer for taking them!
Please let us know if you have any comment, and if you have actively participated, take a second to make sure that your comments were correctly captured.

Thanks,
Francesca

--
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.