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