Subject: [Cbor] 🔔 WGLC with request for reviews on cbor-cddl-control-03

From: Christian Amsüss <[email-masked]>
Date: Tue, 1 Jun 2021 20:34:27 +0200

Hello CBOR group,

this mail marks the start of a two week WGLC on cddl-control[1].

As this document has seen no recent review activity, I urge all
prospective users to read the current version and provide reviews.

Without positive reviews, this WGLC can not complete.

Best regards,
Christian

[1]: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-control/

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Jun 2021 21:06:02 +0200

> prospective users to read the current version and provide reviews.

Well, I’m not a “prospective user” (more like an actual one), but I have been using various parts of this document over the past year as the implementations became available.  

Here are two observations that maybe could benefit from some additional discussion.

.feature has been around for a year, and it really turned out to be a brilliantly simple solution for a complex need (compare “if-feature” in YANG…).
One nit that is sometimes a bit hard to manage is the consistent use of feature names (maybe this is a tool issue, or something that a usage convention could help with).
The biggest confusion was created in one case where part of the spec said

	.feature “1.1”

while another said

	.feature 1.1

(yes, the floating point number.)
The cddl tool treats these as different features (which they obviously are), but generates exactly the same output for these.
This led to a little goose hunt…
Limiting the controller side to text strings doesn’t quite feel right either, as there may be good use for a structured feature name.
So my provisional thinking is that this should be handled by better tool support and maybe adding a little warning text in the draft.

.abnf needed .det, that was a surprise to me when implementing this.
(The other surprises were how mind-bogglingly easy the implementation was after all, and how useful the .abnf control operator is in an IETF world where much is already available in ABNF — so much better than regexps...)

As specified now, .det dedents just the rhs, and explains

   If left-hand-side (target) dedenting is needed as well, this can be
   achieved with the slightly longer construct "("" .det lhs) .det rhs”.

Well, after some use it turns out that it is much more likely that one needs both sides dedented, so maybe we switch to this and change the note to:

   If dedenting is needed only on one of the sides, this can be
   achieved with slightly longer constructs such as »lhs .cat ("" .det rhs)« 
   or »(lhs .det “”) .cat rhs«.

Apart from these somewhat advanced notes, I’m still rather happy with the draft both from a user (model author) side and from an implementer side.

Now keep the reviews flowing, please…

Grüße, Carsten

(Please excuse the random smartquotes.)

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 16 Jun 2021 12:24:55 +0200

Hello Carsten, hello CBOR group,

> The cddl tool treats these as different features (which they obviously
> are), but generates exactly the same output for these.
>

The current draft text describes the features to "usually be a string",
ands adds that arrays can make sense too.

> So my provisional thinking is that this should be handled by better
> tool support and maybe adding a little warning text in the draft.

The text sounds good to me; a message produced by the tool ("Warning:
CDDL feature {} is neither a string nor an array. This is allowed but
unusual.") should catch floating features before they come into use.

> [on .det ]
>
> Well, after some use it turns out that it is much more likely that one
> needs both sides dedented, so maybe we switch to this [...]

This really sounds to me like it should be a unary control. We
don't have them, so either of the current proposals is viable for me --
but playing a bit with the unary control (more spitballing than actually
suggesting): We *can* have empty groups on the RHS, right? So could we
emulate unary operators by adopting a method-call-like pseudosyntax?

  cbor-tags-oid = '
    oid = 1*arc
    roid = *arc
    arc = [nlsb] %x00-7f
    nlsb = %x81-ff *%x80-ff
  ' .det ()

would read like any other language's method call. Granted, the same
parallel would be seen as terribly confusing, and 

    cbor-tags-oid-decrypted = cbor-tags-oid .det () .rot13 ()

as I understand wouldn't even make the dedented text available to the
obfuscating rot13 control.

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Jun 2021 13:31:50 +0200

Hi Christian,

> On 2021-06-16, at 12:24, Christian Amsüss <[email-masked]> wrote:
> 
> Signed PGP part

Good point; a warning has been added in 0.8.25.

> suggesting): We *can* have empty groups on the RHS, right?

Unfortunately, the RHS needs to be a type (as does the LHS).
That is a limitation of control operators; they operate on types only.

> So could we

(Even [] doesn’t work with the current tool as .det complains about its RHS not being a string.  Creating a special case just so we can avoid ‘’ or “” doesn’t strike me as a great solution.)

Grüße, Carsten