Subject: Re: [Cbor] Review of draft-bormann-cbor-cddl-control-01

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Sep 2020 13:02:37 +0200

Hi Jim,

thank you for the comments!

> On 2020-08-30, at 04:57, Jim Schaad <[email-masked]> wrote:
> 
> A couple of comments on this document.  It is very possible that I have
> already made this comments and they are on your to do list.
> 
> 1.  Abstract needs to be expanded to identify what operators are in this
> document.

Done.

> 2. Bikeshed topic - I don't really like the name of the .feature control.
> The problem is that the definition of a feature is not at all clear from the
> name of the control.  Among other things it does not say which extension
> points are targeted.   I don't know that I have a good suggestion at this
> point but something long the lines of .map-extensions is a much tighter
> description of what is here.

I really like that name, and (once you know what the .feature control does) something clumsy like map-extensions is further away from being readable than .feature.

> 3.  Section 2.1 - I just ran into a potential issue with RFC 8610 that is
> highlighted here.    On my system I would expect the result to be b =
> "foo\r\n  bar\r\n  baz\r\n".  Both "\n" and "\r\n" are considered as legal
> inside of a byte string value and I did not find text to resolve it for the
> non-hex/base64 case (where it is not relevant).  

Indeed, this is not specified in RFC 8610, which I consider a todo.
I wrote draft-bormann-dispatch-modern-network-unicode to address this class of problem, but that hasn’t seen recent updates (it will, soon).
For now, I have updated the comment to say that the equivalent is for \n-newline systems.

> 4. Section 4 - Define behavior .feature is referenced outside of a map key.
> Or are there other places where it can be used and thus these need to be
> enumerated.

It can be used anywhere.
No need to enumerate because it literally is anywhere.

Where does it say map key?
Oh, that’s the example.

(The biggest real-life example that I know of, https://github.com/one-data-model/SDF/blob/master/sdf-feature.cddl , also uses keys map entries, but also map values and generic values in an any-like construct.)
I copied over a type extension example.

> 5. Acknowledgements - I think this does not read correctly as it says that I
> suggested improvements on .feature rather than the document as a whole which
> is what I think you meant to say.

Swapped.

> 6. Section 3 - The description says that following is legal, but does not
> give a clue on what the correct behavior would be:
> 
> Value = text . abnf "full-date\n"
> 
> The text says that it is followed by zero or more rules, I would assume that
> at least one rule would be required and the given target name must exist as
> a rulename for a rule.  I think you might want to switch from element to
> rulename in this text as well.  Element would allow for
> 
> Value = text .abnf "(WSP / CRLF WSP”)

(If WSP and CRLF are defined below(*) and the position of the quote is fixed.)
Is that a problem?

Zero rules make sense in very simple applications such as:

Number = text .abnf “1*%x30-39"

If we change element to rulename, that usage of course goes away.

(*) Added a sentence making this clearer.

Changes are in https://tools.ietf.org/rfcdiff?url2=draft-bormann-cbor-cddl-control-02.txt

Grüße, Carsten