Minutes interim-2019-cbor-07: Wed 15:00
minutes-interim-2019-cbor-07-201905221500-01

CBOR WG Meeting - Interim 07
Wednesday, May 22, 2019, 15:00 - 16:00 UTC
Chairs: Francesca Palombini, Jim Schaad

Recordings: https://www.youtube.com/watch?v=TvUAwHjmlWg

* Presents:
        Francesca Palombini
        Jim Schaad
        Carsten Bormann
        Michael Richardson
        Laurence Lundblade
        Henk Birkholz

* Regrets
        Paul Hoffman

* CDDL
        Issue has been raised for dealing with negative floating point literals
        Fix: hexfloat = [“-"] "0x" 1*HEXDIG ["." 1*HEXDIG] “p" exponent
        Agreement that this should be fixed in AUTH48
        Carsten to send note to RFC editor and AD + list

* CBOR specification: https://tools.ietf.org/html/draft-ietf-cbor-7049bisCBORBis
    - Status update
      No changes since last meeting.  Paul has started some pull requests.
    - Issue discussion
      Carsten has not had time to go through Paul's pull requests and will do
      in the next two weeks.

* CBOR Array Tag: https://tools.ietf.org/html/draft-ietf-cbor-array-tags
    - Status update
fixed several open issues (see github).
#7: text should already be there
    - Issue discussion
    Francesca to shepherd this document
    Reviewers to check that updates are all OK

* Charter discussion

Proposal:
--
Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript
Object Notation (JSON, RFC 7159) data interchange format to include binary data
and an extensibility model, using a binary representation format that is easy
to parse correctly. It has been picked up by a number of IETF efforts (e.g.,
CORE, ANIMA GRASP) as a message format.

The CBOR working group will update RFC 7049 to fix verified errata. Security
issues and clarifications may be addressed, but changes to the document will
ensure backward compatibility for popular deployed codebases. The resulting
document will be targeted at becoming a Full Internet Standard. After that, the
CBOR working group will monitor issues found with the CBOR specification and,
if needed, will produce an updated document.

Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of
valid messages in a text representation, it is useful for protocol
specifications to use a description format for the data in CBOR-encoded
messages. The Concise Data Definition Language (CDDL) is such a description
technique that has already been used in CORE, ANIMA, CDNI, and efforts outside
the IETF.

The first version of CDDL has been published as RFC XXXX.  While this
specification has been completed, several new features were raised during the
update process that were not included, in order not to delay publication, and
to allow publication in the Standards Track.  One example of such a feature is
the ability to combine multiple CDDL files together using a mechanism other
that manually concatenating them together for processing. The working group
will collect these features as well as other features that are raised by users
of CDDL, evaluate their utility and add to a second edition of the
specification if warranted.

The working group will define the approach to further evolving CDDL as a
sequence of editions, which might also add further extension points, probably
as part of the introduction of the next edition of the CDDL base specification.
 The body of existing specifications that make use of CDDL is considered
precious, and the WG will set out not to damage their value.

The working group will evaluate the necessity of providing advice and guidance
for developers using CBOR and CDDL.  It is currently expected that this would
be done using a Wiki of some type.  This work would not be expected to be
published by the IETF.

There are a number of additional CBOR tagged types that are either currently
adopted by the working group, other working groups, or individual submissions.
Additionally, there are expected to be other such documents that will come to
the attention of the working group.  In some cases the working group expects to
adopt and publish these proposals.

The working group will evaluate and place proposals in one of the following
categories using a dispatch like process:

General purpose tagged types that are expected to have broad usage:  The
working group will normally adopt and publish such proposals.  Examples of
proposals in this category are CBOR Sequence (draft-bormann-cbor-sequence) and
Error Indications (draft-richter-cbor-error-tag).

Internet wide specific purpose tagged types:  The working group may decide to
adopt these proposals, but typically it would just provide input and recommend
that they be published either as an Independent Submission or by a different
working group.

Narrow purpose tagged types:  The working group may provide evaluation of such
proposals, but typically would not support Working Group adoption, and could
recommend publication in a different forum. An example of this might be
portions of draft-bormann-cbor-tags-oid dealing with some of the more esoteric
types such as regular expressions --

MR: Revision of CDDL full internet standard? Dependent on RFC7049bis?
CB: No and yes.
MR: in CDDL2 intention of mechanism to indicate if you could tolerate RFC7049
or need 7049bis? CB: there is no difference.

MR: interest or out of scope for a tag that warns if there is newer stuff from
newer revision? CB: this could be discussed but not worth doing that

JS: charter: CDDL v2 would consume and produce the same output as CDDL1 with
the same input

HB: highlight that CDDL v-2 is an extension of CDDL but CDDL is stable.

MR: will CDDL v-2 update or obsolete the v-1?
CB JS: yes
MR: Maybe put 1.0 in the CDDL title?
CB: YANG 1.1 substential changes from 1.0. Don't think CDDL would be the same
amount of changes. MR: CDDL 2019? CB: worse

JS will publish to the new charter to the list and the WG will review again in
two weeks.