Re: [Cbor] tag optionality and dCBOR

[Laurence Lundblade <[e-mail]>]

I like the distinction between deterministic serialization and deterministic representation.

No complaints about having text that discusses tag use for deterministic representation but it might be better in section 5 as the title of section 4 is “Serialization Considerations”.

LL



> On Mar 7, 2023, at 10:01 AM, Carsten Bormann <[e-mail]> wrote:
> 
> 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
>