Re: [Cbor] Working group last call on draft-ietf-cbor-packed

[Marco Tiloca <[e-mail]>]

Hi Carsten,

Thanks for addressing them, the PR looks good! I've just added two small 
comments inline in the PR.

Best,
/Marco

On 2022-05-18 00:26, Carsten Bormann wrote:
> Hi Marco,
>
> thank you for your comments!
>
> I have created a pull request that should address them:
>
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcbor-wg%2Fcbor-packed%2Fpull%2F4&data=05%7C01%7Cmarco.tiloca%40ri.se%7C9d6ad5c970744ee0867308da385472bf%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637884232604758227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AxEI0zwNoQGXuf6nN9oxB7VeXRWldxt8tuvU%2Fq%2BEylo%3D&reserved=0
>
> Comments, suggestions, further PRs :-) welcome.
>
> Grüße, Carsten
>
>
>> [Section 2.3]
>>
>> * It can be confusing to see "suffix" in Table 2 and "prefix" in Table 3 used as tag content. I think it's better to have something like "Tag XXX(prefixed rump)" for the entries in Table 2, and "Tag XXX-YYY(suffixed rump)" for the entries in Table 3.
>>
>> * "For a rump of type array and map, the affix also needs to be an array or a map."
>>
>>     It's better if it is explicitly spelled out, to not mix arrays and map. That is: "For a rump of type array, the affix also needs to be an array. For a rump of type map, the affix also needs to be a map."
>>
>> * "For an array, the elements from the prefix are prepended to the rump array, while the elements from a suffix are appended."
>>
>>     I suppose you mean "For an array, the elements from a prefix are prepended to those of the rump, while the elements from a suffix are appended to those of the rump." Correct?
>>
>> * The example include  224("art"), 225("obart")
>>
>>     As per Table 2 and the considered prefix table, shouldn't this rather be  225("art"), 226("obart")  ?
>>
>> * It would be good to have one or two examples where the rump and the affix are strings of different types.
>>
>>
>> [Section 3]
>>
>> * "By one or more tags enclosing the packed content. These can be defined to add to the packing tables that already apply to the tag."
>>
>>     Which tag? Do you mean "apply to the packed content" (regardless of how the tables have been possibly populated already)? Or do you mean any other present and already processed tag?
>>
>> * "Usually, the semantics of the tag will be to prepend items to one of the tables."
>>
>>     Based on the following paragraph and Section 3.1, it is rightly expected that the specification and registration of such a tag specify the semantics for extending the packing tables. I think it's worth making the requirement explicit.
>>
>>
>> [Section 3.1]
>>
>> * The last paragraph seems to generally apply when relying on a tag for packing table setup with prepending semantics.
>>
>>     Since Section 3.0 refers to that semantics as the most expected one, it can be good to have these considerations already in the second bullet point of Section 3.0.
>>
>>
>> [Section 4]
>>
>> * It's useful to have one subsection per registry.
>>
>> * Shouldn't the tag 51 defined in Section 3.1 also be registered?
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se