I’m fine with A, but I’d like this to be the definition of it: When a kid is an integer it is not a separate kid space, but rather a compact alternate encoding of some one-byte kid values. The one-byte kid values 0x00 through 0x30 may be encoded either as h’00’ through h’30’ or as the integers -24 through 23. That is, a one-byte kid is converted to an integer by subtracting 24 from it, putting on the wire as an integer and turned back into a byte string kid by adding 24.
Integer encoding is only permitted for single-byte kid’s between 0x00 to 0x30. (There is no encoding advantage for other kid values) The point of the integer kid encoding is to service a particular use case where saving one by in the encoded kid is worth while. The integer kids will encode in one byte where as the byte strings of length one encode in two bytes. It is advantageous to the COSE SW stacks, COSE APIs and COSE key databases that the integer-encoded kid not be a separate space from the byte-string encoded kids. If it is a separate space then the stacks, APIS and databases much carry a tag along side with the kid to indicate which kid space it is from. LL > On Mar 23, 2022, at 7:00 AM, Carsten Bormann <[email protected]> wrote: > > On 22. Mar 2022, at 09:42, Göran Selander > <[email protected]> wrote: >> >>> I’d like to ask those who are proposing kid => int / bytes: are the two >>> kid name spaces disjoint >> >> Yes. An integer kid is considered different from a byte string kid. > > OK. Is this a deliberate decision or did you consider making integers > synonyms for certain byte strings? > > (My proposal uses them as synonyms for certain two-byte strings. This > actually increases the surface of short identifiers as much as keeping them > separate does.) > > Grüße, Carsten > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
