Re: [Cbor] Packed CBOR review

[Carsten Bormann <[e-mail]>]

> 
> 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])
Etc.
But stacking the tags (and spending another array) costs three more bytes.

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.)

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

(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?

Grüße, Carsten