Re: [Cbor] Packed CBOR review

[Henk Birkholz <[e-mail]>]

Hi Brendan,

quick reply with an upfront, overall +1. Small comments in-line

On 17.06.21 11:08, Brendan Moran wrote:
> 
>> On 16 Jun 2021, at 14:07, Carsten Bormann <[e-mail]> wrote:
>>
>> On 2021-06-16, at 11:21, Brendan Moran <[e-mail]> wrote:
>>>
>>> I would also propose adding another element to the table: an identifier for a pre-shared reference table:
>>
>> I’m wondering what the allocation mechanics for such an identifier would be.
> 
> We can have our cake and eat it too. I don’t see a reason not to support all of these choices.

That sounds absolutely reasonable to me!

> 
>>
>> Let me go through a few cases and explain how I would handle it.
>>
>> * IANA
>>
>> Pro: can be very compact.
>> Con (pro as well): high threshold, limited set.
>>
>> Solution: allocate a tag for the identifier, either wrapping a tag 51 or replacing it (in particular if not all tables need to be advanced).
>>
>> Task: We probably should define how to define such a tag.
>>
>> * Context
>>
>> Pro: can be embedded nicely.
>> Con: Wherever the context comes from (e.g., referencing standard) needs to make sure the reference is unambiguous.
>>
>> Task: Not sure what we can do here, except maybe giving an example.
>>
>> * URI
>>
>> Pro: Free for all.
>> Con: Hard to control.
>>
>> There will need to be some security and assurance of non-mutability on the data that URI describes.
>> Preferred URI scheme would be ni:, but see next.
Henk
>>
>> Task: Define URI import tag; shape of data structure that should be used (almost, but not entirely, like tag 51).
>>
>> * Hash
>>
>> Pro: No-brainer
>> Con: Can’t find the dictionary unless I already know it.
>> Hashes are large (at least when secure).
>>
>> Task:
>> Define Hash import tag, shape of data structure that is being hashed (see above).
>>
> 
> 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
> 

Semantics look fine, not sure of the final structure though.

> 
>> 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]]
> 
> 2) eliminate any distinction between the different tables; leave that to the packing table.
> 
> Packed-CBOR-Dictionary = [?reference, [*fragment]]
> 
> For simplicity in the parser, I’d be inclined to go with option 1 and just make the Packed-CBOR-Dictionary a packing table with no rump.

We are really optimizing for bytes here, right? That should be 
significant decision factor. Then again, a tad bit more hierarchy here 
might provide great benefits?

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


Viele Grüße,

Henk

> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor
>