Minutes IETF100: cbor
minutes-100-cbor-01

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.