[Rats] Re: CBOR tag-identified subordinates in EAT and CMW

[Carl Wallace <[e-mail]>]

Inline...

On 10/8/24, 9:16 AM, "Thomas Fossati" <[e-mail] <mailto:[e-mail]>> wrote:


hi Laurence,


On Mon, 7 Oct 2024 at 21:31, lgl island-resort.com
<[e-mail] <mailto:[e-mail]>> wrote:
> [snip]
>
> EAT should probably say “the contents of $EAT-CBOR-Tagged-Token MUST
> be a CBOR tag”, but it doesn’t. We maybe should fix that before EAT
> publication.

[CW] Initially, I was wondering if the syntax from CMW should be adopted along the prose you suggest (since that would put CDDL teeth behind it) but I am not sure, as described below.

If you are on it, maybe also a small typographical fix:
s/$EAT-CBOR-Tagged-Token/$CBOR-Tagged-Token/
since the CBOR-tagged token is not necessarily itself a EAT.

[CW] This seems reasonable.

> EAT chose to bstr wrap to allow for easier decoding implementations.
> An advantage of bstr-wrapping something is that you can skip over it
> if you don’t know what its format is. That’s kind of important for
> plug-in formats.
>
> CMW sort of defines the socket $cbor-tag for this
>
> cbor-CMW = cbor-record / cbor-collection / $cbor-tag
> cbor-tag<tn, $fmt> = #6.<tn>(bytes .cbor $fmt)
>
> Three comments:
>
> 1) Is the plug-in socket $fmt or $cbor-tag? I don’t think this CDDL
> will validate because $cbor-tag is not the same as cbor-tag.


No, this is valid CDDL: $cbor-tag (the socket) is implemented by (the
generic) cbor-tag<tn, $fmt>

[CW] I think naming fmt with a $ prefix is confusing. It's not a type socket, it's just a parameter for that macro definition.

For example, the following flips a coin to decide whether to create a
CBOR-based or "native" (i.e., bstr-wrapped binary blob) format:

```sh
cat << 'EOF' | cddl - g 1


start = $cbor-tag

[CW] Similarly naming a socket "$cbor-tag" and a macro "cbor-tag" is a bit confusing. There's still nothing that compels one to only stuff CBOR tags into $cbor-tag though the common naming creates that impression.

$cbor-tag /= cbor-tag<1668576819, cbor-thing>
$cbor-tag /= cbor-tag<1668576818, non-cbor-thing>

cbor-tag<tn, $fmt> = #6.<tn>(bytes .cbor $fmt)

[CW] The .cbor control "indicates that the byte string carries a CBOR-encoded data item." The "non-cbor-thing" type passed as $fmt suggests the type is not CBOR encoded. How can that be used with the .cbor control? We need a means of tagging non-CBOR encoded stuff (for example, DER encoded data). Maybe we need a pair of definitions:

	cbor-tagged-cbor<tn, fmt> = #6.<tn>(bytes .cbor fmt)
	cbor-tagged-data<tn> = #6.<tn>(bytes)

[CW] This could be coupled with the addition of some MUST statement a la what Laurence proposed for EAT to require only CBOR tags be used with the $cbor-tag socket.

cbor-thing = bstr


non-cbor-thing = {
&(eat_nonce: 10) => bstr .size (8..64)
}


EOF
```

<snip>

> 3) The bstr wrapping should be of the combination of tag number and
> tag content. The way it is written now, it is mandating that the
> content of a subordinate token must be a bstr. That won’t work for
> UCCS, because its tag content is a map.

[CW] If non-CBOR is handled separately, then the cbor-tagged-cbor could be simplified to:

	cbor-tagged-cbor<tn, fmt> = #6.<tn>(fmt) 

This is working as intended: in CBOR tag-based CMWs using TN(), the tag
content is consistently a bstr. The CMW "frontend" removes the bstr
header and the "real" message buffer is dispatched to the type-specific
decoder based on the tag number.

[CW] Handling CBOR types this way is fine too, of course.

Note that CBOR-Token-Inside-CBOR-Token is also making the choice of
requiring bstr-wrapping, though there is no outer typing information
which makes the situation is a bit more shaky. (One may argue that the
types can be derived from the outer eat_profile, but there are still
potentially ambiguous cases. So, I think it's safer to fix EAT and
require a tag when plugging into that socket as you said above.)


Going back to CMW, that's the processing required for TN()-derived
tags. For UCCS (which already defines its own), Section 3.2.1 applies,
i.e.: if you have a tag already no extra tagging is needed. I think the
bug here is that Section 3.2.1 does not provide its own CDDL snippet for
the complementary set of CBOR tags (i.e., those that aren't
TN()-derived.)

[CW] I'm not quite sure what you mean here unless you mean avoiding the bstr wrapper around CBOR types.

<snip>