[Cbor] Minutes IETF101 CBOR

[Francesca Palombini <[e-mail]>]

Hi all,

I uploaded the minutes for the CBOR meeting at IETF100 on the datatracker: https://datatracker.ietf.org/doc/minutes-101-cbor/
Big thanks to Paul Hoffman and Christian Amsüss 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.

I also want to join Alexey in thanking Joe for his time as chair, and welcome Barry, looking forward to work together.

Francesca

--
CBOR
IETF 101 - London
Tuesday, Mar 20, 2018, 13:30-15:30
Chairs: Joe Hildebrand, Francesca Palombini
Recordings: https://play.conf.meetecho.com/Playout/?session=IETF101-CBOR-20180320-1330 or https://youtu.be/FrVinVcs-P0
  Minutes by Paul Hoffman, Christian Amsüss
  Nothing from the slides reproduced here

* Introduction [15'] : Chairs
  https://youtu.be/FrVinVcs-P0?t=5m55s
  Agenda bashing and status update
  CDDL had WGLC, that generated review comments to be discussed today. 7049bis: Implementation matrix updated (see wiki). array tags got reviews, ready for adoption when reviews addressed.


* CDDL, draft-ietf-cbor-cddl-02 Presented by Carsten Bormann
   https://youtu.be/FrVinVcs-P0?t=8m32s
  - Changes since IETF 100: cuts in maps introduced for one particular application. From regexp discussion there: Using XSD regexp that are still weird but not too much, and [something with unicode].
  - Created a "freezer" document for things that will not go into the main document
  - On map matching: CDDL has single concept of "groups" (for maps and arrays) that are grammars of types; describe linear languages. Linear properties are only used for arrays, and as maps are unordered (thus match anything), implementations need to be driven from grammar and not from text. That also creates some nondeterminism -- that hasn't hurt anywhere, but edge cases might come up.
  - Map validation (though "validation" not a term of CDDL): wildcard in matches could consume explicit matches [if the scribe understood correctly]. For that (and only that), cuts are introduced: once a fork is matched, the path is committed, and if the rest won't match, the whole thing won't. This is only meaningful on a match. That comes with limitations [...].
  - Are there only editorial issues left, or is anything technical still open?
  Jeffrey Yasskin: Semantics of group and cuts are not specified well
    Wants to know precisely what causes a map to match. We need a precise specification of the matching algorithm.
    Carsten: This is precise as it's a parse expression grammar, which is greedy. It becomes a problem when expressed in a nondeterministic[?] finite automaton.
  Jim Schaad: Wants to change the ordering.
    Match the most specific keys first, specific before "any"
    Jeffrey: Can't say one type is more specific than other types.
    Choice types can just overlap and not be more specific than each other.
    Jim: Anything is a value > constructed type > groups (Value is more specific than type is more specific than any.)
  Sean Leonard: I want to express that I am opposed to introducing "cuts" into CDDL v1.0. Cuts transform a context-free grammar into a context-sensitive one. An alternative, "subsets" or "constraints", was sketched out in Singapore. From an editorial point, this is introducing new matter at the last minute when it needs to be fleshed out more over the coming months, i.e., after we get this version of CDDL out. (So basically it is similar to Jeffrey Yaskin's point: not well specified and also trying to do too much.)
    Carsten: If we want colon to be a short cut for "^ =>", we need to do this now, can't be added later. And that is the meaning probably most spec writers will expect of ":". The alternative is to smearing the previous cases into the later more generic ones. This won't make concise specificatons.
      Jeffrey: useful to have ":"" syntax act as a cut, not sure we need the cut syntax. Just column is maybe easier to specify.
    Henk Birkholz: Exception is the behavior of cuts
      If we don't want a simple notation, we need to decide this soon
      Likes the last example; intuitive
    Carsten: The interesting proposal here is to only have ":" and not "^".
      It's weird to have a shortcut that you can't have in long form
    Sean: (refers to slide 15) So the point is that you want to say "4 is text only, all other uints are anything else", right? So the slide says "* unit" and that means "* all uints except 4", right? What happens when later you want to say 5 is only a byte string? You have to put ? 5 : at the top, but you can't put it at the top, you are supposed to be putting it at the bottom...
    Jim: if you append a colon-thing to the bottom, you're going to expect enforcement, but not checked/enforced.
    Carsten: By creating a sorting mechanism, this consideration could be handled. I don't like the sorting mechanism b/c spec writer can intend a sequence.
    Sean/Jim: Spec writer can intend a sequence, but extension writer can only append.
    Carsten: [...] You can give the first thing a name, and have that as an extension point, and have the wild card after the named.
    Sean: The way that "constraints" work is that you say, with appropriate syntax: * unit -> any FIRST. Then in the subsequent parts of the spec, you identify specific instances of *uint => any. For example: "when uint is 4: text". "When uint is 5: byte string". (this is discussed in draft-seantek-constrained-abnf, for ABNF.)
    Carsten: [...] There are several proposals. Some proposal to have the shortcut but not the long form, others not to do that at all (refer to slide 15). Take it from the list from there.
    Francesca: Yes.
  - Carsten: Next topic: operator precedence. Operator precedence is logical when it comes to groups and types. The same syntax in a map context is unfamiliar in a type choice after a [quantifier]. General changes in operator precedence would create annoyance in form of needing more parens and raising syntax errors if missing. We can add text to explain and encourage a style that doesn't contain surprising cases. Comments? Room: silent.
    Hank: I see the necessity, but it violates the rule of not being noisy, and specs will be paren-laden after that, and move away from the being easy-to-read-and-write, but I see the point.
    Paul: It's never too hard to read too many parenthesis.
    Carsten: It doesn't need to be names, more common is to name the choice and than use that name. We can still make the recommendation w/o littering up specs -- but yes, we should check that.
  Carsten: Addressing Jim's review.
    @Dead code: should not lead to hard errors. A tool might still give warnings on that. It's generally undecidable, but often possible in realistic cases.
    @generics: grammar says it, text doesn't, but should say it too. @precedence: there were errors.
    @unwrap grammar: found copy/paste error.
    @terminology: we should make it visible that there are CBOR and CDDL terms, and they never mix.
  Jeffrey: CDDL spec is written as a tutorial, not a spec
    Appendix C is a good start, but it should move there before becoming an RFC.
    Carsten: A sensible proposition -- which would need half a year.
      Jeffrey: can we speed that up with a pull-request style?
    Alexey: Is this just reordering?
      Jeffrey: More. For some cases, I don't even know the algorithm Carsten has in mind. For other, it's clear enough that I'd be capable of writing the spec, but it takes time.
      I could sketch something in a month, but getting the exact words would take longer.
    Francesca: The WG said it wants this out as soon as possible
    Sean: Let's get version 1 out now and run a more formal spec on next version if we feel it's necessary.
      Jim: Agrees
    Joe Hildebrand: Sees a ton a value for this, but wants something sooner
    Carsten: Wants a list of the items Jeffrey does not understand
    Jeffrey: Can't currently use this in web specs
    Joe: We know that there is still work to do, we expect a -bis
    Alexey: Is comfortable with this approach
  Alexey: When can you be done?
    Carsten: Before late May. Would like to get input from Jeffrey.
  Francesca: To the WG: keep checking the doc (see github for most recent update). Bring leftover points/issues to the mailing list. After the update, we'll see if we need another WGLC.

* CBOR specification, draft-ietf-cbor-7049bis-02 Presented by Carsten Bormann
  https://youtu.be/FrVinVcs-P0?t=51m52s
  - This is about taking this to standard level, learn from first 5 years but don't futz around. This is way beyond errata, but follows the definition of standard level (look it up).
  - Since -00: experience says making readers infer data model from spec is mistake. We now define "generic data model" with extension points.
  - Separation of integer and floating point types (as it has been used). That played back into key equivalence. Now there are environments that don't allow that separation easily -- and we can't fix that. Needs to be considered when writing a model, will need a bit of general guidance.
  Joe: In JSON RFC, if you use something like an integer that is >2^53, you'll have problems
    Carsten: We won't have that problem
    Joe: Nevermind, not an useful idea
  - On canonicalization (c14n): this was problematic btwn authors in original spec, but there are uses for it -- let's help those people. Careful: There is key equivalence that can come from the application level. Floats are problematic too. We want to encourage generic encoder writers to not ignore it when users ask for c14n. To help them: Provide recommendations (and that's all that is in the RFC). Those recommendation rules were leaky, and keyorder (often complained about by implementors). The key order will change to byte-wise lexical -- but we also keep the old one in (but not recommendation) so existing specs can still reference it. Too bad, sorry. We will want to be more specific in float normalization; we have 3 models, should we express a preference? Own preference: Prefer shortest encoding in all cases (For int, length info, strings, tag number, floating, bignum etc).
    Jim: Worries about things like bignums into ints
      Worries about loss of tagging
    Carsten agrees, but has questions about whether it matters
    Jim: Yes in the crypto world completely different things
    Paul: For example a counter that is supposed to be 128bits
    Carsten: You can represent that in 64 bits if you can
    Jim: TSA signature, 2 int.
    Jeffrey: 2 examples. From FIDO: AGL found software bugs based on processors getting the length wrong. Geo location extansion to web authen that use floating point, did not want short encoding for floating.
    Matt Miller: More in the cryptographic context, if uses as a counter, semantic of a counter but syntax a set of bits of determinate length. Catastrophic to decrypt. Proposal: if we propose shortest encoding you have to have very clear considerations that you have to be careful
      Carsten: Example of things that need to be constant size
    Joe: We have the option of saying "don't do canonicalization of any protocol, use bytes"
      Carsten: We can do both. In the crypto space, we have learned it is bad, but in other use spaces, it could be OK
    Thiago Macieira: What happens if you decode and reincode in a compliant program
      You may be making bignums in all implementations
      Does this mean that bignums become mandatory?
      Carsten: It might be an option for your decoder
        Another thing a decoder can do is *check* canonicalization.
        Does this answer the question?
      Thiago: It's an answer to the question, but I am not satisfied.
    Matt: An alternative nuclear option: point to a different document
      Sean: A separate document might be good
    Jeffrey: All the specs should specify canonical output for testing
      Also contrains encoders to what they can put out
      We don't have to state a preference, but for basic generic data model we can have one but not extended generic, and giving such a canonicalization a name is sufficient for other specs.
    Sean: To what extent is type and tag is assumed to be saved across encoding
      Jim: +1. Are you canonicalizing the data model or the CBOR structure
      Carsten: Yes
        It's important for parser speed that it can discard information that is immaterial to the data model. Whether that includes int/bignum is up to questio
    Joe: If something is in canonical form, and I re-generate canonical form, these are equal.
      Carsten: That's almost the definition of canonical.
    Paul: Suggests that we only list ideas, but no preferences
      We should give some information, "but you make your own rules, and you're gonna cry."
    Jeffrey: Generic canonical is bad thing, protocol specific canonicalizatiion is important
    Matt: CBOR has as strong idea of what types are, unlike JSON. 1 more vote to do not deal with canon in this doc
    Joe: A world with 20 CBOR canonicalizations would be much worse than where we are today
      ASN.1 are an anti-pattern for writing a parser
      1) Never canonicalize, it's evil
      2) Here is a canonicalization form in this doc
      3) There is a canonicalization form in another doc
    Sean: I guess the point is, to what extent is CBOR type & tag information supposed to be preserved when serializing between different implementations?
    Carsten: We can split the technical issues from the procedural issues.
    Jeffrey: The rest of the set is close to ready, but this is not, suggests different doc
    Alexey: Group needs to decide between "saying very little" and "strongly against it"
    Paul: For this doc we can say "it got took out for a reason". There might be a doc in the future
    Carsten: Splitting out might be the best way.
    Thiago: Also yank of equivalence of keys
      Joe: Good point, we need to do analysis first
  - implementation matrix
  Jeffrey: There should be a better way to determine consensus to accept PR submitted to github
    Pull requests should be discussed on the list sooner
    Francesca: Reminder: important/big PR should go to the list
    Joe: we can be more aggressive on getting them included when we think the consensus has been reached
    Paul: Maybe wait three weeks after the end of discussion in
     the mailing list to include them
  Jeffrey: Chrome has two implementations that will get added

* Array Tag, draft-jroatch-cbor-tags-07, Presented by Carsten Bormann
  https://youtu.be/FrVinVcs-P0?t=1h35m56s
  2-byte space or 3-byte space
    Paul: 2-byte is fine
    Jim: 3-byte is fine and we might end up regretting
    Sean: Weak +1 for 3-byte
  Other registration in IANA overlaps
    Alexey: We cannot stop them but maybe we can convince them
    Zach Shelby: Did something in CORE
      Also has a fast track
      Maybe have a separation of rules
  Will be adopted in the WG

* Wrap-up: Chairs
  https://youtu.be/FrVinVcs-P0?t=1h53m38s
  Joe: will be stepping down as CBOR chair