Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126

[Carsten Bormann <[e-mail]>]

Hi Laurence,

CDDL does not describe behavior, but the shape of data.

> Maybe a key question here is whether you can say in CDDL “this next item must always be interpreted as a date even though it will never have a date tag”.

CDDL can say “this item is a number”.  It does not tell you how to “interpret” things, that would be the job of a language that transforms the data just received into data that is used by an application.

> If CDDL doesn’t have than, then you can’t describe some CBOR-protocols with it.

You sure can “describe” the shape of data in CBOR protocols, but you will also need some information about how you plan to interpret the data.

> CWT would be one of those protocols as it forbids adding the tag to dates.

(For the exp, nbf, and iat claims, or claim numbers 4 to 6:) Yes, the CWT RFC (RFC 8392) tells you that the value here is a number, not a tagged date.

> The designer of a protocol using a new data type will indicate in their protocol for each occurrence of it whether the tag must be present or not (never saying the tag may or may not be present). The designer will typically require the tag only when necessary to disambiguate the type of the data item.

Right.  If you need to register for CWT a new claim that could either take a number (such as the longitude of the satellite that this claim is about) or a date/time (such as the time the satellite was launched), then a tag could be useful to make that distinction.  

That example is a bit contrived, because it’s just not as usual to have a choice between a number and a date.  More likely might be a choice between a date/time represented as a Tag 1 and a Tag 1001.  The encoding could choose to leave off the tag from the number that is the enclosed item of Tag 1, so you would have a choice between a number and a Tag 1001.

> The implementor of a general purpose library to generate one of these new data item types must give the caller the option to include or not include the tag. Maybe this is just by never automatically outputting the tag and having a distinct output tag function.
> 
> The implementor of a general purpose library to decode one of these new data types must allow the caller to say that the next data item should be decoded as this new data type whether or not it is tagged. Maybe it even errors out if it is tagged for the cases where the protocol document says no tag should be used.

Right.

> What I don’t know is whether CDDL can describe all this desired behavior.

CDDL can describe the shape of the data interchanged, but it can’t describe the mapping to application semantics.  It can provide hints, and that’s one of the things that the unwrap operator is good for: When you apply it to a tag, this is a hint that you do not just want the data shape of that tag’d enclosed item, but also its semantics.

Grüße, Carsten