Thinking about Mike’s comment today in COSE/Vienna about backwards compatibility. Looked at my code around this. That definitely seems like an issue.
What about defining “kid2” as just int? “kid” stays as bstr only. Then there’s no backwards compatibility break. Adding support for another integer parameter isn’t difficult. The downside is a little extra code to look at two different parameters. You’d probably want to say that only one of the two kids MUST be present. Another random idea — could you say that it is allowed to translate an integer kid to a bstr kid by assuming network byte order and stripping leading zeros? LL > On Aug 13, 2021, at 3:01 AM, Laurence Lundblade <l...@island-resort.com> > wrote: > > Understood about the use case. Thx for the background. > >> On Aug 10, 2021, at 3:13 AM, Göran Selander >> <goran.selander=40ericsson....@dmarc.ietf.org >> <mailto:goran.selander=40ericsson....@dmarc.ietf.org>> wrote: >> >> Assume that we do want to allow key identifiers to be CBOR ints in certain >> settings, what is the best (least intrusive) way to allow this while still >> maintain compatibility with 'kid's supporting the type bstr? Another >> alternative to what has been listed below is to define 'kid2' to only be of >> type int - is that a better option? > > I didn’t write actual code to check, but they about the same to me. > > ‘kid' as int/bstr seems less confusing to me than ‘kid2’. It tells you it > does exactly the same thing whether it is an int or a bstr. > > So my pick is ‘kid’, but ‘kid2’ is OK too. > > LL
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
