Illegal CDDL when defining script.RegExpRemoteValue and script.DateRemoteValue

[shs96c]

The ABNF grammar for parsing CDDL is given in RFC 9682. In this spec, we define script.RegExpRemoteValue as:

script.RegExpRemoteValue = {
  ? handle: script.Handle,
  ? internalId: script.InternalId,
} .and script.RegExpLocalValue

Reading the grammer, the map on the right-hand side of the assignment matches:

type1 = type2 [S (rangeop / annotator) S type2]
     / "#" "6" ["." headnumber] "(" S type S ")" ; note no space!
     / "#" "7" ["." headnumber]             ; note no space!
     / "#" DIGIT ["." uint]                ; major/ai
     / "#"                                 ; any
     / "~" S typename [genericarg]
     / "{" S group S "}"
     / "[" S group S "]"
     / "&" S "(" S group S ")"
     / "&" S groupname [genericarg]

That is "{" S group S "}". However, the only match that is allowed an annotator is type2 [S (rangeop / annotator) S type2], where type2 is defined as:

type2 = value
      / typename [genericarg]
      / "(" type ")"

which doesn't match the expression we've used to define the regex remote value. Further, it is not clear what is meant by .and script.RegExpLocalValue with this construction as that annotation isn't defined in either RFC 9682 or 8610.

We should update the spec so that we only contain conformant CDDL.

[OrKoN]

RFC 8610 gives the following examples as valid https://datatracker.ietf.org/doc/rfc8610/#:~:text=3.8.5.%20%20Control%20Operators%20.within%20and%20.and

3.8.5.  Control Operators .within and .and

   A ".and" control on a type indicates that the data item matches both
   the left-hand-side type and the type given as the right-hand side.
   (Formally, the resulting type is the intersection of the two types
   given.)

      "type1 .and type2"

[OrKoN]

I think also my understanding is that RegExpRemoteValue uses .and on two types and not groups.

[shs96c]

The grammar in the spec is pretty clear that the only legal combination is type2 [S (rangeop / annotator) S type2

TBF, the grammar in the original spec didn't cover the case of typename = ( group ) which is used extensively in the RFC and our spec.

Thanks for pointing me to the bit in the spec about .and. That's really helpful.

[tidoust]

Hmm, where do the grammar extracts you quoted come from, @shs96c? Looking at the grammar in RFC 9862 that you linked to, I see other definitions for type1 and type2:

type1 = type2 [S (rangeop / ctlop) S type2]
; space may be needed before the operator if type2 ends in a name

type2 = value
      / typename [genericarg]
      / "(" S type S ")"
      / "{" S group S "}"
      / "[" S group S "]"
      / "~" S typename [genericarg]
      / "&" S "(" S group S ")"
      / "&" S groupname [genericarg]
      / "#" "6" ["." head-number] "(" S type S ")"
      / "#" "7" ["." head-number]
      / "#" DIGIT ["." uint]                ; major/ai
      / "#"                                 ; any

I don't know if the right-hand side of the assignment is meaningful, but at least it seems to comply with the grammar defined in the RFC?