Skip to main content

Minutes IETF98: cbor
minutes-98-cbor-00

Meeting Minutes Concise Binary Object Representation Maintenance and Extensions (cbor) WG
Date and time 2017-03-30 18:00
Title Minutes IETF98: cbor
State Active
Other versions plain text
Last updated 2017-04-06

minutes-98-cbor-00
CBOR WG Meeting
IETF 98 - Chicago
Thursday, March 30, 2017, 13:00 - 15:00
Chairs: Joe Hildebrand, Francesca Palombini Minutes taken by Paul Hoffman
    Text on the slides is not reproduced here
    See https://datatracker.ietf.org/meeting/98/session/cbor for slides
    Action items collected by Henk Birkholz

* Introduction  [15'] : Chairs
    First meeting of CBOR WG
    Using GitHub in general, not strictly
    Issues are discussed on the list

* CBOR specification status: Carsten Bormann
    https://tools.ietf.org/html/rfc7049
    Made defining new tags easy
        May want to revisit the IANA considerations
    Kerry Lynn: is there test suite or test vectors?
        Carsten: We have examples in the RFC
            Maybe this is a good time to start this
        Joe: Has a pretty comprehensive suite in Node
            Also has a fuzzing suite
            Maybe pull that out as a separate repo
    Brian Carpenter: When a new tag is defined, does it go into the RFC?
        Joe: There is an IANA registry
        Carsten: Different levels of requirement
        Joe: Do people have opinions about this policy? Say so on the list.
            Carsten: We may want to make this a bit harder because we are
            running out the 2-byte range Joe: We might give tag guidance Rick
            Taylor: DTN WG is using CBOR
                Could use implementation guidance
        Henk Birkholz: Where will these go?
            Carsten: Use a GitHub wiki
        Ira McDonald: Opposed to the first-come, first-serve range
            Wants a minimum of specification required
            Dave Thayler: We need more reasons for this discussion
            Alexey Melnikov: We don't have to do this now
            Sean Leonard: We might want to get a specification for things that
            are generally used DaveT: Can't be guaranteed that you won't have a
            breaking change
        Carsten: Shows the IANA repository
            The expert can give pushback on "specification required" before
            giving DaveT: Question in the industry about which of these can be
            converted to JSON
                WG should be aware of conversions from JSON
                Carsten: Document more that tags are voluntary
            James Woodyatt: When you have precious values, demand becomes high
                6lo has some issues with this
                May need a parsing switch into smaller tags
                Michael Richardson: Asks the nature of the pressure
                Carsten: it is reasonable that a tag could redefine the tag
                space inside Sean: The tag is supposed to be globally
                understandable
                    If you want to make something contextual, you can
                    Joe: Can imagine a tag that switches context
    Action items:
        * Joe will create repo for CBOR test & fuzzer suite in github cbor
        organization * Carsten will place pointer to Joe’s suites on cbor.io *
        Carsten will start a wiki page for implementation guidelines * Carsten
        will make more clear in text that you do not have to use tags * Carsten
        will create specific text about outer and inner tags

* CDDL: Carsten
    https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/
    FDT = Formal Description Technique
    No semantics in CDDL today, only structure
    Many specs are using CDDL to encode JSON
    Let's not turn it into a scheme language, but keep it as structural
    Henk: We should come up with a consistent example that goes throughout the
    document DaveT: ABNF supports string concatenation
        There are plenty of protocols don't need offsets
    Matt Miller: We should do things that present the least surprise
        Computed values might give surprise
    Sean: Reuse syntax from other DLs
        Maybe have a different syntax for regexps
    Dave Waltermire: Reduce computational complexity depending on where it will
    be used DaveT: No less expressive than JSON Schema? Hannes Tschofenig:
    Tried to push JSON Schema here but it might have been too complicated Matt:
    Rejection was a reaction to XML Schema, maybe an over-reaction Joe: What we
    are not doing here is a validation language; we are only do a specification
    language
        Hannes: But COSE did code generation
        Joe: Difference is in defaults for objects
            Try to stay away from validation because it has been wrong
    DaveT: If we want CDDL to be usable, we have to see what people are doing
    instead
        Should not do what they are not needing
    Matt: We are trying to say what you can define JSON formally
    Henk: I can read this (RFC 7071 slide)
        Validation is not our goal, it is a valuable side-effect
    Hannes: There was an assumption that implementers would use the schema, but
    they really wanted examples Michael: Unless the CDDL is defining bytes on
    the wire, we don't have to obsolete any of them Sean: Wants constraints
        Numeric constraints should use a programming language construct
    DaveW: Non-text labels: doesn't that require some things here?
    Henk: The jump to validation is pretty tiny
        Joe: We agree on structure, but need to get new consensus on validation
    Joe: Does anyone object to us starting with this document? (No objections
    in the room)
        Lots have read this, surprising number have used it to write spec
        Need to come up with a new name on the list before we come up with a WG
        draft Spec to refer to quickly (current form) (small editorial pass),
        then start a -bis soon, versus work more on the spec Rick: Quickly, and
        rip out verification for now Jim Schaad: Quickly, easy for people to
        read
            Do the authors think that any feature is underspecified?
            Henk: within-template needs a bit more focus, but it is used well
        Brian: Quickly
        James: Has written an internal spec, doesn't need it rushed
            Found a few places (esp the generic syntax) the could use a bit
            more focus
        DaveW: What will be cut?
        Henk: Notify every author who is using it
        Hannes: Feels like there is a rush but there was not before
        Rick: We should have an audit of documents in the pipeline
        Matt: Start with things in the RFC Editor queue
    Action items:
        * Henk will make the convention of expressing constants in UPPER CASE
        explicit * Henk will create text to illustrate purpose: interaction
        between humans and machines * Generic Types: Carsten will take a shot
        at that being a little bit underspecified * Henk will prepare a branch
        for an expediated draft polish * Carsten will lead the discussion if we
        need a new name for cddl * Carsten will review IANA considerations for
        "specification required"
so there is a field to record IETF change control

* Array tags: Carsten
    https://datatracker.ietf.org/doc/draft-jroatch-cbor-tags/
    Joe: Reserving this many tags in one-byte space is overkill
    Rick: How do you represent flags here

* Time tags: Carsten
    https://tools.ietf.org/html/draft-bormann-cbor-time-tag-00
    The tags in CBOR only solve 85% of the hard time problem
    Also talked about draft-bormann-lpwan-cbor-template

* OID: Sean
    https://datatracker.ietf.org/doc/draft-bormann-cbor-tags-oid/
    Carsten: How do we decide to change registrations to give them shorter tags?
        Joe: Wants the docs to be short and easy to understand
            Contact authors to see if they want to do the work here
        Maybe has a draft with a UUID
    Alexey: Do the earlier registrations have a change control field?
        Joe: They should