Minutes interim-2019-cbor-10: Wed 15:00
minutes-interim-2019-cbor-10-201907031500-00

CBOR WG Meeting - Interim 10
Wednesday, July 03, 2019, 15:00 - 16:00 UTC
Chairs: Francesca Palombini, Jim Schaad

Present:
    1) Michael Richardson
    2) Francesca Palombini
    3) Jim Schaad
    4) Laurence Lundblade
    5) Paul Hoffman

* Charter discussion: https://github.com/cbor-wg/charter
        - Ballot: https://datatracker.ietf.org/doc/charter-ietf-cbor/ballot/

Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript
Object Notation (JSON, RFC 8259) 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 deal with existing 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 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. CDDL has been published as RFC 8610. 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 than 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 as
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 and CBOR
related media type specifications that are currently adopted by the working
group, are work items in other working groups, or exist as 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 such proposal individually and decide about addition of a respective
milestone. Proposals that are deemed to be out of scope for the working group,
e.g. because they are too narrow purpose specifications, may still be published
as individual submission or in another groups if there is a specific need. The
CBOR group will review these proposals on request.

MCR: YANG work that is now on CoRE? Does the charter excludes it?
JS: Does not exclude it, don't know if we want to work on this, but we can
discuss it.

AP Chairs: Update the text with both final edits and Alexeys edits and send back

* CBOR specification: https://tools.ietf.org/html/draft-ietf-cbor-7049bisCBORBis

    Cleared out the PR and produced v-06. Newest part is the merged security
    considerations. Should include Laurence's input. Unfinished: issue #86.
    Merged PR18 that had input on tag validity, but some text should be decided
    on. PH: I don't mind that we check some and not others. CB: why the
    difference between checking on MIME and CBOR embedded ? MCR: MIME: we are
    checking that the encoding is valid, not the content CB: we could say "CBOR
    embedded needs to be "well-formed for it to be valid" LL: should we say
    "MUST be conformant with the MIME standard" (RFC 2049) CBOR is different
    since this is the CBOR spec CB: we would get ourselves downref because MIME
    is draft standard CB: CBOR validity based on tag being well-formed? LL:
    yes. At least well-formed, maybe even valid. PH: well-form is good. JS:
    well-formed is sufficient. AP Authors to implement this

    issue #77
    JS: wasn't this discussed last meeting?
    77 -> would be good with webauthn people feedback. Editorial clarification
    that this is one way of doing it and we are not necessarily recommending
    this particular way. Write a proposal and bring to the list.

    Authors need to do the changes from issues left, will bring to the list if
    anything comes up that needs more discussion.

    LL: looked over security considerations, initial comments: not very happy
    with strict mode, seems like it's claiming security properties it shouldn't
    be claiming. "security context" is not good wording. confused about scrict
    mode valid, invalid, well formed. Will comment on those in more detail. CB:
    validity checking decoding different from enforcing preferred deterministic
    encoding. JS: does this relate to issue #45 CB: no, strict mode is about
    validity checking at the CBOR level.

    JS: anything else that needs to be discussed?
    CB: no.
    PH: open new issue on re-reading strict mode.

* CBOR Array Tag: https://tools.ietf.org/html/draft-ietf-cbor-array-tags
    - Status update (v-05)
    - No WGLC repeat is needed
    - Start shepard writeup following submission deadline
    - AP Jeffrey and Laurence to check the their reviews are addressed

* AOB
LL: new draft for RATS, would like to get feedback
FP: post to the ml
- next 2 interims cancelled (Jul 17, 31). Next interim after IETF105 Aug 14.
- Agenda call to come soon