On Mon, Mar 21, 2022 at 07:01:39PM +0100, Laurence Lundblade wrote: > Let me try to be more clear. > > The COSE standard now is: > > kid => bstr > > If we make this change: > > kid => int / bstr > > then we break backwards compatibility for COSE as Mike pointed out today. So > we need a separate parameter called kid2, ckid, intkid or such. > > To not break backwards compatibility we need: > > intkid = int > > or: > > intkid = int / bstr > > (I don’t remember why an int kid was needed, but do remember I was convinced > that it was)
So, if you make it required that you have exactly one of 'kid' or 'intkid', you need signaling to know which one to use. If you have that signaling, it's not a huge stretch to instead use the signaling for "okay, 'kid' can be int now". There may be gaps, like group communication scenarios (but then you have to weaken "exactly one"), but it seems more interesting to explore those gaps than to just say there is breakage if you switch 'kid' to int. There is breakage if you just start sending something new and expecting people to understand it, too! To reiterate: if you want to roll out *anything* new, you need to have a deployment plan. So let's compare what the deployment plans look like for int 'kid' and 'intkid', rather than comparing apples to oranges. (It is probably also worth thinking about "you have at most one of 'kid' or 'intkid' and how things degrade if something would have benefited from 'kid' but actually got an 'intkid' that it doesn't understand.) -Ben _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
