> 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. Just to be clear on the source. This proposal is based on a previous conclusion on the COSE mailing list considering different solutions: Solution A. kid => int / bytes Solution B. kid => bytes kid2 => int / bytes Solution C. kid => bytes kid2 => int In this previous discussion (see first part of this thread [1]) there was a mild preference for A. We can revisit this now, but it is good if people participating in the discussion are aware of the arguments made previously. Göran [1] https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/ From: Carsten Bormann <[email protected]> Date: Tuesday, 22 March 2022 at 00:00 To: Michael Richardson <[email protected]> Cc: Laurence Lundblade <[email protected]>, Orie Steele <[email protected]>, Göran Selander <[email protected]>, [email protected] <[email protected]> Subject: Re: [COSE] Key identifier of type bstr / int On 21. Mar 2022, at 23:20, Michael Richardson <[email protected]> wrote: > >> kid => int / bstr > > It's one of the features of CBOR, as a self-describing format, that we can > introduce new ways to do things. Indeed. So this is obviously an extension. Old implementations can’t use the new data items enabled by that extension. New implementations don’t have problems with old data items, so we call this backwards compatible, but not forward compatible. We didn’t identify this as an extension point, so the lack of forward compatibility is likely to be universal — if you use an integer kid, old systems overwhelmingly will not understand you. Now, there is also API compatibility — can you upgrade the COSE library without upgrading the using application. I’d like to ask those who are proposing kid => int / bytes: are the two kid name spaces disjoint (so you need an API extension, too), or is an integer kid just a way to express the same kid as was already possible to express using a byte string kid. Another way to say the latter is that all kids are byte strings and the integer representation is just a compressed way to express such a byte string. Obviously, the latter way to interpret kids is slightly less efficient, because there are now two ways to express certain kids. But the change is also local, i.e. you can do it in your library without changing anything else. If we go for the latter, we will want to make sure that in particular the integers -24..23 map to useful byte strings and v.v. Note that there is no need to make these byte strings short; e.g., a decimal representation (‘-24’ to ‘-1’ and ‘0' to ’23’ in CBOR DN), or maybe an octal one (’50’ to ’77’ and ’00’ to ’27’) would work well. We don’t even need to support integers outside -24..23. Grüße, Carsten
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
