RFC 8610 section 3.8.4 defines `.cbor`/`.cborseq` as control operators asserting that a `bstr`, once parsed as CBOR (or a sequence of CBOR items), matches the given type. This is the standard way to describe a byte string containing nested CBOR-encoded data -- exactly how COSE (RFC 9052) describes a `COSE_Sign1`'s protected header or payload field, for instance.
Neither operator is in `OPERATORS`/`OPERATORS_EXPECTING_VALUES` in `packages/cddl/src/parser.ts` today. `bstr .cbor sometype` currently crashes the parser (via the same underlying issue as #87 -- an unguarded `parseOperator()` call -- once #88 is merged it'll instead hit "expects a X property" from the operator not being recognised at all, rather than parsing).
I have a small patch (just the two operator-table additions, no new parsing logic needed since the operator's value is a plain type reference, which `parseOperator` already handles generically) and I'll open a PR.
RFC 8610 section 3.8.4 defines `.cbor`/`.cborseq` as control operators asserting that a `bstr`, once parsed as CBOR (or a sequence of CBOR items), matches the given type. This is the standard way to describe a byte string containing nested CBOR-encoded data -- exactly how COSE (RFC 9052) describes a `COSE_Sign1`'s protected header or payload field, for instance.
Neither operator is in `OPERATORS`/`OPERATORS_EXPECTING_VALUES` in `packages/cddl/src/parser.ts` today. `bstr .cbor sometype` currently crashes the parser (via the same underlying issue as #87 -- an unguarded `parseOperator()` call -- once #88 is merged it'll instead hit "expects a X property" from the operator not being recognised at all, rather than parsing).
I have a small patch (just the two operator-table additions, no new parsing logic needed since the operator's value is a plain type reference, which `parseOperator` already handles generically) and I'll open a PR.