Re: [Cbor] tag optionality and dCBOR

[Carsten Bormann <[e-mail]>]

On 2023-03-07, at 18:42, Laurence Lundblade <[e-mail]> wrote:
> 
> Section 4.2 of 8949 discussed tags in relation to deterministic encoding and around 5 minutes into the dCBOR video this is discussed.
> 
> I’d like to drive a wedge between serialization variability (e.g. integer lengths, map sorting) and tag optionality and would like there to be no requirements in dCBOR around tag optionality. I think tag optionality is a protocol/application design characteristic.

Indeed.  Section 4.2 really talks about different ways an application may represent something (using the presence or absence of tag 1 as an example).
Since we did have protocols that considered representing the same information  both with and without a tag, the text is quite useful to recommend against this practice.

If your application likes representing today as 1678212055 and 1(1678212055) half of the time each, or the number 1 as integer 1 and float 1.0 half of the time each, you have a deterministic encoding issue.  That is not a CBOR problem.  But CBOR gives you the tools to make that difference, and if the application jitters about uncontrollably, that’s a problem.  The text might have been a bit shorted by just saying “folks, deterministic representation is not just a representation format layer problem, your application also needs to play”.

> This is a little bit of a round about way to highlight this — A protocol that sends three integers (e.g. red, green and blue for a pixel) could use an array where red is first, green is second and blue is third. Or it could use a map and label the three integers. I expect dCBOR to be completely silent on this choice. It’s an application/protocol design issue with nothing to do with serialization variability.

No, but with deterministic representation.  See above.

> I think the choice of whether to identify items in a protocol/application by tag is of the same nature.

Yes.

> I also think that discussion of tag optionality should probably not be in section 4 of 8949. It’s not really a related to serialization.

It is the example we were using because there were protocols around that were just about to make this mistake.

Grüße, Carsten