Re: [Cbor] Packed CBOR review

[Brendan Moran <[e-mail]>]

> On 17 Jun 2021, at 10:24, Carsten Bormann <[e-mail]> wrote:
>
>>
>> We can have our cake and eat it too. I don’t see a reason not to support all of these choices.
>
> Absolutely — we then just need to design how each of these choices should look like.
>
>> If we simply use a different type in each case, the encoding is unambiguous:
>>
>> Basic-Packed-CBOR = #6.51([ ?dictionary-reference, [*shared], [*prefix], [*suffix], rump])
>> rump = any
>> prefix = any
>> suffix = any
>> shared = any
>>
>> dictionary-reference /= standard-reference
>> dictionary-reference /= uri-reference
>> dictionary-reference /= hash-reference
>> dictionary-reference /= context-reference
>>
>> standard-reference = uint
>> uri-reference = tstr
>> hash-reference = bstr
>> context-reference = null
>
> I think I’d rather have
>
> Table-Setup-Uri = #6.52([Uri-reference, any])

This only costs us a tag definition and it simplifies parsing. This is probably correct.

> Etc.
> But stacking the tags (and spending another array) costs three more bytes.

I think this decision depends a lot on what the expected model is. For a single dictionary reference, it’s pretty irrelevant, so we should pick whichever is more idiomatic. The issue is when your reference wants a reference.  For example, suppose I have two reference tables that share a lot of values: Table A and Table B. With stacking tags, I am forced to make a tradeoff: either duplicate data on the endpoint or increase the size of the transmitted data:

If Table A and Table B contain duplicate data:
Data-A = 52([“Table A”, …])

If Table C contains the common parts of Tables A and B:

Data-A = 52([“Table C”, 52([“Table A”, …])])

If every table is allowed to define a reference, this problem disappears, however it creates a new one: a compressor cannot select an arbitrary set of tables known by the decompressor and compose them in the optimal order.

>
> But maybe that stacking is most useful for
> Spiffy-Standard-A-Table-Setup = #6.4711(any)
> Where 4711 is a tag allocated by spiffy standard A.
> (Otherwise we’d need a separate registry for that uint, and that makes me shudder.)
>
> In any case, stacking would allow stacking a couple standard references.
>
> How would the hash reference specify the algorithm?
> (I think CFRG would tell us that collision resistance between algorithms isn’t a well-defined property.)

We could possibly reuse SUIT digest definitions for this:
suit-digest = [algorithm-id : uint, digest: bstr]

If we use a second tag for the reference table setup, this is unambiguous.

Alternatively, cbor-wg or cose-wg could define tags for common digest algorithms.

>
> I’m also not sure that a context-reference always is null, maybe the context supplies alternate tables…

If that is the case, I suspect a context-reference should have its own tag as well.

>
> (I’m always a little put off by optional array elements in a sequence, that gets into actual parsing quickly, but this one here may be OK.)
>
>>> Apparently, in all cases it would be good to have a single data structure shape pre-defined for pre-populating the tables (“dictionary”).
>>
>> I can see two possibilities here:
>>
>> 1) just use the existing structure:
>>
>> Packed-CBOR-Dictionary = [ ?reference, [*shared], [*prefix], [*suffix]]
>
> Probably.
> Should that get a tag?

I don’t think it needs one, but feel free to convince me otherwise. Its use should always be explicit since it’s always known by a compressor or decompressor. It should always be in a map of reference/table pairs.

Best Regards,
Brendan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.