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

From: Jim Schaad <[email-masked]>
Date: Sat, 29 Aug 2020 19:57:48 -0700

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.

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.

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).  

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.

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.

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")

Jim